Subject: RE: [RPSEC] proposed message to the IESG - Aggregation issues

From: "Susan Hares" <[email-masked]>
Date: Wed, 26 Jan 2005 13:48:06 -0500

Stephen, Russ and Blaine: 

For aggregation issues regarding draft-26, 

I would suggest you review the implementation 

report on BGP (draft-26).  Look at the

questions regarding aggregation. These are contained in:

 section 3.46

 Pages 72-75.

This is a description of the aggregation functions

per the BGP specification and the results from

a set of vendors as to the capability. 

Perhaps this language will provide details from 3 vendors

(cisco, Nexthop, Laurel networks).   

Of course, I'd be glad to collect additional responses

from BGP implementers on the survey or this portion.

Sue

  _____  

From: Stephen Kent [mailto:[email-masked]] 
Sent: Friday, January 21, 2005 11:09 AM
To: Russ White
Cc: [email-masked]
Subject: Re: [RPSEC] proposed message to the IESG

At 2:00 PM -0500 1/20/05, Russ White wrote:

		In contrast, Russ White, a co-chair of the WG and a
contributor to this RPSEC document, has asserted that operational
experience should be the primary driver for the requirements document.
Russ has stated that the BGP spec cited above does not accurately
reflect BGP implementation and deployment patterns, and thus is not a
suitable basis for the security requirements document that the WG is
slated to develop.

	Rephrase this to:

	Russ White.... believes the specifications requirement should be
based on an analysis of what is provable within an internetwork using
BGP as its routing protocol, rather than the proving the processes
within the BGP specification have been followed, specifically.

In one of your messages on 1/6 you said:

And at some point, the WG has to decide which of these two models is
valid. I believe that I've made a strong case to consider the
operational use as a valid model, because of gaps in the alternative
model.

This was in response to my comment:

	We both have prejudices in approaching this problem.  One can
fairly say that I used the BGP spec as the basis for developing the
security requirements model that we then addressed with S-BGP. Likewise,
you adopted an operations-oriented view of security when you developed
soBGP. That does not make either approach intrinsically valid or
invalid.

So, based on your comment above, my wording of the fundamental issue
seems accurate.

	I don't claim the BGP spec is wrong, just that the important
questions aren't about process, but how the information in the system
matches reality.

You and I have argued over whether the path in an UPDATE is
representative of the path via which the UPDATE was transmitted. You
said no, yet the spec says yes, as I pointed out. This seems like a
clear example where you believe that the way BGP works does not match
the spec.

Also, a message from Iljitsch on 1/6/05 includes the comment:

Now all of this non-RFC-compliant aggregation works without any problems
because of the longest match first rule.

We have discussed whether aggregation is performed as specified in the
spec, e.g., with regard to use of the ATOMIC AGGREGATE attribute. I
asked colleague to analyze UPDATEs from RV, for all of 2004, and I
reported the results in a message earlier this week. It shows that about
6% or all UPDATEs contain this attribute.  Yet have received messages
from folks who say that this attribute is almost certainly being used in
a non-conformant fashion today.

I can revise the text to say that you and others have questioned whether
the BGP spec matches the way BGP is used in practice.

		Russ has stated that many of these do not reflect BGP
implementation and deployment, hence his insistence on a different basis
for requirements development. I have objected because Russ has not been
able to cite IETF-approved documents that describe the basis he
supports.

	See above. It's not a matter of citing other specifications.
Many of the things which need to be secured are outside IETF
specifications to begin with. For instance, the authorization to
advertise a specific block of addresses is completely outside the BGP
specification, since the BGP specification doesn't cover such things as
how to get an address block, etc. And yet, I think we all agree that
this is a critical requirement.

so, the simple form of your response is that there are no IETF standards
for what you feel are critical aspects of what needs to be considered re
BGP security. Sounds like what I said.

	--

	It seems inappropriate for the IETF to adopt a BGP security
requirements document that employs rationale that conflicts with the BGP
spec, especially when both are developed in the same area.

	Could you please cite a specific instance where the requirements
document actually contradicts the BGP specification?

The question is not whether the security requirements contradict the BGP
spec, but whether the rationale for most of the requirements derives
from the BGP spec. A security requirement can be stated that neither
conforms to the spec nor contradicts it, but that does not make it an
appropriate requirement. Unless we agree on the basis for the
requirements, we can't objectively decide which ones are reasonable and
which are not. That is the argument we are having, and the one that
needs to be resolved before we can make progress.

Steve

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec