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

Roland Bless <[email protected]>
Newsgroups gmane.ietf.nsis,gmane.ietf.tsvwg
Organization Institute of Telematics, University of Karlsruhe
Message-ID <[email protected]>
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.

> packets. Then adding filtering behavior to prevent overloading the slow
> path and this would work better than the alternative of not using RAO.

Yep.

> I do have to question if you really consider 5 tuple filters pushing
> packets into the slow path and then determine if they are a protocol
> going to router or not, as a better option? To me it seems to have the
> same issues with overload.
> 
> And if the document is going to say that no future protocol is going to
> use RAO, then please provide a viable alternative that will work better.

I strongly agree with Magnus here.
 Roland
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.