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

["Adrian Farrel" <[e-mail]>]

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.