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

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

Pls refer my answers inline.

-----Original Message-----
From: Eric Rosen [mailto:[e-mail]] 
Sent: Tuesday, July 24, 2012 9:37 AM
To: Dutta, Pranjal K (Pranjal)
Cc: [e-mail]; 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

> Although the draft re-uses the Hello negotiation method as in RFC 5036, it
> does define procedures for reduction (section 4).

I think the only thing that is new is the idea of configuring two hold
times, one to be used before the session is established and one (infinite)
to be used after.

[Pranjal] Yes that is correct. It describes RECOMMENDED procedures for hello reduction. [/Pranjal]

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

The fact that the session is established does not provide authentication or
integrity for the Hellos.  There is no way to know that any particular
received Hello originated from the trusted peer, or that it has not been
modified, or that it is not a replay of an earlier Hello.  That is, the
security problems with Targeted Hellos are not mitigated by the fact that
the LDP session is secured.  So even after the session is established,
spoofed Hellos can be used to trick the two peers into using different hold
times.

[Pranjal] Yes, agreed. That's where the applicability of ldp-crypto-auth comes in. But still we can't provide resilience of spurious attacks from 
non-trusted sources that may destabilize the authenticated existing hello adjacencies. We can definitely insert a full fledged firewall inside a LDP LSR so that Utopia prevails but we may not like to do that in all types of implementations (systems) where cost vs. gain factor is low. The solution is targeted towards providing probabilistically better resilience, no matter whether the spoofed packets carry bad UDP payload or Good authenticated packet etc (take any case of spoofing). [/Pranjal] 

Bad parameters specified in a received spoofed Hello will eventually get
overwritten by the good parameters specified in the next received authentic
Hello.  Thus the less frequent the authentic Hellos are, the longer it will
take before the bad parameter is overwritten with the good parameter.  

[Pranjal] I have responded on this to Lizhong's earlier question. IMO, we are probably questioning here more on RFC 5036. There is no limit on hello hold time as per RFC 5036. When there is a change in parameter, the change needs to be reflected to peers with "best effort". Some implementations do today by sending a set of hellos within shorted intervals (e.g 5) after a 
parameter change. But what if those 5 hellos are lost (means the hello channel is unreliable enough to loss of contiguous 5 packets or spurious attacks on receiver dropped those packets). If it so happens then perhaps it would result in loss of hello adjacency. I

[/Pranjal]

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

The draft seems to recommend the use of "hello reduction" with infinite hold
time.  If there are situations in which this is not a good idea, the draft
should describe those.

[Pranjal] Yes, we would address the uses cases where precautions are necessary to deploy the solution. [/Pranjal]