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

All,

On 27 Oct 2008, at 16:47, David Ward wrote:

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

So the document will provide guidance for routers to offer a finer  
grain mechanism to narrow down the hole opened by RAO to the  
granularity of protocol.
(e.g. a router not running any RAO-based protocol, will never punt  
because of RAO,
(e.g. a router running RSVP and not STII will be able to intercept RAO- 
marked RSVP messages without punting RAO-marked message for STII in  
slow path).
I agree this is useful.

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

Right. And this situation will remain for quite a while (until the  
recommendations discussed above make their way into production  
networks).

For this reason, Ashok and I have been planning to make a proposal for  
how RSVP could optionally operate without relying on RAO (e.g. based  
on PID=46 matching, based directed signaling as already done in a  
number of scenarios etc). This would avoid the RAO issue even if  
routers do not yet support the new recommended RAO procedures.
Any feedback/guidance from this community on that?

Francois

> 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]
>>> ----------------------------------------------------------------------
>>
>
> _______________________________________________
> nsis mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nsis