IETF Logo Mail Archive

Re: [Idr] RFC-4893 handling malformed AS4_PATH attributes

"John G. Scudder" <jgs@juniper.net> Mon, 15 December 2008 19:41 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 4C19228C12C; Mon, 15 Dec 2008 11:41:29 -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 302D528C12C for <idr@core3.amsl.com>; Mon, 15 Dec 2008 11:41:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.03
X-Spam-Level:
X-Spam-Status: No, score=-6.03 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 t1NJmIsVEyQP for <idr@core3.amsl.com>; Mon, 15 Dec 2008 11:41:27 -0800 (PST)
Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 142D728C129 for <idr@ietf.org>; Mon, 15 Dec 2008 11:41:27 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSUay33ETukZeFoNzjTa0PJ8cljzaicM9@postini.com; Mon, 15 Dec 2008 11:41:20 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; Mon, 15 Dec 2008 11:37:02 -0800
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Dec 2008 11:37:02 -0800
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Dec 2008 11:37:02 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Dec 2008 11:37:01 -0800
Received: from [172.16.13.200] ([172.16.13.200]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mBFJb1M06287; Mon, 15 Dec 2008 11:37:01 -0800 (PST) (envelope-from jgs@juniper.net)
Message-ID: <A0F03ED4-AFA4-474E-A270-658FC0FAB08B@juniper.net>
From: "John G. Scudder" <jgs@juniper.net>
To: Danny McPherson <danny@tcb.net>
In-Reply-To: <DC16446E-ED44-452F-A86B-3844C4579C53@tcb.net>
MIME-Version: 1.0 (Apple Message framework v929.2)
Date: Mon, 15 Dec 2008 14:37:00 -0500
References: <0016361e883459ba8b045e197e41@google.com> <B216E38D-5E44-4375-9CD0-E0E19C47636D@tcb.net> <0016361e883459ba8b045e197e41@google.com> <20081215181155.GC12768@slice> <DC16446E-ED44-452F-A86B-3844C4579C53@tcb.net>
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 15 Dec 2008 19:37:01.0978 (UTC) FILETIME=[809C27A0:01C95EEC]
Cc: Inter-Domain Routing List <idr@ietf.org>
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-Type: multipart/mixed; boundary="===============0986656566=="
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

[resending with cropped cc list to get around brain-damaged ietf  
bogosity filter]

On Dec 15, 2008, at 2:21 PM, Danny McPherson wrote:
> After thinking about this for a few minutes, I can't currently
> come up with any configuration where a forwarding loop would occur
> as a result of just dropping the update (because the "translation"
> occurs on ingress to an AS), so discarding the update is likely
> to be a cleaner action.


AS1---AS2
   \   /
    \ /
    AS3

- AS1 prefers to reach AS3 directly, and advertises its route to AS2.
- AS2 prefers to reach AS3 directly, and advertises its route to AS1.
- Connections AS3-AS1 and AS3-AS2 fail simultaneously.
- AS1 switches to prefer AS2's route, and sends an update message which
   includes a withdraw of its previous announcement.  The withdraw is
   bundled with some advertisements.  It includes a bad attribute.  As a
   result, AS2 ignores the message.
- AS2 switches to prefer AS1's route, and sends an update message which
   includes a withdraw of its previous announcement.  The withdraw is
   bundled with some advertisements.  It includes a bad attribute.  As a
   result, AS1 ignores the message.

End result is that AS1 forwards traffic for AS3 towards AS2, and AS2  
forwards traffic for AS3 towards AS1.  This is a permanent (until  
corrected) forwarding loop.

I'm sure a less-contrived example can also be constructed, but this  
one should be sufficient to prove the point.

--John
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email