Re: [mpls] [MPLS] HELP: Need your opinion on LDP security

[[e-mail]]

Hi Mach,
Yes, I think it is it is reasonable to bring down the session, if operator 
wants to change the hello parameter after the session is already setup. 
Anyway, need more comments from operators.

Thanks.
Lizhong
 

Mach Chen <[e-mail]> wrote on 2010-10-28 20:13:28:

> Hi Lizhong,
> 
> If allowing operators to change parameters, the potential attackers also 
can 
> change it by sending spoofing hellos, then security threat is there.
> 
> If changing hello parameters can not tear an existing LDP session, how 
do 
> the operators make the changes to take effect?  I guess you probably 
have to 
> disable all relevant configuration, then change the parameters, 
afterward 
> enable again. IMHO, this is not what the operators want.
> 
> In addition, normally, changing hold time will not tear down the 
existing 
> session and is natural thing.
> 
> Best regards,
> Mach
> 
> 
> --------------------------------------------------
> From: <[e-mail]>
> Sent: Thursday, October 28, 2010 6:59 PM
> To: <[e-mail]>; <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>
> Subject: Re: [mpls] [MPLS] HELP: Need your opinion on LDP security
> 
> > Hi Mach,
> > LDP Hello's function is to establish session and keepalive. After 
session
> > is established, node should not be allowed to change hold time or
> > transport address dynamically (although not explicitly said in 
RFC5036).
> > If operator wants to change the hello hold time, it is reasonable to 
bring
> > down the session.
> > If we do not allow hello parameters to be changed dynamically (that's 
easy
> > to implement), is there any other security threat?
> >
> > Thanks
> > Lizhong
> >
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 2
> >> Date: Wed, 27 Oct 2010 11:40:18 -0400
> >> From: Eric Rosen <[e-mail]>
> >> Subject: Re: [mpls] [MPLS] HELP: Need your opinion on LDP security
> >> To: Mach Chen <[e-mail]>
> >> Cc: [e-mail], Lamberto Sterling <[e-mail]>
> >> Message-ID: <8822.1288194018@erosen-linux>
> >>
> >>
> >> > if there is no hello authentication,  an established LDP session 
can
> > be
> >> > torn down by a spoofing Hello with a smaller Hold Time interval
> > ordifferent
> >> > Transport Address.
> >>
> >> Do you think we really need replay protection to protect against 
this?
> > To
> >> exploit this vulnerability with a replay attack, an attacker would 
have
> > to
> >> wait patiently until a router is reconfigured with a longer hold time
> > and
> >> hello interval, and then replay that router's old hellos.  This would 
be
> > a
> >> very sophisticated attack.
> >>
> >> If we do want router R1 to be able to discard replays of old Hellos 
from
> >> router R2, I don't think the proposed mechanism is adequate.  At any
> > moment
> >> when R1 does not have a Hello adjacency to R2, the replays of R2's 
old
> >> packets would be acceptable to R1, unless the shared secret has 
changed.
> >> For targeted LDP Hellos, it might be better to have each peer include
> >> something it learned from the other peer's recent Hellos.  E.g., R2
> > could
> >> include in its Hello the sequence number from R1's most recent Hello.
> > Then
> >> R1 could easily distinguish recently generated R2-Hellos from 
replayed
> >> R2-Hellos, and it wouldn't have to know anything about R2's hello
> > interval
> >> or sequence number selection algorithm.  (A few details to be worked
> > out.)
> >> Of course, something like this wouldn't work on a LAN, but the LAN
> >> environment is not where the vulnerability is.
> >>
> >> I am also curious as to why your proposal does not include the IP 
source
> > and
> >> destination addresses, or the transport (UDP) header, in the hash. 
Most
> >> similar proposals seem to do so, but I don't understand all the 
security
> >> issues well enough to know whether that is required or desirable in 
this
> >> case.
> >>
> >> Frankly, I don't think there is enough security expertise on this
> > mailing
> >> list to be able to properly a security proposal of this sort.  If the 
WG
> >> decides to pursue the issue of LDP Hello authentication, the chairs
> > should
> >> ask the Security ADs to assign a security advisor.  But then we'd
> > probably
> >> be told that this work conflicts with the KARP WG ;-)
> >>
> >>
> >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in this 
mail is 
> > solely property of the sender's organization. This mail communication 
is 
> > confidential. Recipients named above are obligated to maintain secrecy 
and 
> > are not permitted to disclose the contents of this communication to 
> > others.
> > This email and any files transmitted with it are confidential and 
intended 
> > solely for the use of the individual or entity to whom they are 
addressed. 
> > If you have received this email in error please notify the originator 
of 
> > the message. Any views expressed in this message are those of the 
> > individual sender.
> > This message has been scanned for viruses and Spam by ZTE Anti-Spam 
> > system.
> > 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.