Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP

From: Ole Troan <[email-masked]>
Date: Wed, 1 Nov 2017 09:06:30 +0100

Mark,

> So truly "inserting" (cut, insert, glue) into an existing packet is not something that has been part of any IETF protocol as far as I'm aware.

IPsec (and some of the IPv6 transitioning work) introduced Bump-in-the-wire and Bump-in-the-stack.
Both are header insertion.

The BITW IPsec, is an IPsec transport offloaded to a security gateway. See RFC4301.

Best regards,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 1 Nov 2017 11:46:25 +0100 (CET)

On Mon, 30 Oct 2017, Michael Richardson wrote:

> And I think that most host stacks discard such things unless configured to
> expect a tunnel from D.

Agreed.

> What to do?
>
> I'd like to make it clear that the above construct is valid and that hosts
> SHOULD process it to remove the first IPIP hader and then process the packet
> as normal, even if "forwarding" is off. (If inner dst: is *NOT* B, then discard)

Ok. If it's configured to expect this kind of IPIP tunnel, agreed. 
Automatically, I don't think it should do this. It should not be default 
behaviour. Otoh I agree that ripping of a header isn't "forwarding" and 
shouldn't count as such. A 6to4 enabled host with forwarding disabled, 
receiving a 6to4 packet addressed to itself, should indeed take off the 
header and then process the inner packet.

If the OS comes by default with 6to4 enabled, then I expect it to be able 
to handle 6to4 packets coming to it. I wouldn't expect it to behave this 
way if 6to4 is turned off, then it should just drop the packet.

> As an aside, it would also be nice if we could say that an IPsec AH 
> header with an unknown SPI should be skipped as if it wasn't even there 
> (including any subsequent IP header as above..)  This is essentially a 
> similar situation.  I suspect that this statement is even more 
> controversial.

If the device isn't configured to do IPsec (even by default), then I don't 
think it should do what you describe.

It just seems weird to have end nodes strip off headers to try to gain 
access to whatever might be in there, at all costs, because it might be 
relevant to it (or not). If it receives an MPLS labeled packet and the 
device understands MPLS, should it start ripping off labels even if MPLS 
has been turned off on the device?

I believe users and admins would be very astonished if end systems started 
doing these things.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Nov 2017 16:17:50 -0400

Mark Smith <[email-masked]> wrote:
    > I think we need to be clear about what is "inserting" is. To me, the word
    > "inserting" means inserting to into something that already exists and has
    > previously been created - cut apart, insert, glue back together.

You can mince words here if you like, I don't mind.

If someone wants to add a packet by encapsulating with a new IP header, then
they have to pick a destination address for that header, and if they keep the
same destination as the inner one, then the end host has to process two headers.

So, if one wants to make the advice of 8200 useable in practice, then one
has to fix 6463.

If one argues that this will hard and shouldn't be done, then 8200 must be
wrong in some way.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Nov 2017 16:24:57 -0400

> Ok. If it's configured to expect this kind of IPIP tunnel,
    > agreed. Automatically, I don't think it should do this. It should not be
    > default behaviour. Otoh I agree that ripping of a header isn't "forwarding"
    > and shouldn't count as such. A 6to4 enabled host with forwarding disabled,

    > If the OS comes by default with 6to4 enabled, then I expect it to be able to
    > handle 6to4 packets coming to it. I wouldn't expect it to behave this way if
    > 6to4 is turned off, then it should just drop the packet.

Fair enough for 6to4.  Having 6to4 on or off is a useful setting that the
end-host should control, and for which the end-host gets some defined
benefit.

Removing redundant IPIP headers at the end-host provides no benefit to the
end-host.  The end-host does this in order to facilitate some unknown service
in the middle that did something.  If we want to enable such things to work
without prior permission (cf: "permissionless innovation") then we need to
fix hosts to do this.

There is also a hack that we could employ to sit on the fence.
We could decide that the destination address should no longer be B, but
instead it could be some well known same-prefix-as-B::anycast-IID,
and have the last router remove the outer IPIP header.
This seems gross in many many ways, but might make everyone happy.

    >> As an aside, it would also be nice if we could say that an IPsec AH header
    >> with an unknown SPI should be skipped as if it wasn't even there (including
    >> any subsequent IP header as above..)  This is essentially a similar
    >> situation.  I suspect that this statement is even more controversial.

    > think it should do what you describe.

Yet we skip other extension headers in order to find the ULP.
In fact, a host that has *NO* IPsec code *at all* will skip it as an unknown
header....  Because we got this wrong, we couldn't use AH to secure ND or any
other multicast (like OSPF) without causing of a flag day.  AH became totally
USELESS.  It was sad.

---

From: Tim Chown <[email-masked]>
Date: Thu, 2 Nov 2017 11:23:29 +0000

Hi Michael,

> On 1 Nov 2017, at 20:17, Michael Richardson <[email-masked]> wrote:
> 
> 

So the 6man chairs were quite keen that we try to push 6434-bis to a conclusion in Singapore, which is a goal the authors are very happy to share.

Obviously, reopening this issue may prove to be contentious.  The simplest and easiest answer is to punt it to a separate draft, and wrap up 6434-bis. I *think* the only other contentious issue that’s still open for the -bis is what we choose to say, or not say, about RAs vs DHCPv6.  In my view, wherever possible we should be just including pointers to existing text in other RFCs, and minimising any additional interpretation.

Having said that, why don’t you try to write some succinct text in advance of the Singapore 6man slot, post it, and see what the reaction is?  Worst case, you’ll then have the basis for a separate draft.

Tim

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 2 Nov 2017 14:03:50 +0100 (CET)

> without prior permission (cf: "permissionless innovation") then we need to

I don't think we should. Whatever is done in the middle that does encap, 
should also make sure it's decap:ed before it reaches the end host.

> other multicast (like OSPF) without causing of a flag day.  AH became totally

Right. I forgot that IPSEC is an extension header in IPv6, I tought of it 
as something that was encapsulated. So I take back what I said.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Nov 2017 08:36:27 +1300

> Obviously, reopening this issue may prove to be contentious.  The simplest and easiest answer is to punt it to a separate draft, and wrap up 6434-bis. I *think* the only other contentious issue tha…

Yes. I think it would be a misuse of a "node requirements" document to specify
something that isn't already well specified elsewhere.

> Having said that, why don’t you try to write some succinct text in advance of the Singapore 6man slot, post it, and see what the reaction is?  Worst case, you’ll then have the basis for a separate…

We need this. Michael is correct that it's a gap in the standards.

    Brian

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Nov 2017 13:15:43 -0300

On 10/31/2017 04:02 PM, Michael Richardson wrote:
> 
> Ole Troan <[email-masked]> wrote:
>     > Without having thought very much about it... I do think requiring a
>     > host to accept tunnelled packets to itself by default or not, requires
>     > further considerations.
> 
> I agree: it requires further consideration.
> 
>     > I am aware of no implementation that would support this. I would also
>     > be worried about this opening the door for "alternate" paths into the
>     > host stack.
> 
> I agree. Nobody does it this way.
> Yet 8200 (and 2460 before it) says that this is the way to insert headers.

No. EHs are not inserted or removed. When you do IPinIP, you are
creating a brad-new packet, *not* inserting EHs in the existing packet.

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

---

From: Tom Herbert <[email-masked]>
Date: Mon, 6 Nov 2017 09:00:17 -0800

> creating a brad-new packet, *not* inserting EHs in the existing packet.
I agree.

I think the sticking point is going whether a node can blindly perform
IP-IP encapsulation on packets to arbitrary destinations (as opposed
to using IP-IP for explicitly tunneling across a network). This
requires the assumption that all nodes in the downstream path will
forward a packet with IP-IP and the added extension headers, and that
the destination will accept such packets. The problem is that if a
packet is dropped because of the encapsulation or EHs and no ICMP
error is returned to the encapsulator then there is no way to recover.
The original source host might see packets being dropped on a
connection but will have no idea why. The encapsulator sees no problem
and so it won't modify its behavior.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Nov 2017 14:08:29 -0300

On 11/06/2017 02:00 PM, Tom Herbert wrote:
> to using IP-IP for explicitly tunneling across a network). 

Answer: No. :-)

> This
> the destination will accept such packets.

First condition: unlikely. Second condition: extremely unlikely.

> The problem is that if a

And, as Ole mention, additional issues caused by the possible fragmentation.

Don't rely on layer-3 in layer-3 encapsulation. ENcapsulate in a
transport layer that can segment data as appropriate to avoid layer 3
fragmentation.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Nov 2017 14:52:37 -0300

> I agree: it requires further consideration.

If you feel like doing/proposing this, some thoughts of th top of my head:

* Beware of the Hop Limit, this thing may allow to circumvent GSTM --
think about remote ND attacks... even remote SLAAC.

* You might need to validate source/destination addresses as packets get
decapsulated (e.g., think about scopes)

* Strong end strong end system model and weak end system models might
(or not) apply here [rfc1112]

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Nov 2017 14:57:15 -0300

> without prior permission (cf: "permissionless innovation") then we need to

"Permissionless innovation" smells a bit like security issue. :-)

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 6 Nov 2017 18:04:47 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Tom Herbert

> I think the sticking point is going whether a node can blindly
> perform IP-IP encapsulation on packets to arbitrary destinations
> (as opposed to using IP-IP for explicitly tunneling across a
> network).

Interesting thread. My question has been, during this exchange, why should we expect that *any* given payload should be assumed ahead of time, by a source, to be acceptable to a destination? Or if not acceptable, to return a particular ICMP message?

> This requires the assumption that all nodes in the downstream path
> will forward a packet with IP-IP and the added extension headers,
> and that the destination will accept such packets.

Yes. And if the source sends some obscure spreadsheet or word processor format, or streaming media compression algorithm, there's no assumption that the obscure format will be acceptable either.

> The problem is that if a packet is dropped because of the
> encapsulation or EHs and no ICMP error is returned to the
> encapsulator then there is no way to recover. The original source
> host might see packets being dropped on a connection but will have
> no idea why.

As in many other examples of not-very-standard payloads? Is there an expectation that any random host out there should know to be the egress of a tunnel? Or is this the sort of job one expects only or mainly from certain routers, very deliberately configured for such a task?

Bert

---

From: Tom Herbert <[email-masked]>
Date: Mon, 6 Nov 2017 10:35:03 -0800

> Interesting thread. My question has been, during this exchange, why should we expect that *any* given payload should be assumed ahead of time, by a source, to be acceptable to a destination? Or if…
Hi Bert,

The source doesn't need to make that assumption. If it puts something
in a packet that causes an intermediate node to drop it then the
source can detect the packet drop as a signal to back off using the
"advanced feature". This is essentially how happy eyeballs works for
IPv6; if IPv6 packets are being dropped then a host can revert to
using IPv4. A similar method could be used to introduce new EHs. The
key here is that it is only the source that is able detect the failure
and so that would be the one who could modify behavior to work around
the problem.

I agree that ICMP should be sent when packets are dropped due to
protocol, and in fact I wrote draft-herbert-6man-icmp-limits to cover
some common cases where routers drop because of EH limits. However,
ICMP is known to not be reliable and probably not robust enough for
this use case.

> Yes. And if the source sends some obscure spreadsheet or word processor format, or streaming media compression algorithm, there's no assumption that the obscure format will be acceptable either.
In that case the destination host can send an error back to the source
host over an application layer protocol.

> As in many other examples of not-very-standard payloads? Is there an expectation that any random host out there should know to be the egress of a tunnel? Or is this the sort of job one expects only…

Hosts can certainly be configured as tunnel endpoints, but they don't
perform automatic decapsulation. It would be quite easy to implement,
but I think there are going to be many concerns over the ramifications
if we do that.

Tom