Subject: Re: notes from discussion of KARP design guidelines

From: Joel Halpern <[email-masked]>
Date: Sun, 10 Jul 2011 10:10:36 -0400

Joe,
     THE KARP WG Chairs have reviewed your comments, in order to figure 
out what the best way to address them.   We would appreciate it if you 
could engage in discussion of this proposal on the KARP working group 
email list.  If you feel we are still not understanding your point, we 
would be happy to make some time avaialble for discussion at the WG 
session in Quebec City.  (Comments from anyone else, particularly WG 
members, on the proposals being made by the WG chairs are appreciated as 
well.)

Rather than a line by line response, we have tried to find the common 
themes and respond to them.  If we have missed major issues, please let 
us know.

You raised concern about the use of the term "on-the-wire."  Rather than 
replace the term, we would prefer to add descriptive text early in the 
document.  This text would note that it is a widely used term in IETF 
documents, including many RFCs.  It would also state for clarity that in 
this document it is used to refer to the message sent from one routing 
process to another.

With regard to your comment about identifiers, we can add in the 
description of protocol reviews indications that such reviews should be 
clear about what IDs the review considers need protecting, as that is 
important context for the protocol review.

As noted in other exchanges, the document abstract needs a complete 
rewrite.  It should be just an abstract, with the rest of the context 
either removed or moved to the introduction.  In doing so, we will add 
text describing briefly the general concept of the routing protocol 
transport.

In general however, protocol specific behaviors are to be left to the 
protocol analysis documents.  Equally, descriptions of detailed threats 
will be left either to the threat document or to the individual protocol 
analysis document as appropriate.

There are several items in your comments indicating that you would like 
to see more discussion in the design guidelines of the protocol 
layering.  That does not seem to be a useful addition to this document. 
  Again, individual protocol analysis documents will deal with that 
where it is appropriate, and avoid it where it is a distraction.  We do 
not see useful general statements of guidance that can be put into this 
document.

Adding some general text in the discussion of communication modes 
elaborating on the difference between the communication as seen by the 
routing and security components, and the actual communication (e.g. that 
what is seen as multicast may be delivered as broadcast or multiple 
uni-cast) does seem a helpful addition to the document, and we will do that.

Yours,
Joel and Brian

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Jul 2011 15:23:50 -0700

Hi, Joel (et al.),

On 7/10/2011 7:10 AM, Joel Halpern wrote:
> Joe,
> THE KARP WG Chairs have reviewed your comments, in order to figure out
> what the best way to address them. We would appreciate it if you could
> engage in discussion of this proposal on the KARP working group email
> list. If you feel we are still not understanding your point, we would be
> happy to make some time avaialble for discussion at the WG session in
> Quebec City. (Comments from anyone else, particularly WG members, on the
> proposals being made by the WG chairs are appreciated as well.)
>

That's a great example of why this term should be removed. The message 
sent from one BGP to another is sent *inside* a TCP connection, and 
nobody would ever call the TCP bytestream payload the message "on the 
wire".

This term is simply sloppy, and just as the security community rightly 
raises issues with similarly poor use of its terms (e.g., "random" where 
pseudorandom or arbitrary are intended, or "authenticated" where 
integrity protection is intended), I consider this a *significant* 
transport issue.

> important context for the protocol review.

OK.

> text describing briefly the general concept of the routing protocol

OK.

> analysis document as appropriate.

My goal is to make some transport properties as notable and discussed in 
as much (or as little) detail as, e.g., multicast and unicast already 
are in the current document.

> Again, individual protocol analysis documents will deal with that where
> it is appropriate, and avoid it where it is a distraction. We do not see
> useful general statements of guidance that can be put into this document.

As noted above, this is already in the document w.r.t. 
multicast/unicast; I'm suggesting that it's equally appropriate to 
include similar discussion of the issues of other layers on routing 
protocol security.

> uni-cast) does seem a helpful addition to the document, and we will do

I'm not sure if this is basically all I'm asking for; see above. The 
intent was to add discussion of some known transport issues that are as 
relevant as the multicast/unicast difference already discussed, in 
similar detail.

Joe

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 12 Jul 2011 23:36:38 +0100

On 12/07/2011 23:23, Joe Touch wrote:
> raises issues with similarly poor use of its terms (e.g., "random" 
> where pseudorandom or arbitrary are intended, or "authenticated" where 

Joe

Please can you suggest a suitable generic term that covers the
set of cases that we need to deal with in routing - i.e.
over the MAC, over IP, over UDP and over TCP, so that we can
discuss inter routing entity message passing as an abstract
operation.

As Joel says when we get to the detailed design of each routing
protocol we will discuss the details, but we want a high level
discussion in this document.

Note BTW that 186 RFCs use the term "on the wire" in this
sort of situation.

- Stewart
> My goal is to make some transport properties as notable and discussed 
> in as much (or as little) detail as, e.g., multicast and unicast 
> already are in the current document.
>
> intent was to add discussion of some known transport issues that are 
> as relevant as the multicast/unicast difference already discussed, in 
> similar detail.
>
> Joe
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Jul 2011 17:26:44 -0700

> Note BTW that 186 RFCs use the term "on the wire" in this

I counted nearly 210, when including "over the wire" too. There are 
similar misuses of, e.g., security terms, though, so let's not let past 
errors suggest continued use.

That said, let's proceed:

First, when you say "on the wire" do you mean:

	(A)- the routing protocol data units (RPDUs)

	(B)- way in which RPDUs are exchanged
		this includes message payloads, meta-info
		(header information), and any other info
		at other layers beyond RPDUs that the routing
		protocol uses or relies upon

I'm presuming the term "on the wire" is intended to differentiate 
between (A) and (B).

There's no good way to describe (B) as a single entity because it's not 
one. You basically are differentiating between the message and the means 
of its communication. The latter is often called a 'channel' in other 
contexts, so maybe that's the term you want - a way to protect the 
'channel'.

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Jul 2011 13:31:00 -0400

Replacing a widely used term ("on the wire") with term that folks will 
not understand does not seem to me personally to be a benefit.

In terms of this document, I do not see a problem with the usage as it 
is.  This is not a protocol document.  The use of the current term in 
this context seems helpful rather than harmful.

Yours,
Joel

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Jul 2011 11:02:25 -0700

Hi, Joel,

> not understand does not seem to me personally to be a benefit.

The problem is that "on the wire" is ambiguous. Many people think they 
know what it means definitively, but their views vary widely.

> is. This is not a protocol document. The use of the current term in this
> context seems helpful rather than harmful.

Since the whole point of this doc centers around protecting the way 
messages are exchanged, not the messages themselves (e.g., as would be 
the case with signed BGP routes), this is a crucial issue to make clear 
and precise in this doc.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 13 Jul 2011 14:24:02 -0400

> not understand does not seem to me personally to be a benefit.

I think Joe's point is that it's widely used as a concept, but what
it means specifically in this document is not clear.  A sentence to
clarify up-front what the definition is in this document might be
enough.

> context seems helpful rather than harmful.

It might be reasonable to add a sentence that says, "In this document,
'on the wire' refers to (A) the routing protocol data itself, as well
as (B) the way in which routing protocol data is exchanged using
underlying protocols, including the headers and other meta-data used by
those underlying protocols", or something like that?

To me, that's a lot more useful than saying "this term is commonly
used" without defining in what sense(s) you mean it in the present
document.

I think it's important because the protections possible are
potentially a lot different, and if you want people to think
about only one or both, it should be made explicit.

On a lighter note, I once generated a lot of confusion using this
term with people working on satellite networks, who were wondering
what wires I could possibly be talking about since all of our links
were microwave.  I guess if KARP covered MANET protocols we'd have
to protect them "on the wireless".

-- 
Wes Eddy
MTI Systems

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Jul 2011 14:34:24 -0400

As I said in my earlier note proposing responses to Joe, we would be 
happy to some text in the front clarifying the usage.  Quoting from my 
earlier email:

This text would note that it is a widely used term in IETF documents, 
including many RFCs.  It would also state for clarity that in this 
document it is used to refer to the message sent from one routing 
process to another.

Apparently, this does not address Joe's concern.

Yours,
Joel

> clarify up-front what the definition is in this document might be

...

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 13 Jul 2011 14:47:03 -0400

> Apparently, this does not address Joe's concern.

"message sent from one routing process to another" doesn't seem to be
right to me either since it sounds like the first definition that
covers routing protocol data only, and not underlying protocols, so I
wouldn't expect that proposal to address Joe's concern.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Jul 2011 11:58:51 -0700

> document it is used to refer to the message sent from one routing

Here's why this is a problem:

1- does this refer to signing a BGP path?

2- does this refer to protecting the channel over which BGP paths are 
exchanged?

 From the intro:
    Four main steps were identified for that tightening:

       o  More secure mechanisms and practices for operating routers.
    ...

       o  Cleaning up the Internet Routing Registry repository [IRR],
    ...

       o  Specifications for cryptographic validation of routing message
          content.
    ...

       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.

So this document is clearly NOT about "the message from one routing 
process to another (that would be 'routing message content', IMO). I.e., 
this doc focuses on securing the transfer mechanism NOT the message.

Thus this is the key to the entirety of the doc. This doc needs to be 
very clear about what this is, at which point it can certainly also then 
refer back to the original RFC (e.g., "this is referred to in RFC 4948 
as 'on the wire'").

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Jul 2011 16:44:34 -0400

Sorry, I apparently missed part of your earlier note.
Would text like:
    This document uses the term "on-the-wire" to talk about the 
information used by routing systems.  This term is widely used in IETF 
RFCs,but is used in several different ways.  In this document, it is 
used to refer both to information exchanged between routing protocol 
instances, and to underlying protocols that may also need to be 
protected in specific circumstances.  Individual protocol analysis 
documents will need to be more specific in their usage.

work to address the issue?
Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Jul 2011 16:58:55 -0400

I don't understand your description of the problem.
As you quote, the document clearly states its scope.
So, when we then define the term "on-the-wire", I don't think we need to 
restate the scope definition.  It woudl seem coutner-productive.

Yours,
Joel

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Jul 2011 14:05:41 -0700

Hi, Joel,

On 7/13/2011 1:44 PM, Joel M. Halpern wrote:
> This document uses the term "on-the-wire" to talk about the information
> used by routing systems. This term is widely used in IETF RFCs,but is
> used in several different ways. In this document, it is used to refer
> both to information exchanged between routing protocol instances, and to
> underlying protocols that may also need to be protected in specific
> circumstances.

I think that is in direct contrast to the current text in the intro, 
that appears to differentiate between the two and focus on the latter.

Joe

> Individual protocol analysis documents will need to be
> more specific in their usage.
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Jul 2011 14:08:13 -0700

Hi, Joel,

> restate the scope definition. It woudl seem coutner-productive.

The current scope is clear from the bullet list only by the assumption 
that (a) the bullets are mutually exclusive, and (b) since the "routing 
message content" is clear, it cannot be part of "on the wire".

I.e., it requires the reader interpret scope by a matter of deduction 
and exclusion, rather than stating it clearly and explicitly.

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Jul 2011 17:26:08 -0400

You wording seems to induce confusion.
Of course the routing message content is part of the message 
on-the-wire.  It is the content of the message.  It is in fact a 
significant part of what is being protected.

What is NOT part of the scope, and which the text says is not part of 
the scope, is the validation of that information.  KARP is not assuring 
that the information is valid.  it is responsible to ensure that the 
message is not modified between the two peers.

Yes, this means that there is an overlap in protection between 
validation information and packet authentication information.  So?  The 
scope is very clear as to whose problem is whose.  (This is merely a 
statement of fact.  If we have path signing and TCP-AO, there are two 
sets of mechanisms preventing modification of some of the BGP 
information.)

The text after the bullet list explicitly says what part is in scope. 
it does not require any assumption or inference.
If there is specific wording you would like to suggest to improve the 
introductory scoping material, I would be happy to look at it.

Yours,
Joel

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Jul 2011 16:02:04 -0700

Hi, Joel,

On 7/13/2011 2:26 PM, Joel M. Halpern wrote:
> validation information and packet authentication information.So? The
> scope is very clear as to whose problem is whose.

That makes absolutely no sense. If there's overlap, then it's obviously 
unclear as to whose problem is whose.

> (This is merely a
> sets of mechanisms preventing modification of some of the BGP information.)

I appreciate that different layers can include redundant protections. 
However, I'm trying to understand what is *expected* from each layer.

> The text after the bullet list explicitly says what part is in scope. it
> does not require any assumption or inference.

Glad to, with a bit more context.

Can you please define what is being validated in the third bullet that 
is NOT protected by the last one or vice versa? AFAICT, it would be:

#3 is entirely responsible for ensuring that a source has permission to 
advertise a particular route

#3 or #4 could confirm the identity of the source of a piece of 
information (#3 is required if transitive, #4 works only if directly 
communicated).

#3 or #4 could confirm the integrity of such information

#4 is required to protect the properties of lower layers insofar as they 
are used as such information to the routing protocol (e.g., BGP tossing 
out routes because TCP connections fail).

If this is the case, then I understand 4 as protecting the *channel* 
over which routing messages are exchanged (which ends up protecting the 
messages too), and 3 as focusing on the routing layer messages themselves.

Is that the case?

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Jul 2011 19:24:57 -0400

I am not sure what you are asking.
KARP is never concerned with whether the party is authorized to send the 
information it is sending.
KARP is concerned with assuring that the information received is either 
the information sent, or recognizably NOT the information sent (so it 
can be discarded.)  (I would have said that more simply, but I have been 
beat up by security folks for descriing what authentication does too 
simply.)  It is also concerned that the receiver be able to correctly 
tell who sent the message, or discard the message.

(Which layer those determinations are made at varies across the 
protocols, and is something we were trying not to get detailed about in 
the design guidelines document.)

Sent and received refer to inforamtion being exchanged between directly 
communicating IP routers.  (Of course, directly depends upon the 
protocol and configuration, as both targetted LDP and remote BGP the two 
parties are directly communicating through other routers.)

This document is NOT supposed to be the framework document for the KARP 
work.  The working group did not have enough energy to produce that, and 
I would therefore not want to turn this into a full-blown framework 
document.
With that understanding, if there is an extra paragraph that will help 
the introduction be clear about this, please send text.

Yours,
Joel

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Jul 2011 16:59:47 -0700

Hi, Joel,

> information it is sending.

Right - that's bullet 3.

> beat up by security folks for describing what authentication does too
> communicating IP routers. (Of course, directly depends upon the protocol
> and configuration, as both targetted LDP and remote BGP the two parties
> are directly communicating through other routers.)

OK - so that's protecting the information exchanged between two routers.

I would argue that it also presumes protecting such information whether 
it's explicit at the routing layer (e.g., BGP path messages), other 
headers (e.g., src/dst addrs, TTLs, and the like, if relied upon by the 
routing protocol), and the semantics of other layers of protocols (e.g., 
whether a connection remains "up", as with TCP or PPTP).

> the introduction be clear about this, please send text.

If we agree on the above, then I can proceed to document suggested 
changes and the paragraph.

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Jul 2011 20:01:21 -0400

There may be a confusion of objectives.
The WG and chairs do not expect the design guidelines document to 
achieve a degree of thoroughness such taht if one checks every item in 
there, and nothing else, then one will be able to do a complete analysis 
of a routing protocol.
Rather, it is intended to provide assistance and a starting point for 
that analysis.  Folks writing analysis documents are expected to bring 
security and routing protocol skills to the table, and to make sure they 
spot all the issues.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Jul 2011 20:02:38 -0400

I am not sure we are in sync, but it looks clsoe enough that proposed 
introductory text would be veyr helpful at this point.

Yours,
Joel