On Fri, Mar 16, 2012 at 4:54 PM, Christopher Morrow <[email protected] > wrote:
> (behind on my reading, but...) > > On Fri, Mar 16, 2012 at 11:56 AM, Brian Dickson > <[email protected]> wrote: > > 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's probably the high-level-goal... 'hi everyone, these routes are > from a "peer", fyi!' to which the further away bgp receiver could then > say: "Oh, I see "peer" routes between two other "peer" sets, that's > not valid according to my policy setup." ?? > > this seems, to me, to get very confusing very quickly. Policed at the > immediate transit/peer/customer boundaries it seems feasible to make > this sort of decision, but further away, ouch. Especially if the > attribute isn't mandated to be used, and if there's no place to check > that 'oh, they set that flag properly for that relationship, good!'. > > Yes, you are correct on all counts. Especially the confusing bit. It would need to be mandated (modulo peer capabilities negotiation). It would need to be tracked/recorded 1:1 with AS hops. It would need to be protected against clobbering, a la crypto. But, with those provisos, you can then validate that the path is sane, policy-wise, is consistent with your local peer/peer policy, and is un-fooled-around-with. Those together, give leak proofing. > > > > > > That is not correct, i.e. you misunderstand. > > > > The desired outcome is that sender/receiver _negotiate_ what is or is > not to > > be sent, > > sender/receiver BGP SPEAKERS negotiate capabilities ('I have > larger-packet capability' || 'only small packets for me') > > > and the protocol merely enforces what has been agreed upon. The automatic > > enforcement > > bgp simply passes along the attributes (well, the protocol does, the > 'process' does many other things, potentially). > > > of this high-level policy, is what stops route leaks from being > initiated or > > propagated. > > policy per BGP PEER, right? > > Yep - where "peer" here means not just neighbor AS, but peering instance with that AS. > > 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. > > If you mean 'ip addresses' and 'ASNs' of the BGP PEERs in question... > you're describing 2 different checks at 2 different layers, I think. > > ip-address is really a tcp-stack question here: > "I tried to connect to 1.2.3.4 from 1.2.3.3, he expected 10.1.1.1 > to connect to his 10.1.1.2" > ASN is checked inside the BGP (application) process: > "I am AS1 I am connecting to AS2, he said AS3 oops!" > > Yep. Add to that, "We both want to do (leak-proofing + bgpsec), I'm her transit provider, she's my transit customer, good." Or, "She think's I'm a Peer, I think she's my transit provider, oops!". It is a 4 x 4 matrix with only 4 "good" combos. > > Unilateral misconfiguration (whether by accident or deliberate act), > which > > could have introduced > > or propagated route leaks, are prevented. > > So, your check would exist at the application above: > "I am AS1, i provide transit to AS2, he says he's AS2 but that he > provides transit to me, OOPS!" ?? > > Yes, except that "we are doing mutual transit" is one of the valid combos. But, yes, strict transit both ways is "ooops!". > > > > 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. > > Those (aspath/prefix-filter/communities) happen on a per-session basis > today in 'configured policy' (operator configured for example) but do > not enter into the application 'session' setup, nor the tcp-stack > parts of the setup. Moving the proposed check into the application > 'session' setup is interesting. > > > 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 > > Imagining the CPE config for this, is a default 'send all routes' > desired here? (desired in all deployments with the assumption that CPE > folk just config as they do today with no extra settings, but > ISP/Transit folks have to do the 'complicated' part?) > > Yes, except now it becomes very easy on both parts while assuring the "right stuff" happens. (I would still advocate the complicated stuff until at least a couple of revs of code are debugged by my competitors.) CPE == "hey, I'm a noob. So I turn on BGP, it comes up, I'm your customer?" ISP == "Yep." CPE: neighbor IPv4|IPv6 as NNN.NNN transit ISP: neighbor IPv4|IPv6 as MMM.MMM customer where "customer" does leak-proofing by allowing properly colored routes from the customer (only), and sends everything. And "transit" does leak-proofing by allowing all routes and sending only properly colored routes. Coloring done on the links is: (self) == colored "customer"; (customer) == mark as non-customer on send, preserve color on receipt; (transit) == preserve color on receipt, preserve color on send. > > 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.) > > how so? if you and I agree that I am a 'customer' and i want you to > 'send all routes' from me, and I will 'not send all routes' from > you... that's 'restricting update propogation' isn't it? > > It is what happens today, it just changes the mechanics and enforcement of this. It is policy, reduced to an absolute minimum, baked into the process/protocol. It does not change the policy per se, so long as one of the options is suitable, for every peering session. (It is.) > I suppose the next step in the 'negotiate capabilities' in my simple > example above is: > If 'send-all-routes' > add community TRANSIT-CUSTOMER > > followed by, at the isp/provider/transit edge: > If community == TRANSIT-CUSTOMER: > accept-route-to-externals > > So, the capability itself doesn't 'restrict update propogation', > "local policy" does, which seems good/fine. > > Yep - except that you need to use extended communities, include the ASN:TRANSIT-CUSTOMER in the community, and prevent modification or stripping of communities. Then, the logic becomes: match extcommunity ^(*:TRANSIT-CUSTOMER)* (*:PEER)? (*:TRANSIT-PROVIDER)*$ accept else reject (and more restrictive on peers and customers) > >> 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. > > which WG? (you mention plural above, and singular here) > > SIDR. > > I do not believe the charter explicitly forces > > the WG onto one side of the line in the sand (feature/not-feature). > > no, the AD's had said (paraphrased): > bgp-mechanics belong in idr > security bgp belongs in Sidr > > Sandy is arguing here that the proposal is 'mechanics' nor 'securing > of the idr' I think. > > What I'm suggesting is, implicit in the charter is that any mechanics necessary to achieve "security", can be read as delegated to SIDR. I'm not suggesting going overboard, but I do suggest that you can't make an omlette (adding security to BGP) without breaking eggs (touching, however slightly, BGP mechanics and semantics.) > > 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. > > I'm not sure I see that, but ... how about this approach. Would adding > the transit/not-transit bit (simplification) to BGP independent of any > security be of interest to BGP/IDR people? Would it help to 'secure' > BGP? > > Yes, it would. There are only two problems I see with that, or maybe more if you combine them. (1) In order to achieve leak-proofing, the whole of the AS_PATH needs a corresponding COLOR_PATH. (Or, modulo information-hiding so no info leakage occurs via COLOR_PATH, see the third ID for how & why). That's a lot of overhead, and if the exact same kind of overhead is already needed for BGPSEC, it'd be easier to piggy-back one bit on the sig block (or encode via algorithm choice!!) (2) You still have to secure the result, for adding protection against malicious path manipulation, even in the case where BGPSEC signatures are on the paths. Otherwise, the color could be manipulated, defeating both leak-proofing and, to a lesser degree, BGPSEC. So, I see it as both a target-of-opportunity (how much lower do you need the fruit to hang??), and a synergistic way of making the added work of either, more attractive when the two are combined. > > 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. > > Sure, sort of like deprecating as-set usage... which happened in IDR, > but was a consequence of discussion in SIDR that said: "Hey, we have > no idea how to secure this, it's non-deterministic data and the > aggregator doesn't have required material in order to 'secure' the > as-set which is in the as-path. Beyond that the usage of AS-SET in the > wild is by and large broken/not-helpful, so deprecating this will not > harm existing users of the system." > > Which I think is basically what's happening with this discussion, no? > perhaps we/wgfolk did a "Exercise is left to the reader, but for now > go talk to IDR"? > > I'm cool with that... > -chris > hoping to read the drafts during the next week... >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
