Subject: Re: [Errata Rejected] RFC6564 (4423)

From: Fernando Gont <[email-masked]>
Date: Thu, 22 Oct 2015 22:06:32 -0300

On 09/17/2015 09:43 AM, C. M. Heard wrote:
>>
>>    Exactly! We can't know all the uses to which IPv6 may be put in the
>> future; and we really should cure ourselves of pretending we can.
>>
>>> In any case, right now RFC6564 not only does not really help (*), but is
>>> misleading: I was tricked myself when I was working on RFC7610 that a
>>> middle-box could parse past unknown EHs. So even if one didn't want to
>>> address this problem (which I think would be a bad idea), at the very
>>> least one shouldn't leave RFC6564 "as is".
>>>
>>> (*) I must say that I was surprised when Erik reminded me some time ago
>>> that they tried to push a similar idea at the time... i.e., not sure why
>>> *that* didn't become RFC6564.
>>
>>    Perhaps someone remembers?
> 
> See Suresh Krishnan's message
> 
> http://www.ietf.org/mail-archive/web/ipv6/current/msg20168.html
> 
> wherein he said
> 
>   "Yes we wanted to do this as well, but the WG didn't want to waste
>    a protocol number for something that may never be used"
> 
> where "this" means something along the lines of the proposed UEH.

The problem here is that unless you "waste" (only!) one protocol number,
you essentially say bye-bye to e.g. new transport protocols, since a
middle-box could never differentiate between a new EH and a new
transport protocol.

And if we want that to happen, we better spell that out explicitly. And
the transport people should be aware about the decision that we're
implicitly making for them.

Thanks!

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

---

From: [email-masked]
Date: Fri, 23 Oct 2015 10:14:32 +0200

> implicitly making for them.

middlebox-behaviour is determined by policy.
that policy might be "deny by default".
meaning any new option in a new UEH would also lead to packet being blocked.

we can't deny operators to fully or partly disconnected themselves from the Internet. however much we think that is the wrong thing to do.
I would posit that there is nothing more we can do as protocol designers here.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Oct 2015 05:41:33 -0300

Hi, Ole,

> meaning any new option in a new UEH would also lead to packet being blocked.

Agreed. But right now we're preventing operators from being able to tell
new transport vs. new EH.

This is a flaw on our side.

Then ops people might be able to block all UEHs and new transport
protocols - it would be up to them.

But right now an op meaning to block e.g. only new transports (but allow
all EHs) or allow new transports (but block new EHs) cannot do so,
because it is impossible to differentiate between each of them.

Question: If you're a middle-box meaning to find the upper-layer
protocol (e.g. transport ports, etc), what would you do if you find an
unknown protocol number? Infer RFC6564? Infer new transport protocol? --
whatever option you choose, would be wrong.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mark Smith <[email-masked]>
Date: Fri, 23 Oct 2015 20:26:51 +1100

> This is a flaw on our side.

I think this is all based on the assumption that middle boxes
performing this sort of inspection in the network are going to be
eternally effective, which is based on an assumption that traffic in
the network is going to eternally be in clear text.

Given what various government secret agencies have been up to, and
have been able to get up to because people didn't deploy crypto when
they could have, I think these are flawed assumptions.

I don't accept that it is a flaw on our side. We believe in dumb
networks and smart hosts, and in a dumb network, crypto of end-to-end
headers (like EHs, excepting a few, and upper layer protocol headers)
and payloads doesn't matter, because we don't look at them in the
network.

I think security people would benefit from starting to realise that
the network isn't the only place that application and host security
can be performed, and as more and more end-to-end encryption occurs,
host and application security won't be possible to be performed in the
network.

A lot of the conversations about network firwalls, IDSes, DPI etc.,
for security purposes are starting to sound to me like the cliché
about all problems looking like a nail if you only have a hammer.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Oct 2015 06:41:58 -0300

Hi, Mark,

> the network is going to eternally be in clear text.

We're not talking about middle-boxes inspecting the application data
stream, but rather about them looking at upper-layer information.

> and payloads doesn't matter, because we don't look at them in the

The network has not been dumb for ages now: firewalls, IDS/IPS,
transparent proxies, NATs, etc., etc (you name it) are certainly not dumb.

> host and application security won't be possible to be performed in the

Security has been host/network-based for ages now: you find both host
and network based firewalls, server-sides and client-side anti-*
software, etc.

And when it comes to encryption, unless I missed something, it is
SSL/TLS (mostly) that is being pushed everywhere -- and it doesn't
prevent anything regarding getting up to the transport protocol info
(protocol, port numbers, etc.).

> about all problems looking like a nail if you only have a hammer.

A lot of the conversations about security are starting to sound that
everything can be solved with encryption. (among other things,
encryption doesn't solve sloppy software/hardware implementations, which
tend t be exploited a lot :-) )

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Oct 2015 08:17:13 +1300

> whatever option you choose, would be wrong.

You have failed to find the upper layer protocol. There seem to be three
choices:

1. Crash. Probably a bad idea.
2. Let the packet continue on its path. That's what RFC2460 requires anyway.
3. Drop the packet.

As it happens we already have IETF consensus about this. As RFC 7045 says,
the choice between #2 and #3 must be configurable:

   Forwarding nodes MUST be configurable to allow packets containing
   unrecognised extension headers, but the default configuration MAY
   drop such packets.

      Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 24 Oct 2015 10:19:57 -0300

Hi, Brian,

> On 23/10/2015 21:41, Fernando Gont wrote:
[....]
>    unrecognised extension headers, but the default configuration MAY

You cannot really tell whether an unknown protocol number is a
unrecognized EH or an unrecognized transport. Therefore, right now
there's nothing like an "unrecognized EH", because in order to tell it's
an EH, you have to "recognize" it in the first place.

I fully agree with the spirit of the statement you quoted from RFC7045.
It would be sensible that a forwarding node can decide whether a packet
with unrecognized options should be allowed through, and for the default
to be to allow them. However, in order to apply such criteria the
forwarding node should be able to tell that it is dealing with EHs
rather than other transports.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Oct 2015 08:21:52 +1300

> an EH, you have to "recognize" it in the first place.

I don't see that it matters. Your parser has failed. If it was a compiler,
that would be the end of it. For a middlebox, the choices are the same,
regardless of whether the bit you can't parse is an extension header
or an unknown layer 4 protocol.

> rather than other transports.

The question of principle is identical: either the policy is to respect
the e2e nature of IP and allow an unknown packet, or to discard it.

I'm not saying it was a good idea to use the protocol number space to
code extension headers; on balance I think it was a bad idea. But
from the point of view of a default-deny policy, it doesn't matter.
An unknown extension header is no more dangerous than an unknown
transport protocol, surely?

Rgds
   Brian

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 25 Oct 2015 09:06:15 -0700

On Fri, Oct 23, 2015 at 12:17 PM, Brian E Carpenter <brian.e.carpenter
>    unrecognised extension headers, but the default configuration MAY

I agree, but the wording in RC 7045 leaves room for ambiguity.
Perhaps a clarification
would be in order: s/unrecognised extension headers/unrecognised Next
Header values/

//cmh

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Oct 2015 08:28:56 +1300

> would be in order: s/unrecognised extension headers/unrecognised Next

The authors of 7045 were well aware of this issue, but we chose to word the
text exclusively for extension headers and to add the corresponding IANA
registry - in other words we didn't intend to cover the issue of unrecognised
protocol numbers at all. So this wasn't careless wording.

If you were suggesting this as an erratum on RFC 7045, I would recommend
it as 'hold for document update' since I think it needs explanatory text.

(There was a fix proposed that people didn't seem to like:
https://tools.ietf.org/html/draft-zhang-6man-offset-option-01)

    Brian

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 25 Oct 2015 15:55:29 -0700

On Sun, Oct 25, 2015 at 12:28 PM, Brian E Carpenter
<[email-masked]> wrote:
>> I agree, but the wording in RC 7045 leaves room for ambiguity. Perhaps a clarification
>> would be in order: s/unrecognised extension headers/unrecognised Next Header values/
>

Understood, but it seems to me that gives middle-box implementors an excuse
to unconditionally discard an IPv6 datagram with an unrecognised Next Header
value, on the grounds that it might identify an unrecognised
upper-layer protocol,
to which the requirements of RFC 7045, by explicit design, do not
apply.  I would
of course argue that such a strategy would not comply with RFC 7045, since the
unrecognized Next Header value could just as well identify unrecognised
extension header, but I'd like to see text that unambiguously rules out this
(broken) behavior.  That said, maybe I'm in the rough here, and the text in
RFC 7045 is sufficiently clear as it stands.

> it as 'hold for document update' since I think it needs explanatory text.

If there were to be an erratum, a better choice than the change I suggested --
given that the text reflects the authors' intent -- would be a note
explaining that
the indistinguishability of unrecognised extension headers and unrecognised
upper layer protocol headers implies that forwarding nodes complying with the
requirements 7045 must be configurable to pass unrecognised upper-layer
protocols.

> https://tools.ietf.org/html/draft-zhang-6man-offset-option-01)

I wasn't ware of that draft, though I had heard of such proposals.  Thanks for
the pointer.

//cmh

---

From: Bob Hinden <[email-masked]>
Date: Mon, 26 Oct 2015 09:30:30 -0700

Hi,

Changing the subject from "[Errata Rejected] RFC6564 (4423)”,

> transport protocol, surely?

As part of the rfc2460bis update from RFC6564 (added in draft-hinden-6man-rfc2460bis-06), it included a new section on defining new extension headers and options.  Text ncluded below.

Personally, I think this is as far as we can go on this topic.  I don’t think there is much else to do.

See the text below.

Bob

------------------

   4.8.  Defining New Extention Headers and Options

   No new extension headers that require hop-by-hop behavior should be
   defined.

   New hop-by-hop options are not recommended because, due to
   performance restrictions, nodes may ignore the Hop-by-Hop Option
   header, drop packets containing a hop-by-hop header, or assign
   packets containing a hop-by-hop header to a slow processing path.
   Designers considering defining new hop-by-hop options need to be
   aware of this likely behaviour.  There has to a very clear
   justification why any new hop-by-hop option is needed before it is
   standardized.

   Instead of defining new Extension Headers, it is recommended that the
   Destination Options header is used to carry optional information that
   need be examined only by a packet's destination node(s), because they
   provide better handling and backward compatibility.  Defining new
   IPv6 extension headers is not recommended.  There has to a very clear
   justification why any new extension header is needed before it is
   standardized.

   If new Extension Headers are defined, they need to use the following
   format:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    .                                                               .
    .                  Header Specific Data                         .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Next Header           8-bit selector.  Identifies the type of
                            header immediately following the extension
                            header.  Uses the same values as the IPv4
                            Protocol field [IANA-PN].

      Hdr Ext Len           8-bit unsigned integer.  Length of the
                            Destination Options header in 8-octet units,
                            not including the first 8 octets.

      Header Specific Data  Variable-length field, Fields specific to
                            the extension header.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Oct 2015 07:43:42 +0900

Hi, Brian,

On 10/25/2015 04:21 AM, Brian E Carpenter wrote:
[....]
> the e2e nature of IP and allow an unknown packet, or to discard it.

Not really.

e.g. see draft-gont-v6ops-ipv6-ehs-packet-drops: it mentions scenarios
in which the intent is *not* a "default deny", but the operator has to
resort to dropping packets if the middlebox cannot parse the entire IPv6
header chain.

> transport protocol, surely?

Routers dropping packets are not enforcing default-deny in that sense -
e.g., if a specific TCP port is to be filtered, a packet with EHs meant
to a different port could be passed. Otherwise everything has to be dropped.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Oct 2015 07:48:30 +0900

Hi, Bob,

On 10/27/2015 01:30 AM, Bob Hinden wrote:
>> The question of principle is identical: either the policy is to
>> respect the e2e nature of IP and allow an unknown packet, or to
>> discard it.
>> 
>> I'm not saying it was a good idea to use the protocol number space
>> to code extension headers; on balance I think it was a bad idea.
>> But from the point of view of a default-deny policy, it doesn't
>> matter. An unknown extension header is no more dangerous than an
>> unknown transport protocol, surely?
> 
> As part of the rfc2460bis update from RFC6564 (added in
> draft-hinden-6man-rfc2460bis-06), it included a new section on
> defining new extension headers and options.  Text ncluded below.
> 

I personally think that allowing middleboxes to parse the entire IPv6
header chain in the presence of new EHs would be valuable. -- please see
my response and Steffan's response to Brian...

> Bob

This part is a bit confusing. The first para seems to argue against
definition of new *EHs* that require hop by hop processing. The second
seems to argue against the definition of new *options* for the (already
defined) HbH Options EH.

> Instead of defining new Extension Headers, it is recommended that
> the Destination Options header is used to carry optional information
> that need be examined only by a packet's destination node(s), because
> they provide better handling and backward compatibility.  Defining
> new IPv6 extension headers is not recommended.  There has to a very
> clear justification why any new extension header is needed before it
> is standardized.
> 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
> Next Header  |  Hdr Ext Len  |                               | 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               + |
> | .                                                               . .
> Header Specific Data                         . .
> . |                                                               | 

The question here is: What do we gain by requiring new EHs to follow
this syntax?

Thanks!

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Oct 2015 13:31:49 +1300

Thanks!

> Personally, I think this is as far as we can go on this topic.  I don’t think there is much else to do.

Well, as a straw man, we could simply state that the extension header registry
is closed and that no more extension headers will be defined, ever.

As a thought experiment, imagine that in 1997 (after Router Alert was defined),
the IETF had stated that no more IPv4 options would be defined, ever.
Practical impact? None.

I'm not particularly advocating this approach, but it is theoretically possible.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Oct 2015 13:55:21 +1300

> to a different port could be passed. Otherwise everything has to be dropped.

Yes, OK. Well, if everyone implements RFC 7045 it will be a good start.
Linux code from 1998 won't help, though.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Tue, 27 Oct 2015 12:12:22 +1100

>> Changing the subject from "[Errata Rejected] RFC6564 (4423)”,

<snip>

> the IETF had stated that no more IPv4 options would be defined, ever.

I would wonder whether somebody came up with alternative and possibly
less efficient ways to achieve what IPv4 options could achieve, and
perhaps did so because they weren't aware of IPv4 options, didn't want
to go through the process of getting a new one approved, or thought
they may be dropped often enough that they couldn't rely on them
working.

In other words, absence of evidence is not evidence of absence.

I think the trouble with going down this path is that it is a slippery slope.

If we put priority on middle box vendors' and deployers' needs above
all others, we'll end up with no or no new EHs, UDP or TCP only, only
well known existing ports and protocols versions, no encryption
allowed, and no multi-pathing (more fundamentally, no asymmetric
traffic paths) because flexibility in any of those areas directly
reduces the value and usefulness of middle boxes. If that is the right
direction, then we may as well have stayed with IPv4, and just added
more and more middle boxes to make it continue to "work" well beyond
its used by date.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Tue, 27 Oct 2015 12:39:38 +1100

<snip>

> more and more middle boxes to make it continue to "work" well beyond

And since I should be challenged on what my alternative is ...

I've come to the belief that in many cases (all?) it is better to try
to solve a problem as close as possible to where it exists, because
then the solution is likely to have more information available to it,
be more accurate and be lower latency, because there is a smaller and
tighter feedback loop.

In the case of the problem of host and application security, I think
that means that the best place to solve it is on the hosts and/or in
the applications themselves. The host and/or application knows what
EHs are legitimate or not, so it can choose to accept them or not. The
host and/or application sees the traffic in clear text that would be
encrypted while it travels over the network. The host and/or
application will understand a new end-to-end transport protocol that
devices in the network can't and shouldn't care to, because, after
all, the new transport protocol headers and payloads may be encrypted
anyway. The host and/or application is at the end of the multiple
paths through the network, so it also sees all traffic for security
inspection purposes.

In many cases, middle boxes that are trying to protect host and/or
applications are not going to be able to be as accurate and effective
at solving the problem, compared to the host and/or application doing
it itself, because of the distance between them and where the problem
exists. I think one of the things this distance does is creates an
information asymmetry, as there is a difference between what the
middle box "thinks" the host and/or application knows and needs, and
what the host and/or application itself knows and needs.

Regards,
Mark.

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Oct 2015 11:08:56 +0900

Hi, Brian,

> Linux code from 1998 won't help, though.

Indeed. But the fact that the Linux code is dated (I should say I didn't
check it) doesn't invalidate the point I'm making.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Oct 2015 11:12:33 +0900

Hi, Mark,

On 10/27/2015 10:39 AM, Mark Smith wrote:
> the applications themselves. 

FWIW, the packet filtering scenarios in
draft-gont-v6ops-ipv6-ehs-packet-drops don't really have to do with host
or application security but rather with e.g. network denial of service
attacks. -- hence the filtering needs to be applied as close to the
attacker as possible.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Oct 2015 11:23:29 +0900

Hi, Brian,

On 10/27/2015 09:31 AM, Brian E Carpenter wrote:
>>> I'm not saying it was a good idea to use the protocol number
>>> space to code extension headers; on balance I think it was a bad
>>> idea. But from the point of view of a default-deny policy, it
>>> doesn't matter. An unknown extension header is no more dangerous
>>> than an unknown transport protocol, surely?
>> 
> Well, as a straw man, we could simply state that the extension header
> registry is closed and that no more extension headers will be
> defined, ever.

That's certainly a way better option that what we have right now. I'd
say I have a preference for UEH/rfc6564 bits, because we do have an
alternative to closing the definition of EHs forever.

But closing the registry as you note is one technically-correct solution
to the problem -- for instance, we did mention it as one of the possible
options in:
<https://tools.ietf.org/html/draft-gont-6man-rfc6564bis-00#section-7>.

> As a thought experiment, imagine that in 1997 (after Router Alert was
> defined), the IETF had stated that no more IPv4 options would be
> defined, ever. Practical impact? None.
> 

Not only possible, but 8while not my preferred option) it is at least
certainly better than what we have right now.

Thanks!

Cheers,

---

From: Mark Smith <[email-masked]>
Date: Tue, 27 Oct 2015 16:01:57 +1100

Hi Fernando,

<snip>

> attacks. -- hence the filtering needs to be applied as close to the

So I think that is the other security problem being solved -
protecting the network's ability to deliver most and hopefully all
legitimate packets to the hosts- and I agree that the network is the
place to perform that security function.

I've wondered if it is completely necessary to fully understand and
interpret the fields in a packet to be able to perform this function.
Instead I think it would be possible and more flexible to perform it
using a set of rules that define match/don't match bit patterns in
specified locations of either the bogus packets to be dropped, or the
compliment of the legitimate packets to be forwarded.

I thought this sounded like an ideal application for SDN switches, as
I know they can have 1000s if not millions of packet matching rules.
However, I did find that at least the OpenFlow 1.5 spec didn't support
the ability to define generic match/don't match bit patterns in
specified locations.

This sort of generic bit pattern matching ability is supported in
Linux using the iptables/ip6tables 'u32' module.

Regards,
Mark.