Re: [Int-area] Fwd: I-D Action:draft-rahman-rtg-router-alert-considerations-03.txt

Jukka Manner <jukka.manner@tkk.fi> Tue, 10 November 2009 03:47 UTC

Return-Path: <jukka.manner@tkk.fi>
X-Original-To: int-area@core3.amsl.com
Delivered-To: int-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3833A6822 for <int-area@core3.amsl.com>; Mon, 9 Nov 2009 19:47:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 DaZhbdy1qTOZ for <int-area@core3.amsl.com>; Mon, 9 Nov 2009 19:47:39 -0800 (PST)
Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by core3.amsl.com (Postfix) with ESMTP id F05B43A6767 for <int-area@ietf.org>; Mon, 9 Nov 2009 19:47:38 -0800 (PST)
Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id nAA3lLdM007821; Tue, 10 Nov 2009 05:47:21 +0200
Received: from smtp-4.hut.fi ([130.233.228.94]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 05624-23-4; Tue, 10 Nov 2009 05:47:21 +0200 (EET)
Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id nAA3l3h8007759; Tue, 10 Nov 2009 05:47:03 +0200
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id BB3031E124; Tue, 10 Nov 2009 05:47:03 +0200 (EET)
X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi
Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yFQT2qgol2Ac; Tue, 10 Nov 2009 05:46:59 +0200 (EET)
Received: from mailsrv.netlab.hut.fi (mailsrv.netlab.hut.fi [130.233.154.190]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 9944B1E00D; Tue, 10 Nov 2009 05:46:59 +0200 (EET)
Received: from [133.93.25.18] (host-25-18.meeting.ietf.org [133.93.25.18]) by mailsrv.netlab.hut.fi (Postfix) with ESMTP id 9B021120050; Tue, 10 Nov 2009 05:46:56 +0200 (EET)
Message-ID: <4AF8E232.9060500@tkk.fi>
Date: Tue, 10 Nov 2009 05:46:58 +0200
From: Jukka Manner <jukka.manner@tkk.fi>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Francois Le Faucheur <flefauch@cisco.com>
References: <20091026141502.19A653A6832@core3.amsl.com> <2727_1256568272_ZZ0KS4007M6MA5K0.00_E5FA0438-FCA0-49C0-824A-F59B46624F46@cisco.com> <4AF3DF94.7090904@tkk.fi> <78CD73AD-BDF3-4F09-B4D7-4163A2023C5F@cisco.com>
In-Reply-To: <78CD73AD-BDF3-4F09-B4D7-4163A2023C5F@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi
Cc: int-area@ietf.org
Subject: Re: [Int-area] Fwd: I-D Action:draft-rahman-rtg-router-alert-considerations-03.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2009 03:47:40 -0000

Hi Francois,

I read the doc on the plane over to Hiroshima. I pretty much agree with
the discussion. Yet, after having read the  document, I was left 
wondering, what is it that you actually want to say with?

In summary, you want to say that a network operator has three options:

1. Catch RAO packets (grab the hand grenade and hope it doesn't blow *)
2. Ignore them, let them pass (pass it on quickly to the next router)
3. Drop them (throw far, far, away, e.g. to /dev/null)

[* Scott Bradner once in a discussion with him compared RAO to a hand
grenade :) ]

All of those choices have implications, of course. Maybe you could be
more clear on these options. What would be a default behavior to do? if
you do 1, you are vulnerable, if you do 2, the next guy might not be 
happy, if you do 3, someone else might not be happy.

(Note that in Section 5 you talk about looking at payload of interest,
yet, here you come back to the problem of how to define the filter at a
suitable granularity as to not catch all RAO packets and DoS yourself.)

Some answers in addition below.

Cheers,
Jukka

Francois Le Faucheur wrote:
> Hello Jukka,
> 
> On 6 Nov 2009, at 09:34, Jukka MJ Manner wrote:
> 
>>
>> My WG having been a victim of a long debate on router alert, I believe 
>> there is value in documenting if or when RAO should or should not be 
>> used.
> 
> Good.
> 
>> Yet, there are already several RFCs that discuss/present RAO (2113, 
>> 2711, 5350). I have thought about the RAO lately and how to go 
>> forward, and it might make sense to merge these existing specs 
>> together, add recent views on RAO, and obsolete the previous RFCs.
> 
> There has been quite a bit of discussion about obsoleting (or not) RFC 
> 2113 & RFC 2711. Our conclusions from that discussion was that the most 
> effective approach was to :
> break down the RAO discussions into two different "tracks":
>     * one track that assumes current RAO definition (RFC2113 & 2711) and 
> router implementation. The aim there is to define a BCP discussing 
> if/where/how RAO should/should not be used in the current IP world. This 
> can be done in a short time frame. This is the scope of 
> draft-rahman-rtg-router-alert-considerations
>     * one track that investigates potential changes to RAO definition. 
> This is the scope of draft-narayanan-rtg-router-alert-extensions. This 
> is much more exploratory and with longer term implications since it 
> would depend on deployment of routers supporting the "new" RAO. This 
> would be a Standards Track document.

Sounds fine. Not sure of the STD track above, maybe first experimental?

> 
> Could we agree to:
>     *  "add recent views on RAO"  (including pointers to relevant parts 
> of RFC5350 such as discussion on Experimental RAO values, and as already 
> done including pointers to relevant text of RFC2113/2711) into 
> draft-rahman-rtg-router-alert-considerations, and
>     * "merge RFC 2113/2711 and obsolete/update/work-along these previous 
> RFCs" in draft-narayanan-rtg-router-alert-extensions if/when the work on 
> changing RAO definition progresses
> ?

Sounds okey to me.

> 
> I believe it is really important to provide a BCP asap on use of RAO in 
> the current situation and the above proposal would help us get there in 
> a reasonable timeframe.
> 
> Thanks
> 
> Francois
> 
> 
>>
>> I will arrive too late on Monday to take part in the int are meeting 
>> and hear the discussion, unless it would happen as the last item on 
>> the agenda.
>>
>> cheers,
>> Jukka
>>
>> Francois Le Faucheur wrote:
>>> FYI.
>>> Francois
>>> Begin forwarded message:
>>>> *From: *Internet-Drafts@ietf.org <mailto:Internet-Drafts@ietf.org>
>>>> *Date: *26 October 2009 15:15:02 CET
>>>> *To: *i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>>>> *Subject: **I-D 
>>>> Action:draft-rahman-rtg-router-alert-considerations-03.txt *
>>>> *Reply-To: *internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>>> directories.
>>>>
>>>> Title           : IP Router Alert Considerations and Usage
>>>> Author(s)       : F. Le Faucheur
>>>> Filename        : draft-rahman-rtg-router-alert-considerations-03.txt
>>>> Pages           : 25
>>>> Date            : 2009-10-26
>>>>
>>>> The IP Router Alert Option is an IP option that alerts transit
>>>> routers to more closely examine the contents of an IP packet.  RSVP,
>>>> PGM, IGMP/MLD, MRD and GIST are some of the protocols that make use
>>>> of the IP Router Alert option.  This document discusses security
>>>> aspects and usage guidelines around the use of the current IP Router
>>>> Alert option.  Specifically, it provides recommendation against using
>>>> the Router Alert in the end-to-end open Internet as well as identify
>>>> controlled environments where protocols depending on Router Alert can
>>>> be used safely.  It also provides recommendation about protection
>>>> approaches for Service Providers.  Finally it provides brief
>>>> guidelines for Router Alert implementation on routers.
>>>>
>>>> A URL for this Internet-Draft is:
>>>> http://www.ietf.org/internet-drafts/draft-rahman-rtg-router-alert-considerations-03.txt 
>>>>
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> Below is the data which will enable a MIME compliant mail reader
>>>> implementation to automatically retrieve the ASCII version of the
>>>> Internet-Draft.
>>> ------------------------------------------------------------------------
>>>> _______________________________________________
>>>> I-D-Announce mailing list
>>>> I-D-Announce@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>> ------------------------------------------------------------------------
>>> _______________________________________________
>>> Int-area mailing list
>>> Int-area@ietf.org
>>> https://www.ietf.org/mailman/listinfo/int-area