Subject: [RPSEC] proposed message to the IESG

From: Russ White <[email-masked]>
Date: Thu, 20 Jan 2005 14:00:25 -0500 (Eastern Standard Time)

> 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.

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.

--

> 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.

--

> 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?

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jan 2005 11:09:05 -0500

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