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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 2 Nov 2008 19:32:40 -0000

Hi Roland,

>> Suppose the Value field is set to zero. That means "routers shall
>> 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.

I quoted from RFC 2113. The full and correct quote is...

   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.

I don't see that it says that the examination has to be in the slow path.

I don't know what "silently ignored" was supposed to mean. It would be 
interesting to know how it has been implemented.

Recall that definining new behavior is well and good, but you have to be 
able to get packets through routers that are already deployed. It is no help 
if they drop them or pass them up to a higher protocol that barfs. Backward 
compatibility is a big part of this problem.

Cheers,
Adrian

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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Nov 2008 09:14:37 +0200 (EET)

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

---

From: David R Oran <[email-masked]>
Date: Mon, 3 Nov 2008 02:33:59 -0500

On Nov 3, 2008, at 2:14 AM, Pekka Savola 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.
>
> 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).
>
> 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.

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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Nov 2008 10:10:34 +0200 (EET)

On Mon, 3 Nov 2008, David R Oran wrote:
>> 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.

ECN doesn't _require_ routers to do anything.

Routers may, if they want, to do optimizations in their drop stragies 
and modify packet's ECN bits.  My understanding is that typically 
routers require special configuration to do this (and many don't even 
support it), and configuring this is rather rare.

---

From: Roland Bless <[email-masked]>
Date: Mon, 03 Nov 2008 10:46:35 +0100

Hi Adrian,

> I don't see that it says that the examination has to be in the slow path.

Ok. But probably more difficult if the decision cannot be made by
looking at the RAO value alone, which was exactly my point:
The value should provide enough information for the decision whether
to pass it up or not (a general value like IPv4 RAO "0" doesn't make
much sense IMHO).

> able to get packets through routers that are already deployed. It is no
> help if they drop them or pass them up to a higher protocol that barfs.
> Backward compatibility is a big part of this problem.

So obviously the whole thing has been messed up by imprecise
specifications and weird implementation behavior. The question
is really how to proceed now.
a) Work on an update of RFC 2113, fixing specification flaws.
   This may cause inconsistent behavior between old implementations
   and new implementations following the new spec/RFC.
b) Define a new RAO option type, this time with proper semantics,
   let alone existing implementations of the old RAO stuff.

Please see also the "I hate Router Alert" slides (slide 13-)
from Robert Hancock @IETF67 (Nov 2006):
http://www.ietf.org/proceedings/06nov/slides/nsis-1/nsis-1.ppt
So the issues of the last bullet on slide 25 are still unsolved
(except for the IANA issues).

Regards,
 Roland

---

From: "Tony Li" <[email-masked]>
Date: Mon, 3 Nov 2008 10:01:53 -0800

|So obviously the whole thing has been messed up by imprecise
|specifications and weird implementation behavior. The question
|is really how to proceed now.
|a) Work on an update of RFC 2113, fixing specification flaws.
|   This may cause inconsistent behavior between old implementations
|   and new implementations following the new spec/RFC.
|b) Define a new RAO option type, this time with proper semantics,
|   let alone existing implementations of the old RAO stuff.
|
|Please see also the "I hate Router Alert" slides (slide 13-)
|from Robert Hancock @IETF67 (Nov 2006):
|http://www.ietf.org/proceedings/06nov/slides/nsis-1/nsis-1.ppt
|So the issues of the last bullet on slide 25 are still unsolved
|(except for the IANA issues).

I'd be happy to help with this effort.

Tony

---

From: David Ward <[email-masked]>
Date: Mon, 3 Nov 2008 12:11:03 -0600

The next rev of our draft will hopefully spell out what is f'bar in  
2113 and an option to extend RAO for easier filtering based upon  
local client registration. We'll take all the help we can get. Should  
be out tomorrow and certainly discussed in MSP.

-DWard

---

From: Max Laier <[email-masked]>
Date: Mon, 3 Nov 2008 21:33:01 +0100

[resend - sorry for any duplicates, but I don't seem to make it to the lists]

Hello,

On Monday 03 November 2008 10:46:35 Roland Bless wrote:
> > Recall that definining new behavior is well and good, but you have to
> > be able to get packets through routers that are already deployed. It is
> > no help if they drop them or pass them up to a higher protocol that
> > barfs. Backward compatibility is a big part of this problem.
>

FWIW, I couldn't agree more.  The discussed alternative Q-mode
encapsulation is - IMHO - still-born.  I don't see how any vendor would get
behind the idea of doing all the processing necessary to identify a
GIST-Query in the fast path.  If that's even possible.  In the current
form, a router would have to look at the UDP-header *and* the payload (and
might even have to parse the NSIS header up to the Q-mode flag).  I doubt
that's something one can do at line speed!

David, Reshad, any input on that topic from your employer?

As Roland said, what we really need - if we want something like Q-mode -
are proper semantics for an IP-level option.  Something that's easy to
parse and easy to filter.

Proper semantics in my book would mean something like:
I) Compare "Option Value" against locally implemented signaling protocols
Ia) Match -> Slow path / deliver locally
Ib) No Match -> Forward

II) On "Edge/Entry-Router"/Firewall in forwarding - compare "Option Value"
against ACL for allowed protocols, option values / allowed peers / rate
limit IIa) Allow -> Forward
IIb) Deny -> Reply with ICMP error (rate limited)

In addition I'd like to reiterate what Tony Li said earlier in this thread:
> 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.

In light of all that it seems contra-productive to make the filtering more
difficult (which is what we are doing at the moment!).  Instead, I think,
we should bite the bullet and allocate a new IP-option value with proper
semantics, even though it is a scarce resource.  As far as I can tell, it's
either that or no Q-mode (or any other future protocol like it) at all.

-- 
/"\  Best regards,                      | [email-masked]
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News