Subject: draft-ietf-l2tpext-security-02.txt

From: Thomas Narten <[email-masked]>
Date: Tue, 10 Jul 2001 12:59:10 -0400

The WG reqested that this document be advanced as a Proposed Standard
quite some time ago. After an inexcusable delay, I have reviewed the
document and have the following questions/comments. I'm sending this
to the WG rather than just the authors as some of the issues go beyond
just editorial clarification.

> (General Error) and the Error Code SHOULD be set to 7 (Try Another).  If
> the Error Code is set to 7, then the optional error message MUST be
> present and the contents MUST contain the dotted decimal IP address
> (UTF-8 encoded) that the Responder desires to use for subsequent
> communications and the initiator MUST parse the result and error code
> information and send a new SCCRQ to the new IP address contained in the
> error message.  This approach reduces complexity since now the initiator
> always knows precisely the IP address of its peer.  This also allows a
> controlled mechanism for L2TP to tie IPSEC filters and policy to the
> same peer.

This seems like a bad way to go. My understanding is that the error
message string is intended for human consumption, hence UTF-8. But
above you are really using it to extend the protocol. Seems like it
would be better to do this properly, i.e, by defining a new AVP or
something (and perhaps putting this in the base L2TP spec?).

> 7.1.  L2TP Security Protocol
> 
> The L2TP security protocol MUST provide authentication, integrity and
> replay protection for control packets. In addition, it SHOULD protect
> confidentiality of control packets. It MUST provide integrity and replay
> protection of data packets, and MAY protect confidentiality of data
> packets. An L2TP security protocol MUST also provide a scalable approach
> to key management.
> 
> To meet above requirements, all L2TP security compliant implementations
> MUST implement IPSEC ESP for securing L2TP control packets and SHOULD
> implement IPSEC ESP for protection of L2TP data packets.  All mandated
> cipher suites, including NULL encryption, of IPSEC ESP MUST be
> supported. Note that if confidentiality is not required (e.g., L2TP data
> traffic), ESP with NULL encryption may be used.  The implementations
> MUST implement replay protection mechanisms of IPSEC.

It is not clear what "all mandated cipher suites" is. Can you list
them, since they are a MUST?

Also, I wonder if the "SHOULD protect confidentiality" should be a
MUST. The IESG may have more to say about this. If its just a SHOULD,
and a customer only controls one of the implementations, you may not
get interoperability... And when it comes to security, you want the
customer to be be able to enable it and have it work...

> The following guidelines are established to meet L2TP security
> requirements using IPSEC in practical situations. Note that this section
> is not a requirement for an implementation to be L2TP security
> compliant.  Its purpose to make the implementors aware of certain
> efficiency and security considerations.

What does "this section" refer to? i.e., just what is not part of the
specification?

> The responder is not required to support the ability to float it's IP
> address and port.  However, the initiator MUST support the ability to
> allow the responder to float it's port and SHOULD support the ability to
> let the responder float it's IP address.

My quick glance of 2661 doesn't find a mention of floating the IP
address. Is it allowed there? And if not, why does this document say 
SHOULD support an undocumented, non-standard extension?

Nits:

For RFCs > 10 pages, its nice to have TOC; can you easily add one?

> media guarantee ordering, and packet losses are typically low. .NH 1 .R

stray nroff commands?

> Given that the dial-in user will typically not trust the LAC and will
> negotiate confidentiality and compression services on its own, the LAC
> may only wish to negotiate IPSEC ESP with null encryption (described in
> []) with the LNS, and the LNS will request replay protection. This will

null reference??

IPSEC vs. IPsec? (I think the preferred spelling is IPsec... change
throughout...)

> >From the LNS's point of view, it will note a PPP packet encapsulated in

Stray > in front of From (thanks to sendmail??)

> Per IKE [7], when using pre-shared key authentication, a key must be
> present for each peer which secure communication is required.  When

s/which/to which/ ??

Thomas