Re: Propagating IP/ECN field when L2TP sits between IP as both L2 payload and PSN

This is a multi-part message in MIME format.
--===============6922963142384731000==
Content-Type: multipart/alternative;
 boundary="------------5702327C13CE5A71D7068A8B"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------5702327C13CE5A71D7068A8B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Ignacio,

RFC6040 contains the following para:

    If an ingress claims compliance with this specification, it MUST NOT
    permanently disable ECN processing across the tunnel (i.e., only
    using compatibility mode).  It is true that such a tunnel ingress is
    at least safe with the ECN behaviour of any egress it may encounter,
    but it does not meet the central aim of this specification:
    introducing ECN support to tunnels.

To be safe, an L2TP ingress could permanently use compatibility mode. 
Compatibility mode simply involves the ingress clearing the 2-bit ECN 
field in the outer (setting to 00). This would not allow the L2TP 
endpoint to claim compliance with RFC6040, but at least it would be 
safe. I think it would be useful to add this as operational advice to 
draft-ietf-tsvwg-rfc6040shim-update.

I would imagine most implementations of L2TP could be configured to do 
this (do you agree?). I suspect some still allow config of the setting 
the whole 8-bit ToS bytes, in which the 2 lowest significant bits are 
the ECN field (distinct from the 6-bit Diffserv field).


Nonetheless, altho safety is important, the main purpose of this draft 
is to go beyond that - to say how an implementer would add ECN support 
to L2TP. See inline...

On 01/06/17 21:24, Ignacio Goyret wrote:
>>> Whereas, if one IP header encapsulates another, if the ECN field
>>> were processed in any way other than RFC6040, it would be invalid
>>> (unless another RFC were written to update RFC6040). Therefore,
>>> whenever L2TP is tunnelling IP in IP, it is mandatory to comply
>>> with RFC6040. So I am asking the L2TPext WG for advice on how you
>>> guys would make a mandatory update to L2TP, rather than 'just' an
>>> optional extension.
>>>
>> I think first we probably need to understand the applicability because
>> it is not an IP-in-IP encap, there's a Layer 2 header in between, not
>> tightly coupled but rather part of the transported payload.
> And an IP header (if present) may be down various layers and not easily
> accessible.
>
> So far, LCCEs do not need to decapsulate all the stacked layers trying
> to look for a potential IP header. Adding that requirement as a MUST is
> a tall order that may be too onerous and impossible to satisfy.

As recently discussed on int-area, I am going to widen the applicability 
of draft-ietf-tsvwg-rfc6040shim-update to include cases where a L2 
header is being encapsulated. But this wider scope would not be as 
mandatory.

I definitely do not want to make this a MUST. I made this point myself, 
in response to Tom Herbert on the int-area list a couple of days ago, 
pasted here:

> On 31/05/17 02:45, Bob Briscoe wrote:
>> One way to include all these cases in the scope of the draft is to 
>> say the tunnel endpoint SHOULD check the L2 payload for an IP header, 
>> even when the L2 header is not being added / removed. But that is 
>> rather an onerous requirement, don't you think? Especially given this 
>> would be asking the implementer to violate layering, we can only ask 
>> that it is done when feasible; it cannot be a hard requirement (e.g. 
>> L2 payload could be encrypted). 

I think MAY is too weak, but SHOULD is too strong, so how about this 
form of wording:
"If feasible, the tunnel endpoint SHOULD check the L2 payload for an IP 
header"

And I intend to add something along the lines of: "Otherwise, if the 
outer is IP, it MUST zero the outer ECN field."

>
>
>> Now, what you describe in terms of level of mandatory applies to RFC 6040.
>> If an implementation does not comply with RFC 6040 it is, well, not
>> compliant with RFC 6040.
> Exactly.
>
> And that's why I believe this should be a _recommended_ extension when
> inner IP headers can be found easily but it cannot be a mandatory
> requirement for the L2TP protocol as a whole.
As above, I strongly agree with you.


Bob

>
> -Ignacio
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------5702327C13CE5A71D7068A8B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Ignacio,<br>
    <br>
    RFC6040 contains the following para:<br>
    <pre class="newpage">   If an ingress claims compliance with this specification, it MUST NOT
   permanently disable ECN processing across the tunnel (i.e., only
   using compatibility mode).  It is true that such a tunnel ingress is
   at least safe with the ECN behaviour of any egress it may encounter,
   but it does not meet the central aim of this specification:
   introducing ECN support to tunnels.
</pre>
    To be safe, an L2TP ingress could permanently use compatibility
    mode. Compatibility mode simply involves the ingress clearing the
    2-bit ECN field in the outer (setting to 00). This would not allow
    the L2TP endpoint to claim compliance with RFC6040, but at least it
    would be safe. I think it would be useful to add this as operational
    advice to draft-ietf-tsvwg-rfc6040shim-update.<br>
    <br>
    I would imagine most implementations of L2TP could be configured to
    do this (do you agree?). I suspect some still allow config of the
    setting the whole 8-bit ToS bytes, in which the 2 lowest significant
    bits are the ECN field (distinct from the 6-bit Diffserv field).<br>
    <br>
    <br>
    Nonetheless, altho safety is important, the main purpose of this
    draft is to go beyond that - to say how an implementer would add ECN
    support to L2TP. See inline...<br>
    <br>
    <div class="moz-cite-prefix">On 01/06/17 21:24, Ignacio Goyret
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">Whereas, if one IP header encapsulates another, if the ECN field
were processed in any way other than RFC6040, it would be invalid
(unless another RFC were written to update RFC6040). Therefore,
whenever L2TP is tunnelling IP in IP, it is mandatory to comply
with RFC6040. So I am asking the L2TPext WG for advice on how you
guys would make a mandatory update to L2TP, rather than 'just' an
optional extension.

</pre>
        </blockquote>
        <pre wrap="">
I think first we probably need to understand the applicability because
it is not an IP-in-IP encap, there's a Layer 2 header in between, not
tightly coupled but rather part of the transported payload.
</pre>
      </blockquote>
      <pre wrap="">
And an IP header (if present) may be down various layers and not easily
accessible.

So far, LCCEs do not need to decapsulate all the stacked layers trying
to look for a potential IP header. Adding that requirement as a MUST is
a tall order that may be too onerous and impossible to satisfy.</pre>
    </blockquote>
    <br>
    As recently discussed on int-area, I am going to widen the
    applicability of draft-ietf-tsvwg-rfc6040shim-update to include
    cases where a L2 header is being encapsulated. But this wider scope
    would not be as mandatory.<br>
    <br>
    I definitely do not want to make this a MUST. I made this point
    myself, in response to Tom Herbert on the int-area list a couple of
    days ago, pasted here:<br>
    <br>
    <blockquote type="cite">On 31/05/17 02:45, Bob Briscoe wrote:
      <blockquote type="cite">One way to include all these cases in the
        scope of the draft is to say the tunnel endpoint SHOULD check
        the L2 payload for an IP header, even when the L2 header is not
        being added / removed. But that is rather an onerous
        requirement, don't you think? Especially given this would be
        asking the implementer to violate layering, we can only ask that
        it is done when feasible; it cannot be a hard requirement (e.g.
        L2 payload could be encrypted).
      </blockquote>
    </blockquote>
    <br>
    I think MAY is too weak, but SHOULD is too strong, so how about this
    form of wording:<br>
    "If feasible, the tunnel endpoint SHOULD check the L2 payload for an
    IP header"<br>
    <br>
    And I intend to add something along the lines of: "Otherwise, if the
    outer is IP, it MUST zero the outer ECN field."<br>
    <br>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="">


</pre>
      <blockquote type="cite">
        <pre wrap="">Now, what you describe in terms of level of mandatory applies to RFC 6040.
If an implementation does not comply with RFC 6040 it is, well, not
compliant with RFC 6040.
</pre>
      </blockquote>
      <pre wrap="">
Exactly.

And that's why I believe this should be a _recommended_ extension when
inner IP headers can be found easily but it cannot be a mandatory
requirement for the L2TP protocol as a whole.</pre>
    </blockquote>
    As above, I strongly agree with you.<br>
    <br>
    <br>
    Bob<br>
    <br>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="">

-Ignacio

</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
________________________________________________________________
Bob Briscoe                               <a class="moz-txt-link-freetext" href="http://bobbriscoe.net/">http://bobbriscoe.net/</a></pre>
  </body>
</html>

--------------5702327C13CE5A71D7068A8B--


--===============6922963142384731000==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
L2tpext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/l2tpext

--===============6922963142384731000==--