Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ]

From: Bob Hinden <[email-masked]>
Date: Mon, 2 May 2016 13:38:35 -0700

Based on the discussion, I think there is agreement to keep the text in the rfc2460bis -04 draft about not inserting extension headers.  I made a change to the second sentence regarding encapsulation based on the email discussion:

   Extension headers must never be inserted by any node other than the
   source of the packet.  One approach to meet a requirement to add
   extension headers is to use IP Encapsulation, for example, as defined
   in [RFC2473].

Please let me know if this is OK.

The other related proposed text regarding not deleting or changing the size of extension headers is:

   Extension headers must never be deleted or changed in size by any
   node on the path the packet takes.

   The contents of an Extension header or Option in an Extension header
   may be modified if this is permitted by the definition of the
   Extension header or option.

This was proposed earlier on the list.  I think it is consistent the prohibition against inserting extension headers.

Please comment.

Thanks,
Bob

> On Apr 28, 2016, at 6:08 PM, Fernando Gont <[email-masked]> wrote:
> 
> On 04/28/2016 09:37 PM, Brian E Carpenter wrote:
>> On 29/04/2016 04:34, Fernando Gont wrote:
>> 
>>> mmm... I guess you don't need ietf permission to violate the specs in
>>> your own walled garden?
>> 
>> Since the protocol police have been very quiet recently, that is a fact of
>> life. However, if we want to be explicit about it (after 2460bis) we could
>> write it up.
> 
> I fully agree. What I meant is: the fact that you could potentially make
> something work in a walled garden doesn't seem an argument to legitimize
> that behavior -- particularly when I guess we're supposed to be
> standarizing more for the general case than for the walled garden case.
> 
> 
>> Diffserv already allows domain-specific packet mutations; the
>> flow label tolerates mutations in certain circumstances. I don't see why
>> we couldn't also describe the circumstances in which other header mutations
>> are allowed. But first, define the precise meaning of "the open Internet."
> 
> Have this mutations the same potential implications as the
> insertion/removal of EHs?
> 
> 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: Tue, 3 May 2016 08:37:27 +1000

Hi Bob,

On 3 May 2016 6:38 AM, "Bob Hinden" <[email-masked]> wrote:
>
> Based on the discussion, I think there is agreement to keep the text in
the rfc2460bis -04 draft about not inserting extension headers.  I made a
change to the second sentence regarding encapsulation based on the email
>    extension headers is to use IP Encapsulation, for example, as defined

+1

>    node on the path the packet takes.

+1

>    Extension header or option.

The thing I would criticise about this text is that it would not discourage
silent and unattributable changes.

I think change can create opportunities for failure, so having change
attributed to the router that makes them is preferable because it can help
identify the failing router. If silent changes can be allowed, I think the
principle should be to try to minimise when they're allowed. Ideally they
should be now limited and left to hop count, traffic class and flow label.

Routing Header type 0 was a good example of how an EH could be changed in
flight as it is possible to work out which router made the last change to
the RH EH. Is it possible to use that as an example of how to do
attributable EH modifications, while pointing out that it was deprecated
because its function could be abused, rather than anything being wrong with
the EH processing being performed?

Regards,
Mark.

> This was proposed earlier on the list.  I think it is consistent the
prohibition against inserting extension headers.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 May 2016 11:58:56 +1200

On 03/05/2016 10:37, Mark Smith wrote:
...
> silent and unattributable changes.

The sentence is actually a no-op anyway; it really states the obvious.
A slightly stronger version would be:

 The contents of an Extension header or Option in an Extension header
 must not be modified unless this is permitted by the definition of the
 Extension header or option.

but I am not sure that is a clarification of RFC 2460; it seems a
bit like a new rule.

     Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 May 2016 17:36:05 -0300

On 04/29/2016 02:08 PM, Michael Richardson wrote:
> 
> (I'd love to also change the behaviour of AH so that one would ignore AH
> headers if one hasn't got a matching SPI#. That's what kept us from using AH
> to secure ND back in the SEND days)

Then, what's the point of doing AH, anyway?

> And, it seems that "10", which creates ICMP Parameter Problem messages
> for multicast destinations, allows for amplication attacks, and we should
> deprecate that behaviour, period.

Agreed:
<https://www.ietf.org/archive/id/draft-gont-6man-ipv6-smurf-amplifier-03.txt>

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 May 2016 18:45:20 -0300

On 04/29/2016 04:05 PM, Pascal Thubert (pthubert) wrote:
> Hello Mark:
> 
> Ø  4) troubleshooting modifications that cannot or cannot easily be
> attributed to a specific node can be very time-consuming, require out of
> hours work and are likely to require potentially disruptive packet
> capturing within or downstream of each network element that could have
> modified the packet (assuming it is possible to access that NE or link).
> 
> DetNet has the concept of Replication and Elimination, which created
> intermediate sources and sinks, and certainly observed that need.

I think the original question was different.

The original question was whether inserting headers is part of RFC2460,
and whether it makes sense to clarify this.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 May 2016 18:47:54 -0300

> Please let me know if this is OK.

I think the original text was even clearer. Put another way:
encapsulation is the only rfc2460-compliant way to add EHs.

>    Extension header or option.

Looks good.

Thanks,

---

From: Bob Hinden <[email-masked]>
Date: Thu, 5 May 2016 17:12:42 -0700

Brian,

> On May 2, 2016, at 4:58 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Since we do allow Extension headers and Options to be modified, I have a slight preference for the previous text.  It is, as you say” stating the obvious.  Seems like saying this here, right after the text about inserting and deleting, makes sense.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 6 May 2016 12:18:13 +1200

Bob,

+1

   Brian

---

From: [email-masked]
Date: Fri, 6 May 2016 10:27:10 +0200

> This was proposed earlier on the list.  I think it is consistent the prohibition against inserting extension headers.

I am not convinced we can add this paragraph.

Have you evaluated the consequence for a BITW implementation of e.g. IPsec (RFC4301)?
(or perhaps other BITWs like an ILNP proxy or SHIM6 proxy)

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 7 May 2016 07:48:46 +1200

> (or perhaps other BITWs like an ILNP proxy or SHIM6 proxy)

There would be consequences if it said "must not be modified unless this is permitted".
But it doesn't. It says "may be modified if this is permitted", which as I said a couple
of days ago is really a no-op.

(BTW there is no RFC describing a shim6 proxy and I sincerely hope there is no
running code either.)

   Brian

---

From: Tom Herbert <[email-masked]>
Date: Fri, 6 May 2016 13:09:07 -0700

> (BTW there is no RFC describing a shim6 proxy and I sincerely hope there is no
For that matter, is there an actual implementation of an ILNP proxy? I
can't find code that just implements ILNP....

Thanks,
Tom

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 May 2016 13:41:10 +1000

Hi,

> Have you evaluated the consequence for a BITW implementation of e.g. IPsec (RFC4301)?

In my thoughts about EH insertion/deletion, to me IPsec has been a
reference model. The reason why was that when I learnt about IPsec and
its transport and tunnel modes, I would have thought that
host-to-IPsec-gateway would use transport mode. This would have meant
that the IPsec gateway would have been inserting and removing the ESP
and/or AH headers to/from the original hosts' packets, rather than
tunnelling them to the host. I think it was a surprise because at the
time I thought of tunnelling as only something that was done between
routers.

In other words,

Host-to-Host: transport mode
Host-to-GW: tunnel mode
GW-to-GW: tunnel mode

None of those would require an IPsec gateway to insert an ESP and/or
AH header into a packet it has received from somewhere else.

This text from Section 4.1 is making it clear that a security gateway
is only allowed to use transport mode if the source or destination
address of the packet is the security gateway itself i.e., the SG is
actually an end-system for this communication.

"To clarify, the use of
   transport mode by an intermediate system (e.g., a security gateway)
   is permitted only when applied to packets whose source address (for
   outbound packets) or destination address (for inbound packets) is an
   address belonging to the intermediate system itself."

RFC4301 seems to be using BITW as more of an implementation method,
rather than having a defined IPsec role.

"c. The use of a dedicated, inline security protocol processor is a
      common design feature of systems used by the military, and of some
      commercial systems as well.  It is sometimes referred to as a
      "bump-in-the-wire" (BITW) implementation.  Such implementations
      may be designed to serve either a host or a gateway.  Usually, the
      BITW device is itself IP addressable.  When supporting a single
      host, it may be quite analogous to a BITS implementation, but in
      supporting a router or firewall, it must operate like a security
      gateway."

This would seem to be saying that when serving a single host, a BITW
implementation is conceptually part of the single host's stack (e.g.,
the text about having an IP address being optional would apply).
However, when it is serving more than one host, it must act as a
security gateway, meaning it must use IPsec tunnel mode for everything
except its own 'end-system' traffic, where it could chose either
transport or tunnel mode.

So I don't think a BITW implementation method for IPsec really
contradicts what is in RFC2460 or what the proposed RFC2460bis text
is.

Regards,
Mark.

---

From: [email-masked]
Date: Sun, 8 May 2016 20:40:02 +0200

> of days ago is really a no-op.

If it is a no-op what purpose does the text serve?
I presume you are only referring to the second paragraph?

----

----

apart from increasing the risk of making something like a BITW style implementation of something not compliant, can you help me understand the motivation behind this change? what are you trying to achieve? have text that can be used to prohibit something happening in the future?

RFC2460 has a very clear "world view". a network consists of hosts, routers and links. RFC2460 specifies very clearly that a router does not examine or process extension headers (with the one well-known exception). adding the above paragraph diffuses and weakens that.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 May 2016 09:41:19 +1200

> If it is a no-op what purpose does the text serve?

Not much - it states the obvious, doesn't it?

> I presume you are only referring to the second paragraph?

Yes.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 May 2016 22:07:26 -0400

> contradicts what is in RFC2460 or what the proposed RFC2460bis text

I agree.  A BITW is just a host implementation that happens to be split
multiple CPUs.

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

---

From: [email-masked]
Date: Mon, 9 May 2016 15:00:57 +0200

Brian,

>> I presume you are only referring to the second paragraph?

From that can I interpret you such that you would be happy with not making any changes to 2460?

Ole

---

From: Bob Hinden <[email-masked]>
Date: Mon, 9 May 2016 09:52:25 -0700

> On May 8, 2016, at 2:41 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Regarding (assuming this is what is being discussed here):

It is just summarizing that some exceptions headers and options allow their content to be changed.  Since we are making statements about inserting and deleting, I think it makes sense to also say that they may change to avoid any future argument that they are or are changeable.  It’s a clarification.

Bob

---

From: joel jaeggli <[email-masked]>
Date: Mon, 9 May 2016 09:55:29 -0700

> and whether it makes sense to clarify this.

It's not obvious how you do this reliably without running into MSS issues.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 May 2016 09:47:20 +1200

On 10/05/2016 04:52, Bob Hinden wrote:

<snip>

> It is just summarizing that some exceptions headers and options allow their content to be changed.  Since we are making statements about inserting and deleting, I think it makes sense to also say t…

Exactly. It's a judgment call whether to include it.

Ole: I support the changes that Bob proposed, but if there is an objection to this
particular clarification sentence I have no strong objection to removing it.

   Brian