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

On Nov 3, 2008, at 2:14 AM, Pekka Savola wrote:

> 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.
Uh, what about ECN? The notion of "special processing" is contingent  
on just what constitutes "special". I don't think anybody said  
anything about a "random" protocol. In fact, very few protocols over  
the years have needed/wanted on-path inspection.

>  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.
>
Only for certain router implementations. Again, any router that  
doesn't understand the protocol will/should ignore it.

> 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.).
Well, the NSIS designers ran up against the need to intercept packets.  
In fact, some of the "C" mode processing, where the next hop is  
explicit, wound up introducing much complexity. We could discuss  
forever the tradeoffs in designing such protools; I'm not sure it  
would produce much more insight or agreement than it has in the past.

Cheers, DaveO.

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