[L2tpext] Comments on draft-elwin-l2tpext-ipservices-01.txt

Some excerpts and associated comments inline below.

Thanks,

- Mark

>4.0 Introduction
>
> Once a L2TP session is established, the current standard [L2TP-V2] and
> [L2TP-V3] has no explicit mechanism to update the session
> characteristics, during the life of the session, between the L2TP
> tunnel endpoints. 

Depending on what you mean by "session characteristics" this is not true. There
is an explicit mechanism in L2TP (the Message Type AVP) that allows new messages
to be created, sent, and processed at any time during the life of a session. Two
examples of such are defined in RFC2661, SLI and WEN. 

> The SUN is sent either from LAC to LNS or LNS to LAC. On receiving
> this the recipient, if needed to respond, responds by sending another
> SUN message. There is no change needed in the L2TP state machine to
> accomodate this message.

Allowing a "response" to a message certainly implies some level of state.

> 6.1 IPSec AVP
> 
> The IPSec AVP is used to inform the tunneling peer to use the
> appropriate IPSec parameters for securing the L2TP session.
>
> When the LNS finds out that incoming user needs IPSec service then it 
> can send this AVP to LAC indicating LAC to send the L2TP packets 
> encrypted using IPSec. If the LAC supports to provide IPSec for 
> the requested LNS then it MUST send the same AVP back in response 
> SUN indicating that the IPSec AVP is valid and LAC will send 
> all L2TP packets through IPSec. If the LAC doesn't allow this, then 
> in SUN reply this AVP MUST not be included. Only after receiving
> SUN from LAC with IPSec AVP inside it, LNS can assume that LAC can 
> support this capability.
>
>
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |M|H|0|0|0|0|    Length         |             Vendor ID         |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |         Attribute Type = 5    |             Reserved          |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |           IPSec Profile Name  ...                             |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

You don't include any description of what the "IPsec Profile Name" is. In
general, this sounds very vendor specific.

The feature described in this section requires a very close tie between your
IPsec and L2TP subsystems. A better alternative might be the L2TP Alternate Data
Channel submitted a long time ago to l2tpext. This method sets up an alternative
UDP port for sending some data packets on. This UDP port, in turn, has an IPsec
SA with the proper security parameters associated with it (and could be utilized
by multiple sessions). Thus, IPsec does not have to be "l2tp-aware" at the
packet level.

An old copy of ADC may be found at:

http://www.watersprings.org/pub/id/draft-ietf-l2tpext-adc-00.txt

Also, you might check out:

http://www.watersprings.org/pub/id/draft-ietf-pppext-secure-ra-00.txt

Which was, again, a method for identifying security policy based on the PPP
user. IIRC, this had to do with IPsec being present on the inner tunneled IP
packet rather than the entire IP/L2TP packet.

> 6.2 QOS AVP
>
> The QOS AVP is used to inform the tunneling peer to use the
> appropriate QOS marking and profile to use for the L2TP session.
>
> This AVP can be used to determine how to mark the packets, from the
> following options:
>
>    a. To reflect the marking from the payload IP packet to the
>       outer IP header, OR
>    b. To apply a specific PHB based marking for all packets from
>       the user (based on PHB ID sent in this AVP), OR
>    c. To mark based on policy lookup
>
>
> If the LAC can support what is requested by LNS then it MUST send
> the same AVP back in response SUN indicating that the QOS AVP is 
> valid and LAC will mark accordingly. If the LAC doesn't allow this, 
> then in response SUN this AVP MUST not be included. Only after 
> receiving SUN from LAC with QOS AVP inside it, LNS can assume that 
> LAC can support this capability.

Why not announce during session setup what types of QoS commands MAY be sent,
and then only send those when the time comes? That elimiates the need for a
request/response. 

>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |M|H|0|0|0|0|    Length         |             Vendor ID         |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |         Attribute Type = 6    |        reserved         | FLG |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |           PHB ID              |    QOS Profile Name ...       |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> This AVP MAY be present in the SUN message.
>
> This AVP MAY be hidden (the H-bit set to 0 or 1) and is optional 
> (M-bit not set). The length (before hiding) of this AVP is 10 + Length
> of QOS-Profile-Name in octets.
>
> Vendor ID is a two octet value, set to 3961 to indicate that this is
> an Corona-assigned attribute. Should this draft become a standard, the
> Vendor ID would become 0 and an appropriate Attribute-Type value will
> be assigned by IANA. The PHBID is encoded as described in [ref-7].
>
> FLG indicates which type of marking is to be applied at LAC. Following
> are the valid values for this:
>

Rather than defining a FLG to further multiplex the desired operation and value
within a given AVP, why not just define 3 separate AVPs, and send only the one
you desire?

> 000 - reflect DSCP from the inner IP packet
> 001 - use the PHBID passed, to determine DSCP to mark the packets. For
>       all other values of FLG, the PHBID is ignored.
> 010 - do a policy lookup, with the profile mentioned, to determine the
>       DSCP marking.
> 011 - reserved
> 1xx - reserved

As with "IPsec Profile" You need a definition of QoS Profile name here, as well
as a better description of what it means to do a "policy lookup" -- Without a
lot more description, I can't imagine this will be a very multi-vendor
interoperable function.

> 7.1.1 Bundling Capability AVP
> 
> The AVP is valid in the L2TP SCCRQ and SCCRP messages only, and it 
> MUST NOT be marked Mandatory. The Bundling Capability AVP is encoded 
> with vendor ID, and the attribute value as 1.

vendor ID doesn't have a value here

> 7.2.1 Base Session AVP
>
> This AVP is sent by the session initiator in ICRQ/OCRQ packet. This AVP
> informs the peer that the current session may not run payload control
> protocol (LCP) over this session. Instead it will directly send the 
> payload (PPP) data packets. 

What about other PPP CPs other than LCP? In general, why define which session
may or may not send PPP Control Protocol packets. Can't you just leave this up
to the implementor? e.g. perhaps one would rather create a flow session with a
high priority and send some or all PPP CP packets across it, and leave the base
session for regular data. I don't see any reason to place implementation
limitations upon this choice.

Also, what about PPP keepalive packets? This is technically an LCP packet, but
one would probably want to send these across the same channel as the bulk of the
PPP data, particularly if one may have a different DSCP or IPsec SA associated
with it. 

In general, I think when you start moving some of your PPP session data to
different data paths, you need a pretty stern warning about the lessened
validity of keepalives across your session.

> 9.0 Security Considerations
>
> This document does not introduce any new security issues beyond those
> inherent in L2TP, and may use the same mechanisms proposed for those 
> technologies, where applicable.

Given that you have an entire section devoted to IPsec, you probably need more
here eventually.

_______________________________________________
L2tpext mailing list
L2tpext@ietf.org
https://www1.ietf.org/mailman/listinfo/l2tpext