On Thu, Mar 15, 2012 at 8:22 PM, Murphy, Sandra <[email protected]>wrote:
> speaking more as regular ol' member > > On Wednesday, March 14, 2012 5:31 PM, Eric Osterweil said: > > >> BGP presently has no feature that lets the sender restrict where the > >>receiver might propagate a route. So the security protections would > >>have to invent the fea ture and secure it at the same time. > > >This presumes the protections are to be incorporated into the control > >plane. I don't know that everyone feels that way, which is why I > >suggested my second comment. > > My understanding of the desired outcome is that the sending ISP wishes > to put restrictions on what the receiving ISP can do with the update. > That is not correct, i.e. you misunderstand. The desired outcome is that sender/receiver _negotiate_ what is or is not to be sent, and the protocol merely enforces what has been agreed upon. The automatic enforcement of this high-level policy, is what stops route leaks from being initiated or propagated. The policy is still determined by the operators at both ends of a peering session. Just like the IP addresses and ASNs, the policies have to match for BGP session establishment. Unilateral misconfiguration (whether by accident or deliberate act), which could have introduced or propagated route leaks, are prevented. The proposal(s) provide all the mechanisms to express any mutually-agreeable policy, including "send all routes in both directions". They do not preclude other refinements, such as AS-path filters, prefix filters, communities-related processing, or anything else. Nothing is unilateral, in what is proposed, so saying that the sending ISP puts restrictions on what the receiver can do, is actually a gross mischaracterization. (No intent is inferred, of course - it is clearly just a misunderstanding of the purpose and intent of the proposals.) > Whether that restriction is communicated inband or outofband, the > intent to restrict BGP update propagation is the same. > > (Incorrect.) > That is a new feature for BGP. > Correct, although whether this is part of BGPSEC (itself a new feature) or not, is the main thing to be discussed, inclusive of IDR's input. > > >> > >> The consensus of the meeting was that this is a bad way to do > >>design. Adding a new feature as part of adding a new security > >>protection has been found to lead to problems. > > >So, now maybe I'm confused... Is BGPSEC not adding a new feature, or > >is it a bad way to do design? > > BGPSEC is not a new *routing* feature. It is protections for existing > routing features. BGPSEC eliminates certain *bad* routing behavior, > but it should not create *new* routing features. > > Pot_ay_to, pot_ah_to. It should fall to the _WG_ to determine whether BGPSEC _is_, and/or _should_, be treated as a new feature. I do not believe the charter explicitly forces the WG onto one side of the line in the sand (feature/not-feature). And, I believe fundamentally, it _needs_ to be a new feature (set) on BGP, with all that goes along with it. There seems to be a strong reluctance among a subset of folks, to say this is a new feature set. This reluctance is appearing to fracture the WG into an us/them dichotomy, which is antithetical to the IETF philosophy. If BGPSEC were not a new feature, there would not be any need to add the BGP options negotiation between peers doing BGPSEC. And, if we acknowledge that it is a new feature, it then is incumbent on the WG members and chairs, to listen to all the WG participants, regarding what the requirements are in reaching the charter's goals, whether they are explicitly in the charter, or implicit consequences of what is necessary and sufficient in reaching those goals. This would potentially include other attributes being added, other data being cryptographically protected, and/or other negotiated peering parameters. Brian
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
