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

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 06 Nov 2009 10:34:28 +0200

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. 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.

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: [email-masked] <mailto:[email-masked]>
>> *Date: *26 October 2009 15:15:02 CET
>> *To: [email-masked] <mailto:[email-masked]>
>> *Subject: **I-D 
>> Action:draft-rahman-rtg-router-alert-considerations-03.txt *
>> *Reply-To: [email-masked] <mailto:[email-masked]>
>>
>> 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
>> [email-masked]
>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

-- 
Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+451 2481
Helsinki University of Technology Mobile: +358+(0)50+5112973
Department of Communications      Fax:    +358+(0)9+451 2474
and Networking (Comnet)           Office: G320 (Otakaari 5A)
P.O. Box 3000, FIN-02015 TKK      E-mail: [email-masked]
Finland                           WWW:    www.comnet.tkk.fi

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 6 Nov 2009 10:24:55 +0100

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.

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
?

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
>
>>> *Subject: **I-D Action:draft-rahman-rtg-router-alert- 
>>> considerations-03.txt *
>>> *Reply-To: [email-masked] <mailto:[email-masked] 
>>> >
>>>
> <jukka_manner.vcf>

---

From: Jukka Manner <[email-masked]>
Date: Tue, 10 Nov 2009 05:14:51 +0200

Hi Francois,

I read the doc on the plane over to Hiroshima. I pretty much agree with 
the discussion, or at least understand it. 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 1, you are vulnerable, if you 2, the next guy might not be happy, if 
you 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:
>> used.
> 2113 & RFC 2711. Our conclusions from that discussion was that the most 
> effective approach was to :
> 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

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

> of RFC5350 such as discussion on Experimental RAO values, and as already 
> done including pointers to relevant text of RFC2113/2711) into 
> 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
> 
> 
>>

---

From: Jukka Manner <[email-masked]>
Date: Tue, 10 Nov 2009 05:46:58 +0200

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?

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.

Cheers,
Jukka

Sounds okey to me.

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 13 Nov 2009 21:27:23 +0900

Hello Jukka,

On 10 Nov 2009, at 12:46, Jukka Manner wrote:

> Hi Francois,
>
> I read the doc on the plane over to Hiroshima.

and I happen to be reading this message on the plane back from  
Hiroshima  ^)

> I pretty much agree with

right.
Note that "2 Let them pass" has several flavours:
	2a. "really Ignore them"
	2b. "tunnel them over"
and those have different implications (eg with 2a the operator cannot  
use RAO-based application inside his network, with 2b he can).

> more clear on these options.

Valid point.
We could make explicit for each options the implications in terms of:
	(i) does this prevent/allow users to deploy RAO-based applications  
transparently on top of the operator (ie overlay model)
	(ii) does this prevent/allow operator to deploy RAO-based  
applications in his network
	(iii) how much does this isolate the operator from external RAO

> What would be a default behavior to do? if

Right now, the doc says that 3 is the least preferred.
Beyond that, I find it difficult to make a universal recommendation  
between 1 and 2. To me it seems a choice the operator has to make  
based on the "implications" discussed above, based on the operators  
requirements (e.g. does the operator need to deploy RAO application in  
his network?) and based on whether some options are feasible (e.g.  
does the transport technology & routers allow tunneling of RAO?). I'm  
thinking that if we make the "implications" explicit as discussed  
above, the operator would have all the necessary information to make  
the decision.
Do you feel we can make a default universal recommendation?

One more comment below:

>>> 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  
>> 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 :
>>    * 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.
>

Makes sense.

Thanks again for your comments.

Francois

>
>> 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
>>>
>>>>> A New Internet-Draft is available from the on-line Internet- 
>>>>> Drafts directories.
>>>>>

---

From: Jukka Manner <[email-masked]>
Date: Tue, 24 Nov 2009 09:45:40 +0200

Hi,

You had one question below about providing a proposal for a "default" 
rule. I'm the wrong person (an academic) to make proposals on what an 
operator SHOULD or SHOULD NOT do. Probably someone else should think 
about the right approach. My only point was to make it as clear and 
simple as possible, what the alternatives and their pros and cons are.

cheers,
Jukka

Francois Le Faucheur wrote:
> between 1 and 2. To me it seems a choice the operator has to make based 
> on the "implications" discussed above, based on the operators 
> his network?) and based on whether some options are feasible (e.g. does 
> the transport technology & routers allow tunneling of RAO?). I'm 
> thinking that if we make the "implications" explicit as discussed above, 
> the operator would have all the necessary information to make the decision.
>>> 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
>>> 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.
>>
>>> as already done including pointers to relevant text of RFC2113/2711) 
>>> into draft-rahman-rtg-router-alert-considerations, and
>>> previous RFCs" in draft-narayanan-rtg-router-alert-extensions if/when 
>>> the work on changing RAO definition progresses
>>> ?
>>
>> Sounds okey to me.
>>

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 24 Nov 2009 11:38:43 +0100

Hello Jukka,

On 24 Nov 2009, at 08:45, Jukka Manner wrote:

> Hi,
> 
> You had one question below about providing a proposal for a "default" rule.

I was only asking whether you felt it was possible to converge on one "default" rule. 
As explained below, I personally don't think it is possible (or even desirable) because the trade-off is very dependent on a few key environment specifics (listed below).

> I'm the wrong person (an academic) to make proposals on what an operator SHOULD or SHOULD NOT do. Probably someone else should think about the right approach. My only point was to make it as clear and simple as possible, what the alternatives and their pros and cons are.

My proposal is that:
	* we keep the statement that option 3 is the "last resort" option
	* we further clarify the alternatives (1, 2a, 2b)
	* we further clarify pros & cons of each of those
	* we leave it to the network operator to decide which is best in his environment.

Cheers

Francois

>> and I happen to be reading this message on the plane back from 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?
>>> 
>> and those have different implications (eg with 2a the operator cannot use RAO-based application inside his network, with 2b he can).
>>> 
>>    (i) does this prevent/allow users to deploy RAO-based applications transparently on top of the operator (ie overlay model)
>>    (ii) does this prevent/allow operator to deploy RAO-based applications in his network
>>> 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.
>> Beyond that, I find it difficult to make a universal recommendation between 1 and 2. To me it seems a choice the operator has to make based on the "implications" discussed above, based on the operators requirements (e.g. does the operator need to deploy RAO application in his network?) and based on whether some options are feasible (e.g. does the transport technology & routers allow tunneling of RAO?). I'm thinking that if we make the "implications" explicit as discussed above, the operator would have all the necessary information to make the decision.
>>>>> 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 :
>>>>   * 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.
>>> 
>>>>   *  "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
>>>>> 
>>>>>>> *Subject: **I-D Action:draft-rahman-rtg-router-alert-considerations-03.txt *
>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>>>>

---

From: Jukka Manner <[email-masked]>
Date: Tue, 24 Nov 2009 12:49:24 +0200

Right. If you don't want to restructure the whole draft, then you could 
add this clarification as a summary section at the end.

Jukka