Comments on draft-ietf-l2tpext-keyed-ipv6-tunnel-01
Qi Sun <sunqi.csnet.thu <at> gmail.com>
2015-01-14 16:12:35 GMT
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.
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.
2) A mapping table of v6 address and the port ID.
3) One session per tunnel.
4) The Session ID field is there, but it may be processed. (This is a “MUST" in RFC3931.)
5) Cookie length MUST be 64 (which can be 32-/64-bit in RFC3931).
6) The cookie can be randomly selected, or all ones. (It MUST be configured or signalled with a random value
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.
Could the wg shed some light on why this document is Informational instead of Standard Track? Thanks!
The other comments are mainly about the technical/editorial content of the draft, detailed as follows.
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”?
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.
3. In Sec 3, the last sentence of this section misses the period at the end.
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.
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].
1) Could the authors give the definitions of “2-stage resolution” and “one-stage” resolution?
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?
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.
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?
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
1) Is the Ethernet OAM method configured per tunnel, or per device?
2) s/this document recommends/ it is RECOMMENDED in this document/ ??
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?
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/ ??
Hope that helps.