(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!'.
>
>
> 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?
> 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!"
> 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!" ??
>
> 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?)
> 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?
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.
>> 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)
> 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.
> 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?
> 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"?
-chris
hoping to read the drafts during the next week...
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
