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

Pekka Savola <[email protected]>
Newsgroups gmane.ietf.tsvwg,gmane.ietf.nsis
Message-ID <[email protected]>
Adding my 5c,

I have been advocating the position that RAO option needs to be 
deprecated, and I'm glad to see that this discussion has started. My 
reasoning is that I as a network operator am not interested in 
supporting various kinds of protocols that want/need routers on the 
path to do something special with transiting packets.  It seems that 
in many cases, especially in the research field and other SDOs, the 
first reaction when designing a protocol requiring some interaction 
with routers is defining a RAO option.

Wrt your comments below:

On Fri, 31 Oct 2008, David R Oran wrote:
>> While that was not the expectation as RAO was initially defined, this could 
>> be the case in practice because a network is actively blocking RAO packets 
>> at some trust boundary (because some of his routers may not be very 
>> selective in punting so they'd get affected by RAO packets from an 
>> application they are not interested in; or because one of his internal 
>> application -say RSVP-TE- uses the same protocol as some end-to-end 
>> application - say IPv4 RSVP).
>
> One can raise the firewall/SBC shibboleth against just about ANY kind of 
> packet. The logical reductio ad absurdum of this logic is that we should 
> abandon demultiplexing at the IP layer entirely and simply tunnel everything 
> through TCP port 80 because that's the only thing some firewalls will let 
> through by default.

I'm not sure if you got the point above, at least as I see it.

As long as nobody defines that DCCP, SCTP, TCP port 80, or a random 
protocol X requires special processing at routers forwarding a packet, 
nobody objects.  These could be classified as "end-to-end" protocols, 
meaning that the routers don't need to care about them as long as the 
destination address is not one of theirs (with some well-established 
exceptions such as TTL going to zero).

Now, "hop-by-hop" protocols building on top of RAO are a different 
matter; these require work.  Deploying such a hop-by-hop protocol in 
an end-to-end environment is likely to cause issues, so a dual use of 
the same protocol in two different contexts is likely unwise.

Note that a hop-by-hop protocol could be designed that would not 
leverage RAO.  The protocol or its associated machinery would just 
first need to figure out the IP addresses of routers, and then set 
those as a destination address for these packets.  The routers would 
accept them or not, but those packets would not require any special 
processing in the forwarding logic (nor any punting to slow path, 
etc.).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
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.