Subject: draft-ioametal-ippm-6man-ioam-ipv6-options and RFC4302

From: Brian E Carpenter <[email-masked]>
Date: Mon, 8 Apr 2019 11:38:17 +1200

Hi,

As far as I understand the IOAM "Incremental Trace Option" and the
proposed mapping to IPv6 options, the draft seems to imply that an
IAOM option might get bigger as the packet flows through multiple
IAOM-aware routers.

(In fact I see that this is confirmed explicitly in
draft-ioametal-ippm-6man-ioam-ipv6-deployment.)

That is in direct conflict with RFC4302 (page 26), since the option
data length is included in the ICV calculation, even if the option
data is excluded.

I don't know if that is a show stopper, but at the very least the draft
should state that it will break the IPsec Authentication Header mechanism.

It will also potentially break PMTUD. Again, I don't know if that really
matters, but I think it needs to be stated.

I also note that this proposal is another good example for
draft-carpenter-limited-domains. We're getting to the point where
most proposals for IPv6 extensions are limited-domain protocols.

Regards
   Brian Carpenter

---

From: Mark Smith <[email-masked]>
Date: Mon, 8 Apr 2019 10:12:29 +1000

> most proposals for IPv6 extensions are limited-domain protocols.

And even in a limited domain, if the processing behaviour doesn't comply
with RFC8200, then it isn't IPv6 anymore.

Protocol specs aren't just packet formats (of course it would be much
easier  for everybody if they were, but then they aren't a protocol - an
agreement on behaviour.)

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 8 Apr 2019 13:53:02 +1200

Top-posting for one point:
As far as I am aware, RFC8200 does *not* state that the
option data length must not be changed in a mutable
hop-by-hop option.

Regards
   Brian

On 08-Apr-19 12:12, Mark Smith wrote:
> 
> 
> On Mon., 8 Apr. 2019, 09:38 Brian E Carpenter, <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
> And even in a limited domain, if the processing behaviour doesn't comply with RFC8200, then it isn't IPv6 anymore.
> 
> Protocol specs aren't just packet formats (of course it would be much easier  for everybody if they were, but then they aren't a protocol - an agreement on behaviour.)
> 
> 
> 
>     Regards
>        Brian Carpenter
> 
>     [email-masked] <mailto:[email-masked]>

---

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Mon, 8 Apr 2019 12:32:52 +0000

Just to clarify on the incremental tracing, draft-ietf-ippm-ioam-data [https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-05] defines tracing that can be achieved in 3 modes:
1. Pre-allocated Trace [Section 4.2.1]: that does not change the size of the trace option in transit.
2. Incremental Trace [Section 4.2.2]: which was designed based on hardware prototyping and optimization to insert trace data at fixed offset from the header and grow the option in transit. 
3. We also have another mode of tracing being discussed called Immediate export or Post card mode* that has minimal tracing data added to the option.

Not all encapsulation of IOAM data are expected to recommend/implement all the modes of tracing. 
We could not get to the discussion in 6man about incremental trace option, please refer to Slide 16 in [https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-in-situ-oam-ioam-in-ipv6-and-deployment-considerations-for-in-situ-oam-with-ipv6-options-00]. Based on feedback we can decide if this option makes sense in v6 representation of IOAM trace data at all. 
We will expand the discussion of incremental tracing and the caveats in the next revision of draft-ioametal-ippm-6man-ioam-ipv6-deployment.

Thanks,
Shwetha

* Immediate export/Post card mode tracing : does not require the tracing data to be carried within the option in the packet, but has instructions on what to collect and export with minimal context for correlation.
draft-ietf-ippm-ioam-data-05 – Immediate export flag
draft-song-ippm-postcard-based-telemetry

On 4/8/19, 7:23 AM, "ipv6 on behalf of Brian E Carpenter" <[email-masked] on behalf of [email-masked]> wrote:

    Regards
       Brian

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 8 Apr 2019 12:40:41 +0000

Cc'ing IPPM as well. 

Frank

> -----Original Message-----
> From: ipv6 <[email-masked]> On Behalf Of Shwetha Bhandari (shwethab)
> Sent: Montag, 8. April 2019 14:33
> To: Brian E Carpenter <[email-masked]>; Mark Smith
> <[email-masked]>
> Cc: 6man WG <[email-masked]>
> Subject: Re: draft-ioametal-ippm-6man-ioam-ipv6-options and RFC4302
> 
> Just to clarify on the incremental tracing, draft-ietf-ippm-ioam-data
> [https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-05] defines tracing that
> can be achieved in 3 modes:
> 2. Incremental Trace [Section 4.2.2]: which was designed based on hardware
> prototyping and optimization to insert trace data at fixed offset from the header
> and grow the option in transit.
> 3. We also have another mode of tracing being discussed called Immediate
> export or Post card mode* that has minimal tracing data added to the option.
> 
> We could not get to the discussion in 6man about incremental trace option,
> please refer to Slide 16 in
> [https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-in-
> situ-oam-ioam-in-ipv6-and-deployment-considerations-for-in-situ-oam-with-
> ipv6-options-00]. Based on feedback we can decide if this option makes sense in
> v6 representation of IOAM trace data at all.
> We will expand the discussion of incremental tracing and the caveats in the next
> revision of draft-ioametal-ippm-6man-ioam-ipv6-deployment.
> 
> Thanks,
> Shwetha
> 
> * Immediate export/Post card mode tracing : does not require the tracing data
> to be carried within the option in the packet, but has instructions on what to
> collect and export with minimal context for correlation.
> draft-ietf-ippm-ioam-data-05 – Immediate export flag draft-song-ippm-
> postcard-based-telemetry
> 
> On 4/8/19, 7:23 AM, "ipv6 on behalf of Brian E Carpenter" <ipv6-
> [email-masked] on behalf of [email-masked]> wrote:
> 
>     > On Mon., 8 Apr. 2019, 09:38 Brian E Carpenter,
> <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     >     Hi,
>     >
>     > Protocol specs aren't just packet formats (of course it would be much easier
> for everybody if they were, but then they aren't a protocol - an agreement on
> behaviour.)
>     >
>     >
>     >
>     >     Regards
>     >        Brian Carpenter
>     >

---

From: Tom Herbert <[email-masked]>
Date: Mon, 8 Apr 2019 08:11:48 -0700

> option data length must not be changed in a mutable
Brian,

There is no allowance in RFC8200 for changing the Option Type or Option Length:

"The third-highest-order bit of the Option Type specifies whether or
not the Option Data of that option can change en route to the packet's
final destination."

This is also supported by

"When an Authentication header is present in the packet, for any
option whose data may change en route, its entire Option Data field
must be treated as zero-valued octets when computing or verifying the
packet's authenticating value."

And note that if the option length were to change, that would
necessiate adding or deleting TLVs in the EH. If the length increases
then some other TLVs would overwritten, if the length decreases then
new TLVs need to be set (even if they're just padding).

Regardless of whether the option length can change, there's also no
provision in RFC8200 that would allow an intermediate node to change
extension header length or insert a new EH. So the space in the packet
for HBH options is fixed, and so for something like IOAM the sender
can just set an mutable option (data is mutable that is) with enough
space for its purposes.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 9 Apr 2019 10:55:49 +1200

> There is no allowance in RFC8200 for changing the Option Type or Option Length:

Agreed. But while there are restrictions on what a forwarding node
can do, I don't believe there is any statement that forbids this
particular behaviour for mutable HbH options.

> packet's authenticating value."

Indeed. But the Auth header is optional.
 
> new TLVs need to be set (even if they're just padding).

Sure. Messy code, but not impossible.
 
> for HBH options is fixed,

No, that isn't stated anywhere. If a forwarding node expands a HbH
option as the IOAM spec implies, downstream nodes will have no
difficulty interpreting the packet.

I'm not advocating this, but I think it's a fact.

> and so for something like IOAM the sender

I agree. But that would need to be added to the spec. It would
avoid the messy code, too.

    Brian

---

From: Tom Herbert <[email-masked]>
Date: Mon, 8 Apr 2019 16:22:41 -0700

> Indeed. But the Auth header is optional.
But, RFC8200 also states that with the exception of HBH option,
intermediate nodes do not process extension headers. So when a node
processes HBH options it doesn't know whether they are covered by an
AH ICV, and hence the node MUST assume they are and abide by the rules
mutable data in packet headers which are articulated in RFC8200.

> Sure. Messy code, but not impossible.
It may be possible to code such a thing, but we haven't seen any
proposal that shows how to this robustly and securely.

> I'm not advocating this, but I think it's a fact.

I'm not convinced that is a fact. Suppose some downstream node doesn't
handle the large option size or doesn't like something else about the
modified option and decides to drop the packet. The intermediate node
might even send an ICMP error like in draft-ietf-6man-icmp-limits-00.
But even if the source gets an ICMP error, what can it do? It didn't
cause the error, and there's no way of knowing which node in the
network inserted problematic data. The offending node that inserted
the bad data gets no notification that it is causing a problem. So all
this may very well result in a communications black hole.

The lack of accountability of in-flight packet modifications
fundamentally breaks the model of ICMP errors and the model that the
source node is responsible for creating and formatting packets. IMO,
in-flight modification of packets is very risky and hard to be robust
for this reason. The requirements for modification need to be
unambiguous and strict, which I believe RFC8200 already provides.

Tom

---

From: Mark Smith <[email-masked]>
Date: Tue, 9 Apr 2019 11:50:52 +1000

> <[email-masked]> wrote:

<snip>

> unambiguous and strict, which I believe RFC8200 already provides.

What's really going on is that people are trying to do host processing
of packets "in the network". NAT, NFV and SFC are all examples.

Host processing of packets is only supposed to occur at the node that
has the packet's destination address. If the node isn't assigned the
packet's destination address, then it is by RFC8200 definition a
router,

   router       a node that forwards IPv6 packets not explicitly
                addressed to itself.

   host         any node that is not a router.

and only forwards the packet's towards it's destination address, in a
payload oblivious manner. This is why encryption of packets' payloads
doesn't cause forwarding problems.

If in-flight processing of a packet involves processing beyond the
IPv6 fixed header and HbH option, then the path the packet is taking
is actually a series of host hops (with the possibility of forwarding
routers in between the host hops).

Since those hops are hosts, it means that these host hops need to be
explicitly identified using a packet's source and destination address
fields. In effect, each host hop is both originating and
re-originating the packet along the path.

If the original packet needs to be preserved at each of these host
hops, then there needs to be somewhere else to record and store the
individual host hops' SA and DA. Another outer IPv6 (or IPv4) header
is the answer, and as Brian observed during BCP 204 development, IP
tunnel endpoints are hosts, because they're originating packets or the
final destination for them.

Semantically, this also means that source and destination addresses in
all packets are always host addresses.

Regards,
Mark.