Subject: TSVDIR review of draft-ietf-karp-design-guide

From: Joe Touch <[email-masked]>
Date: Wed, 29 Jun 2011 22:54:59 -0700

Hi, all,

I've reviewed this document as part of the transport area directorate's 
ongoing effort to review key IETF documents. These comments were written 
primarily for the transport area directors, but are copied to the 
document's authors for their information and to allow them to address 
any issues raised. The authors should consider this review together with 
any other last-call comments they receive. Please always CC 
[email-masked] if you reply to or forward this review.

The document discusses design issues for protecting routing protocols.

The most problematic issue is the term "on the wire" which is used in 
various contexts to imply physical, link, network, or transport protocol 
layers. This needs to be clarified.

Transport protection appears to be a potential focus of the design 
guide, but is inconsistently discussed. In some cases, transport issues 
are raised (TCP issues for BGP); in other cases, the relevant transport 
isn't even noted (e.g., RIP over UDP). This should be corrected throughout.

It is important for this document to be more clear on what layers were 
in scope for the design guide, and what guidelines are being given with 
respect to those layers, even in a general sense.

Further information on these issues is provided below. There is 
additional feedback provided below ("other notes") as a suggestion.

I hope this feedback will be useful to the authors, and will be glad to 
provide further assistance either on- or off-list as useful.

Joe

---------------------------------------------------------------------

 >> please note that some of these comments apply to the 
draft-ietf-karp-threats-reqs-03 as well; further, there is duplicate 
text that is not needed in both these docs. FWIW, the threats-reqs doc 
has many issues as well which are not addressed here.

Of the four issues noted in the intro, the last uses the ambiguous term 
"on the wire". This is confusing in both this and the threats doc, and 
many times both docs us the term 'wire' or 'bits', all of which would 
typically indicate either the link layer or the physical media or both. 
There is no rationale for this focus in either document.

The threats document should more clearly indicate *why* protection 
beyond the routing messages (the SIDR work) is needed, and what the 
expected threats are. These appear to be:
	- routing protocols often rely on information in the
	link, transport or network packets
	- routing protocols often rely on properties of transport
	connections to infer reachability, e.g., if a TCP connection
	cannot stay up, then the endpoint's routes should not be
	considered reachable
(if there are other reasons, please clarify) The threats then appear to be:
	- spoofing link/network addresses
	- spoofing transport ports
	- disrupting the TCP connection (where TCP is used)
Note that falsification (as noted in the threats doc) is not in this 
list since it is (IMO) clearly the purvue of the SIDR work. Also out of 
scope should have been any of the interference issues, unless the 
*performance* of the TCP connection needs protection.

This doc then may need to protect the link or network protocol ID and/or 
transport protocol from interference. This should be more clearly stated 
in the threats doc, IMO, and the term "on the wire" should be avoided.

The discussion of multicast should note that multicast can be 
implemented by broadcast, true multicast, or serial unicast; these may 
have different security requirements.

The document should more clearly indicate the underlying protocol used 
as a key property of a routing protocol, especially because (as above) 
this document appears to focus on guidelines for link, network, and/or 
transport protocols. E.g., the discussion on OSPF, RIP, and ISIS should 
more clearly indicate that, e.g., RIP runs over UDP, OSPF runs over IP 
directly, and IS-IS runs natively over L2. Similar info would be useful 
for BFD, RSVP, etc.

The document is unclear on its overall advice, other than a somewhat 
general description of "do good stuff". E.g., it notes:

       Not all routing protocol authentication mechanisms provide
       support for replay attacks, and the design teams should
       identify such authentication mechanisms and work on them so
       that this can get fixed. The design teams must look at the
       protocols that they are working on and see if packets captured
       from the previous/stale sessions can be replayed.

More specific advice would be, e.g.:

	Not all routing protocol authentication mechanisms provide
	protection from replay attacks. Such deficiencies should
	be addressed at that layer, rather than having design
	teams conclude that such systems thus require lower layer
	(transport, network, or link) protection from replays.

----
Other notes:

Overall, this document would benefit from a revision focused on 
clarification, where the focus of each section and advice were made more 
clear.

The abstract is excessively detailed and doesn't get to the point until 
"This document...". Everything preceding that should be removed, and the 
result should be appended with a few sentences summarizing the 
recommendations.

The intro refers in a lot of detail to the motivation for the doc (some 
of which may be historically important but is not relevant to the doc 
itself), but only briefly notes the KARP threats document. This 
document's observations should be motivated by addressing those threats, 
so it would be important to summarize them in this doc in the intro as 
context.

The summary of RFC 4984 discusses four tightening steps as if they were 
indicated by that RFC; that RFC only suggests tightening itself. This 
doc should more clearly indicate that "The WG identified four...".

-----

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 30 Jun 2011 09:13:13 -0400

I am conufsed by this review of the KARP design guidelines document.
My first reaction was that I had trouble understanding the general 
points.  However, when I looked at the more detailed explaantion, what I 
see is "The threats document should ...".  But this is not a review of 
the threats document.
As a result, when the review then says "the document" I have no idea 
what document is meant.

In addition to that general comment, I am completely unable to 
understand the reviewers concern with the use of the term "on the wire". 
  I can believe that there is an issue with the way it is used, but have 
no clue how to begin to address it.

Similarly, there is an assertion that it is important for the document 
to be more clear on what layers are in and out of scope.  This is 
comment seems to be an assertion by the reviewer not grounded in the 
document.  Neither document is not a scope document.  The scope is 
defined by the charter.  Discussion of layers where it is not needed is 
a distraction.  If there are specific places where such additions would 
be helpful, that is a comment we can react to.

As a lesser issue, it is not clear that the different ways of delivering 
multiple content are actually relevant to the design guidleines 
document.  The different routing protocols have their modes of 
operations.  Ones which send distinct messages to distinct peers are 
different from ones which, as routing protocols sned single messages to 
broadcast or multicast.  As such, it is not at all clear what the 
reviewer is asking be clarified in this regard.

Yours,
Joel M. Halpern

On 6/30/2011 1:54 AM, Joe Touch wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 Jun 2011 06:52:39 -0700

Hi Joel,

> As a result, when the review then says "the document" I have no idea

 From the design guide section 1:

       Readers must refer to the [I-D.ietf-karp-threats-reqs] for a
       clear definition of the scope, goals, non goals and the
       audience for the design work being undertaken in KARP WG.

I did so, and found issues there that caused problems here, which is why 
those issues are included.

> no clue how to begin to address it.

There are more than a few who frequently refer to a protocol's "packets 
on the wire". This is ambiguous and can mean:

	- app messages (here, routing PDUs)
	- transport messages (e.g., TCP segments)
	- network messages (e.g., IP packets)
	- link messages (e.g., ethernet segments)
	- the physical media (e.g., WIFI)

Protecting each of these results in different kinds of defense. The 
document needs to avoid the use of this term as if it were well-defined 
in the IETF literature and unambiguous within the IETF community.

> to be more clear on what layers are in and out of scope. This is comment
> seems to be an assertion by the reviewer not grounded in the document.
> Neither document is not a scope document. The scope is defined by the
> charter.

Neither document should expect that readers are familiar with the 
charter; relevant context should be summarized in the intro (and is not, 
currently).

The KARP charter says:
---
The KARP working group is tasked to work with the routing protocol
working groups in order to improve the communication security of the
packets on the wire used by the routing protocols. This working group is
concerned with message authentication, packet integrity, and denial of
service (DoS) protection. At present, this charter explicitly excludes
confidentiality and non-repudiation concerns.
...
Routing protocols use a range of transport mechanisms and communication
relationships. There are also differences in details among the various
protocols. The working group will attempt to describe the security
relevant characteristics of routings protocols, such as the use or
non-use of TCP, or the frequent use of group communication versus purely
pairwise communication. Using these characteristics, the working group
will then provide suitable common frameworks that can be applied, and
tailored, to improve the communication security of the routing
protocols. In later phases, it is expected that the working group will
investigate the suitably of defining conceptual structures and APIs, so
as to enable further work to be more effective.
---

Again, I note that "on the wire" is not clear, nor the term "packet". 
The term "transport mechanisms" is overloaded, but in the IETF tends to 
refer to layer 4; that's not appropriate here, as some important routing 
protocols are directly layered over L2 or L3.

> Discussion of layers where it is not needed is a distraction.

A design guide to secure routing protocol message exchanges needs to 
clearly identify, by example, the expected kinds of protection needed 
for the message exchange. This breaks down to two parts:

	A- securing the message content
	B- securing any information provided by the way in
	which the messages are exchanged
		1- securing explicit info (e.g., IDs,
		if relied upon by the routing protocol)
		2- securing implicit info (e.g., connection
		status, message ordering or success, etc.,
		as used by the routing protocol)

AFAICT, KARP is focused on (B) which is necessarily in the context of 
L2, L3, and/or L4 {where SIDR addresses (A)}. That's fine, but a 
*design* guide should be more clear about what B means, and what kinds 
of things to look out for or address.

> If there are specific places where such additions would be helpful, that
> is a comment we can react to.

I refer you again to the intro, which states:

...   Section 8.2 calls for "[t]ightening the
       security of the core routing infrastructure."  Four main steps
       were identified for that tightening:

       o  More secure mechanisms and practices for operating routers.
          This work is being addressed in the OPSEC Working Group.

       o  Cleaning up the Internet Routing Registry repository [IRR],
          and securing both the database and the access, so that it
          can be used for routing verifications.  This work should be
          addressed through liaisons with those running the IRR's
          globally.

       o  Specifications for cryptographic validation of routing
       message content.  This work will likely be addressed in the
       SIDR Working Group.

       o  Securing the routing protocols' packets on the wire

       This document addresses the last bullet, securing the packets
       on the wire of the routing protocol exchanges.

The third bullet describes securing routing protocol messages as out of 
scope. The last sentence describes "on the wire" as in scope, again as 
if this were a clear indication of what needs to be protected.

> document.

Can you please then explain what "on the wire" means if not "differnt 
ways of delivering multiple content"? Isn't that exactly the scope?

 > The different routing protocols have their modes of

The difference between unicast and multicast is important, but so is the 
difference between whether a protocol relies on a connection being up, 
or message delivery being ordered. Again, specifically:

	B- securing any information provided by the way in
	which the messages are exchanged
		1- securing explicit info (e.g., IDs,
		if relied upon by the routing protocol)
		2- securing implicit info (e.g., connection
		status, message ordering or success, etc.,
		as used by the routing protocol)

IMO, neither B1 nor B2 is sufficiently addressed in this doc, and 
neither can be addressed in the absence of a clear discussion of the 
different properties of L2, L3, and/or L4 as they impact routing 
protocols over which they operate.

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 30 Jun 2011 10:14:52 -0400

How much of this would change if the abstract began with:
This document captures the design guidance that the KARP working group 
is using at the time of publication for guiding the chartered security 
analysis and proposal work that it is doing.

And we put that in the front of the intro as well.
(The abstract needs to be replaced with an actual abstract.  I had 
thought that could be resolved in parallel with the IETF last call.)

Would that help, or would you have the same concerns?

Yours,
Joel

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 Jun 2011 07:19:27 -0700

Hi, Joel,

> Would that help, or would you have the same concerns?

Regarding the context of what the WG focus and scope is, merely 
referring to the WG isn't sufficient. The relevant points of scope need 
to be included or explained.

However, this doesn't need to refer to the WG at all. The history of the 
doc is not relevant on that point, except perhaps in the Acks. For the 
intro and abstract, a clear statement of scope is needed.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 Jun 2011 10:23:45 -0700

(resending cc'd to the KARP WG rather than SIDR; please respond to this 
post instead)

Hi, all,

Joe

----
Other notes:

-----