Re: [RPSEC] BGP Security Requirements v08

At 9:33 AM -0400 7/11/07, Russ White wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>>>  I see this requirement as a (possibly unnecessary) corollary to the
>>>  requirement for supporting non-contiguous deployments.  The fact that
>>>  the interpretation is ambiguous about how specifically one achieves this
>>>  goal (perhaps properly) reflects the fact that solutions can get
>>>  creative.
>>
>>  "A BGP security mechanism MUST provide backward compatibility in
>>  the message formatting, transmission, and processing of routing
>>  information carried through a mixed security environment.  Message
>>  formatting in a fully secured environment MAY be handled in a
>>  non-backward compatible fashion. Care must be taken to ensure either that
>>  UPDATES can traverse intermediate routers which don't support the new
>>  format, or that UPDATEs using a new format are not sent to ASes that cannot
>>  support such messages."
>
>This is a pretty traditional and standard argument in routing protocol
>circles whenever extensions to a routing protocol are proposed--do we
>make it so older routers can at least forward the new information, or do
>we make it so it won't work in the presence of older routers? IMHO, it
>generally comes down to--is the information useful to routers on the
>other side of the nonsupporting router?

I agree that it is generally useful to have a router forward data 
that it can't use itself, but that a later router might be able to 
use.  However, I am not comfortable with a suggestion that if a 
solution cannot always guarantee this capability, that it is an 
unacceptable solution.

>Maybe it's useful to break this into two questions?
>
>1. Is information about the authorization of an originator to advertise
>reachability useful to AS' on the "other side" of a non-supporting AS?

it could be useful.

>2. Is information about the validity of an AS path useful to AS' on the
>"other side" of a non-supporting AS?

because there may be no way to verify the number, much less the 
identify of ASes listed in an UPDATE between the end of the secured 
path and the current AS, the utility of the passing that data beyond 
the end of the secured part of the path is questionable.

Steve

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec