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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 20 Oct 2008 11:52:07 +0200

Hi,

Adding TSVWG and NSIS as "owners" of a protocol using RAO, or that
consider using RAO.

Thanks for producing the draft. I definitely think we need to document
the IETF consensus on this. I don't wish anyone to have to go through
the NSIS debate regarding RAO in the future.

I looked through this draft.
http://www.ietf.org/internet-drafts/draft-rahman-rtg-router-alert-dangerous-00.txt

I reacted on the following sentence from Section 4:

   A router SHOULD inspect Router Alert packets before sending them to
   the "slow path" so that if the protocol to which a packet belongs is
   not enabled on the router or on the incoming interface (physical or
   virtual), then the packet is dropped.

Isn't this preventing use of RAO completely unless all nodes between
source and destination supports RAO and that protocol? Isn't the right
answer to not kick it into the slow path and simply forward it?

To me it seems that this recommendation is death blow to any protocol
already using RAO and completely preventing future use. To me it seems
that the main issue with RAO is how its handling has been implemented.
If one did the filtering of the option in fast path and used the alert
option number to correctly filter for the applications and protocols
present on the node then you would not get such amount of slow path
packets. Then adding filtering behavior to prevent overloading the slow
path and this would work better than the alternative of not using RAO.

I do have to question if you really consider 5 tuple filters pushing
packets into the slow path and then determine if they are a protocol
going to router or not, as a better option? To me it seems to have the
same issues with overload.

And if the document is going to say that no future protocol is going to
use RAO, then please provide a viable alternative that will work better.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: David Ward <[email-masked]>
Date: Mon, 20 Oct 2008 06:50:55 -0500

Magnus -

> the NSIS debate regarding RAO in the future.

DW: As you know this works comes directly from the NSIS debacle and  
we were volunteered as stuckkeys.

> answer to not kick it into the slow path and simply forward it?

DW: It would be the right thing if those were the semantics of RA.

> path and this would work better than the alternative of not using RAO.

DW: TBH, the draft is meant to be as close to a death blow as  
possible while leaving a pinhole of hope for the savvy designer.

> same issues with overload.

DW: We can add this as we attempt in the document to state warnings,  
expectations and deployment behavior. If you think adding a paragraph  
that one can negotiate or filter your way into enabling a pinhole; I  
see the utility. You made this clear during the NSIS discussion as well.

> use RAO, then please provide a viable alternative that will work  

DW: Use IPv6 RA :-)

-DWard

> _______________________________________________
> routing-discussion mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/routing-discussion

---

From: "McDonald, Andrew" <[email-masked]>
Date: Tue, 21 Oct 2008 09:23:31 +0100

>> use RAO, then please provide a viable alternative that will work better.

Are you saying that you regard IPv6 RAO as OK, but IPv4 RAO is bad? The 
current draft seems to lump IPv4 (RFC2113) and IPv6 (RFC2711) router 
alert together.

Andrew

---

From: Roland Bless <[email-masked]>
Date: Tue, 21 Oct 2008 10:35:52 +0200

Hi Magnus,

> answer to not kick it into the slow path and simply forward it?

Yes, the behavior should be: simply forward the packet in case
the router does not understand/intercept packets with this RAO value.
Otherwise an efficient interception as we need it in NSIS is
not possible.
If the router is the destination of the packet and it doesn't
understand the RAO, it probably could drop the packet.

> path and this would work better than the alternative of not using RAO.

Yep.

> use RAO, then please provide a viable alternative that will work better.

I strongly agree with Magnus here.
 Roland

---

From: David Ward <[email-masked]>
Date: Tue, 21 Oct 2008 11:31:27 -0500

Roland -

> understand the RAO, it probably could drop the packet.

DW: The RSVP spec doesn't state this clearly thus the confusion.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Oct 2008 15:57:39 +0100

> DW: The RSVP spec doesn't state this clearly thus the confusion.

Why are we talking about RSVP here? RAO for IPv4 is RFC 2113 which says:

2.2  Semantics

   Hosts shall ignore this option.  Routers that do not recognize this
   option shall ignore it.  Routers that recognize this option shall
   examine packets carrying it more closely (check the IP Protocol
   field, for example) to determine whether or not further processing is
   necessary.  Unrecognized value fields shall be silently ignored.

   The semantics of other values in the Value field are for further
   study.

Maybe not 100% clear in regards to the value and that the packet simply
should be forward for unrecognized value. But I think it is reasonable
that your document helps clarify this.

Cheers

Magnus Westerlund

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 27 Oct 2008 15:18:32 -0000

Magnus,

It is not a question of the Value field.

Suppose the Value field is set to zero. That means "routers shall examine 
this packet further".

It is clear what they do if they examine the packet and decide it is for 
local processing (for example, they look at the IP Protocol field and see 
the payload is RSVP, and there is a local RSVP stack enabled on the 
interface).

It is unclear what they do if the payload is STII and there is no local 
stack.
Router alert says "pass it up for local processing" but there is no-one to 
pass it to.
Should it be dropped, forwarded on the slow path, or forwarded on the fast 
path?

The only evidence we have for the "correct" behavior is in 2205 where 
packets are send with RA and are expected to be able to pass through 
non-RSVP clouds.

Even the "silently ignore" for unrecognized Value fields is ambiguous. Does 
that mean drop the packet (ignore the packet) or forward it (ignore the RA 
option)?

Lastly, it is really unclear what should be done with a packet that carries 
RA and a protocol that *is* active on the router but which is not expecting 
router alert packets. For example, UDP. Should the packets be delivered 
there and then dropped (causing unnecessary processing) or should the 
protocol be expected to register as a router alert consumer with the fast 
path (requiring specifics of the implementation)?

These are all issues that could usefully be documented in Reshad's draft.

Cheers,
Adrian

----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "David Ward" <[email-masked]>
Cc: "Roland Bless" <[email-masked]>; "Adrian Farrel" <[email-masked]>; 
"Reshad Rahman" <[email-masked]>; "NSIS" <[email-masked]>; 
<[email-masked]>; "tsvwg" <[email-masked]>
Sent: Monday, October 27, 2008 2:57 PM
Subject: Re: [NSIS] I-D 
ACTION:draft-rahman-rtg-router-alert-dangerous-00.txt

---

From: David Ward <[email-masked]>
Date: Mon, 27 Oct 2008 10:47:20 -0500

Adrian -

Thanks for expanding on the issue that I allude to. I agree that we  
can call out in the draft. Note: were considering discussing the  
draft in the routing open area meeting in Minneapolis.

Where I think we are heading is that we need to describe that   
routers have built-in protection mechanisms to mitigate the risk and  
that new protocols register as a router alert consumer. If the  
registration mechanism is useful, protocol developers should  
understand  routers should disable RA option processing on routers  
that do not require it and have no registered clients  (eg, do not  
run RSVP, MPLS OAM, IGMPv2/v3, etc.). Unfortunately due to the the  
very limited use of IPv4 RA today, such registration and full  
filtering doesn't exist on all legacy gear and continues to be a CPU  
load vector. Thus, all new protocols/apps must have the client  
registration, explicitly call out the use of filters, etc.

I am walking the razor's edge here trying to not deprecate IPV4 RAO  
completely but, be rather dramatic on how it is to be used due to the  
critical infrastructure dependent on it.

-DWard

On Oct 27, 2008, at 10:18 AM, Adrian Farrel wrote:

> Suppose the Value field is set to zero. That means "routers shall  
> examine this packet further".
>
> It is clear what they do if they examine the packet and decide it  
> is for local processing (for example, they look at the IP Protocol  
> field and see the payload is RSVP, and there is a local RSVP stack  
> enabled on the interface).
>
> It is unclear what they do if the payload is STII and there is no  
> local stack.
> Router alert says "pass it up for local processing" but there is no- 
> one to pass it to.
> Should it be dropped, forwarded on the slow path, or forwarded on  
> the fast path?
>
> The only evidence we have for the "correct" behavior is in 2205  
> where packets are send with RA and are expected to be able to pass  
> through non-RSVP clouds.
>
> Even the "silently ignore" for unrecognized Value fields is  
> ambiguous. Does that mean drop the packet (ignore the packet) or  
> forward it (ignore the RA option)?
>
> Lastly, it is really unclear what should be done with a packet that  
> carries RA and a protocol that *is* active on the router but which  
> is not expecting router alert packets. For example, UDP. Should the  
> packets be delivered there and then dropped (causing unnecessary  
> processing) or should the protocol be expected to register as a  
> router alert consumer with the fast path (requiring specifics of  
> the implementation)?
>
> ----- Original Message ----- From: "Magnus Westerlund"  
> <[email-masked]>
> Cc: "Roland Bless" <[email-masked]>; "Adrian Farrel"  
> <[email-masked]>; "Reshad Rahman" <[email-masked]>; "NSIS"  
> <[email-masked]>; <[email-masked]>; "tsvwg"  
> <[email-masked]>
> Subject: Re: [NSIS] I-D ACTION:draft-rahman-rtg-router-alert- 
> dangerous-00.txt
>
>
>> David Ward skrev:
>>> Roland -
>>>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 27 Oct 2008 18:32:44 +0100

All,

On 27 Oct 2008, at 16:47, David Ward wrote:

> run RSVP, MPLS OAM, IGMPv2/v3, etc.).

So the document will provide guidance for routers to offer a finer  
grain mechanism to narrow down the hole opened by RAO to the  
granularity of protocol.
(e.g. a router not running any RAO-based protocol, will never punt  
because of RAO,
(e.g. a router running RSVP and not STII will be able to intercept RAO- 
marked RSVP messages without punting RAO-marked message for STII in  
slow path).
I agree this is useful.

> Unfortunately due to the the very limited use of IPv4 RA today, such  
> registration and full filtering doesn't exist on all legacy gear and  
> continues to be a CPU load vector.

Right. And this situation will remain for quite a while (until the  
recommendations discussed above make their way into production  
networks).

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?

Francois

> Thus, all new protocols/apps must have the client registration,  
> explicitly call out the use of filters, etc.
> completely but, be rather dramatic on how it is to be used due to  
> the critical infrastructure dependent on it.
>
> -DWard
>
>> ----- Original Message ----- From: "Magnus Westerlund" <[email-masked] 
>> >
>> Cc: "Roland Bless" <[email-masked]>; "Adrian Farrel" <[email-masked] 
>> >; "Reshad Rahman" <[email-masked]>; "NSIS" <[email-masked]>; <[email-masked] 
>> >; "tsvwg" <[email-masked]>
> nsis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsis

---

From: "Tony Li" <[email-masked]>
Date: Thu, 30 Oct 2008 14:37:16 -0700

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.

Regards,
Tony

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 31 Oct 2008 14:36:38 +0100

Hello Tony,

> detecting and surviving DoS attacks must exist in every  

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

---

From: David R Oran <[email-masked]>
Date: Fri, 31 Oct 2008 10:22:59 -0400

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

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

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

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

---

From: Roland Bless <[email-masked]>
Date: Sat, 01 Nov 2008 01:05:21 +0100

Hi Adrian,

comments inline.

> examine this packet further".

IMHO this is a strange definition/use causing all the problems you are
describing in the text below. The RAO should allow for easier
interception of control/signaling packets while allowing to leave
packets in the fast path, i.e. forward them, if they are not of
interest.
If a router intercepts only those packets matching specific
RAO values situations could not occur where there is no suitable
application/protocol entity for further processing. As soon as
an application registers for specific RAO value(s), it will get
such packets. Thus, I think that the concept of having a general
value for "intercept and examine" is really counter-productive
(would be nearly the same as passing every packet with an RAO up).
So IMHO the RAO value should be the demultiplexer already.

> local processing (for example, they look at the IP Protocol field and
> see the payload is RSVP, and there is a local RSVP stack enabled on the
> interface).
> 
> Router alert says "pass it up for local processing" but there is no-one
> to pass it to.
> Should it be dropped, forwarded on the slow path, or forwarded on the
> fast path?
> 
> Even the "silently ignore" for unrecognized Value fields is ambiguous.
> Does that mean drop the packet (ignore the packet) or forward it (ignore
> the RA option)?
> 
> carries RA and a protocol that *is* active on the router but which is
> not expecting router alert packets. For example, UDP. Should the packets
> be delivered there and then dropped (causing unnecessary processing) or
> should the protocol be expected to register as a router alert consumer
> with the fast path (requiring specifics of the implementation)?

I would say the latter. If a router only intercepts packets containing
RAO values of registered protocols, it should forward all other
packets. If the general purpose value of 0 (only for IPv4 RAO) is
avoided, there will be also no attacking problem if they router
only passes those packets up into the slow path that carry a locally
registered RAO value. From an NSIS perspective it would be optimal
if only those packets are intercepted that contain specific RAO values
whereas all other RAO packets remain in the fast path. This is also
important for scalability reasons, e.g., intra-domain aggregation
concepts...

Regards,
 Roland