Subject: Re: A problem with RFC 6465's Uniform Format for Extension Headers

From: RJ Atkinson <[email-masked]>
Date: Mon, 10 Feb 2014 08:54:23 -0500

At Thursday, 6th February 2014 07:21:49 -0500, Thomas Narten wrote:
> At Wed, 05 Feb 2014 01:25:03 -0300, Fernando Gont wrote:
> > 1) If this problem remains un-addressed, then it's impossible to
> > differentiate between new upper-layer headers (e.g. a new transport
> > protocol) and new extension headers. Since such new extension headers
> > might be leveraged for malicious purposes, the end-result is that
> > middle-boxes are going to block *everything* (see RFC7045),
> > which means:
> > 
> >   + no new extension headers
> >   + no new transport protocols
> > 
> > ... so I think we really don't want to go there.
> 
> But we are already there. Folk won't deploy anything other than
> TCP/UDP because NAT won't deal with it. That has already been reality
> and is the reason that other or new transport protocols appear to be
> virtually undeployable today.
> 
> Reality is that existing middleboxes tend to process what they
> understand and have been explicitely coded to deal with. They just
> punt on anything else because that is the easiest/safest thing to do.
> 
> I see little that we can do to change that.
> 
> Thomas

I agree with Thomas Narten's analysis.  

The deployed situation perhaps isn't ideal, but the IETF ought to  
hew to the deployed reality.  Today's reality is that the Internet 
is very unlikely to deploy any new transport protocol(s) or any new 
IPv6 extension headers.  My own preference (has been and) would be 
to outright ban all new IPv6 Extension Headers -- insisting that 
future IPv6 extensions be specified as options within the existing 
Destination Options header or Hop-by-Hop Options header.

ENTERPRISE/OPERATOR FIREWALLS:

I understand that some residential users have (or want to have)
pure/direct IPv6 connectivity without any firewalls/middleboxes.

(Many folks that I know have some form of home firewall. Many
of those folks demand NAT for the perceived security benefits.  
At a previous employer of mine, IPv6 NAT/NAPT was the single
most commonly requested IPv6 feature -- by a wide margin.)

However, every enterprise/corporate/similar IPv6 user (or planned 
future IPv6 user) that I can identify is staying that a full firewall 
is a non-negotiable absolute requirement for ALL Internet-related
connectivity.  The handful of content providers that I've talked with
also will not permit their content servers to be directly connected
-- all are using some form of firewall.

[Aside:  Quite commonly, the firewall device also acts as a site's 
VPN termination point (e.g. for IPsec-based or TLS-based VPNs).]

NEWER TRANSPORT PROTOCOLS:

Few, if any, IP firewalls support SCTP at present.  Ditto for NORM,
although NORM can traverse some firewalls because NORM usually runs
over UDP.  I'm not certain why SCTP has little or no deployment,
but one certainly wonders how SCTP could be deployed widely -- 
given that most firewalls simply drop all SCTP traffic.  My sense
is that any new transport protocol probably should use UDP framing
(or UDP encapsulation) if it wants to be easily and widely deployed.

There is probably more mileage to be had from further TCP optimisation/
extension than from a new reliable transport protocol.

HARDWARE PACKET PARSERS:

The handful of wire-speed packet parsers that I am familiar with
all are built out of ASICs.  The set of options/headers/protocols
that those packet parsers can process in hardware are fixed at the
time that the Verilog of the ASIC is frozen -- and will not change
during the lifetime of that ASIC's deployment.  Any unrecognised
"Next Header" value likely will cause either (a) packet to be dropped,
(b) packet to be processed without further parsing, or (c) packet
to be kicked to a CPU-based (or NP-based) slow-path packet handler.
Of those three, alternative (a) is the most likely to be seen in
the deployed Internet.

With improvements in FPGAs, one certainly can imagine that some future
generation of wire-speed hardware packet parsers would be built using
FPGAs.  Those could, in principle at least, be updated after deployment.
It is unclear to me whether such updates would be supplied by the
manufacturer or how many users would deploy updates that are supplied
by the manufacturer.

BOTTOM LINE:

My perception is that this ship sailed several years ago, and that it
is either impossible or nearly impossible to deploy any new IPv6
Extension Header (although IPv6 options carried in existing headers
still seem possible) or any new transport-layer protocol using different
framing from TCP/UDP.

Yours,

Ran Atkinson

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Feb 2014 11:45:36 -0300

Hi, Ran,

On 02/10/2014 10:54 AM, RJ Atkinson wrote:
> hew to the deployed reality.

FIWIW, that's the bottom-line of my reasoning.

> Today's reality is that the Internet 

That's certainly among the options -- and is an acceptable outcome: if
you receive a packet that has an unrecognized next header, treat it as a
new transport protocol (and probably drop it).

But we currently assume that there might be new extensions, and that we
can parse unrecognized headers -- which we cannot.

> ENTERPRISE/OPERATOR FIREWALLS:
[...]

I fully agree with all your observations.

> over UDP.  I'm not certain why SCTP has little or no deployment,

Apparently, there's a fair share of SCTP deployment, albeit not for
public Internet services. And, in many cases, SCTP is being encapsulated
on top of UDP.

> still seem possible) or any new transport-layer protocol using different

FWIW, Extension Headers seem to be widely dropped. See e.g.:
<http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>
(Tim Chown has obtained similar results). However, we still need to
determine when in the network such packet drops happen.

What I would expect is that:

1) We clarify that despite RFC 6465, no middle-box can parse
unrecognized Next Headers. i.e., no middle-box could parse a new
Extension Header, unless the middle-box explicitly supports it.
Then, we either provide a way for them to parse unknown headers (as in
our UEH I-D), or ban new extension headers once and for all -- and we
forget about this.

2) Even with the current data, it seems that employing extension headers
for protocol extensions is not really a viable option in the real world.
That is, if we were to specify a new option (even if it is to be
included in a Dst Options header), that would lead to packet drops
(rather than "ignore the extensions/options"). The conclusion would be
that, for the general case, "think twice before relying on Ext Headers,
then don't". And this should be documented, so that any protocol design
that means to use EHs is aware of the fact that it probably won't work
as expected in the deployed world.

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Feb 2014 08:06:34 +1300

> Destination Options header or Hop-by-Hop Options header.

Not to dispute the facts of life as Thomas and Ran present them,
but let me point out that this argument recurses. If we forbid
additional Extension Headers (i.e. freeze things as they are listed
in RFC 7045) but allow new Options, in a few years somebody will
write

   Today's reality is that the Internet is very unlikely to deploy
   any new IPv6 Destination Options, because firewalls block
   unknown options.

Guess what? This argument has been used against new IPv4 options
since 1994 to my personal knowledge.

(Hop-by-hop options are pretty much a dead duck anyway.)

Just saying...

   Brian

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 10 Feb 2014 15:07:19 -0500

On 10  Feb 2014, at 14:06 , Brian E Carpenter wrote:
> but let me point out that this argument recurses.
> 
> If we forbid additional Extension Headers (i.e. freeze things
> as they are listed in RFC 7045) but allow new Options,
> in a few years somebody will write
> 

(I am not sure, but I think Fernando might have posted this,
or words like this, within the past week. :-)

> since 1994 to my personal knowledge.

Many ISPs have long declined to carry IPv4 transit packets that
contain IPv4 options because all IPv4 options create interrupts
to transit routers (i.e. easily exploited DDOS attack vector on
the ISP and its routers).  That reality creates a large barrier 
to deployment of anything in the global Internet.

A key difference for IPv6, compared with IPv4 options, is that any 
options inside an IPv6 Destination Options header do NOT have the 
hop-by-hop behaviour (from the router's perspective), so they
are not automatic easily-exploited DDOS attack vectors on the ISP
or its routers.

So there is a meaningful technical difference between the 
IPv4 history and the case of options in an IPv6 Destination
Options header.

As to firewalls, the IPv6 firewalls seem (on average) to be more
configurable (e.g. often ICMPv6 has selective filters whereas, 
in the same box, ICMPv4 only has "drop all/accept all" filtering).

Some sites deliberately will configure their firewalls to drop
nearly everything optional (headers, transport protocols, flying
geese, whatever).  Nothing here will change that for such sites.

Other sites configure their firewalls more selectively.  What we
do here might have an impact on those deployments and sites.

> (Hop-by-hop options are pretty much a dead duck anyway.)

Agreed.  Many ISPs long ago decided that they will drop all
IPv6 packets with the IPv6 Hop-by-Hop Header at their ingress
border router.  The "hop-by-hop" behaviour creates an easily
exploited DDOS attack vector on the deployed infrastructure.
Bad actors found that out years ago, and the ISPs responded
shortly thereafter.

BOTTOM LINE:

I don't think that draft-gont-6man-ipv6-universal-extension-header
is worth any time investment, because it can't change the deployed 
operational behaviour.

If we bother to do anything, we ought to just acknowledge reality
and say that no more IPv6 extension *headers* are allowed.  Instead,
options must be used.  We also should note that options with hop-by-hop
behaviour likely cannot be deployed reliably across the global public
Internet.  That would mean that any "new" NextHeader value would
denote a transport-layer protocol (which I think also would be 
very difficult to deploy - I have never seen SCTP on-the-wire).

Yours,

Ran

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Feb 2014 17:27:39 -0300

> is worth any time investment, because it can't change the deployed 

FWIW, if anything, I care about middle-boxes being able to process the
entire IPv6 header chain, and differentiate between transport protocols
and ext headers. Among the possible ways to do this are:

1) Ban new ext headers once and for all, xor,

2) Do something like the UEH we specified, xor,

3) Reserve a range for the universal format in RFC 6465.

And if we do anything other than 3), possibly also clarify that the
section on the universal format in RFC 6465 is to be forgotten --
because quite a few of us got confused with it.

While I have my preference, any of the above 3 would work for me.

Now, if you ask what are my personal beliefs regarding deployability of
Ext Headers in the public Internet, my take would be "Forget it -- It
won't work".

> very difficult to deploy - I have never seen SCTP on-the-wire).

For SCTP/IPv4, the reason for not seeing SCTP is probably NATs. -- Also,
neither Windows nor Linux support it AFAICT. While in IPv6 this could be
different, I expect firewalls that "only allow outgoing connections" to
be pretty common... so one way or another, they situation would not be
that different.

Cheers,