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

["Dutta, Pranjal K (Pranjal)" <[e-mail]>]

Please find my answers further inline.

-----Original Message-----
From: Eric Rosen [mailto:[e-mail]] 
Sent: Monday, July 23, 2012 2:04 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Markus Jork; Giles Heron; Thomas Nadeau; [e-mail]; VIGOUREUX, MARTIN (MARTIN); [e-mail]
Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-tldp-hello-reduce-03

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 version 00 was informational. It was made to standards track as per feedback received from WG IETF-SFO. Although the draft re-uses the 
Hello negotiation method as in RFC 5036, it does define procedures for 
reduction (section 4). I am OK if majority votes for Informatonal.
[/Pranjal]

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.  

[Pranjal] When I said UDP packets in port 646 it was not meant to be non-Hello packets - it was meant to be any packet in port 646 that includes LDP Hello Packet (parser won't say bad_msg) or any garnage UDP payload. Sporadic floods of good LDP Hellos are tantamount to DoS attack. If such a flood comes from an "existing" adjacency then one solution could be rate limiting on existing adjacencies (there are several established techniques). If an implementation doesn't have such techniques (e.g h/w assisted) then it is possible that such attacks from one peer may bring down other adjacencies, if the hold time of other adjacencies are relatively small. The draft does not claim as solution for DoS prevention but for probabilistically better resilience on sporadic attacks. [/Pranjal]


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.

[Pranjal] Could you elaborate in more details what self-correction means in this context? If we read the section 4, it mentions that Hello Reduction starts only after a LDP session is ESTABLISHED. There are additional well known security methods to secure LDP session (e.g TCP MD5). Do you mean to say that a peer to which we may be running a trusted LDP session can be 
considered as spoof? Well, nobody can prevent a trusted peer not to do spoofing with hellos (hide-and-seek), if the peer administration decided to do so but the draft doesn't claim solution for such spoofing. If there is 
a trusted peer and hello reduction procedures set the holdtime as 3 days
And the session is lost then hello reduction terminates immediately. This 
Is mentioned clearly in point 4 in section 4. Then I don't see your point 
how a spoofed hello adjacency stays up for 3 days. 



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

[Pranjal] We may not like to do that due to backward compatibility with RFC 5036, unless we say that T-LDP Hellos are deprecated. However, I think there are vendor implementations (at least one vendor I am aware of) that does LDP session protection with T-LDP hellos while link adjacencies to same peer may get lost for a short window. Thus it may not be a sound approach to get rid of T-LDP Hellos. [/Pranjal].

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.

[Pranjal] It depends on case by case. If LDP session transport address is 
different from IP addresses used for T-LDP hellos then Session Keepalives are not substitute. But if we want to use protocols like BFD for fast tracking reachability of T-LDP IPs (there are other protocols as well) then Hellos are redundant. If any Hello param are changed during the life time 
of a adjacency then hellos can be exchanged immediately to reflect the change keeping reduced hold time intact and draft does not prevent it from doing so (corrective action). I would like to hear opposing side of the argument that claims the period fast T-LDP hellos are mandatory for proper functioning of LDP as a protocol and need to quantify the "fastness".  [/Pranjal]