[Softwires] softwire-encaps-safi

[Carlos Pignataro <[e-mail]>]

On 5/5/2008 David Ward <[e-mail]> wrote:
>        draft-ietf-softwire-encaps-safi-00.txt

Please find some comments on ietf-softwire-encaps-safi, I hope these are 
useful:


     Tunnel Type (2 octets): It identifies the type of the tunneling
     technology being signaled. This document defines the following types:

       - L2TPv3: Tunnel Type = 1

L2TPv3 can be encapsulated in different ways over IP (e.g., directly
over IP proto 115, and over UDP). This document refers implicitly
(without mention) to L2TPv3 over IP (the only L2TPv3 mandatory
encapsulation from RFC3931), but does not explicitly clarify it. Could
this be disambiguated, e.g., by either: i. Renaming the Tunnel Type 1 to
"L2TPv3 over IP", or ii. Providing further L2TPv3 encap details (IP vs.
UDP, etc) in the Encapsulation sub-TLV for the L2TPv3 TLV Type?

~~~~~~

      * Session ID: a 4-octet value locally assigned by the advertising
        router that serves as a lookup key in the incoming packet's
        context.

Could "non-null" be added as a constrain for the Session ID? The 
all-zeros identifies and L2TPv3 Control Packet (instead of data packet) 
when running directly over IP. From RFC3931:

    Session ID

       A 32-bit field containing a non-zero identifier for a session.
...
    L2TP over IP uses the reserved Session
    ID of zero (0) when sending control messages.
...
          Note that the control message header in this case begins after
          the all-zero Session ID when running over IP

~~~~~~

       |                        Cookie (Variable)                      |
...
       * Cookie: an optional, variable length (encoded in octets - 0 to 8
         octets) value used by L2TPv3 to check the association of a
         received data message with the session identified by the Session
         ID. The Cookie value is tightly coupled with the Session ID.


This text defining/describing the Cookie field seems to allow for any
length of cookie from 0 to 8 octets; however, from RFC3931:

       The Assigned Cookie is a 4-octet or 8-octet random value.
...
       The value's length
       (0, 32, or 64 bits) is obtained by the length of the AVP.

Should this description constrain itself to either a 0-, 4- or 8-octet 
cookie (instead of any len between 0..8 octets)?

~~~~~~

4.2. Protocol Type sub-TLV
...
    Note that the protocol type sub-TLV is optional, e.g. if the
    tunneling technology is GRE, this sub-TLV is not required.

Is this sub-TLV also optional for L2TPv3 tunneling, which encap (unlike 
GRE) does not have a PID, or is it mandatory for L2TPv3 Tunnel Type? If 
still optional, how is the encapsulated Protocol Type (tunneled payload 
PID) signaled, checked, selected/validated in the dataplane?

~~~~~~

6. Security Considerations

Shouldn't this section be augmented with the security considerations of 
the tunneling protocols used? e.g., for l2tpv3, source (and dest) 
validation (for tunneled traffic) vs. (or plus) suggested use of  the 
cookie, etc?

~~~~~~

References:

I notice this document does not reference RFC2784 + RFC2890 and RFC3931. 
It seems it should, for example draft-ietf-softwire-encaps-ipsec (that 
does not concern with defining the Tunnel Types for L2TPv3 or GRE still 
add 2784/3931 references.



Thanks,

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

_______________________________________________
Softwires mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/softwires