Re: [Int-area] Comments for draft-ietf-intarea-tunnels-02

[Joe Touch <[e-mail]>]

Hi, Vincent,

Thanks for your detailed comments. All are queued up for the next revision.

Comments below only where needed.

Joe

On 6/8/2016 7:44 AM, Vincent Roca wrote:
> Hello everybody,
>
>
> First of all, I need to say that I found the
> draft-ietf-intarea-tunnels-02 I-D extremely useful
> and wish I found it before.
>
> We exchanged a few private emails with Joe last week and I promised to
> send detailed
> comments on the list. Here they are... Sorry if this is a bit long.
...
> I also clarified the case of encapsulation header size that is deducted.
It's worth noting throughout that MTU is defined as the size of the payload.

> ** Path MTU definition: I think it's worth clarifying that we focus on
> the tunnel PMTU in this I-D.
> I also explain that the encapsulation header size has already been
> subtracted from the
> Tunnel PMTU.
>
> OLD:
>    o  Path MTU (PMTU): the largest message that can transit a path.
>       Typically, this is the minimum of the link MTUs of the links of
>       the path.
>
> NEW:
>    o  Path MTU: the largest message that can transit a path.
>       Typically, this is the minimum of the link MTUs of the links of
>       the path.
>
>    o  Tunnel Path MTU (TunnelPMTU): the largest Tunnel Transit Packet
> (or fragment)
>       that can transit inside the tunnel's path. The encapsulation
> header size is already
>       subtracted from TunnelPMTU and this TunnelPMTU  is not visible
> from outside the
>       tunnel, unlike the Tunnel MTU.

This definition is what the tunnel MTU is intended to convey.

I think we do need another term for the path MTU between the egress and
ingress but NOT inside the tunnel. I prefer to just call that the PMTU
between the ingress and egress, though.

>
>
> ** In tunnel MTU definition:
> Say explicitly that the encapsulation header size has already been
> subtracted from
> the Tunnel MTU,  since encapsulation headers are considered as
> "headers from lower
> protocols" and therefore excluded.
>
> OLD:
>    o  Tunnel MTU (TMTU): the largest message that can transit a tunnel.
>       Typically, this is limited by the egress reassembly MTU.
>
> NEW:
>    o  Tunnel MTU (TunnelMTU): the largest message that can transit a
> tunnel.
>       The encapsulation header size is already subtracted from TunnelMTU.
>       Typically, the TunnelMTU is limited by the EgressRMTU.
This should be clarified as the MTU that can transit *inside* a tunnel.

...
> ** Still section 4.1: we cannot say that 1500 is the minimum
> EgressRMTU as
> we need to remove the encapsulation header size before as detailed above.
> I also tried to explain why... Not easy! Do you have a better explanation?

It's because IPv6 uses the term MTU in terms of the link payload, not as
the network payload.

Throughout this doc, we similarly refer to the tunnel as a link, so link
MTU is the correct notion.

...
> ** Section 5.2: I fully agree with:
>    "Detect when the egress MTU drops below the required minimum and shut
>    down the tunnel if that happens - configuring the tunnel down and
>    issuing a hard error may be the only way to detect this anomaly, and
>    it's sufficiently important that the tunnel SHOULD be disabled."
>
> However this not only an implementation aspect. This is also required
> for security
> reasons and therefore it should be discussed in the Security
> Considerations section
> as well. E.g., we observed opposite behaviors from an on-the-shelf IPsec
> implementation and discussed consequences in our (now expired)
> draft-roca-ipsecme-ptb-pts-attack-00.
>
> [WG: we already discussed this aspect in private emails with Joe last
> week.]

See below - I think Vincent and I are still working on this...

> ** Section 5.4.4: it is said, for the "consistent with this doc" part,
> that:
>         "Shuts the tunnel down if the tunnel path MTU isn't => 1280."
> This contradicts the example of section 4.1 where TunnelPMTU ==
> 1280-40-TOptSz
> is valid...
> Do you mean "Shuts the tunnel down if the Tunnel MTU, seen from the
> outside network,
> isn't >= 1280"?

Yes. That's consistent with tunnel = link and MTU = payload.

> ** Section 6, Security considerations
> As already discussed privately with Joe, I may have other items but
> still need
> to think it over.
>
>
> ** Section A.1: the following sentence is ambiguous:
> OLD:
>         "When the encapsulated packet exceeds the MTU of the tunnel, the
>         packet needs to be fragmented."
> This is the Tunnel Path MTU, not MTU of the tunnel which can be
> understood as
> synonymous to the Tunnel MTU.

It's the tunnel MTU, as clarified above.

> ** Section A.1/ A.2:
> Discussion in section 4.1 assumes an Outer Fragmentation scheme. The
> notion of
> Egress Reassembly also assumes an Outer Fragmentation. In fact it
> seems to be
> the model assumed throughout this I-D but this is not clearly stated
> unless I missed
> something. Am I right?

You are correct.

> It's clearly more universal as it does not make any assumption on the
> inner packet
> (can it be fragmented on path or not, as explained in A.2).
> I think the I-D should identify from the beginning the assumption made
> (Outer vs.
> Inner fragmentation) as it will impact the discussion. Said
> differently move Appendix A
> in Section 3 for instance.

Point taken, esp. with discussions on other lists (e.g., v6ops) and the
notion of "recursive" tunneling (X in X, for any X).

Joe