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

Hello Tony,

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 ...".
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).
If the application (e.g. end-to-end IPv4) relies on RAO it will just  
not be able to transit through that network.
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.

Cheers

Francois


>
>
> Regards,
> Tony
>