Re: I-D ACTION:draft-rahman-rtg-router-alert-dangerous-00.txt

Adrian -

Thanks for expanding on the issue that I allude to. I agree that we  
can call out in the draft. Note: were considering discussing the  
draft in the routing open area meeting in Minneapolis.

Where I think we are heading is that we need to describe that   
routers have built-in protection mechanisms to mitigate the risk and  
that new protocols register as a router alert consumer. If the  
registration mechanism is useful, protocol developers should  
understand  routers should disable RA option processing on routers  
that do not require it and have no registered clients  (eg, do not  
run RSVP, MPLS OAM, IGMPv2/v3, etc.). Unfortunately due to the the  
very limited use of IPv4 RA today, such registration and full  
filtering doesn't exist on all legacy gear and continues to be a CPU  
load vector. Thus, all new protocols/apps must have the client  
registration, explicitly call out the use of filters, etc.

I am walking the razor's edge here trying to not deprecate IPV4 RAO  
completely but, be rather dramatic on how it is to be used due to the  
critical infrastructure dependent on it.

-DWard

On Oct 27, 2008, at 10:18 AM, Adrian Farrel wrote:

> Magnus,
>
> It is not a question of the Value field.
>
> Suppose the Value field is set to zero. That means "routers shall  
> examine this packet further".
>
> It is clear what they do if they examine the packet and decide it  
> is for local processing (for example, they look at the IP Protocol  
> field and see the payload is RSVP, and there is a local RSVP stack  
> enabled on the interface).
>
> It is unclear what they do if the payload is STII and there is no  
> local stack.
> Router alert says "pass it up for local processing" but there is no- 
> one to pass it to.
> Should it be dropped, forwarded on the slow path, or forwarded on  
> the fast path?
>
> The only evidence we have for the "correct" behavior is in 2205  
> where packets are send with RA and are expected to be able to pass  
> through non-RSVP clouds.
>
> Even the "silently ignore" for unrecognized Value fields is  
> ambiguous. Does that mean drop the packet (ignore the packet) or  
> forward it (ignore the RA option)?
>
> Lastly, it is really unclear what should be done with a packet that  
> carries RA and a protocol that *is* active on the router but which  
> is not expecting router alert packets. For example, UDP. Should the  
> packets be delivered there and then dropped (causing unnecessary  
> processing) or should the protocol be expected to register as a  
> router alert consumer with the fast path (requiring specifics of  
> the implementation)?
>
> These are all issues that could usefully be documented in Reshad's  
> draft.
>
> Cheers,
> Adrian
>
> ----- Original Message ----- From: "Magnus Westerlund"  
> <[email protected]>
> To: "David Ward" <[email protected]>
> Cc: "Roland Bless" <[email protected]>; "Adrian Farrel"  
> <[email protected]>; "Reshad Rahman" <[email protected]>; "NSIS"  
> <[email protected]>; <[email protected]>; "tsvwg"  
> <[email protected]>
> Sent: Monday, October 27, 2008 2:57 PM
> Subject: Re: [NSIS] I-D ACTION:draft-rahman-rtg-router-alert- 
> dangerous-00.txt
>
>
>> David Ward skrev:
>>> Roland -
>>>
>>> On Oct 21, 2008, at 3:35 AM, Roland Bless wrote:
>>>
>>>> Hi Magnus,
>>>>
>>>> Magnus Westerlund wrote:
>>>>> I reacted on the following sentence from Section 4:
>>>>>
>>>>>    A router SHOULD inspect Router Alert packets before sending  
>>>>> them to
>>>>>    the "slow path" so that if the protocol to which a packet  
>>>>> belongs is
>>>>>    not enabled on the router or on the incoming interface  
>>>>> (physical or
>>>>>    virtual), then the packet is dropped.
>>>>>
>>>>> Isn't this preventing use of RAO completely unless all nodes  
>>>>> between
>>>>> source and destination supports RAO and that protocol? Isn't  
>>>>> the right
>>>>> answer to not kick it into the slow path and simply forward it?
>>>>
>>>> Yes, the behavior should be: simply forward the packet in case
>>>> the router does not understand/intercept packets with this RAO  
>>>> value.
>>>> Otherwise an efficient interception as we need it in NSIS is
>>>> not possible.
>>>> If the router is the destination of the packet and it doesn't
>>>> understand the RAO, it probably could drop the packet.
>>>>
>>>
>>> DW: The RSVP spec doesn't state this clearly thus the confusion.
>>
>>
>> Why are we talking about RSVP here? RAO for IPv4 is RFC 2113 which  
>> says:
>>
>> 2.2  Semantics
>>
>>   Hosts shall ignore this option.  Routers that do not recognize this
>>   option shall ignore it.  Routers that recognize this option shall
>>   examine packets carrying it more closely (check the IP Protocol
>>   field, for example) to determine whether or not further  
>> processing is
>>   necessary.  Unrecognized value fields shall be silently ignored.
>>
>>   The semantics of other values in the Value field are for further
>>   study.
>>
>> Maybe not 100% clear in regards to the value and that the packet  
>> simply
>> should be forward for unrecognized value. But I think it is  
>> reasonable
>> that your document helps clarify this.
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> IETF Transport Area Director & TSVWG Chair
>> --------------------------------------------------------------------- 
>> -
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> --------------------------------------------------------------------- 
>> -
>> Ericsson AB                | Phone +46 8 4048287
>> Färögatan 6                | Fax   +46 8 7575550
>> S-164 80 Stockholm, Sweden | mailto: [email protected]
>> --------------------------------------------------------------------- 
>> -
>