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

Mach,

As far as network boundary/edge is concerned, if LDP is not enabled on the outside interfaces, then the implementation should allow any LDP packet (IP packet with UDP/TCP port=646) to be ignored. This should not require any filtering.

For LDP enabled on the inside interfaces, if we are concerned about the MITM (man-in-the-middle) attack, then wouldn't the 'Configuration Sequence Number' TLV be sufficient to counter that reasonably?

Cheers,
Rajiv

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mach Chen
> Sent: Tuesday, October 26, 2010 11:59 PM
> To: Ronald Bonica; Vishwas Manral
> Cc: mpls@ietf.org; Lamberto Sterling
> Subject: Re: [mpls] [MPLS] HELP: Need your opinion on LDP security
> 
> Hi Ron,
> 
> Thanks for sharing your opinion!
> 
> Filtering is an at hand candidate method, but filter all LDP traffic at the
> edges is not so easy, and sometime it may become impossilbe when you have to
> set up LDP connections outside the edges. In addition, the operators should
> very carefully design and configure the rules, this also needs extra
> resources and is sometime boresome.
> 
> BTW, second-order issue is an issue:)
> 
> Best regards,
> Mach
> 
> 
> --------------------------------------------------
> From: "Ronald Bonica" <rbonica@juniper.net>
> Sent: Wednesday, October 27, 2010 3:50 AM
> To: "Vishwas Manral" <vishwas.ietf@gmail.com>; "Mach Chen" <mach@huawei.com>
> Cc: <mpls@ietf.org>; "Lamberto Sterling" <lamberto.sterling@gmail.com>
> Subject: RE: [mpls] [MPLS] HELP: Need your opinion on LDP security
> 
> > Folks,
> >
> > Is it safe to assume that if an operator is using LDP, he should filter
> > all LDP traffic at the network edges. If that is the case, authentication
> > of LDP traffic becomes a second-order issue?
> >
> >                                                    Ron
> >
> >
> >> -----Original Message-----
> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> >> Vishwas Manral
> >> Sent: Tuesday, October 26, 2010 3:44 PM
> >> To: Mach Chen
> >> Cc: mpls@ietf.org; Lamberto Sterling
> >> Subject: Re: [mpls] [MPLS] HELP: Need your opinion on LDP security
> >>
> >> Hi Mach/ Lamberto,
> >>
> >> I guess, I agree with Mach and Vero here. An established session can
> >> be torn down with an invalid Hello. I was thinking of an invalid
> >> router trying to make a connection but missed the part of the issues
> >> when the session is UP.
> >>
> >> If you have not clarified this in the draft yet you could add some
> >> text in this regard.
> >>
> >> Thanks,
> >> Vishwas
> >>
> >> On Tue, Oct 26, 2010 at 9:11 AM, Mach Chen <mach@huawei.com> wrote:
> >> > Hi Lamberto,
> >> >
> >> > Thanks for your opionion!
> >> >
> >> > But if there is no hello authentication,  an established LDP session
> >> can be
> >> > tore down by a spoofing Hello with a smaller Hold Time interval or
> >> different
> >> > Transpot Address.  And the current TCP authentication mechanism can
> >> not help
> >> > for such attack.
> >> >
> >> > Best regards,
> >> > Mach
> >> >
> >> > -----原始邮件----- From: Lamberto Sterling
> >> > Sent: Tuesday, October 26, 2010 8:36 PM
> >> > To: vishwas.ietf@gmail.com
> >> > Cc: mpls@ietf.org
> >> > Subject: Re: [mpls] [MPLS] HELP: Need your opinion on LDP security
> >> >
> >> > Hi,
> >> > +1, I fully agree with Vishwas. No much benefit of hello security.
> >> >
> >> > Lamberto
> >> >
> >> >
> >> > Message: 3
> >> > Date: Mon, 25 Oct 2010 21:21:07 -0700
> >> > From: Vishwas Manral <vishwas.ietf@gmail.com>
> >> > Subject: Re: [mpls] [MPLS] HELP: Need your opinion on LDP security
> >> > To: Vero Zheng <verozheng@huawei.com>
> >> > Cc: mpls <mpls@ietf.org>
> >> > Message-ID:
> >> >      <AANLkTik3NNJcuAcR4ZEFY4hdNV_n-RpWiesxxTYUNZmE@mail.gmail.com>
> >> > Content-Type: text/plain; charset=ISO-8859-1
> >> >
> >> > Hi Vero/ Mach,
> >> >
> >> > I had thought of this in some detail earlier.
> >> >
> >> > My reasoning is the follows. Thinking of what we loose if we do not
> >> > authentication in LDP Hellos. We will go ahead and try to establish
> >> > TCP sessions (which will anyway fail as TCP authentication is there).
> >> >
> >> > If we think of what we loose when adding the Authentication in
> >> Hellos,
> >> > it is using additional CPU capacity and an additional mechanism which
> >> > is an overhead. There is nothing to loose in case of replays as the
> >> > TCP messages are authenticated and session will be dropped even if
> >> > Hellos are retransmitted.
> >> >
> >> > That said I had added a section for support of IPsec for LDP in the
> >> > IPv6 draft (which we dropped as it was slightly out of context in the
> >> > draft). You may want to consider that.
> >> >
> >> > Thanks,
> >> > Vishwas
> >> >
> >> > 2010/10/24 Vero Zheng <verozheng@huawei.com>:
> >> >>
> >> >> Hi Folks,
> >> >>
> >> >> We would like to hear you opinion on LDP security.
> >> >>
> >> >> Unlike all other LDP messages, the Hello messages are sent using
> >> UDP?not
> >> >> TCP.
> >> >> This means that they cannot benefit from the security?mechanisms
> >> available
> >> >> with TCP.
> >> >> [RFC5036] does not provide any?security mechanisms for use with
> >> Hello
> >> >> messages except to note that?some configuration may help protect
> >> against
> >> >> bogus discovery events.
> >> >>
> >> >> Do we need to allow the use of different keys from the ones used on
> >> the
> >> >> TCP
> >> >> session?
> >> >>
> >> >> We have submitted a new?"LDP Hello Cryptographic Authentication"
> >> draft. In
> >> >> this draft, we introduce a new Cryptographic Authentication
> >> TLV?which is
> >> >> used in LDP Hello message as an optional parameter.
> >> >> An LSR can be configured to?only accept Hello messages from specific
> >> peers
> >> >> when authentication?is in use.
> >> >> The URL for it is:
> >> >> http://tools.ietf.org/id/draft-zheng-mpls-ldp-hello-crypto-auth-
> >> 00.txt
> >> >> Looking forward to your comments.
> >> >>
> >> >> BR,
> >> >> Mach and Vero
> >> >> _______________________________________________
> >> >> mpls mailing list
> >> >> mpls@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/mpls
> >> >>
> >> >>
> >> >
> >> >
> >> > ------------------------------
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > mpls mailing list
> >> > mpls@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/mpls
> >> >
> >> _______________________________________________
> >> mpls mailing list
> >> mpls@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mpls
> >
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls