Re: [sidr] request for agenda items for interim meeting 6 Jun

"John G. Scudder" <jgs@juniper.net> Thu, 31 May 2012 17:35 UTC

Return-Path: <jgs@juniper.net>
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 CDA7D11E808C; Thu, 31 May 2012 10:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.584
X-Spam-Level:
X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 blAzuu0y-Oni; Thu, 31 May 2012 10:35:35 -0700 (PDT)
Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id C3E4F11E8081; Thu, 31 May 2012 10:35:26 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKT8er3sILfXaiRdUV/u1457AqwzHDzCt0@postini.com; Thu, 31 May 2012 10:35:34 PDT
Received: from [172.16.13.205] (172.16.13.205) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Thu, 31 May 2012 10:31:30 -0700
MIME-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: "John G. Scudder" <jgs@juniper.net>
In-Reply-To: <D7A0423E5E193F40BE6E94126930C4930B9B247700@MBCLUSTER.xchange.nist.gov>
Date: Thu, 31 May 2012 13:31:29 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <5F5F8CF8-061C-47C9-942C-7908963EF347@juniper.net>
References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <4FBBB6D1.9000008@bbn.com> <m2r4ub7vta.wl%randy@psg.com> <4FBC0936.7000905@bbn.com>, <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> <24B20D14B2CD29478C8D5D6E9CBB29F625F12333@Hermes.columbia.ads.sparta.com> <AAAF2A7E-4CC7-426C-8956-BF68A2327009@juniper.net> <D7A0423E5E193F40BE6E94126930C4930B9B247700@MBCLUSTER.xchange.nist.gov>
To: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
X-Mailer: Apple Mail (2.1278)
Cc: "idr@ietf.org List" <idr@ietf.org>, "Murphy, Sandra" <Sandra.Murphy@sparta.com>, "sidr@ietf.org list" <sidr@ietf.org>
Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun
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: Thu, 31 May 2012 17:35:35 -0000

On May 30, 2012, at 8:02 PM, Sriram, Kotikalapudi wrote:

>> 
>> Right, and agreed (see "formally an attack" above). But to repeat my further
>> point, if the AS_PATH is present (even if not secured): "at least there's scope for a
>> network operator on the receiving end to tolerate the validation failure and use
>> the route anyway, if desired. In the case where there's no AS_PATH, the data are
>> just gone with no chance for appeal."
>> 
> 
> John,
> 
> I do not agree that in the event of "validation failure" the route becomes unusable
> in BGPSEC as currently specified.

That's not what I meant. My point was that a feature may be applied that wants to change the AS_PATH in a way that can't be represented in the BGPSEC_Path_Signatures. In other words, your later statement:

> the Secure_Path segment is still usable as it provides the AS path info.

is not correct in all cases. Likewise, to this statement:

> So validation failure in BGPSEC does not mean that "the data are just gone."

My point is not that validation failure causes this. It's that absent AS_PATH, a semantically non-representable AS_PATH will be lost if forced through BGPSEC_Path_Signatures.

To reiterate, the options to address the case where a feature wants to produce output that can't be represented in BGPSEC_Path_Signatures are:

- Don't solve it. Effectively forbid any such feature.
- Carry both AS_PATH and BGPSEC_Path_Signatures in every update. Rules for reconciliation would be required.
- Downgrade BGPSEC update to BGP update. 
- Extend BGPSEC_Path_Signatures format to be able to represent the needed feature. (As Sandy noted, this only makes sense insofar as the feature isn't formally an attack, so this option is incomplete.)

The validation failure I spoke of is a potential *consequence* of the middle two options above, and as you say, the operator can then decide what to do.

--John