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
On 7/13/2011 5:08 PM, Joe Touch wrote:
Hi, Joel,
On 7/13/2011 1:58 PM, Joel M. Halpern wrote:
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.
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
Yours,
Joel
On 7/13/2011 2:58 PM, Joe Touch wrote:
On 7/13/2011 11:34 AM, Joel M. Halpern wrote:
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.
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
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf