Re: [sidr] various

Brian Dickson <brian.peter.dickson@gmail.com> Sat, 12 November 2011 17:29 UTC

Return-Path: <brian.peter.dickson@gmail.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 C7EFC21F85AE for <sidr@ietfa.amsl.com>; Sat, 12 Nov 2011 09:29:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.546
X-Spam-Level:
X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 R7+PpKVNVKXH for <sidr@ietfa.amsl.com>; Sat, 12 Nov 2011 09:29:07 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 01C9521F8540 for <sidr@ietf.org>; Sat, 12 Nov 2011 09:29:06 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so5325699bkb.31 for <sidr@ietf.org>; Sat, 12 Nov 2011 09:29:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Eud7Z8Ee5b0OzdrHiFYhC4pQcv46IEBSJ+YJZ5LIt20=; b=QwROyoYXgHckCFwlUel0zhKn8dZWtBKn2xfhjChT7nY4/AZJUyiSPlTbvTPS1iXcmu OXnRh+pU2iVjH5rx4oAvpB2wFtz1BNlRNgSmvtATy359N1xgzYx5+ihPoBE3R5QjRDLp A2eRatA2IMIXQfD0TCfGReLU6EYsG2UD6H8QU=
MIME-Version: 1.0
Received: by 10.204.7.133 with SMTP id d5mr12907497bkd.64.1321118945917; Sat, 12 Nov 2011 09:29:05 -0800 (PST)
Received: by 10.223.54.15 with HTTP; Sat, 12 Nov 2011 09:29:05 -0800 (PST)
In-Reply-To: <m2ehxef1ob.wl%randy@psg.com>
References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> <DCC302FAA9FE5F4BBA4DCAD4656937791451B2CC8D@PRVPEXVS03.corp.twcable.com> <m2ehxef1ob.wl%randy@psg.com>
Date: Sat, 12 Nov 2011 12:29:05 -0500
Message-ID: <CAH1iCiqFLU0rTWtu5hSXa1+D=cHqpf=2u4ArP4XNk986MVX03Q@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Randy Bush <randy@psg.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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 17:29:07 -0000

In the case of confederations, and presuming BGPSEC is used among the
confederation members,
it should be the case that upon entry to the confederation, the "TO"
ASN of the sender's signature
is the AS Confederation Identifier, i.e. the externally visible ASN as
which the confederation appears
to its eBGP neighbors.

The confederation will, in propagating an eBGP announcement, create an
AS_CONFED_SEQUENCE,
and corresponding signatures.

Removing the signatures and removing the AS_CONFED_SEQUENCE, I
believe, will preserve the
signature validity, since the confederation member sending to a
non-confederation member will add
the AS Confederation Identifier (ASN) to the AS_SEQUENCE, and add its
signature. The AS-path
and signatures over such, will be valid/consistent. I.e., I think it
"just works".

So, I propose the following alternative text:

  To prevent exposure of the internals of BGP Confederations [RFC5065],
  and to comply with the requirement that the AS_SEQUENCE be identical
  to the sequence of ASNs from the Signature-Block, a BGPsec speaker
  which is a Member-AS of a Confederation MUST remove every Signature-
  Segment which corresponds to a unique ASN in the AS_CONFED_SEQUENCE
  prior to the AS_CONFED_SEQUENCE being removed from the AS_PATH,
  and prior to adding its own Signature-Segment to the Signature-Block.

Or, wording to that effect.

Brian

On Fri, Nov 11, 2011 at 10:40 PM, Randy Bush <randy@psg.com> wrote:
> to two of your comments, in my unpublished edit buffers
>
> 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.
>
> 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?
>
> randy
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>