Subject: [RPSEC] BGP Security Requirements Draft: Section 2 (II)

From: Russ White <[email-masked]>
Date: Mon, 27 Dec 2004 15:41:42 -0500 (Eastern Standard Time)

Y'all:

More thoughts on the current section 2 of the bgp security requirements doc 
below.

:-)

Russ

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

--

In the deployment requirements section, 2, I would split each of the
items in the bulleted list up into separate subsections, instead of
keeping all this information in a single bulleted list. I would
rereword as follows:

2. Deployment Requirements

We have determined, through discussion with several large internetwork
operators and equipment vendors, that some attributes of BGP are
critical to the operation of the Internet and internetworks using BGP
to provide routing information. Each section below discusses one of
these attributes in detail.

2.1. Convergence Speed

(The text as it sits here is pretty much fine today, though making it
into a section might allow it to be broken up into multiple
paragraphs, instead of one long one).

2.2. Incremental Deployment

I think there are multiple requirements here that aren't called out in
the text very well, and one I'd like to see added, if
possible. Something like this:

We will not be able to deploy a newly secured BGP protocol
instantaneously, and will be unable to dictate a partitioning of large
internetworks by network operators. Because of this, there are several
requirements any proposed mechanism to secure BGP must consider:

o BGP MUST support transmitting, receiving, and acting on both secured
and unsecured routing information with any security system in place.

o The security system MUST allow the formation of peering
relationships with peers supporting or not supporting any security
system designed for BGP.

o The security system MUST use backward compatible in the message
formatting, transmission, and processing of routing information
carried through a mixed security environment. Message formatting in a
fully secured environment MAY be handled in a non-backward compatible
fashion.

The one I'd like to see added here is this:

o In an environment where secure and nonsecured routing information is
transmitted, there MUST be some mechanism for a receiver to determine
if the originator, or any intervening autonomous system, intended the
information to be secured.

IMHO, this one is critical in an incramental deployment. I don't know
if I've worded it right, though.... Thoughts would be appreciated.

2.3. Trust level Variability

(Again, I think the wording in the document is probably fine, but it
should be split into separate paragraphs, and thought through a little
more thoroughly).

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Dec 2004 16:24:17 -0500

More comments and edits, with the usual conventions.

Now that I have gone through Russ's comments on the new document, 
I'll go back to look at the document itself.  Sorry for doing this 
out of order.

Steve
------

We have determined, through discussion with several large 
internetwork operators and equipment vendors, that some attributes of 
BGP are critical to the operation of the Internet and internetworks 
using BGP to provide routing information. Each section below 
discusses one of these attributes in detail.

<the justification provided here is not compelling, as worded. There 
is no indication whether the operators you spoke with represent the 
views of most ISPs around the world, just Tier 1 providers in the 
U.S. or worldwide, etc.>

I think there are multiple requirements here that aren't called out 
in the text very well, and one I'd like to see added, if
possible. Something like this:

o The public Internet not be able to deploy a newly secured BGP 
protocol via a "flag day," i.e., not all ASes will  transiton to a 
secured version of BGP simultaneously. and will be unable to dictate 
a partitioning of large networks by network operators.

<the second part of the sentence seemed to be addressing a second 
order effect of a possible deployment. Is the intent to say that a 
solution MUST allow incremental deployment on an intra-AS basis, as 
well as on an inter-AS basis? If so, say it that way. The we can 
argue over whether this is a reasonable demand :>

Because of this, there are several features that any proposed BGP 
security architecture MUST incorporate:

o BGP speakers that implement BGP security features MUST be able to 
continue to interact with speakers that do not implement the 
features. Thus they MUST support transmitting, receiving, and acting 
on both secured and unsecured routing information.

<I deleted the next bullet because it was redundant relative to the one above.>

< the bullet above seems to anticipate the bullet you added below. I 
question both, not just from the perspective of the technical ability 
to engineer a solution that meets the requirement, but from the 
management perspective. The security community has a fair amount of 
experience in the security arena that shows that folks are very bad 
at managing security-relevant configuration data. We see this al the 
time in enterprise contexts, e.g., in terms of an inability of local 
security managers to secure servers, desktops, laptops, etc. That is 
one reason why firewalls are so popular, i.e., the provide a simpler, 
centralized management capability, even though we also see a general 
inability to manage large firewall rule lists. So, I think it is a 
bad idea to require that incremental deployment be transitive. My 
guess is that operators can manage the notion of which neighbors have 
deployed a security system, just as they do today for the TCP/MD5 
checksum. But, to extend this ASes that are not neighbors is asking 
too much from a management standpoint.>

o In an environment where secure and nonsecured routing information 
is transmitted, there MUST be some mechanism for a receiver to 
determine if the originator, or any intervening autonomous system, 
intended the information to be secured.

<for the reasons cited above, I would strongly recommend against adding this.>

---

From: Russ White <[email-masked]>
Date: Tue, 28 Dec 2004 16:42:59 -0500 (Eastern Standard Time)

> operators and equipment vendors, that some attributes of BGP are critical 
> to the operation of the Internet and internetworks using BGP to provide 
> routing information. Each section below discusses one of these attributes 
> in detail.
>
> <the justification provided here is not compelling, as worded. There is 
> no indication whether the operators you spoke with represent the views of 
> most ISPs around the world, just Tier 1 providers in the U.S. or 
> worldwide, etc.>

These appear to be self-evident, to me....

> o The security system MUST use backward compatible in the message formatting, 
> transmission, and processing of routing information carried through a mixed 
> security environment. Message formatting in a fully secured environment MAY 
> be handled in a non-backward compatible fashion.
>
> question both, not just from the perspective of the technical ability to 
> engineer a solution that meets the requirement, but from the management 
> perspective. The security community has a fair amount of experience in 
> the security arena that shows that folks are very bad at managing 
> security-relevant configuration data. We see this al the time in 
> enterprise contexts, e.g., in terms of an inability of local security 
> managers to secure servers, desktops, laptops, etc. That is one reason 
> why firewalls are so popular, i.e., the provide a simpler, centralized 
> management capability, even though we also see a general inability to 
> manage large firewall rule lists. So, I think it is a bad idea to require 
> that incremental deployment be transitive. My guess is that operators can 
> manage the notion of which neighbors have deployed a security system, 
> just as they do today for the TCP/MD5 checksum. But, to extend this ASes 
> that are not neighbors is asking too much from a management standpoint.>
>
> transmitted, there MUST be some mechanism for a receiver to determine if the 
> originator, or any intervening autonomous system, intended the information to 
> be secured.
>

I don't see how you can, realistically, not require transitive incremental 
deployment in any security system to be deployed. Anything currently being 
deployed in BGP requires transitive incremental deployment.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Wed, 29 Dec 2004 10:07:12 -0500

At 4:42 PM -0500 12/28/04, Russ White wrote:
>>internetwork operators and equipment vendors, that some attributes 
>>of BGP are critical to the operation of the Internet and 
>>internetworks using BGP to provide routing information. Each 
>>section below discusses one of these attributes in detail.
>>
>><the justification provided here is not compelling, as worded. 
>>There is no indication whether the operators you spoke with 
>>represent the views of most ISPs around the world, just Tier 1 
>>providers in the U.S. or worldwide, etc.>
>

if it's self evident, then what is the answer?  I made it a multiple 
choice question, so it's not that hard :-).

>>carried through a mixed security environment. Message formatting in 
>>a fully secured environment MAY be handled in a non-backward 
>>compatible fashion.
>>
>>< the bullet above seems to anticipate the bullet you added below. 
>>I question both, not just from the perspective of the technical 
>>ability to engineer a solution that meets the requirement, but from 
>>the management perspective. The security community has a fair 
>>amount of experience in the security arena that shows that folks 
>>are very bad at managing security-relevant configuration data. We 
>>see this al the time in enterprise contexts, e.g., in terms of an 
>>inability of local security managers to secure servers, desktops, 
>>laptops, etc. That is one reason why firewalls are so popular, 
>>i.e., the provide a simpler, centralized management capability, 
>>even though we also see a general inability to manage large 
>>firewall rule lists. So, I think it is a bad idea to require that 
>>incremental deployment be transitive. My guess is that operators 
>>can manage the notion of which neighbors have deployed a security 
>>system, just as they do today for the TCP/MD5 checksum. But, to 
>>extend this ASes that are not neighbors is asking too much from a 
>>management standpoint.>
>>
>I don't see how you can, realistically, not require transitive 
>incremental deployment in any security system to be deployed. 
>Anything currently being deployed in BGP requires transitive 
>incremental deployment.

Maybe I don't understand what you mean by "transitive incremental 
deployment." What I said was that it makes sense to deploy BGP 
security in adjacent ASes, incrementally, which seems to be what is 
done today for other, new BGP features. Requiring that two 
non-adjacent ASes that have deployed BGP security features be able to 
take advantage of these features imposes a significant management 
burden that will likely lead to management-induced security problems.

Steve