[Idr] RFC-4893 handling malformed AS4_PATH attributes

Kaliraj Vairavakkalai <kaliraj@juniper.net> Thu, 11 December 2008 14:24 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6EC73A6A6F; Thu, 11 Dec 2008 06:24:58 -0800 (PST)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495803A6782 for <idr@core3.amsl.com>; Thu, 11 Dec 2008 06:24:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYHqzBtiRjJF for <idr@core3.amsl.com>; Thu, 11 Dec 2008 06:24:57 -0800 (PST)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 5450B3A69DA for <idr@ietf.org>; Thu, 11 Dec 2008 06:24:55 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSUEir+mQg7a5l2x4G9HpJ7fK51GLOMqg@postini.com; Thu, 11 Dec 2008 06:24:51 PST
Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Thu, 11 Dec 2008 06:11:14 -0800
Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 06:11:14 -0800
Received: from emailbng1.jnpr.net ([10.209.194.15]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 06:11:14 -0800
x-mimeole: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 11 Dec 2008 19:41:10 +0530
Message-ID: <CD705FABA8532448AA1FB7A96C88FF140898F8A4@emailbng1.jnpr.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: RFC-4893 handling malformed AS4_PATH attributes
Thread-Index: AclbmlFaSJ+YIsdVQhKzDBvTfiRh/g==
From: Kaliraj Vairavakkalai <kaliraj@juniper.net>
To: "Quaizar Vohra" <qv@juniper.net>, <enkechen@cisco.com>, <idr@ietf.org>, "Yakov Rekhter" <yakov@juniper.net>, <tony.li@tony.li>, <skh@nexthop.com>
X-OriginalArrivalTime: 11 Dec 2008 14:11:14.0303 (UTC) FILETIME=[53A2A8F0:01C95B9A]
Subject: [Idr] RFC-4893 handling malformed AS4_PATH attributes
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Dear Authors, IDR-list, 

I tend to suggest couple changes in the following RFCs:

RFC-4893: In section "4.2.3.  Processing Received Updates":
--------
Please consider Adding this text:
   If a NEW BGP speaker receives an Update message containing the path 
   segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC3065] in the 
   AS4_PATH attribute, it may discard the Update after logging the event
   locally containing details like the attribute (type, length, and
value), 
   peer-address, as-path (may help in determining the originator of the 
   malformed-attribute) etc. 


RFC-4271: section "6.3 UPDATE Message Error Handling"
---------
Please consider Changing this text:
   If an optional attribute is recognized, then the value of this
   attribute MUST be checked.  If an error is detected, the attribute
   MUST be discarded, and the Error Subcode MUST be set to Optional
   Attribute Error.  The Data field MUST contain the attribute (type,
   length, and value).
To:
   If an optional attribute is recognized, then the value of this
   attribute MUST be checked.  If an error is detected, the update
   MUST be discarded, and a warning logged locally containing details
like
   the attribute (type, length, and value), peer-address, as-path (may
help
   in determining the originator of the malformed-attribute) etc.

Motivation behind the suggestion:
---------------------------------
This suggestion is focused on error-handling of "optional transitive
attributes" recognized by a BGP speaker receiving them. Because any
errors in the semantics of the optional-transitive-attribute will be
caught by a BGP-speaker which could be far away from the place of
origination of the error(as the speaker who don't recognize the
opt-trans-attribute will just propagate them to their peers), it may be
good idea to be more-lenient in the way the error is handled. i.e. I
feel tearing down the BGP session with the immediate neighbor must be
avoided. Because this affects the session between two BGP speakers
neither of whom are-responsible-for(originated) the
malformed-optional-transitive-attribute. 

Thanks,
Kaliraj 
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr