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

On Oct 31, 2008, at 9:36 AM, Francois Le Faucheur IMAP wrote:

> Hello Tony,
>
First, I very much agree with Tony on his point about RAO not making  
the control plane protection problem worse, especially that changing  
the "forward normally if you don't want to deal with it" semantics  
would be a large step backward. Second, I find the boundary filtering  
arguments equally unpersuasive. See below.

> On 30 Oct 2008, at 22:37, Tony Li wrote:
>
>>
>> Hi Francois,
>>
>> |For this reason, Ashok and I have been planning to make a
>> |proposal for
>> |how RSVP could optionally operate without relying on RAO (e.g. based
>> |on PID=46 matching, based directed signaling as already done in a
>> |number of scenarios etc). This would avoid the RAO issue even if
>> |routers do not yet support the new recommended RAO procedures.
>> |Any feedback/guidance from this community on that?
>>
>>
>> It seems to me that this entire area is delving WAY too far into the
>> implementation side of the world.  Please recall that the whole  
>> purpose of
>> the RAO was to make it easier for the data plane to sort out  
>> control plane
>> packets that would not otherwise be punted.
>>
>> Prior to RAO existing, folks were already sending those control plane
>> packets anyway, and we asked the data plane to work much harder.   
>> It seems
>> to me that you are, in effect, asking to undo this.  That seems
>> counter-productive to me.
>>
>> The attacks listed in draft-rahman-rtg-router-alert- 
>> dangerous-00.txt exist
>> *whether or not RAO is used*.  If you ask routers to filter control  
>> plane
>> packets without RAO, then the bad guy simply targets his DoS attack  
>> against
>> those same control plane packets.  Regardless, the same mechanisms  
>> for
>> detecting and surviving DoS attacks must exist in every  
>> implementation.
>
> I very much agree the mechanisms for detecting and surviving DoS  
> attacks must exist in any case.
>
> But one practical problem (that draft-rahman points out) is that  
> "Any application that relies on IP Router Alert should expect that  
> the incoming packets MAY be dropped by default ...".
I'm sort of on board until the words "by default". This is a big  
change in the intent and expectations.

>
> 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.

>
> If the application (e.g. end-to-end IPv4) relies on RAO it will just  
> not be able to transit through that network.
And if it relies on DCCP, or SCTP, or...or...or. This logic argues for  
us just packing our bags and going home. Instead, we should be writing  
a BCP which tells these middlebox guys to honor the semantics of RAO -  
just ignore it and forward the packet, unless some OTHER field renders  
the packet "dangerous" to the firewall policy. Blocking solely on RAO  
is as silly as dropping packets with a TTL of 1 because the next hop  
might be bombarded in the control plane generating ICMP hop exceeded  
responses.

>
> If the application relies on filtering, then it will transit through  
> that network and can still be intercepted downstream of that network  
> by enabling filtering.
>
> Another approach is to reduce/remove the motivations for networks to  
> block RAO packets. draft-rahman goes in that direction by  
> recommending PID-level RAO filtering. draft-dasmith-mpls-ip-options  
> goes in that direction too by allowing a network to protect itself  
> from external RAO packets without dropping them. etc. But it is not  
> clear if this will be sufficient for the RAO blocking practices to  
> disappear in a reasonable future.
>
we can not legislate against stupidity. However, we CAN write a strong  
statement saying routers/middleboxes MUST NOT drop packets simply  
because they have RAO set.

Best.
Dave Oran.
> Cheers
>
> Francois
>
>
>>
>>
>> Regards,
>> Tony
>>
>
> _______________________________________________
> routing-discussion mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/routing-discussion