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

[Thomas Nadeau <[e-mail]>]

On Jul 23, 2012:5:04 PM, at 5:04 PM, Eric Rosen <[e-mail]> wrote:

> 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.

	Just following up on some old emails and I noticed this one.   I am not sure if you recall, but this was discussed when we originally presented the draft (something like 2+ years ago).  In effect that is what we are saying with the draft. Since BFD Hellos are used to maintain liveliness now in most implementations, the hellos that are sent after the sessions are established are superfluous. Perhaps too much emphasis was placed on the security aspects versus the optimization nature of the solution, but that is the general idea. A side-effect are the potential security benefits.   

	Keep in mind too that when this was discussed originally, we did ask the WG whether or not to take Luca's suggestion of re-writing the LDP spec to fix this and a few other issues or just do this simple optimization; the guidance we received was to take the optimization route on this one as it seemed simple, quick and effective.

	--Tom



> 
> 
> 
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>