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

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

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

---

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.
> routing-discussion mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/routing-discussion

---

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

On Nov 3, 2008, at 12:01 PM, Tony Li wrote:

>
>
> |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: "Tony Li" <[email-masked]>
Date: Mon, 3 Nov 2008 10:01:53 -0800

Tony

---

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
_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis