Subject: Re: Looping [was: Proposed revised Extension Header text for rfc2460bis]

From: "C. M. Heard" <[email-masked]>
Date: Mon, 1 May 2017 20:31:31 -0700

On Mon, 1 May 2017 16:35:33 -0700 Tom Herbert wrote:
> The wording in RFC2460bis is:
>
> "Extension headers (except for the Hop-by-Hop Options header) are not
> processed, inserted, or deleted by any node along a packet's delivery
> path, until the packet reaches the node"
>
> Inserted or deleted are not common operations so maybe they can be
> squashed, but in the Internet extension headers _are_ being processed
> in modern Internet routers as Joel said, if nothing else to find the
> transport header. It's hard to rectify the standard against this
> reality other than to not use an EH at all which is pretty much where
> hosts are currently.

It would be more accurate to say that they are being _examined_ for
various purposes, most notably to find transport headers and to
examine them. That is not the same as being _processed_ as would
happen in end nodes.

Earlier versions said "are not examined" but the editor removed that.

//cmh

---

From: Tom Herbert <[email-masked]>
Date: Mon, 1 May 2017 20:54:21 -0700

> examine them. That is not the same as being _processed_ as would
Okay, but what would you call it when an intermediate drops a packet
because it encounters an unknown extension header? Or if it drops a
packet because a destination options EH makes the headers too big to
fit in its parsing buffer so that the transport header cannot be
found? It seems like the node is doing more than just examining them
in these cases; it's taking definitive action (i.e. dropping packets)
based on the presence of EHs other than HBH.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 May 2017 16:38:24 +1200

On 02/05/2017 15:54, Tom Herbert wrote:
...
> because it encounters an unknown extension header?

Sabotage.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 2 May 2017 08:04:57 -0700

>> because it encounters an unknown extension header?
Hi Brian,

One person's "sabotage" is another person's "value add" :-) Regardless
of what it's called and regardless of what the specification says, the
net effect is the same: if hosts can't reliably send extension headers
then they won't send them at all. This is a straightforward
application of the robustness principle, but effectively obsoletes the
protocol feature and that should be no surprise to anyone (I have been
calling this protocol ossification, but that might not be correct use
of that term).

Conceptually, if nodes gave a clear reason for why they are dropping a
host's packets with EH, then it is possible for the host to modify
subsequent packets to be more palatable. While it's true that ICMP is
also unreliable, at least if the error messages were defined we could
establish the pretense that source hosts and network nodes are working
together to achieve end to end connectivity. AFAICT the reason that
ICMP is being dropped is different from why EH is being dropped: the
ICMP case seems to be more of a security policy decision, whereas EH
seems to be more because of operational constraints and processing
limitations of devices. If that is the case maybe the ICMP drop case
is more easily addressed?

Btw, this discussion is not just limited to intermediate nodes. As I
mentioned in another thread we intend to add configurable limits to
the number of options that are accepted at a destination host. When
the destination drops the packet because of such limits it is
indistinguishable to the source host from an intermediate node
dropping the packet, so any attempted mitigations (like sending an
ICMP error) should similar.

I don't think the wording in RFC2460bis needs to change, but maybe
some guidance could be added to node requirements...

Tom

Tom

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

---

From: Tim Chown <[email-masked]>
Date: Tue, 2 May 2017 15:41:49 +0000

Hi,

> On 2 May 2017, at 16:04, Tom Herbert <[email-masked]> wrote:
> 
> <snip>
> 

I think I saw you mention this before, and it sounds reasonable. Feel free to propose text for 6434-bis …

Tim

---

From: "Leddy, John" <[email-masked]>
Date: Tue, 2 May 2017 15:56:50 +0000

Are we all talking about the same mechanisms that are expected in production environments?

I won’t address the HBH extension header, but focus on the Routing EH.

I would expect most/all SP’s would still have basic filtering in place to protect their infrastructure.
Any packet destined to an SP’s infrastructure block from an untrusted source should expect to be blocked.
Routers themselves would drop based on a trusted SRC ACL, but entry points to the network would also likely drop based on a DST ACL for the infrastructure address block.  The DST ACL acts as a proxy for the actual destinations, but the packet will be dropped with or without an EH if the src is not trusted to send packets.  If the packet has a Routing EH, but the destination is not part of the SP’s infrastructure, why would you explicitly drop it?  Even if you violated 2460bis and processed the EH on entry to the network and looked for an address that belonged to the infrastructure to drop the packet, the effect would be the same but there would be a lot more per packet processing.  You could just wait until the EH is processed then drop it when it re-enters the network with the dst part of the infrastructure block.  (not that worried about ping pong attacks, it can be done at higher levels in the stack anyway).

As a host building a packet with a Routing EH, I would not expect that picking any Internet addresses would just work and can be inserted into the EH.  There needs to be another mechanism to allow the application to know what can be put in the EH, this mechanism may be application dependent, but it isn’t just toss any addresses from a traceroute into an EH.  There may be components within the infrastructure that are open to being the dst of a packet with a Routing EH or separate addresses on core infrastructure that are open, but it wouldn’t be everything.

Right?

John

On 5/2/17, 11:04 AM, "ipv6 on behalf of Tom Herbert" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Brian,

    

    Tom
    
    Tom

---

From: Tom Herbert <[email-masked]>
Date: Tue, 2 May 2017 10:53:11 -0700

> I think I saw you mention this before, and it sounds reasonable. Feel free to propose text for 6434-bis …
It was Bob Hinden's suggestion to consider modifying node requirements
for host side processing of EH. I will propose some text.

Tom