From: "George, Wes" <wesley.george@twcable.com>
To: Randy Bush <randy@psg.com>
Date: Sat, 12 Nov 2011 00:41:10 -0500
Thread-Topic: various
Thread-Index: Acyg7OK1AuGT5SM6Q/eB0ZwemBiAlAAAxTMA
Message-ID: <DCC302FAA9FE5F4BBA4DCAD4656937791451B2CCDA@PRVPEXVS03.corp.twcable.com>
References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com>
 <4EB02586.5010101@bbn.com>
 <DCC302FAA9FE5F4BBA4DCAD4656937791451B2CC8D@PRVPEXVS03.corp.twcable.com>
 <m2ehxef1ob.wl%randy@psg.com>
In-Reply-To: <m2ehxef1ob.wl%randy@psg.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] various
Precedence: list

> From: Randy Bush [mailto:randy@psg.com]
> Sent: Friday, November 11, 2011 10:41 PM
> To: George, Wes
> Cc: sidr wg list
> Subject: various
>
> draft-ietf-sidr-bgpsec-ops-02
>
>    To prevent exposure of the internals of BGP Confederations
> [RFC5065],
>    a BGPsec speaker which is a Member-AS of a Confederation MUST NOT
> not
>    sign updates sent to another Member-AS of the same Confederation.
>

[WEG] does that mean that routes using confeds as transit ASes cannot parti=
cipate in BGPSec at all?
(eg if the update path goes:
Origin ASN -> confed AS ($private) -> confed AS ($public) -> eBGP peer)
If that's the case, would be useful to be more explicit about it.

Or do you mean that confed AS1 will not be in the signature chain/AS path a=
nd the public ASBR (the external side of the confed) will sign as if it lea=
rned the routes directly from the Origin ASN? If it's the latter, you proba=
bly need more clarifying text, and that may actually require some text in t=
he protocol definition to cover the special-case handling.

Related: It may be that we have to simply say that Private ASNs can't be BG=
PSec participants, whether in confeds or otherwise, for many of the same re=
asons - AFAICT it'd be impossible to build a signature path and then update=
 it downstream to reflect the external AS it gets replaced with.

> draft-ietf-sidr-pfx-validate-04
>
>    An implementation MUST support 4 Octet AS Numbers, [RFC4893].
>
> as our friendly blood-sucking vendors have said, the latter is thought
> to be obvious.  but i figured to document it anyway, no harm.
>
> cool?

[WEG] works for me!

Wes

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.