Re: [sidr] pCNT & prepending

"Montgomery, Douglas" <dougm@nist.gov> Thu, 28 July 2011 19:58 UTC

Return-Path: <dougm@nist.gov>
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 098D121F8AA8 for <sidr@ietfa.amsl.com>; Thu, 28 Jul 2011 12:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.322
X-Spam-Level:
X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QHE9TXa5F09 for <sidr@ietfa.amsl.com>; Thu, 28 Jul 2011 12:58:01 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 41BC421F8A7B for <sidr@ietf.org>; Thu, 28 Jul 2011 12:58:01 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.323.0; Thu, 28 Jul 2011 15:58:08 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 28 Jul 2011 15:58:00 -0400
From: "Montgomery, Douglas" <dougm@nist.gov>
To: Highwayman <chris.hall@highwayman.com>
Date: Thu, 28 Jul 2011 15:55:06 -0400
Thread-Topic: [sidr] pCNT & prepending
Thread-Index: AcxNO2kv7vK/uVZFS/Klned0i1HAEwAJNZTI
Message-ID: <D7A0423E5E193F40BE6E94126930C493087C7907B4@MBCLUSTER.xchange.nist.gov>
References: <3E7A5153-26C1-4974-9A1B-33AB92FCD657@tcb.net> <D7A0423E5E193F40BE6E94126930C493087C7907AE@MBCLUSTER.xchange.nist.gov>, <A29C8509-5F88-46BD-888F-E2C6650FEAD7@highwayman.com>
In-Reply-To: <A29C8509-5F88-46BD-888F-E2C6650FEAD7@highwayman.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"
MIME-Version: 1.0
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] pCNT & prepending
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, 28 Jul 2011 19:58:02 -0000

Chris, 

Do you think the proposed receiver processing rules below are insufficient?

dougm
 

________________________________________
From: Highwayman [chris.hall@highwayman.com]
Sent: Thursday, July 28, 2011 11:31 AM
To: Montgomery, Douglas
Cc: Danny McPherson; sidr wg list
Subject: Re: [sidr] pCNT & prepending

It's not clear to me how the system is protected from some unscrupulous transit provider setting their AS's to zero width, in order to attract more traffic.  Unless there is a side channel for ASN which may validly announce themselves in this way ?

I agree that transparency is the minimum requirement. I do not, yet, discount the emotional demand for Route Server users to not be seen to be RS users.  For many years we peered at LINX and, frankly, would not have dreamt of either using the RS, or be seen to be using it -- we were big boys -- notwithstanding, we peered openly... go figure :-)

Chris
--
Chris Hall.                  +44 7970 277 383 (iPhone)


On 28 Jul 2011, at 11:11, "Montgomery, Douglas" <dougm@nist.gov> wrote:

> Danny,
>
> Yes, that is certainly the idea if we agree to protect prepending (as opposed to just avoiding multiple Sigs in the the presence of prepending).
>
> If we protect prepending, the pCNT must be carried in the protocol, covered by the Sig and verified ... i.e., what you suggest below .. in validation.
>
> Note, that if you don't want to protect prepending ... only avoid repeating sigs ..., then you don't have to carry pCNT in the protocol.  Just update the Sig verification algorithm treat sequences of repeated AS's as one.
>
> If we like the "translucent" approach to support RS, then we need to carry pCNT in BGSSEC.   You are right we do need enhanced receive/process rules such as:
>
> 1. Only accept pCNT=0 from peers that are configured to be route servers.
>
> 2. Don't accept paths with multiple pCNT=0 entries in a row.
>
> Anyway, if we like this approach, we can talk the details of the receiving rules / process rules to protect potential abuse.
>
> dougm
>
> Doug Montgomery - Manager Internet and Scalable Systems Research Group / Information Technology Laboratory / NIST
> ________________________________________
> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Danny McPherson [danny@tcb.net]
> Sent: Thursday, July 28, 2011 11:02 AM
> To: sidr wg list
> Subject: [sidr] pCNT & prepending
>
> Doug et al,
> I like the general objective of pCNT and this seems a good idea to me.  My only comment at the microphone was that if we add this for compression, then validation should require that pCNT MUST be equal to the number of _contiguous ASx appearances in the path (i.e., no more, no less, and only contiguous).
>
> I do wonder if pCNT=0 for transparent route servers introduces the opportunity for some sort of downgrade attack of sorts..
>
> -danny
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr