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