Subject: Re: [Softwires] I-D Action:draft-ietf-softwire-hs-framework-l2tpv2-05.txt

From: Florent Parent <[email-masked]>
Date: Wed, 25 Jul 2007 14:11:18 -0500

Here's some initial comment on this draft.

Florent

4.1.  Softwire Transport Related

FP>  Should be title "L2TPv2 Security Related"? Also would probably
FP> make sense to put 4.2 "L2TPv2" before this section.

   RFC 3193   "Securing L2TP using IPsec" [RFC3193].

   RFC 3948   "UDP Encapsulation of IPsec ESP Packets" [RFC3948].

              *  IPSec supports both IPv4 and IPv6 transports.

5.1.  L2TPv2 Tunnel Setup

...
   In the Softwire model, an L2TPv2 packet MUST be carried over UDP.
   The underlying version of the IP protocol may be IPv4 or IPv6,
   depending on the Softwires scenario.

FP> In the case where UDP encapsulation of IPsec ESP packets [RFC3948]
FP> is used to protect L2TPv2, this 'MUST' becomes too strong: NAT
FP> traversal is achieved by IPSec. One idea proposed a while ago
FP> Francis D. was to allow optimization by carrying L2TPv2 over IP
FP> (proto 115), thus removing an extra UDP header.

FP> Proposed change: "In the Softwire model, an L2TPv2 packet not
FP> protected by IPsec MUST be carried over UDP." ?

5.2.  PPP Connection

5.2.1.  MTU

   The MTU of the PPP link SHOULD be the link MTU minus the size of the
   IP, UDP, L2TPv2, and PPP headers together.  On an IPv4 link with an
   MTU equal to 1500 bytes, this could tipically mean a PPP MTU of 1460
   bytes.  This may vary according to the size of the L2TP header, as
   defined by the leading bits of the L2TP message header (see
   [RFC2661]).  Additionally, see [RFC4623] for a detailed discussion of
   fragmentation issues.

FP> When IPsec is used, the PPP MTU will need to be smaller to avoid
FP> fragmentation at the outer IP layer.

FP> "... this could typically mean a PPP MTU of 1460 bytes when IPsec
FP> is not used." ?

10.  Security Considerations

   A detailed discussion of Softwires security is contained in
   [I-D.ietf-softwire-security-requirements].

   The L2TPv2 Softwires solution provides the following tools for
   security:

   o  IPsec [RFC3193] provides the highest level of security.

FP> Since it was decided to use the new IPsec architecture and IKEv2,
FP> we should reference RFC4301 and 4306. RFC3193 is still relevant
FP> w.r.t. interaction of L2TPv2 and IPsec.

   o  PPP CHAP [RFC1994] provides basic user authentication.

   o  L2TP Tunnel Authentication [RFC2661] provides authentication at
      tunnel setup.  It may be used to limit DoS attacks by
      authenticating the tunnel before L2TP session and PPP resources
      are allocated.

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: Bruno STEVANT <[email-masked]>
Date: Thu, 26 Jul 2007 00:04:13 +0200

Minutes of the meeting available soon ?
I am wondering why IPSec and IKEv2 jumped into the scene ...

Florent: one thing about optimizing L2TP transport over IP/IPSec:  
don't fear encapsulaton, RoHC will help us. Or am I wrong ? ;)

-- 
Bruno STEVANT - ENST Bretagne

---

From: Florent Parent <[email-masked]>
Date: Wed, 25 Jul 2007 17:23:08 -0500

> Minutes of the meeting available soon ?

I don't recall who were the minute takers. I'll let Alain or David answer 
that one.

> I am wondering why IPSec and IKEv2 jumped into the scene ...

Well, IPsec is already reference in some places in the draft.

>
> Florent: one thing about optimizing L2TP transport over IP/IPSec: don't
> fear encapsulaton, RoHC will help us. Or am I wrong ? ;)

You probably mean 
IPv6-over-PPP-over-L2TPv2-over-UDP-over-ESP-over-UDP-over-IPv4? :)

Florent