[109844] in North American Network Operators' Group
Re: 91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 - announced
daemon@ATHENA.MIT.EDU (bill fumerola)
Thu Dec 11 17:46:49 2008
Date: Thu, 11 Dec 2008 14:46:44 -0800
From: bill fumerola <billf@mu.org>
To: bjorn@mork.no
In-Reply-To: <87ej0ex5dt.fsf@obelix.mork.no>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Thu, Dec 11, 2008 at 01:28:46PM +0100, bjorn@mork.no wrote:
> No you can't rely on that. But still, RFC4271 doesn't seemt to allow
> ignoring it. Which must be a bug in the RFC, or my reading of it.
> Hopefully the latter. Great if someone could correct the interpretation
> below.
>
> IMHO, an optional transitive attribute with the partial bit set should
> not cause session tear-down, since the attribute is forwarded across one
> or more routers not handling it and therefore not filtering it.
>
> However, RFC4271 does not make such an exception for optional +
> transitive + partial AFAICS:
[..... copy/paste deleted .....]
> Which basically means that you can take down every RFC-compliant 4-byte
> ASN honouring router today by injecting a bogus AS4_PATH attribute into
> the mostly 2-byte-ASN-only Internet...
>
> Or did I miss something? I certainly hope I did.
this was brought up in the IETF IDR mailing list today. i've attached
the response from that thread that addresses your reading of the RFC.
-- bill
--Nq2Wo0NMKNjxTN9z
Content-Type: message/rfc822
Content-Disposition: inline
Return-Path: <idr-bounces@ietf.org>
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on elvis.mu.org
X-Spam-Level:
X-Spam-Status: No, score=-6.6 required=6.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
SPF_PASS autolearn=ham version=3.2.3
X-Original-To: billf@mu.org
Delivered-To: billf@mu.org
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32])
by elvis.mu.org (Postfix) with ESMTP id 873311A3C39
for <billf@mu.org>; Thu, 11 Dec 2008 10:39:30 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 95FC63A69F1;
Thu, 11 Dec 2008 10:39:35 -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 1FA703A69F1
for <idr@core3.amsl.com>; Thu, 11 Dec 2008 10:39:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 CClvyBMXIyxj for <idr@core3.amsl.com>;
Thu, 11 Dec 2008 10:39:32 -0800 (PST)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171])
by core3.amsl.com (Postfix) with ESMTP id E3C2A3A69C0
for <idr@ietf.org>; Thu, 11 Dec 2008 10:39:31 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by
exprod7ob109.postini.com ([64.18.6.12]) with SMTP
ID DSNKSUFeWgHjBnT7+Kd02259AJ2jBT4EboUu@postini.com;
Thu, 11 Dec 2008 10:39:26 PST
Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net
(172.24.192.35) with Microsoft SMTP Server id 8.1.311.2;
Thu, 11 Dec 2008 10:36:26 -0800
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by
p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec
2008 10:36:26 -0800
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net
with Microsoft SMTPSVC(6.0.3790.3959);
Thu, 11 Dec 2008 10:36:26 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net
with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 10:36:25 -0800
Received: from [172.16.13.200] ([172.16.13.200]) by magenta.juniper.net
(8.11.3/8.11.3) with ESMTP id mBBIaLM13903;
Thu, 11 Dec 2008 10:36:21 -0800 (PST) (envelope-from jgs@juniper.net)
Message-ID: <4D86C4C6-F7CD-46B9-ABBE-04530F4D1278@juniper.net>
From: "John G. Scudder" <jgs@juniper.net>
To: Kaliraj Vairavakkalai <kaliraj@juniper.net>
In-Reply-To: <CD705FABA8532448AA1FB7A96C88FF140898F8A4@emailbng1.jnpr.net>
MIME-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 11 Dec 2008 13:36:21 -0500
References: <CD705FABA8532448AA1FB7A96C88FF140898F8A4@emailbng1.jnpr.net>
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 11 Dec 2008 18:36:25.0811 (UTC)
FILETIME=[5FA21A30:01C95BBF]
Cc: skh@nexthop.com, idr@ietf.org, Quaizar Vohra <qv@juniper.net>,
tony.li@tony.li, Yakov Rekhter <yakov@juniper.net>
Subject: Re: [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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org
Hi Kaliraj,
There are well-known correctness problems with simply discarding an
UPDATE. This gets discussed on the list every few years, every time
some implementation bug crops up which causes a lot of NOTIFICATIONS.
To date, the WG has resisted the temptation to compromise the
protocol's correctness. You do have a good point that optional
transitives are especially problematic; however, the correctness
problem still exists if you start dropping UPDATEs, so this would seem
to be a case of cutting off the patient's head to cure the flu.
Now that you bring it up though, the text from RFC 4271 you quote is
kind of bizarre:
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).
Can anyone offer an explanation of what it's supposed to mean that the
attribute MUST be discarded given that the section also says that
you're going to send a NOTIFICATION and tear down the entire session?
Seems as though the clause "the attribute MUST be discarded" should
itself be discarded.
--John
On Dec 11, 2008, at 9:11 AM, Kaliraj Vairavakkalai wrote:
> 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.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--Nq2Wo0NMKNjxTN9z--
