Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt

Warren Kumari <warren@kumari.net> Tue, 10 January 2012 23:53 UTC

Return-Path: <warren@kumari.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5A221F85F7 for <idr@ietfa.amsl.com>; Tue, 10 Jan 2012 15:53:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.231
X-Spam-Level:
X-Spam-Status: No, score=-106.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 qKU-iqf9bJBP for <idr@ietfa.amsl.com>; Tue, 10 Jan 2012 15:53:08 -0800 (PST)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 33E3221F8777 for <idr@ietf.org>; Tue, 10 Jan 2012 15:53:07 -0800 (PST)
Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E709A1B40BCB; Tue, 10 Jan 2012 18:53:06 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF6181C654044@EUSAACMS0701.eamcs.ericsson.se>
Date: Tue, 10 Jan 2012 18:53:06 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <F8B1F64B-7E4A-4320-9AC9-17F5141B80B5@kumari.net>
References: <20111216182324.17528.28150.idtracker@ietfa.amsl.com> <9CD76392-6F52-441C-BCF5-2335D7F49B8F@kumari.net> <4EEBEAEB.8070304@cisco.com> <0156DFD0-B706-42B0-93AB-89C9E6E252FD@kumari.net> <20120105014532.GC7464@slice> <0ED867EB33AB2B45AAB470D5A64CDBF6181C654044@EUSAACMS0701.eamcs.ericsson.se>
To: Jeff Tantsura <jeff.tantsura@ericsson.com>
X-Mailer: Apple Mail (2.1084)
Cc: "keyupate@cisco.com" <keyupate@cisco.com>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2012 23:53:09 -0000

On Jan 4, 2012, at 8:51 PM, Jeff Tantsura wrote:

> +1
> 

Thank you.

I have just uploaded a new version with this text slightly changed, please confirm that this version is still acceptable to you.

Keyur also pointed out that AS numbers show up in all sorts of other places (as an example, AS specific Extended Communities) -- as they may show up in yet more places as BGP gets extended I also inserted some fairly generic text saying that you SHOULD handle these as malformed and respond appropriately. While not ideal, I think it is OK.


W


> Regards,
> Jeff
> -----Original Message-----
> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas
> Sent: Wednesday, January 04, 2012 5:46 PM
> To: Warren Kumari
> Cc: keyupate@cisco.com; idr@ietf.org
> Subject: Re: [Idr] I-D Action: draft-ietf-idr-as0-01.txt
> 
> [Explicit cc on the draft-ietf-idr-error-handling authors for the comments below.]
> 
> Warren,
> 
> On Sat, Dec 17, 2011 at 12:26:10PM -0500, Warren Kumari wrote:
>> On Dec 16, 2011, at 8:05 PM, Enke Chen wrote:
>>> 1) Is it really necessary to make AS 0 an error in the AGGREGATOR and AS4_AGGREGATOR attributes?  What is the gain?
>> 
>> I'll double check with co-authors on Monday -- I don't think it is strictly necessary to prevent attack, rather it seemed more elegant to check AS 0 where ever it occurs.
> 
> While I generally agree with Enke that treating as a malformed route is probably excessive, I think the recommended behavior is desirable.  The mandate that the error-handling draft procedures must be used makes it acceptable.  Without those procedures, bouncing the session is almost certainly the wrong thing to do.
> 
>> It was brought up on the NANOG list that some vendors support zero'ing 
>> out the AGGREGATOR (see Junipers "no-aggregator-id" as an example -- 
>> this appears to only zero out the router ID, but I haven't checked all 
>> implementations), so checking for AS 0 in the .*AGGREGATOR may be a 
>> bad idea, so at the moment I'm leaning towards removing it (obviously, 
>> this being a WG doc, with the WG's approval)
> 
> Older varieties of gated had bugs with respect to the AS number that was selected to be placed in the aggregator AS field.  JunOS may have had similar bugs at one point but the behavior that I can see in a cursory check of the code should result in a system AS number being placed there.
> 
> My recommendation for the as0 draft is that we leave in the current text and let the attribute be treated as "malformed" by the error-handling draft.
> The behavior in that draft of attribute-discard is reasonable.
> 
>>> 2) The error handling for AS4_PATH / AS4_AGGREGATOR is specified in rfc4893bis (draft-ietf-idr-rfc4893bis-04.txt). Thus it should be referenced if you specify AS 0 as an error for the AS4_PATH / AS4_AGGREGATOR.
>>> 
>> 
>> Doh! This was mentioned a few times and I intended to do so, but it completely slipped my mind when typing... Thanks for reminding me....
> 
> Similarly, there should be references for these attributes added to the error-handling draft.
> 
> -- Jeff
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> 


---
Don't be impressed with unintelligible stuff said condescendingly .
    -- Radia Perlman.

Warren Kumari
warren@kumari.net