On Sat, Nov 12, 2011 at 7:45 PM, George, Wes <[email protected]> wrote:
>> From: Randy Bush [mailto:[email protected]]
>> Sent: Saturday, November 12, 2011 9:58 AM
>> To: George, Wes
>> Cc: sidr wg list
>> Subject: Re: various
>>
>> > Do you or do you not agree that on the transition between private ASN
>> > and public, if remove-private is configured, any signatures
>> containing
>> > private ASN must be removed even if the eBGP peer is BGPSec capable?
>>
>> with the statement as is, if it is a private asn or a public asn, it is
>> not signing.
>
> [WEG] sigh. Let me try one more time.
> This question is not about confederations so "the statement" is not 
> applicable.
> Think just bog-standard, vanilla eBGP, with two BGPSec speakers, one of whom 
> is using a private ASN, announcing routes that must be carried to the DFZ. 
> Make more sense now as to why I'm making the distinction between private and 
> public ASN?

Should we presume in your example, that the sequence is:

private -> public -> public

I.e. that there is no public ASN before the private ASN, and the route
is originated by the private AS?

I think the answer is something along the lines of, the private AS
announces with its private AS as the origin,
and the upstream public AS has its own trust anchor for assigning its
instances of private AS ROA records.

The public AS, to the outside world, appears to be the real
originator, so the original signature is stripped completely,
and a new signature block created using the public AS's "real" ROA
info and signed as if it really was originated.

Everything works beyond that.

There really cannot be a transitive 1918->non-1918 signature path,
because there cannot be 1918 ROAs with global significance, because of
the AS's non-uniqueness.

BGPsec from the announcer, transitively, can only be done with a
public ASN. 4-byte ASNs are available now, expect demand to increase
with BGPsec, IMHO.

Brian
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to