Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide
draft-ietf-karp-routing-tcp-analysis-07

[Ballot comment]

- I agree with Sean's discuss

- I think I agree with Adrian's discuss:-)

- A nit: last para of section 5: I think you should replace
"public/private keys" with "public key certificates
[rfc5280]" since there are ways to use asymmetric
cryptography without certificates (e.g. ssh-like).

[Ballot discuss]

  There was a long thread that was started by the Gen-ART Review  by
  Ben Campbell on 18-Dec-2012.  I am surprised to see this document
  up for approval without any changes.  Based on that thread, I am
  expecting some changes.

[Ballot discuss]
I want to support this document by balloting "Yes": it is important work
and I found Section 4 to be useful.  But before I can do that I need to
you answer a few question for me.

---

In Section 2.3

  In addition, LDP distributes labels in the clear, enabling hackers to
  see what labels are being distributed.  The attacker can use that
  information to spoof a connection and distribute a different set of
  labels causing traffic to be dropped.

I understand how the distribution of labels in the clear could be
considered as an issue especially with per platform label spaces where
the knowledge of the FEC/label mapping might be used to inject traffic
into an LSP if it can somehow be tunnelled to an LSR.  However, I don't
understand your second sentence. Do you "LDP session" or "LSP" when you
say "spoof a connection"? If you mean "LDP session", how does the
knowledge of labels enable this? If you mean "LSP" how does this enable
distributing a different set of labels (and to whom"?

Furthermore, Section 2.3.2 seems to say this is neither an issue nor in
scope for this document or the WG. Why is it mentioned?

---

Shouldn't section 2.3 discuss the fact that there are two types of LDP
sessions? The first is between physically adjacent nodes (i.e., one hop
apart making GTSM practical) and the other (called targeted sessions)
being potentially across multiple hops?

---

Section 2.4

  Attacks on PCEP [RFC5440] may result in damage to active networks.
  These include computation responses, which if changed can cause
  protocols like LDP to setup sub-optimal or inappropriate LSPs.

LDP systems don't use PCE.
You could probably s/LDP/RSVP-TE [RFC3209]/

---

Shouldn't section 2.4 mention section 10.2 of RFC 5440 and what it has
to say about the use of TCP AO?

---

If 2.3.1.1 is deemed important for this document, then there needs to be
something similar in section 2.4 for PCEP. Discovery in PCEP (when
manual config is not used) is via an IGP which makes a spoofing attack
all the more interesting. See also para 3 or Section 3.

Similarly, why is there no subsection of section 3 to mention issues for
PCEP that result from discovery issues?

---

Why is there no subsection in section 2 covering BGP? You have one for
each of LDP, PCEP, and MSDP.

[Ballot comment]
I have a number of minor nits with this document that you might want to
address if you are revising the document.

---

Stewart's proposals to resolve the algorithm agility question look good
and I hope they will get included.

---

You shouldn't use citations in the Abstract because it needs to stand
alone.

---

Section 1 says

  In order to secure the routing protocols this document performs an
  initial analysis of the current state of TCP based protocols
  including BGP, LDP, PCEP, and MSDP

I think that only these 4 protocols are discussed, so "including" is
misleading.

---

Please check your abbreviations in Section 1.1. Some of them are not
used in this document:
- KDF
- KEK

Additionally, the well-known abbreviation OSPF has already seen its
one use before this section starts.

Note that LSR stands for "Label Switching Router" per RFC 3031

Note that PCEP stands for "Path Computation Element Communication
Protocol" per RFC 5440

---

I would have felt better had section 2.3 had a reference to RFC 5920.
That document does not provide a complete and detailed security analysis
of the use of TCP for LDP, but it does give some pointers.

---

Section 2.3.1.2 might very usefully refer to section 2.9 of RFC 5036.

---

Section 3.1

  Labels are similar to routing information which is distributed in the
  clear.  It is important to ensure that routers exchanging labels are
  mutually authenticated, and that there are no rogue peers or
  unauthenticated peers that can compromise the stability of the
  network.  However, there is currently no requirement that the labels
  be encrypted.

This paragraph is mixing two issues. The first and third sentences are
on one topic (which 2.3.2 says is out of scope). The middle sentence is
relevant for this document.

---

In section 5, I might have added that it should be configurable per-node
or per-interface whether fallback is allowed. This may be an issue for
6518 rather than this document, but the point is that fallback to an
inferior security mechanisms is an attack mechanism (i.e., if you can
attack messages so that both parties believe they need to fall back you
can reduce the protocol mechanism to using the more attackable
processes).

[Ballot discuss]
I fully support the publication of this draft, but before moving to yes I believe the optimal state and the security considerations sections need to indicate that the protocols need to support algorithm agility (i.e., they must not hardwire one algorithm in).  The point being that algorithms weaken overtime and this feature needs to be supported in order ease transition from the old to the new algorithm.

[Ballot comment]
1) s1: Nitpicking, but technically the OPSEC WG didn't publish the RFC.  Maybe just make the penultimate paragraph some bullet points:

  This document builds on several previous analysis efforts into routing
  security:

  o [RFC6039] describes issues with existing cryptographic
      protection methods for routing protocols
  o [draft-ietf-karp-ospf-analysis-03] analyzes OSPF security
      according to KARP Design Guide

2) s2.1: Can we come up with a term other than signature?  Calling an HMAC a signature is just wrong.

  This digest acts like a signature for that segment,
  computed using information known only to the connection end points.

Maybe

  This digest is computed using information known only to the
  connection end points and this ensures authenticity and integrity of
  messages.

3) s2.1, s2.3.1.2, s2.5: The other big knock against TCP-MD5 is that it does not support algorithm agility.

4) The intro in s2.3 explains imply that unencrypted LDP messages lead to DoS attacks so I think it would be good in s2.3.2 to explain that the authentication mechanisms are the primary means to defeat the attackers.  It might be best to actually move that bit from s2.3 to s2.3.2.

5) s2.4: Shouldn't this section point out that PCEP mandates TCP-MD5 (s10.2 in RFC 5440)?  Is it not supported in the wild?

6) s3: If we're talking about the optimal approach, could we also add that it should be used :)

r/  The routing protocols should provide a mechanism to authenticate the
  routing information carried within the payload.
/  The routing protocols should provide a mechanism to authenticate the
  routing information carried within the payload and administrators
  should enable it.

7) s4: Because you used the term integrity before maybe: r/tamper protection/integrity protection

8) s4: Are you really distributing the MKT?

  An automated KMP therefore has to
  include a way to distribute MKT between two end points with little or
  no administration overhead.

9) s4: In the 3rd to last paragraph it's probably worth adding the following (or something like it) to the end of the paragraph because I'm pretty sure the point is that TCP-AO is crypto agile:

  Therefore, TCP-AO meets the algorithm agility requirements.

10) s5: maybe replace security with key management protocol:

  new authentication and security mechanisms

11) (an absolutely shameless plug) Would adding a reference to RFC 6151 help when discussing not using HMAC-MD5 in new protocols?

12) Nits:

a) s1:r/a analysis/an analysis
b) If you listing the abbreviations you missed: HMAC, SHA, AES, CMAC, AO, CA :)
c) s2.1: r/attacks.TCP/attacks.  TCP
d) s2.4: r/As RFC 5440 states, PCEP could be the target of the following
  attacks./As RFC 5440 states, PCEP could be the target of the following
  attacks:
e) s3: r/It should also negotiate Security
  Association (SA) parameter/It should also negotiate Security
  Association (SA) parameters
f) s5: expand CA to Certification Authority (CA)

IANA has reviewed draft-ietf-karp-routing-tcp-analysis-05, which is
currently in Last Call, and has the following comments:

IANA notes that this document does not contain a standard IANA
Considerations section. After examining the draft, IANA understands
that, upon approval of this document, there are no IANA Actions that
need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide) to Informational RFC


The IESG has received a request from the Keying and Authentication for
Routing Protocols WG (karp) to consider the following document:
- 'Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design
  Guide'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-11-19. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document analyzes Border Gateway Protocol (BGP) [RFC4271], Label
  Distribution Protocol (LDP) [RFC5036], Path Computation Element
  Protocol (PCEP) [RFC5440] and Multicast Source Distribution Protocol
  (MSDP) [RFC3618] according to guidelines set forth in section 4.2 of
  Keying and Authentication for Routing Protocols Design Guidelines
  [RFC6518].




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-karp-routing-tcp-analysis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-karp-routing-tcp-analysis/ballot/


No IPR declarations have been submitted directly on this I-D.

1) You need to move the RFC2119 statement out of the Abstract
and into the body of the text. (noting the spurious trailing dot)

2) In the Abstract PCEP and MSDP need to be expanded since
they are not "well known" abbreviations. For cleanness I
would also expand BGP and LDP though this in not required.
I think it would be useful if each had a reference to
an RFC.


3) Next sentence could use a bit of English polish

  This document looking at the last bullet performs an initial analysis
  of the current state of BGP, LDP, PCEP and MSDP according to the
  requirements of KARP Design Guidelines [RFC6518]. 

4) This draft builds

  Suggest "this document" as it will not be a draft much longer

5) Section 2 of this document looks at the current state of security for
  the four routing protocols.

  Suggest you name the RPs here.

6) Section 3 examines what the optimal
  state would be for the four routing protocols according to KARP
  Design Guidelines [RFC6518] and Section 4 does a analysis of the gap
  between the existing state and the optimal state of the protocols and
  suggests some areas where improvement is needed.

  It's not the "state" of the protocols that is of concern, it's
  the security mechanisms.

7) 1.1.  Contributing Authors

  Anantha Ramaiah, Mach Chen

  It's up to you, but it's usually to put in a bit more than just
  two names with no other text and no other details.

  Again up to you but I wold put them down near the real authors
  so as not to disrupt the readers flow of thought.

8) 2.  Current State of BGP, LDP, PCEP and MSDP

  This section looks at the current state of transport protocol and any
  authentication mechanisms used by the protocol.  It describes the
  current security mechanisms if any used by BGP, LDP, PCEP and MSDP.

  It's not really the "State" of those protocols so much as the
  current security and authentication methods.


9) In extreme cases, these attacks prevent routes
  from converging after a change.

  routes or routers?

10) GTSM [RFC5082]

    Please expand GTSM

11) Even when BGP, LDP, PCEP and MSDP sessions use access lists they are
  subject to spoofing and man in the middle attacks. 

  I think you mean "vulnerable to" rather than "subject to" since although
  vulnerable they may not be attacked.

12) para starting TCP MD5 [RFC2385] deprecated - first two sentences
  do not scan right.


13) 2.2.  It is well known that longer

    I think that should be "that the longer", and then "the greater
    the chance"

14) In addition, labels are distributed in the clear, enabling hackers to
  see what labels are being exchanged that could then be used to launch
  an attack.

  Surely this is only true if they have access to the path, in any case
  the English needs a look at as it does not read well.
 

15) such LDP is vulnerable to the same extent as other
  routing protocols that distribute their routing information in the
  clear.

  Is there a reference to support this?



16) 2.3.3.  Denial of Service Attacks

  The discovery mode attack is similar to the spoofing attack except
  that when the spoofed Hello messages are sent with a high enough
  frequency, it can cause the adjacency to time out.

  Please explain why.



17)  As the RFC states, PCEP ....

  which RFC? (and again later)


18) According to the RFC, inter-AS scenarios when PCE-to-PCE
  communication is required, attacks may be particularly significant
  with commercial as well as service-level implications.

  that does not scan right.

19)reside in the same AS. 

  Please check that you expand AS on first use.



20) 2.5.  MSDP

  Please note earlier comment on expanding MSDP and a ref here would
  be of help to the reader.

  also

  MSDP also advocates imposing a limit on number of source address and
  group addresses (S,G) that can be stored within the protocol


  You do not normally "store" anything is a protocol.


21) 3.  Optimal State for BGP, LDP, PCEP, and MSDP

  Again the term "state" does not seem the right word.


22)For spoofing attacks that LDP is vulnerable to during the discovery
  phase, LDP should be able to determine the authenticity of the
  neighbors sending the Hello message.

  I think you you mean something like:

  To harden LDP against its current vulnerability to spoofing
  attacks, LDP needs to upgraded such that an implemantation
  is able to determine the authenticity of the
  neighbors sending the Hello message.
 


23) 4.  Gap Analysis for BGP, LDP, PCEP and MSDP

  This section outlines the differences between the current state of
  the routing protocol and the desired state as outlined in section 4.2
  of KARP Design Guidelines [RFC6518]. 

  "state" again. Maybe "security capability" is the right term.

24)At a transport level the routing protocols are subject to some of the

  perhaps "these routing protocols"

25)From a security perspective there is lack of comprehensive KMP.

  The English does not read right it would be nice to spell
  out KMP even if it is at the top of the RFC. Same with MKT

26) requires a out of band key signaling mechanism....

  s/a/an/
  s/suggest/suggests/ (and does is suggest that or state that?)


27)  There is a need to protect authenticity and validity of the routing/
  label information that is carried in the payload of the sessions.
  However, that is outside the scope of this document at this time

  s/at this time/ it will never be in scope once we publish.


28)As described in LDP [RFC5036], the threat of spoofed Basic Hellos can
  be reduced by accepting Basic Hellos on interfaces that LSRs trust,

  by only accepting Basic....

  employing GTSM [RFC5082] and ignoring Basic Hellos not addressed to
  the "all routers on this subnet" multicast group.  Spoofing attacks
  via Extended Hellos

  Aren't they "Targetted Hellos" ?


29) PCE discovery according to its RFC

  Suggest that you ref the RFC, and PCC needs expanding.


30) Security Requirements

  The name of the mandatory section is "Security Considerations"
  If this is not that section, then please add it.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

As indicated in the header, this document is intended for informational
status.  It is an analysis of protocols, according to the KARP
guidelines, and as such belongs as an informational document.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

    This document analyzes BGP, LDP, PCEP and MSDP according to
    guidelines set forth in section 4.2 of Keying and Authentication for
    Routing Protocols Design Guidelines [RFC6518].

Working Group Summary

    The working group was happy with this document.  Joe Touch expressed
concerns about the descriptions of TCP-MD5 and TCP-AO.  All the specific
concerns he raised have been addressed, but his comments suggest that he
may have additional unspecified concerns.

Document Quality

    This document has been reviewed by the Working Group and by the
chairs.  It does a good job laying out both the common issues across the
protocols it analyses, and the protocol specific issues.  The level of
detail is appropriate to the working group goals as laid out in the
charter and the guidelines document.

Personnel

  Joel Halpern is the document shepherd.  Stewart Bryant is the
responsible Area Director.  Joel and Brian Weis are the responsible
Working Group Chairs.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document Shepherd has read this document both before the WG last
call, and after the resolution of comments.  It is in good shape, and
the shepherd believes it is ready for publication as an Informational RFC.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

While not extensively reviewed, there were sufficiently many distinct
individuals who reviewed the document, issues were raised and resolved.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document is clearly a security related document.  While it has had
review from indivduals who are quite knowledgable about security, I
anticipate and welcome the Security Directorate review. The document
does not contain formal language material needing special treatment. And
operational security issues of routing protocols are dealt with by the
working group in a separate document, so normal operations and
management review should suffice for this.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

There are no special concerns with this document.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

The shepherd has confirmed with each document author that all known IPR
has been disclosed.  The working group was also asked if anyone knew of
undisclosed IPR, and no such indications were brought forward.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The working group has a tendency towards quiet.  The shepherd, wearing
his co-chair hat, believes that the support is reasonably broad, even
though not vocal.  The working group does understand the document, and
there are no dissenters.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

There have been no threats of appeal nor any other indications of
significant unhappiness.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

ID nits complains about references, which I consider an issue to be left
for final editing.  Otherwise, it does not report any problems.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no relevant formal review criteria.  The shepherd did keep in
mind the relevant guidelines in RFC 6518 in reviewing this document, and
it meets those guidelines.

(13) Have all references within this document been identified as
either normative or informative?

The references section is split into Normative and Informative
references, and the individual references are places appropriately.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

The only normative reference which is not an RFC is
draft-ietf-karp-threats-reqs, which is in the process of being revised
for the IESG.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

As this is an informative document, there are inherently no downward
normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Publication of this document will not affect the status of any existing
RFCs.  This is not a revision of, nor a supplement to, any existing RFC.
  Rather, it is a new work product being created by this working group.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document does not assign any code points, and therefore has no IANA
actions, considerations, or impact.  It has no IANA considerations
section, rather than having a section stating this explicitly which
would need to be removed during final editing.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None (see 17).

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None, as there is no formal language material to be verified by
automated tools.

Yours,
Joel M. Halpern