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

[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:
> Adrian Farrel wrote:
> > 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.
>
> 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).
>
> > 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.
>
> 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).

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 protected]
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News