Re: [sidr] various

"George, Wes" <wesley.george@twcable.com> Sat, 12 November 2011 05:40 UTC

Return-Path: <wesley.george@twcable.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8981F0C4F for <sidr@ietfa.amsl.com>; Fri, 11 Nov 2011 21:40:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.345
X-Spam-Level:
X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vaz3fmqBPOo for <sidr@ietfa.amsl.com>; Fri, 11 Nov 2011 21:40:51 -0800 (PST)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 014B41F0C3C for <sidr@ietf.org>; Fri, 11 Nov 2011 21:40:50 -0800 (PST)
X-SENDER-IP: 10.136.163.15
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.69,498,1315195200"; d="scan'208";a="281299858"
Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Nov 2011 00:36:02 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Sat, 12 Nov 2011 00:40:49 -0500
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
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Nov 2011 05:40:51 -0000

> 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 participate 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 and the public ASBR (the external side of the confed) will sign as if it learned the routes directly from the Origin ASN? If it's the latter, you probably need more clarifying text, and that may actually require some text in the protocol definition to cover the special-case handling.

Related: It may be that we have to simply say that Private ASNs can't be BGPSec participants, whether in confeds or otherwise, for many of the same reasons - 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 proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use 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 dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.