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

From: Lamberto Sterling <[email-masked]>
Date: Tue, 26 Oct 2010 20:36:24 +0800

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 <[email-masked]>
> Subject: Re: [mpls] [MPLS] HELP: Need your opinion on LDP security
> To: Vero Zheng <[email-masked]>
> Cc: mpls <[email-masked]>
> Message-ID:
>        <[email-masked]>
> 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 <[email-masked]>:
> > 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> >
>
>
> ------------------------------

---

From: Mach Chen <[email-masked]>
Date: Wed, 27 Oct 2010 00:11:35 +0800

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: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] [MPLS] HELP: Need your opinion on LDP security

Hi,

Lamberto

Message: 3

Hi Vero/ Mach,

Thanks,
Vishwas

2010/10/24 Vero Zheng <[email-masked]>:
> This means that they cannot benefit from the security?mechanisms available
> with TCP.
> We have submitted a new?"LDP Hello Cryptographic Authentication" draft. In
> An LSR can be configured to?only accept Hello messages from specific peers

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 26 Oct 2010 12:43:53 -0700

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 <[email-masked]> wrote:
> -----原始邮件----- From: Lamberto Sterling

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 26 Oct 2010 15:50:47 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Vishwas Manral
> Sent: Tuesday, October 26, 2010 3:44 PM
> To: Mach Chen
> Cc: [email-masked]; Lamberto Sterling

---

From: Thomas Morin <[email-masked]>
Date: Tue, 26 Oct 2010 16:19:10 -0400

Here is a strawman : if you are to update specs for targeted LDP to fix 
this issue, why not get a little step further than putting security into 
UDP hellos, and require Hellos to be sent *in* the TCP session (rather 
than as UDP, seperately from the TCP session) ?  This has the advantage 
of not having to re-invent TCP authentication, or, even if you don't use 
TCP authentication, has the advantage of making it hard to successfully 
spoof a Hello.

-Thomas

Mach Chen a écrit :
> 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
>
>> Do we need to allow the use of different keys from the ones used on 
>> the TCP
>> session?
>>

---

From: Mach Chen <[email-masked]>
Date: Wed, 27 Oct 2010 11:59:23 +0800

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" <[email-masked]>
Sent: Wednesday, October 27, 2010 3:50 AM
To: "Vishwas Manral" <[email-masked]>; "Mach Chen" <[email-masked]>
Cc: <[email-masked]>; "Lamberto Sterling" <[email-masked]>
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
>
>
>> can be
>> the

---

From: Vero Zheng <[email-masked]>
Date: Wed, 27 Oct 2010 15:14:45 +0800

Hello Thomas,

Thanks for sharing your opinion.

Requiring Hellos to be sent in the TCP session will break the current implementation and may give the vendors a lot of work:)
It could be one of the way to combat the spoofing issue, but may not be the step which vendors would like to take.

BR,
Vero

--------------------------------------------------
From: "Thomas Morin" <[email-masked]>
Sent: Wednesday, October 27, 2010 4:19 AM
To: <[email-masked]>
Subject: Re: [mpls] [MPLS] HELP: Need your opinion on LDP security

---

From: Mach Chen <[email-masked]>
Date: Wed, 27 Oct 2010 15:42:32 +0800

Hi Thomas,

Thanks for your thoughts on this issue!

I think this an candidate solution that can solve the hello spoofing issue, 
and this is also the way that BGP protocol adopts. But it will change a lot 
of the LDP Hello and Session processing. Given that there are lot of LDP 
implements and deployments, such changes seems costly.

Best regards,
Mach

> than as UDP, seperately from the TCP session) ?  This has the advantage of 
> not having to re-invent TCP authentication, or, even if you don't use TCP 
> authentication, has the advantage of making it hard to successfully spoof 
> a Hello.
>
> -Thomas
>
>
> Mach Chen a écrit :
>> Hi Lamberto,
>>
>> 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: Dave Katz <[email-masked]>
Date: Wed, 27 Oct 2010 08:34:47 -0600

This would also break the neighbor discovery mechanism.

--Dave

---

From: Eric Rosen <[email-masked]>
Date: Wed, 27 Oct 2010 11:40:18 -0400

> if there is no hello authentication,  an established LDP session can be 
> torn down by a spoofing Hello with a smaller Hold Time interval or different 
> 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 ;-)

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 27 Oct 2010 14:23:33 -0500

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mach Chen
> Sent: Tuesday, October 26, 2010 11:59 PM
> To: Ronald Bonica; Vishwas Manral

---

From: Mach Chen <[email-masked]>
Date: Thu, 28 Oct 2010 17:18:55 +0800

Hi Rajiv,

Thanks for your opinion!

Please see inline...

Best regards,
Mach

--------------------------------------------------
From: "Rajiv Asati (rajiva)" <[email-masked]>
Sent: Thursday, October 28, 2010 3:23 AM
To: "Mach Chen" <[email-masked]>; "Ronald Bonica" <[email-masked]>; 
"Vishwas Manral" <[email-masked]>
Cc: <[email-masked]>; "Lamberto Sterling" <[email-masked]>
Subject: 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.
>
Not all the implmentations will do such check and drop the LDP packets 
(Target hello) , and I know there are at least two implmentations do not do 
this.

In addition, in case of LDP is enabled on the outside interfaces, then you 
can't lie on such mechanism.

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

If there are MITM attacks, I am not sure how you can use the 'Configuration 
Sequence Number' TLV to avoid the attack. You can't not identify whether an 
LDP Hello with/without a different Configuration Sequence Number other than 
the provious one is a spoofing Hello. And that the 'Configuration Sequence 
Number' TLV is an optional TLV.

>> Mach Chen

---

From: Vero Zheng <[email-masked]>
Date: Thu, 28 Oct 2010 18:08:12 +0800

Hi Eric,

Thanks for the comments.
Please see in-line.

BR,
Vero

--------------------------------------------------
From: "Eric Rosen" <[email-masked]>
Sent: Wednesday, October 27, 2010 11:40 PM
To: "Mach Chen" <[email-masked]>
Cc: <[email-masked]>; "Lamberto Sterling" <[email-masked]>
Subject: Re: [mpls] [MPLS] HELP: Need your opinion on LDP security

> packets would be acceptable to R1, unless the shared secret has changed.

If R2's old Hello carries a sequence number, which is NO longer valid by the time the packet is replayed, then the packet will NOT be accept by R1, even though the shared secret has not changed. Thats why the sequence number is included in the authentication TLV.

> issues well enough to know whether that is required or desirable in this

We are also not security expert, if it turns out that this is required or deirable in the LDP hello security case, we will certainly modify the mechanism accordingly.

> be told that this work conflicts with the KARP WG ;-)

It will be great to receive the advice from the security expert. Regarding Karp WG, I believe its one of their task to coordinate with routing WGs working on routing security issues.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 28 Oct 2010 11:40:29 -0400

> If R2's old Hello carries a sequence number, which is NO longer valid by
> the time the packet is replayed, then the packet will NOT be accept by R1,
> even though the shared secret has not changed.

t0: R1 has a Hello adjacency to R2, based on R1's having received Hellos
    from R2.  Part of R1's state for this Hello adjacency is the last
    sequence number received from R2.

t1: R2 goes down, stops sending Hellos.

t2: R1 deletes its Hello adjacency to R2, because R2 hasn't sent any Hellos
    for awhile, and the Holding Time has expired.  R1 no longer remembers
    the last sequence number received from R2.

t3: An attacker replays the Hellos that R1 sent to R2 yesterday. Let's say
    that the sequence number in the first replayed Hello is n.   R1
    establishes a Hello adjacency to R2, and remembers that n is R2's last
    sequence number.

t4: R2 comes up and starts sending new Hellos to R1.  The first such Hello
    has sequence number m.  Let's suppose m < n.  (We can't necessarily
    expect R2 to remember the sequence number it used before it went down.)

t5: R1 drops the Hello from R2 because m is not in the valid sequence number
    range.    

At this point the Hello adjacency has been "hijacked".

Note that I am not saying that there is a need to protect against this sort
of replay attack.  I'm just saying that the proposed mechanism does not
protect against it.

---

From: Vero Zheng <[email-masked]>
Date: Fri, 29 Oct 2010 14:20:12 +0800

Eric,

Thanks for your valuable comments.
We will consider this carefully.

BR,
Vero

--------------------------------------------------
From: "Eric Rosen" <[email-masked]>
Sent: Thursday, October 28, 2010 11:40 PM
To: "Vero Zheng" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Subject: Re: [mpls] [MPLS] HELP: Need your opinion on LDP security

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 29 Oct 2010 08:44:22 -0500

Hi Mach,

Pls see inline,

> (Target hello) , and I know there are at least two implmentations do not do

Aah!! Such an implementation would be susceptible to a bigger DoS attack, IMO.

It is a bad idea to accept and process a packet on a port/socket whose protocol is not enabled yet.

In fact, that's a violation of RFC 5036 section 3.5.2.1

<excerpt>
      A Link Hello is acceptable if the interface on which it was
      received has been configured for label switching.

      A Targeted Hello from source address A is acceptable if either:

      -  The LSR has been configured to accept Targeted Hellos, or
      -  The LSR has been configured to send Targeted Hellos to A.
</excerpt>

> can't lie on such mechanism.

Ditto. If LDP is enabled (for things such as Inter-AS), then the problem may happen. 

> And that the 'Configuration Sequence Number' TLV is an optional TLV.

Optional should not be an issue. Most security related options are optional. :) Even the proposed 'Cryptographic Authentication TLV' is optional. :)

Cheers,
Rajiv

> From: Mach Chen [mailto:[email-masked]]
> Sent: Thursday, October 28, 2010 5:19 AM
> To: Rajiv Asati (rajiva); Ronald Bonica; Vishwas Manral

---

From: "iLya" <[email-masked]>
Date: Fri, 29 Oct 2010 16:10:16 +0200

Sent: Friday, October 29, 2010 3:44 PM

> Optional should not be an issue. Most security related options are 
> optional. :) Even the proposed 'Cryptographic Authentication TLV' is 
> optional. :)
>

In my opinion if Man-in-the-middle is determined to break some session down 
nothing will stop this - they can simply drop hello packets and that will 
suffice. So Hello Auth and sequence numbers won't provide usable protection, 
only false sence of security.

Kind regards,
iLya

---

From: Mach Chen <[email-masked]>
Date: Sat, 30 Oct 2010 09:48:55 +0800

Hi Rajiv,

Thanks for your prompt response!

Please see inline...
Sent: Friday, October 29, 2010 9:44 PM

>      -  The LSR has been configured to send Targeted Hellos to A.

Recently, we did experiments in lab and found that the result of most of the 
major implmentations are alike on this. Actually, this does not violate the 
rules for Targeted Hello as you excerpted. If an LSR has established a 
Target session with A, it should have been configured to accept/send 
Targeted Hellos from/to A, and a spoofing Hello can easily to be made up as 
if sending from A.

> Ditto. If LDP is enabled (for things such as Inter-AS), then the problem 

Yes, this one of the scenarios that the draft tries to solve.

In addition, in case of LDP is not enabled on the edge devices, even if the 
LDP implementation can do source address and UDP port check, then the 
spoofing hellos will not be blocked at the edge devices by LDP, unless you 
configure the other necessay filtering rules on the edges.

Best regards,
Mach

---

From: Vero Zheng <[email-masked]>
Date: Sat, 30 Oct 2010 10:10:59 +0800

Hi iLya,

Thanks for your comment.

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. This is the problem our mechanism try to solve. If we didnt make this clear in the draft, we will clarify it in the later version.

BR,
Vero

--------------------------------------------------
From: "iLya" <[email-masked]>
Sent: Friday, October 29, 2010 10:10 PM
To: "Rajiv Asati (rajiva)" <[email-masked]>; "Mach Chen" <[email-masked]>; "Ronald Bonica" <[email-masked]>; "Vishwas Manral" <[email-masked]>
Cc: <[email-masked]>; "Lamberto Sterling" <[email-masked]>
Subject: Re: [mpls] [MPLS] HELP: Need your opinion on LDP security