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

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 23 Jul 2006 12:08:56 +0200

On 21-jul-2006, at 20:44, Tony Li wrote:

>> suppose a new system
>> includes a way to authenticate the AS path by requiring each AS/
>> router to sign its changes to the AS path. Now there is a non-
>> upgraded AS in the middle. Obviously this makes it impossible to
>> authenticate the AS path in this manner. This makes it unnecessary
>> and therefore harmful to include the AS path authentication
>> information when sending an update to a non-upgraded router.

> It seems to me that if path authentication information is carried  
> across
> a non-upgraded AS, that the non-upgraded AS is always going to see  
> that
> as useless and by your logic harmful information.

I assumed the determination of usefulness to be wider than just a  
single AS.

Others pointed out that path authentication could still work if there  
are non-upgraded, but trustworthy ASes in the middle of the path.

I suppose the issue isn't a black/white one. This makes it harder to  
determine what to do in practice, but that doesn't alleviate my  
concern that some people may want to dump several hundred bytes of  
authentication data in the path attributes for each prefix they  
source since this data MAY be useful somewhere, and routers all over  
the internet start running out of memory.

> If we prohibit a
> solution from ever asking for opaque transport, then we lose out on
> potential benefit.

The greatest benefit of all is keeping the internet running.  :-)

Making it run securely is a secondary consideration.

> Obviously, any solution needs to be cognizant of how it will behave  
> in a
> non-contiguous deployment and make intelligent decisions as to how it
> will operate.  However, I'm unwilling to support a requirement that  
> says
> that a solution may not use opaque transport of path attributes.
> There's a possible benefit that we should not prohibit.

Right. I wasn't saying that this should be prohibited, my problem is  
that some requirements indirectly (seem to) mandate this approach,  
rather than just allow it, even in cases where it is either harmful  
and/or has no benefits.

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