Hi, Joel,
On 7/13/2011 2:26 PM, Joel M. Halpern wrote:
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.
That makes absolutely no sense. If there's overlap, then it's obviously
unclear 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.)
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.
If there is specific wording you would like to suggest to improve the
introductory scoping material, I would be happy to look at it.
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
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
