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

Hi Roland,

>> Suppose the Value field is set to zero. That means "routers shall
>> examine this packet further".
>
> IMHO this is a strange definition/use causing all the problems you are
> describing in the text below. The RAO should allow for easier
> interception of control/signaling packets while allowing to leave
> packets in the fast path, i.e. forward them, if they are not of
> interest.

I quoted from RFC 2113. The full and correct quote is...

   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.

I don't see that it says that the examination has to be in the slow path.

I don't know what "silently ignored" was supposed to mean. It would be 
interesting to know how it has been implemented.

Recall that definining new behavior is well and good, but you have to be 
able to get packets through routers that are already deployed. It is no help 
if they drop them or pass them up to a higher protocol that barfs. Backward 
compatibility is a big part of this problem.

Cheers,
Adrian

> If a router intercepts only those packets matching specific
> RAO values situations could not occur where there is no suitable
> application/protocol entity for further processing. As soon as
> an application registers for specific RAO value(s), it will get
> such packets. Thus, I think that the concept of having a general
> value for "intercept and examine" is really counter-productive
> (would be nearly the same as passing every packet with an RAO up).
> So IMHO the RAO value should be the demultiplexer already.
>
>> 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)?
>
> I would say the latter. If a router only intercepts packets containing
> RAO values of registered protocols, it should forward all other
> packets. If the general purpose value of 0 (only for IPv4 RAO) is
> avoided, there will be also no attacking problem if they router
> only passes those packets up into the slow path that carry a locally
> registered RAO value. From an NSIS perspective it would be optimal
> if only those packets are intercepted that contain specific RAO values
> whereas all other RAO packets remain in the fast path. This is also
> important for scalability reasons, e.g., intra-domain aggregation
> concepts...
>
> Regards,
> Roland
>