The MPLS WG Archive

[Albert Tian <tian@redback.com>]

Hi, Alex,

These are very good suggestions. We will add more text on making the hello more
secure as well as analyzing the risks of spoofed hellos.

Thanks,

Albert


Alex Zinin wrote:
> 
> A more elaborate version of the comment I made at the mic today:
> 
> The draft uses the LDP Hello message to negotiate enabling of the TTL
> check. Though the draft says that only Link Hellos (T=0) should be
> used for this, it does not say anything about securing those Hellos.
> Neither RFC3036 nor the draft _require_ the receiving LSR to drop Link
> Hellos that are sent to an address other than the AllRouters multicast
> (e.g. an LSR's unicast address). So if a spoofed Link Hello is
> accepted, the receiver may mistakenly apply the TTL check to a session
> with a peer that does not support it, and hence prevent it from coming
> up. Similarly, if a Hello without the new parameter is spoofed, the
> attacker may cause the LSR to disable the check and mount a
> overloading DoS attack against an existing session.
> 
> I would suggest that the draft is modified to recommend that Link
> Hellos (with or without the new optional parameter) MUST be sent to
> the unroutable AllRouters multicast address and MUST be dropped by the
> receiver if they are not. This should make the Link Hellos at least as
> secure as the session packets.
> 
> The Security Consideration section should also be extended to describe
> the potential Link Hello spoofing attack possible by an on-the-wire
> adversary, and then point out that given the current network
> operational practices, the risk of such exposure is considered to be
> sufficiently low.
> 
> --
> Alex