Re: [L2tpext] Comments on draft-ietf-l2tpext-keyed-ipv6-tunnel-01

[Giles Heron <[e-mail]>]

Hi Qi,

On 18 Feb 2015, at 16:00, Qi Sun <[e-mail]> wrote:

> Hi Giles,
> 
> Thanks for addressing my comments! (And apologise for confusing Session ID and cookie sometimes :)
> 
> Just think of something:
> 
>>> 4) The Session ID field is there, but it may be processed. (This is a “MUST" in RFC3931.)
>> 
>> So we distinguish two cases:
>> a) implementation of this draft at both ends - in which case the session ID may be ignored (and we recommend setting it to all ones).
>> b) interoperability between this draft and existing implementations which require a session ID (which is therefore configured to a fixed value).
> 
> So:
> if a device finds out the remote Session ID is all-ones, then it knows the peering device implements tis draft; 

not necessarily - the remote device might have just picked an all-ones session ID (pretty unlikely)

> if the remote Session ID is not all-ones but 64-bit long, then it knows the peer is a compatible implementation;
> if the remote Session ID is not 64-bit, then it will fail that connection. 

Again I think there's some confusion here re session ID and cookie.

the session ID is 32 bits.

the optional cookie may be 32 or 64 bits in RFC3931.  in this draft the cookie is mandatory and must be 64 bits.
> 
> Is the above the correct logic? The device doesn’t have to be explicitly configured with the type of the peering device, right?

so the logic is incorrect (see above).

re configuration the device doesn't have to be explicitly configured with the type of the remote device.   as long as you can configure the session ID and cookie it's all good.

Giles

> Thanks,
> Qi
> 
> On Feb 18, 2015, at 4:21 PM, Giles Heron <[e-mail]> wrote:
> 
>> Hi Qi Sun,
>> 
>> thanks for your comments!
>> 
>> my feedback inline:
>> 
>> On 14 Jan 2015, at 16:12, Qi Sun <[e-mail]> wrote:
>> 
>>> Dear WG & authors,
>>> 
>>> I have reviewed this draft and I think it's very useful, as it greatly simplifies the l2tpv3 tunnels by taking parts from l2tpv3. 
>>> 
>>> Also I have some comments about it. The tricky one would be the intended status of this document. Currently it’s an Informational document, which means it doesn’t change RFC3931. However, there are a number of normative language, which might be confusing. 
>>> 
>> 
>> yes - the new version is standards track.
>> 
>>> I’ve made a list of features of the keyed IPv6 tunnel, with some comparison to RFC3931. Please correct me if anything is wrong. 
>>> 1) Not use L2TPv3 Control Plane defined in RFC3931.
>> 
>> yes.
>> 
>>> 2) A mapping table of v6 address and the port ID.
>> 
>> yes - each v6 address corresponds to a local port or port/VLAN.
>> 
>>> 3) One session per tunnel.
>> 
>> yes.
>> 
>>> 4) The Session ID field is there, but it may be processed. (This is a “MUST" in RFC3931.)
>> 
>> So we distinguish two cases:
>> a) implementation of this draft at both ends - in which case the session ID may be ignored (and we recommend setting it to all ones).
>> b) interoperability between this draft and existing implementations which require a session ID (which is therefore configured to a fixed value).
>> 
>>> 5) Cookie length MUST be 64 (which can be 32-/64-bit in RFC3931).
>> 
>> Yes.
>> 
>>> 6) The cookie can be randomly selected, or all ones. (It MUST be configured or signalled with a random value in RFC3931.)
>> 
>> No.  The draft says it SHOULD be randomly selected but that it MUST be checked.
>> 
>> I guess the difference here is that we're mandating a 64 bit cookie, whereas RFC3931 has an optional cookie which may be 32 or 64 bits.  So the question may be whether there are platforms that are unable to create a random value?  (I'm certainly not qualified to debate what is "random" here).
>> 
>>> 7) Local and remote endpoints SHOULD send different cookie values.  The value of the cookie MUST be able to be changed at any time. The receiver must be willing to accept both "old" and "new" cookie values. Cookie values SHOULD be changed periodically. 
>>> 
>>> I think item 4) ~ 7) potentially change the behaviour of LCCE when processing a l2tpv3 (i.e. keyed-v6-tunnel) packet. 
>> 
>> Agreed.  Which is why the draft says it is "based" on L2TPv3.  However, as the draft also states, we need to be able to interoperate with existing implementations.   I guess one caveat to that is that the draft will only interoperate with an LCCE that supports the 64 bit cookie.  I've added a paragraph to that effect.
>> 
>>> Could the wg shed some light on why this document is Informational instead of Standard Track? Thanks!
>> 
>> that has been fixed now :)
>> 
>>> The other comments are mainly about the technical/editorial content of the draft, detailed as follows.
>>> <comments>
>>> 1. Sec 2, para 3
>>> IPv6 address is treated as the IPv6 L2TPv3 tunnel endpoint.
>>> 
>>> [Qi] How about “… IPv6 address is treated as the identifier of the IPv6 L2TPv3 tunnel endpoint”?
>> 
>> fixed.
>> 
>>> 2. Sec 2, para 4
>>>  Certain deployment scenarios may require using a single IPv6 address
>>> to identify a tunnel endpoint for many IPv6 L2TPv3 tunnels.
>>> [Qi] s/many/multiple/
>> 
>> fixed.
>> 
>>> 3. In Sec 3, the last sentence of this section misses the period at the end.
>> 
>> fixed.
>> 
>>> 4. Sec 4
>>> The s-tag (or in the multi-stack access case the s-tag and c-tag)
>>> SHOULD be removed before the packet is encapsulated.
>>> [Qi] Maybe a reference related to “s-tag” and “c-tag” would be helpful here.
>> 
>> I've changed that throughout S-tag and C-tag (and have aligned section 2 with that also). I've also made changes so that the draft says tag instead of S-tag when discussing a single-tagged frame (as that VID may in fact be a C-tag) and have made it clear that it's only "service-delimiting" tags that are stripped at ingress.
>> 
>> have also added refs to 802.1Q/802.1ad.
>> 
>>> 5. Sec 4, Session ID
>>>  o  Session ID.  In the "Static 1:1 mapping" case described in
>>>     Section 2, the IPv6 address resolves to an L2TPv3 session
>>>     immediately, thus the Session ID may be ignored upon receipt.  For
>>>     compatibility with other tunnel termination platforms supporting
>>>     only 2-stage resolution (IPv6 Address + Session ID), this
>>>     specification recommends supporting explicit configuration of
>>>     Session ID to any value other than zero.  For cases where both
>>>     tunnel endpoints support one-stage resolution (IPv6 Address only),
>>>     this specification recommends setting the Session ID to all ones
>>>     for easy identification in case of troubleshooting.  The Session
>>>     ID of zero MUST NOT be used, as it is reserved for use by L2TP
>>>     control messages RFC3931 [RFC3931].
>>> [Qi] 
>>> 1) Could the authors give the definitions of “2-stage resolution” and “one-stage” resolution?
>> 
>> didn't we already do that?  "2-stage" (now changed to "two-stage") is IPv6 address + Session ID and "one-stage" is IPv6 Address only.
>> 
>>> 2) The session ID can be explicitly configured to any value other than zero, or all ones, right? Is there a 3rd type of session ID configuration?
>> 
>> no - just those two, since the first is for two-stage and the second for one-stage.
>> 
>>> 3) The text is a little confused to me. I think that ignoring the Session ID is the behaviour of the receiving device, and setting Session ID is the behaviour of the sending device, right? I would expect it to be explicitly described here.
>> 
>> yes, but surely that's obvious?  It's pretty hard for a sending device to ignore session ID or for a receiving device to set it ;)
>> 
>>> 4) In section 3, it says:
>>> "The cookie MUST be 64-bits
>>> long in order to provide sufficient protection against spoofing and
>>> brute force blind insertion attacks."
>>> However, the text in this section recommends setting the Session ID to all ones. Can the all-ones cookie provide sufficient protection?
>> 
>> are you confusing the session ID and the cookie?
>> 
>>> 6. Sec 6, paragraph 3
>>> …, this document recommends that Ethernet OAM as defined in IEEE
>>> 802.1ag [IEEE802.1ag] and/or ITU Y.1731 [Y.1731] is enabled for keyed
>>> IP tunnels.
>>> [Qi]
>>> 1) Is the Ethernet OAM method configured per tunnel, or per device?
>> 
>> configuration would be per tunnel I think, as we can't assume that all remote devices support E-OAM.
>> 
>>> 2) s/this document recommends/ it is RECOMMENDED in this document/ ??
>> 
>> hmmm - I'm not sure. I think recommends is better as RFC2119 language is about ensuring interoperable implementations etc.  I don't think that applies here.
>> 
>>> 7. Sec 8, para 3
>>> [Qi] This paragraph is taken from the L2TPv3 RFC3931, with the reference to RFC1750 changed to RFC4086 (Note: RFC4086 obsoletes RFC1750).
>>> Should there be a reference to the related section of RFC3931 besides taking text from it?
>> 
>> Yes - in fact I think it's better just to refer to RFC3931 rather than duplicating text.  So I've done that.
>> 
>>> 8. Sec 8, the last para
>>> The L2TPv3 64-bit cookie must not be regarded as a substitute for
>>> security such as that provided by IPsec when operating over an open
>>> or untrusted network where packets may be sniffed, decoded, and
>>> correlated for use in a coordinated attack.
>>> [Qi] s/must not/MUST NOT/ ??
>> 
>> again that's not about interop so I think it's better not to use RFC2119 language.
>> 
>>> </comments>
>>> 
>>> Hope that helps.
>> 
>> yes - great comments.  Thanks!
>> 
>> Giles
>> 
>>> Best Regards,
>>> Qi Sun
>>> 
>>> 
>>> _______________________________________________
>>> L2tpext mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/l2tpext
>