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

[Eric Rosen <[e-mail]>]

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

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

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.  

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