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.
Whether that restriction is communicated inband or outofband, the
intent to restrict BGP update propagation is the same.
That is a new feature for BGP.
>>
>> 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.
The ability to restrict where a receiver can propagate an update is
not presently BGP behavior. Brand new routing behavior. That's the
difference.
>By adding information to BGP updates.
The information added to BGP updates for BGPSEC is there only to
eliminate bad behaviors. Adding information is not the same as
adding a new BGP routing feature.
>I did not invalidate your summary of the minutes. I simply clarified
>that those a t the interim meeting do not (in this case) speak for all
>of us, and it's not clear how many of us agree. Why is that not
>fair?
You spoke of those who might not agree with the interim meeting.
I was only suggesting that you and anyone not in attendance could
comment on the mailing list, by referring to the archive.
>> The message below asks for idr's (not grow's) consideration of how
>>to proceed. Do you have some objection to idr being part of the
>>definition of a new routing feature?
>Nope, I think it's great, but lets not conflate issues and use
>vagaries where we can be specific. ;)
Glad you agree with the strategy.
--Sandy, explaining a message sent as wg co-chair but giving my
own regular ol' member opinion
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
