Re: [RPSEC] BGP Security Requirements v08

[Curtis Villamizar <[e-mail]>]

In message <p06240528c2baa0b1241a@[128.89.89.71]>
Stephen Kent writes:
>  
> 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.


I think most of the WG is comfortable with this and is insisting on
it.  How many times do we need to go in circles on this?  Once every
IETF meeting?


> >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.


Yes.  So don't create a protocol that prevents it.


> >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.


The real world problem is that this is the best you are going to get
for attempts to use any such mechanism on most of the Internet at
least during early deployment which might be many years or longer.
There is no sense defining a protocol which won't get deployed.  If
you do there is a good chance it won't be widely implemented - or
implemented at all without someone throwing big money at it.  So even
if the application you have in mind would never trust information from
another island, you need this capability to have some chance that the
protocol you define will get widely implemented and eventually
deployed in enough places to start to gather critical mass.

A bit of optimism maybe.


> Steve


Curtis


_______________________________________________
RPSEC mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rpsec