Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

From: Philipp Kern <[email-masked]>
Date: Thu, 1 Nov 2012 10:09:54 +0100

On Thu, Nov 01, 2012 at 09:35:07AM +0900, Lorenzo Colitti wrote:
> Operators who want to have their routers do things like:
[…]
> - Stateless ACL processing for security purposes
[…]
> configure their routers to look at upper-layer headers. If the routers
> cannot parse the extension header chain but only look at the next header
> value in the IPv6 header, then the operators have a choice:
> 
> 1. Give up the above functionality.
> 2. Drop all packets with extension headers.
> 
> It's not just the fragment header, it's all extension headers. The fragment
> header is just the most important one.

Isn't the point that another packet will arrive later that doesn't bear
the information anymore that's needed to do the filtering decision?
Hence the fragmentation being the only concept that pushes information
away from a per-packet point of view to one where you'd require state?

(Also: To say that it wasn't forseen what would be possible in hardware
today a decade ago and then argue based on the current state of
technology to remove a feature does sound a tad wrong to me. Hardware
does evolve.)

Kind regards
Philipp Kern

---

From: Havard Eidnes <[email-masked]>
Date: Thu, 01 Nov 2012 14:01:55 +0100 (CET)

Hi,

I would like to pick up on section 2.2 in the draft, named
"Impact on Applications".  As far as I've seen so far in the
discussion, there has been almost no discussion of this part of
the draft.  I also find the analysis and explanation of the
issues faced by DNS in general and DNSSEC in particular to be
... somewhat weak.

>   DNS is one application that may be vulnerable when fragment
>   dropping occurs.

"Vulnerable" is not a word I would use in this context, since it
rings of "security issue".  "Affected" is perhaps a better word.

Secondly, who gets affected, and what is the effect?  That's not
mentioned, and it probably should be.

Even though EDNS0 and DNSSEC is mentioned in the draft, the
implications are not spelled out.  It may come as a surprise to
some that all currently supported versions of BIND and Unbound,
as well as all Windows name servers from 2008R2 onwards, all in
the role as recursive resolver by default send DNS queries with
EDNS0 buffer size set at around 4096 bytes *and* set the "send
DNSSEC information, if available" flag, *even if the recursive
resolver is not configured to do DNSSEC validation*.

In practice, this means that even if you don't use DNSSEC, unless
you take steps to prevent it, your recursive resolver will
increasingly need to be able to receive fragmented packets in order
to work satisfactorily.

>   The current choices open to the operators of DNS servers in
>   this situation are to defer deployment of DNSSEC, fragment
>   responses, or use TCP if there are cases where the rrset
>   would be expected to exceed the MTU.

This part of the draft is at best unclear.  If I'm an authoritative
name server, serving a zone which is DNSSEC signed, which results in
large (>1500 bytes) responses to a given query received over UDP,
where the querier asks for DNSSEC info and specifies a large buffer
size with EDNS0, I have no choice but to respond using UDP, and if
the resulting datagram is largish, I have to use fragmentation.  In
particular, the authoritative name server has no option to "use
TCP", that initiative has to come from the recursive resolver who
initiated the query in the first place.  The various recursive
resolver implementations have various different strategies for
dealing with situations where queries sent with DO=1 and EDNS0
bufsize=<large> doesn't make it back, among them dropping down the
bufsize, dropping EDNS0 (and DO=1) entirely, or resorting to TCP.
Meanwhile time is ticking away, since the recursive resolver
typically needs to experience multiple query timeouts before
engaging in alternative behaviour.

Who's affected by this?  Those using the recursive resolver who
happily announces that it wants large packets, but which has also
implemented non-initial fragment dropping in the infrastructure
around its recursive resolver.  "You make your bed, now you lie in
it." might be a valid response.

To my mind deferring DNSSEC deployment until each and every corner
on the Internet won't have issues with reception of fragments is a
total non-starter.  I predict that there will always be a fresh
supply of overly paranoid firewall administrators who insist on
breaking parts of the protocols, either through ignorance, fear, or
for other reasons.  If we wait until this supply dries up, we will
be waiting forever.

The draft goes on to say:

>   The use of fallback to TCP will impose a major resource and
>   performance hit and increases vulnerability to denial of service
>   attacks.

Here I will at least partially agree.  I think RIPE Labs recently
did a measurement which ended up indicating that a query over TCP
takes 2 to 3 times as long as a query over UDP to complete.  In
addition, TCP imposes increased state load on the publishing DNS
servers.  "Increased vulnerability to denial of service attacks" I'm
not so sure of.  It's always been a requirement that publishing DNS
name servers be reachable over TCP, so that should make it "the
same".  (Yes, I'll concede that this latter point is probably widely
ignored...)

So...

With the steadily increasing deployment of DNSSEC and with
fragmented UDP packets going with that, I think we should clearly
document to avoid problems caused by both running recursive
resolvers with the default configuration and at the same time
configure their infrastructure surrounding their recursive resolvers
to drop non-initial fragments, and that this advice is valid even if
they themselves don't use DNSSEC.  (Yes, that's an overly
complicated senctence, but I have to dash...)

Regards,

- Håvard

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 Nov 2012 11:36:59 -0700

On 10/31/2012 5:58 PM, Lorenzo Colitti wrote:
> On Thu, Nov 1, 2012 at 9:51 AM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     However, you've answered the key issue - this is not about
>     fragments, but rather about two things:
>
>     a) DPI
>              DPI cannot be done on packets with any options
>              so this either means operators need to ignore DPI
>              on such packets or drop them
>
>
> I don't think we should use the term DPI, because we don't really have
> consensus on what it means. I suspect some would assert that just
> looking at layer 4 headers is not DPI and that it's only DPI if you look
> into layer 4 payloads as well.

IMO, a router that looks beyond the IP headers is doing DPI. I realize 
others think DPI means looking at the E2E data.

However, to avoid confusion, I'll just state that:

- anything that looks only at an IP packet is a router

- anything that looks at higher layer headers isn't a router anymore. it 
might be a firewall, filter, etc., and whether the box can do that at 
line rate is a question customers should ask their vendors, not a 
problem the IETF should solve.

Joe

---

From: [email-masked]
Date: Thu, 01 Nov 2012 20:24:16 +0100 (CET)

> problem the IETF should solve.

This looks like a nice theoretical classification that is rather useless
in practice.

A modern router with multiple 10G interfaces (say a Juniper MX or Cisco
ASR9K) can be configured to look at higher layers. The primary function
of these routers is forwarding packets at high speeds. The fact that
these routers *can* look at higher layers is not going to make me stop
calling them routers. I don't think I'm alone here :-)

As for the idea that routers shouldn't look at higher layers:

- Routers need to be able to protect themselves. This may require
looking at higher layer info, as noted by several people.

- At the borders of my AS I may need to look at higher layer info to
protect services or customers within my AS. For instance: I may want
my recursive name servers to be pingable from outside my AS - but any
DNS lookups towards these servers from outside my AS should be dropped.
The obvious place for such filtering is at the border routers, done in
hardware at high speed.

Sure I can ask my vendors if their boxes can parse arbitrarily long
IPv6 header chains at line rate. But *until* such boxes are installed
in my network: If I'm being attacked with "hard to parse" IPv6 traffic
at line rate, I'm much more likely to configure my border routers to
drop traffic (for instance by dropping all IPv6 headers except those I
know I need) than simply not doing anything at "because routers should
not look at higher layers".

Steinar Haug, AS 2116

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 Nov 2012 12:56:44 -0700

> calling them routers. I don't think I'm alone here :-)

Fine.

Then either get your vendors - of whatever boxes you want to call them - 
to support the current option structure, or choose not to support IPv6.

There are choices here.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 Nov 2012 13:21:27 -0700

On 11/1/2012 1:11 PM, Joel Jaeggli wrote:
...
>> Then either get your vendors - of whatever boxes you want to call them - to support the current option structure, or choose not to support IPv6.
>
> That's not an operationally useful statement.

Well, we had a third alternative in IPv4, which was to avoid options. I 
don't think that's a practical alternative here.

What's more likely is that we'll start running IPv6 with fragmentation 
(and options) over IPv6 with no options just to get the fast-path 
processing.

At that point, either operators will forward those packets and we have a 
badly busted Internet that exists only at the edges, or operators will 
toss all those packets because they can't inspect them, at which point 
we have a badly busted Internet.

Continued insistence on looking inside IP packets will then result in no 
IPv6.

> and it's not what's cooked into silicon by a number of companies that are well represented at the IETF.

Sure, but it may be time to consider that their business model may be 
flawed if this is what they expect.

>> There are choices here.
>
> Indeed, and the observable phenomena on the internet indicate what operators and their vendors arrived at indepedantly.

Well, either this works or it kills IPv6.

However, as I noted, the only realistic recommendation from this group 
is "it's OK to configure routers to drop all packets with any options". 
IMO that's not an appropriate position for an ops group to take, since 
it undermines an existing standard.

So if options are being deprecated in IPv6, that needs (IMO) to be taken 
to intarea, not simply asserted here.

Joe

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 1 Nov 2012 20:11:51 +0000

>> calling them routers. I don't think I'm alone here :-)

not really it isn't. What got me down this rathole was l3+l4 hashing.

> Then either get your vendors - of whatever boxes you want to call them - to support the current option structure, or choose not to support IPv6.

That's not an operationally useful statement. and it's not what's cooked into silicon by a number of companies that are well represented at the IETF.