[L2tpext] IESG review of draft-ietf-l2tpext-l2tp-base

["W. Mark Townsley" <[e-mail]>]

The IESG has been reviewing the base L2TPv3 specification, 
draft-ietf-l2tpext-l2tp-base-xx.txt. The last two updates, versions 13 and 14, 
contain changes based on these discussions. A summary of the changes are 
detailed below. Comments welcome.

Thanks,

- Mark

draft -14 updates:

Updated to not preclude support of L2TP over IPv6. This included normalization 
of any specific references to IPv4 as either simply "IP" or pointing out any 
differences between L2TP over IPv4 vs. L2TP over IPv6. Most significant changes 
required were the Result Code AVP which may include IP addresses within Error 
Message text, and stronger wording that the Router ID AVP was not specifically 
an IPv4 address. The IPv6 discussion triggered an additional thread on IP 
fragmentation resulting in new text in section 4.1.4 on this topic.

Clarification of Session ID and Cookie text in section 4.1.

Additional text regarding use of the UDP Checksum in section 4.1.2.3

The Connect Speed AVPs are now 64 bits, the L2TPv2 32bit AVPs which were being 
carried over unchanged are now deprecated in L2TPv3.

Corrected the following 3 cases of improperly capitalized "MUST NOT":

"The L2TPv3 Cookie MUST NOT be regarded as a substitute for security such as
that of IPsec when operating over an open or untrusted network where
packets may be sniffed, decoded and correlated for use in a coordinated
attack. See section 4.1.3 for more information on running L2TP over IPsec."

"This policy MUST NOT be considered a license to send malformed AVPs,
but rather, a guide towards how to handle an improperly formatted"

"LCCE to the other.  Such protection MUST NOT be considered a substitution
for end-to-end security between communicating hosts or applications."

The Application ID AVP was found to be unnecessary for the base specification, 
and was identified as potentially prone to abuse and associated interoperability 
problems as currently defined. The Application ID text was subsequently removed, 
but may be reintroduced in a separate document. Associated L2TP L2VPN documents 
which use this AVP will need to be updated due to this change, though none of 
the L2TPEXT documents should be affected.

One MUST include a new Random Vector AVP if two hidden AVPs with the same 
attribute number are present in a single message (this is an edge case in 
practical usage of L2TP, but is theoretically a security hole).

Section 5.1 and 7.1, clarifications on reserved bits in the AVP format, and how 
to handle malformed AVPs.

Our Vendor-Specific AVP format includes a 16-bit field for the Vendor-ID. It was 
noted that Enterprise codes beyond 65,535 are possible in the not too distant 
future. An "Extended Vendor ID AVP Format" is defined in section 5.1 just in 
case this happens. Only implementations need Vendor IDs beyond 16 bits (or those 
requiring interoperability with vendor-specific features of implementations with 
vendor IDs beyond 16 bits) need be able to parse or create AVPs with this new 
format.

Considerable update of IANA section to be more clear.

If Control Message Authentication is enabled, two shared secrets may be 
configured and a message may be signed with each to enable a secret to be 
changed gracefully (section 5.4.1).

Moved Acknowledgement section.

New RFC 3667/8 Boilerplate.

Various reference updates.

Reformatting of whitespace in some tables to keep them under 72 columns and 
various other nits.

draft -13 updates:

Various small wording clarifications throughout the document that are not worth 
detailing here.

Fixing of nomenclature used to describe control message hashing and 
clarification of procedure in a number of places. Many thanks to Russ Housley 
for his review of this.

Updated and moved "L2TP and IPsec" section to 4.1.3.


_______________________________________________
L2tpext mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2tpext