Subject: [RPSEC] issue: coverage

From: Sandy Murphy <[email-masked]>
Date: Tue, 8 Mar 2005 13:55:26 -0500 (EST)

There have been a few messages from people saying that the draft
should indicate what it is going to cover and suggesting that it must
cover lots of BGP features that aren't in the base spec.  The list
included:

communities
confederations
VPN's
MPLS
flap dampening
route reflectors
MBGP

The draft as written won't cover these.  I can see no discussion on
the list of coming to consensus of what is to be covered and what not.

I see the point of those who say that the other features (which are
carried in the protocol) must be covered in the security requirements.
If the security requirements should happen to disable one of these
features, that would not be a good thing.  OTOH, I also heartily
endorse Bill's comment about the inclusion of all these features
representing a full employment act for BGP security folks.

So what's the consensus?  Base spec, Base spec with a best-effort eye
to avoid preventing use of other extensions, or base spec plus all
spec'd extensions?

--Sandy

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

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 10 Mar 2005 11:11:28 +0100

I am responsible for several of the posts on this so I will respond now.

Omitting all these extensions is fine by me but:

- I would expect protests at the IESG/AD level that we are excluding IPv6; my
impresssion is that such behaviour is politically incorrect.

- I would expect operator protests at the exclusion of communities (eg RFC 3765,
RFC 1997) since I believe they are often used to effect policy of the kind that
has been much discussed on this list.

I agree about the lack of consensus over this.

Tom Petch

---

From: Russ White <[email-masked]>
Date: Thu, 10 Mar 2005 13:52:44 -0500 (Eastern Standard Time)

> confederations

I don't see much we can do here, actually....

> MPLS

Well, MPLS is one specific case of a VPN. As long as VPNs stay within a 
single provider, we are fine here, because they essentially don't matter 
from the perspective of the work we're doing.

However, when we get into multiprovider VPNs, we run against a brick 
wall.... :-( In most of these cases, we will find the customer's IGP cost 
carried as a community, which leads to the first case you mention, and the 
case I attempted to address in another email, basically as: "I don't have a 
clue how we can address this case."

Further, there is a legitimate need to change some of the attributes 
associated with a VPNv4 route, either in the 2547 model, or the "biscuit" 
model (the current work with L2TP, GRE, and others, which, though I've not 
looked at it a lot, seems to be a generalization of 2547). For a specific 
instance, the customer might _want_ you to modify the IGP metrics they've 
dumped into BGP at the AS boundary. Another specific instance is that you 
need to be able to change the route target and identifier at the AS 
boundary, since you and the other AS may not have the same actual numbering 
systems, and such (?).

> flap dampening

This is local to a router, so is not an attribute.

> route reflectors

Again, local, and thus not an attribute.

> MBGP

MBGP attributes, policies, and etc, are similar to unicast and other 
AFI/SAFI's, so I don't think we need to worry much, here (?). I would think 
it's best to get some basic work done, and worry about this one later, if 
possible.

I would say base spec + best effort, based on what the concensus is of 
what's important.

:-)

Russ

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