Re: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

[Eric Rosen <[e-mail]>]

Pranjal> This draft does not change or violate procedures defined in RFC
Pranjal> 5036. It proposes an OPTIONAL method of reduction of "targeted'
Pranjal> hellos (only - as the name of the draft suggests) and the proposed
Pranjal> method is backward compatible with procedures defined in RFC
Pranjal> 5036. The method uses the hello timeout negotiation procedures as
Pranjal> per RFC 5036 without any changes in negotiation procedures.

If the draft does not change any of the procedures specified in RFC 5036,
and does not define any new procedures or messages either, then why is the
draft marked as "standards track"?  At best it would be "Informational".
But are you saying that all the draft really does is to suggest that a
particular parameter be set to a particular value?  That doesn't seem like
very much content.

Pranjal> The reduction of hellos provides probabilistically better
Pranjal> resiliency on maintenance of hello adjacency during sporadic DoS
Pranjal> attacks. Sporadic DoS attacks on UDP port 646 can result in loss of
Pranjal> "good" hello packets for certain period of time and thus leading to
Pranjal> loss of existing adjacencies.

If an attacker can send you UDP packets on port 646, why doesn't he make
them look like Hello packets specifying a short hold time?  That's a much
more effective attack than a "sporadic DoS attack".  In fact, if real Hellos
are not being sent at all, it just becomes easier to mount an attack with a
spoofed Hello.  An attacker could send a spoofed Hello with a hold time of 3
days, and the session would stay up for a few days and then fail
mysteriously, for no apparent reason.  An attack whose effects are not felt
until days later can be quite hard to deal with.  When the Hellos are sent
periodically, on the other hand, there is a self-correction mechanism that
prevents this.

If you want to reduce the targeted Hello load, it might be better to invent
a way (i.e., a protocol change) of turning them off entirely after the
session comes up, so that arriving Hellos are just discarded.  (

BTW, the draft asserts that the periodic Hellos have no value that is not
better served by either BFD or the LDP session keepalives.  I don't know
whether that's true, but it would be nice to see an argument with a little
more substance.