Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt

From: [email-masked]
Date: Fri, 21 Jul 2006 13:48:19 -0400 (EDT)

Curtis  Villamizar said:

Iljitsch van Beijnum writes:
>> >   2.  A BGP security mechanisms may authenticate (or encrypte)
>>
>> Encrypt?
>
>
>Not likely imho.  Ask Sandy?  :-)

I don't know that I'm the right person to ask - Russ White or Sue
Hares might have more data to give an answer based on facts.

But I can speculate.  I have heard people say that they do not
want to reveal routing information to everyone.  Usually this is
motivated as not wanting to reveal the topology info of their
infrastructure.  I may not grok the need, but I have heard it
expressed.

>You never know though.  Approximate GPS
>location of a mobile router would be encrypted if anyone every decided
>they needed that.  Location could be used in routing. 

In my own blue-sky-ing, I was thinking of the presentation at the
idr meeting about QoS needs in the GIG.  Some QoS parameters might
provide info the sender would not want revealed to just anyone.

>> It would certainly be a bad idea to carry information in path
>> attributes that is invalidated as soon as it is relayed by a non-
>> upgraded router. (This is just an example of a bad idea.)
>
>
>If authentication information is all that is added to BGP then tossing
>*all* the authentication information is certainly a bad idea.
>
>What might make sense is to toss any per hop path authentication
>before advertising to a router that would not add its authentication.
>That would make sense if policy was based only on prefering a route
>with a completely authenticated path over one that is not complete but
>did not prefer paths with less hops not authenticated over ones with
>more hops not authenticated.  OTOH if a completely authenticated path
>was not available a path with only AS from a small set of fairly well
>trusted AS in it might be preferred over one with more untrusted AS.

I agree with this, particularly if you mean preferring a *partially*
authenticated path with a gap over fairly well trusted ASs.

>Removing information because it won't be needed downstream could be
>considered a configurable space optimization.   Sound like I need a
>SHOULD in that paragraph, making it.
>
>> >   1.  The security information SHOULD be passed intact but
>> >       uninterpreted across routers that did not support the same
>> >       security mechanism.

As I noted in another message, a mechanism carried in an optional
transitive attribute is (likely?) configurable already, given the
SHOULD status of propogating it in the BGP spec.  So your SHOULD is
implementable.

--Sandy

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