Subject: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 13 Apr 2014 19:10:44 +0100

Hi authors,

Thanks for progressing with this document. It is good to see security being
taken seriously by the WG.

I have done my usual AD review after receiving the publication request. This has
led me to a small number of issues and questions, below.

It would be nice to see these addressed, but I am open to discussion including
the authors and WG saying that I am wrong or that the additions are out of
scope.

Thanks for your work,
Adrian

===

I think that the threat analysis is a bit thin. As with all interior routing
protocols, there seem to be two possibilities. The first is that a bad LDP
message is admitted (directly or through a tunnel) into the network. The second
is that there is a bad actor in the network. It would help if the document was a
little clearer about which attacks it is defending against and why normal
protection at the edge of the network is not considered enough for the former,
and why a bad actor within the network would waste its time attacking LDP when
there is so much else it can do!

---

IANA stuff...

Section 2.1 should use "TBD1" and Section 2..3 and 8 should be similarly
updated to identify the new Cryptographic Authentication TLV.

The back reference in section 8 should presumably say "2.3" not "3.2".

---

Section 2.1 has

   The Cryptographic Authentication TLV Encoding is described in section
   2.2.

I think this should read 2.3.

---

Section 2.2.

   o  Security Association Identifier (SA ID)

      This is a 32-bit unsigned integer used to uniquely identify an LDP
      SA, as manually configured by the network operator.

"Unique" in what scope? Presumably "globally unique" is not needed.

I am also concerned by the requirement for manual configuration because
that is open to error and attack. Each LDP speaker will have an SA with
each of its peers and each peer must have the same SA ID for
communication to work. If you are going to go to this extent, it seems
like you don't actually need Hellos to do discovery and you will only
use them for "keepalive" in which case, it might be better to replace
that second aspect of the Hello with something like a KeepAlive message!

It is perhaps ironic that part of the reasoning you apply against access
lists is the resources they take up on each LSR, yet you are requesting
that each peer that is allowed to communicate has an SA configured which
seems to me to be more resources than a simple access list.

Is there no way to generate the AD ID value from other known information
or the LDP session?

Perhaps this concern is best addressed by writing a Management
Considerations section to describe:
- what needs to be configurable in an implementation
- what needs to be configured per SA
- what needs to be made available for inspection
- what logging takes place

---

There is a small alignment error in the figure in Section 2.3

---

Section 4 is a little odd. The implication of the wording is that this
document sets requirements on all implementations of all other protocols
that use cryptographic authentication.

I would suggest deleting the whole section and updating Section 5 as
follows...

OLD
   Ks is a Protocol Specific Authentication Key obtained by appending
   Authentication Key (K) with the two-octet LDP Cryptographic Protocol
   ID appended.
NEW
   Ks is a Protocol Specific Authentication Key obtained by appending
   Authentication Key (K) with the two-octet LDP Cryptographic Protocol
   ID TBD2 (to be defined by IANA) from the "Authentication
   Cryptographic Protocol ID" registry.  Ks is used to mitigate cross-
   protocol attacks when multiple protocols share a common key.
END

---

Section 6.2

   if the locally computed Hash is not equal to the received value of
   the Authentication Data field, the received packet MUST be discarded,
   and an error event SHOULD be logged.

It is customary to give some warning about rate limiting logging because
logging usually takes more resources than receiving packets, so if you
are subject to a storm of bad Hellos you could die trying to log them.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 17 Apr 2014 13:12:52 +0200

Adrian,

Given my limited understanding of the security mechanisms, I
nevertheless have one question I need to ask.

You say:

On 2014-04-13 20:10, Adrian Farrel wrote:
> It would help if the document was a

My understanding is that this document was written as a response to the
risk analysis in RFC 6952. If I remember correctly you had a number of
questions, but also said that you had no objections after having these
question answered.

Since RFC 6952 says we have a security hole that we need to close, you
said that you approve of that, we tried to fill the hole; how should I
understand the comment above? Do you just want another reference to
RFC 6952?

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 17 Apr 2014 14:09:25 +0100

Hello,

I don't think that is the history at all!
This document started as draft-zheng-mpls-ldp-hello-crypto-auth in October 2010.
Before that the issue with the Hello was discussed and batted around for a
while.
There is a risk with the Hello and it needs a solution.
No issue with that, and I support this draft.

RFC 6952 comes from draft-ietf-karp-routing-tcp-analysis-00.txt that was adopted
by KARP in June 2011. That derives from draft-mahesh-bgp-ldp-msdp-analysis first
posted in February 2011 (note that the discussion of LDP Hellos didn't make it
into this document until -01 in May 2011).

But who cares?

RFC 6952 does not describe the attacks or their mitigations. It just notes that
spoofing a Hello can have some bad effects.

As a deployer, I need help to explain when I need to insist on having this
feature implemented by my supplier (BTW, it looks like none of the suppliers is
implementing it) and when I need to enable it. It seems to me that this feature
is needed to protect against attacks (which 6952 claims have been seen in the
wild), but that those attacks only arise in specific situations.

Since the security mechanisms defined in this document are pretty heavy-weight
(compare with simple text passwords so loved for IGP security :-) it would be
great to get some help on this topic. Are all networks always exposed (if so it
looks like a must-have feature)? Are the risks only significant for targeted
LDP? Is the network safe if it applies access controls at the edges and assumes
no subversion of routers? Does applying an access list at the LDP speakers
provide protection against everything except address spoofing?

Cheers,
Adrian

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: 17 April 2014 12:13
> To: [email-masked];
[email-masked]
> Cc: [email-masked]
> Subject: Re: AD review of draft-ietf-mpls-ldp-hello-crypto-auth
> 
> Adrian,
>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 17 Apr 2014 15:41:37 +0200

Adrian,

Sorry if I don't have the history right, but it is not really the that
is my problem.

It is the tension between

 > No issue with that, and I support this draft.

and

 > why a bad actor within the network would waste its time attacking LDP
 > when there is so much else it can do!

The first seems says that there is a risk that needs to be taken care
of, the second seems to say that this is moot.

/Loa

--

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 17 Apr 2014 16:41:52 +0100

> of, the second seems to say that this is moot.

*If* a bad actor within the network is the only vulnerability, and *if*all* such
bad actors are compromised routers, then it is moot. But "moot" means "subject
to debate, dispute, or uncertainty." Let's debate :-)

Without seeing the text that describes how the attacks might be made, I
(probably like the rest of the WG) am assuming "Here is a security hole: we had
better plug it."

Knowing there is a hole, and knowing what the fix is, is really important. That
means the I-D should be published as an RFC, whatever.

Knowing when the solution needs to be used is an important piece of additional
guidance to make the document more useful.

Adrian

---

From: Vero Zheng <[email-masked]>
Date: Fri, 18 Apr 2014 03:08:04 +0000

> RFC 6952 comes from draft-ietf-karp-routing-tcp-analysis-00.txt that was adopted by KARP in June 2011. That derives from draft-mahesh-bgp-ldp-msdp-analysis first posted in February 2011

(note that the discussion of LDP Hellos didn't make it into this document until -01 in May2011).

Adrian,

That is not correct. The discussion of LDP Hellos was in the document from the very beginning. The hello spoofing was discussed in both the discussion on current state/optimal state of the protocols in -00.

Obviously, the document authors care:)

Cheers, Vero

> From: mpls [mailto:[email-masked]] On Behalf Of Adrian Farrel

> Sent: Thursday, April 17, 2014 9:09 PM

> To: 'Loa Andersson'; [email-masked]

> Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth

> This document started as draft-zheng-mpls-ldp-hello-crypto-auth in October

> 2010.

> RFC 6952 comes from draft-ietf-karp-routing-tcp-analysis-00.txt that was

> adopted by KARP in June 2011. That derives from

> draft-mahesh-bgp-ldp-msdp-analysis first posted in February 2011 (note that

> the discussion of LDP Hellos didn't make it into this document until -01 in May

> 2011).

> As a deployer, I need help to explain when I need to insist on having this feature

> implemented by my supplier (BTW, it looks like none of the suppliers is

> Since the security mechanisms defined in this document are pretty

> heavy-weight (compare with simple text passwords so loved for IGP security :-)

> it would be great to get some help on this topic. Are all networks always

> exposed (if so it looks like a must-have feature)? Are the risks only significant

> for targeted LDP? Is the network safe if it applies access controls at the edges

> and assumes no subversion of routers? Does applying an access list at the LDP

> speakers provide protection against everything except address spoofing?

> > To: [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>

> > Cc: [email-masked]<mailto:[email-masked]>

> > > little clearer about which attacks it is defending against and why

> > > normal protection at the edge of the network is not considered

> > > enough for the

> former,

> > > and why a bad actor within the network would waste its time

> > > attacking LDP

> > when

> > My understanding is that this document was written as a response to

> > the risk analysis in RFC 6952. If I remember correctly you had a

> > number of questions, but also said that you had no objections after

> > having these question answered.

> _______________________________________________

> mpls mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 18 Apr 2014 18:56:30 +0100

Vero, you're very right. Sorry about that: let's blame my old age, shall we?
 
Anyway, the main point is that 6952 exposes the issue, but does not scope the
risk. 
This I-D plugs the hole, but doesn't say when or why you might need the feature.
 
A
 
From: Vero Zheng [mailto:[email-masked]] 
Sent: 18 April 2014 04:08
To: [email-masked]; 'Loa Andersson';
[email-masked]
Cc: [email-masked]
Subject: RE: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth
 
adopted by KARP in June 2011. That derives from
draft-mahesh-bgp-ldp-msdp-analysis first posted in February 2011
(note that the discussion of LDP Hellos didn't make it into this document until
-01 in May2011).
 
Adrian,
That is not correct. The discussion of LDP Hellos was in the document from the
very beginning. The hello spoofing was discussed in both the discussion on
current state/optimal state of the protocols in -00.
Obviously, the document authors careJ
 
Cheers, Vero
 
> As a deployer, I need help to explain when I need to insist on having this
feature
> > From: Loa Andersson [ <mailto:[email-masked]> mailto:[email-masked]]
> > To:  <mailto:[email-masked]> [email-masked];
>  <mailto:[email-masked]>
> > Cc:  <mailto:[email-masked]> [email-masked]
>  <mailto:[email-masked]> [email-masked]
>  <https://www.ietf.org/mailman/listinfo/mpls>