Subject: Re: [v6ops] WG Doc? draft-gont-v6ops-ipv6-ehs-packet-drops

From: joel jaeggli <[email-masked]>
Date: Tue, 5 Apr 2016 10:01:18 -0300

On 3/29/16 6:51 AM, [email-masked] wrote:
>>>>> Yes. It's a bug in RFC2460 that this ambiguity arises.
>>>> 
>>>> I took it as a feature. IMO, the idea of a chain enables this
>>>> feature, and I don't think it should be so quickly dismissed as
>>>> potentially useful.
>>>> 
>>>> I appreciate that not everyone agrees, though.
>>> 
>>> It does break PMTUD though.
>>> 
>> 
>> Which I think is because of an expectation that the device
>> identified in the packet source address (the "sender") is
>> responsible for creating the whole packet. It can't be a "unicast
>> source address" field if there are multiple sources of the
>> information in the packet.
>> 
>> It also breaks troubleshooting methods and assumptions about the
>> source address field that have been true for IPv6, IPv4 and many,
>> if not all, past layer 3 protocols.
>> 
>> One perspective on tunneling is that when it modifies the packet,
>> it adds another source address field to record that another device,
>> other than the original packet source device, has made additions to
>> the packet.

Encapsulation does not alter the wrapped packet, except perhaps by
decreasing the ttl.

> indeed, and is why 2460 bis states: "Extension headers must never be
> inserted by any node other than the source of the packet.  IP
> Encapsulation must be used to meet any requirement for inserting
> headers, for example, as defined in [RFC2473]."
> 
> cheers, Ole
> 
> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Apr 2016 03:00:16 +1000

> Encapsulation does not alter the wrapped packet, except perhaps by

I agree, I was using "modified" in the sense that if you don't consider
what layers these actions are taking place, the packet originally sent has
been modified compared to after it has been encapsulated. The thing about
tunneling though is what and by whom it was added is clear and unambiguous
because of encapsulation.

Adding, deleting or changing EHs in the network would be silent about who
made the changes (except when modification records who did the change e.g.
RH0). In this case the packet source address has lost its much of its
clarity, because there are now multiple sources of the information in the
packet.

Regards,
Mark.

---

From: Joe Touch <[email-masked]>
Date: Tue, 5 Apr 2016 10:40:45 -0700

On 4/5/2016 10:00 AM, Mark Smith wrote:
> Adding, deleting or changing EHs in the network would be silent about
> who made the changes (except when modification records who did the
> change e.g. RH0). In this case the packet source address has lost its
> much of its clarity, because there are now multiple sources of the

Given the pervasive presence of NAT and other header rewriting devices,
there are already many such sources. Unless the header is authenticated,
there are no assurances as to exactly where the information therein
originated.

Joe

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Apr 2016 13:41:19 +1000

On 6 Apr 2016 3:40 AM, "Joe Touch" <[email-masked]> wrote:
> Given the pervasive presence of NAT

Not in the IPv6 Internet yet I hope.

and other header rewriting devices,
> there are no assurances as to exactly where the information therein

So that sounds a bit like an argument that if the IP packet is not
authenticated, then devices processing them don't have to respect the
protocols at all, because there is nothing to prevent the changes being
detected.

Regards,
Mark.

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Wed, 06 Apr 2016 11:54:24 +0200

> there are no assurances as to exactly where the information therein
NAT is not pervasively present in IPv6 networks, so that's not really 
relevant to the discussion.

The outer packet headers can't be fully invariant end to end, because 
some fields have to/ may be rewritten along the path, even in normal 
operations e.g. HBH options, flow label, and hop count. So any 
protection of header content would have to be very limited in scope.

But even authenticated headers get messed around, so that's also no 
solution in and of itself.  Look at the hoops that people have to jump 
through (both technical and legal) to make https and other strong end to 
end transports work over NAT and proxies.

IMHO the end to end principle is still worth fighting for.

But IMVHO another consequence of the end to end principle is that if you 
want end to end protection, you'd better do it yourself, at a layer you 
control, and not rely on any underlying infra to guarantee it for you. 
On a routed network, there's always a man in the middle. So you can 
never trust headers in the general case, even if they're authenticated.

Whilst the end to end principle itself doesn't preclude in-flight 
deep-packet-inspection (where appropriate/legally justified/technically 
possible). [Note: Your lawyers may disagree. You may be subject to 
different laws.]

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Joe Touch <[email-masked]>
Date: Wed, 6 Apr 2016 10:25:03 -0700

On 4/5/2016 8:41 PM, Mark Smith wrote:
>> Unless the header is authenticated,

It means there are no assurances. That does not mean that intermediate
devices have no rules or consequences - it means that the receiver
cannot *assume* otherwise.

Joe