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

From: Bruno STEVANT <[email-masked]>
Date: Mon, 6 Aug 2007 15:46:10 +0200

Florent,

I am integrating your comments to the draft.
See inline for other comments ...

Le 25 juil. 07 à 21:11, Florent Parent a écrit :

> 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.

OK

>
> 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." ?
>

Many solutions are available to put L2TPv2 over IPsec:  IKE or IKEv2  
with tunnel or transport mode.
The security framework allow to pick any solution, the only  
requirement is to have NAT-traversal (Section 3.5)
I agree that UDP may not be required when using IPsec.
But should we document somewhere how IPsec will encap the L2TPv2  
softwire ? Or is current RFCs sufficient ?

BTW, FD proposal was : IP/UDP/ESP/L2TPv2/PPP/IP ?

> 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." ?

Same as above: should we document MTU with the different IPsec  
solution or is there a pointer with sufficient explanation for that ?

> 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.

OK

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

-- 
Bruno STEVANT - ENST Bretagne

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

---

From: Florent Parent <[email-masked]>
Date: Tue, 07 Aug 2007 15:22:36 -0400

--On 6 août 2007 15:46:10 +0200 Bruno STEVANT 
<[email-masked]> wrote:
> Many solutions are available to put L2TPv2 over IPsec:  IKE or IKEv2 with
> tunnel or transport mode.
> The security framework allow to pick any solution, the only requirement
> is to have NAT-traversal (Section 3.5)

I don't see how we can have interoperable implementations if the document 
allows an implementor to pick any solution. Look back at the thread 
<http://www1.ietf.org/mail-archive/web/softwires/current/msg00524.html>. I 
was working under the assumption that IKEv2 was the consensus moving 
forward (?).

As for tunnel vs. transport, why would IPsec tunnel mode be used to protect 
L2TPv2, which already established a p2p tunnel?

> But should we document somewhere how IPsec will encap the L2TPv2 softwire
> ?  Or is current RFCs sufficient ?

If you are referring to RFC3193, it does not cover the new IPsec 
architecture/IKEv2. That is covered in 
draft-ietf-softwire-security-requirements.

> BTW, FD proposal was : IP/UDP/ESP/L2TPv2/PPP/IP ?

Yes, but Francis can correct me :)

> Same as above: should we document MTU with the different IPsec solution
> or is there a pointer with sufficient explanation for that ?

My take is that 1460 is fine as is (using my suggested change). A reference 
to draft-ietf-softwire-security-requirements can be added for information 
on considerations when IPsec is used.

Florent

---

From: Bruno STEVANT <[email-masked]>
Date: Wed, 8 Aug 2007 10:50:10 +0200

OK, I will modify the draft to make requirements on encapsulation  
only in the case where no security solution (IPsec) is involved.
As requirements for IPsec are described in the security documents,  
pointers will be added when necessary.

Some points I think are still unclear between H&S ans Security draft :
* In H&S we state that NAT-traversal is mandatory. In Security, NAT- 
traversal is mentioned in 3.5 but not documented in the encapsulation  
table (3.5.4.1) and IPsec without UDP encap (port 500) is still  
documented. Does the requirements of H&S forbid IPsec port 500 ?
* Should the security document mention the MTU to be used when using  
IPsec ?
* FD encap (IP/UDP/ESP/L2TPv2/PPP) is not documented anywhere. Since  
this may be possible, should we document it in the security document  
and make the requirement of UDP encap for L2TPv2 a SHOULD instead of  
a MUST ?

Le 7 août 07 à 21:22, Florent Parent a écrit :

>
>
> --On 6 août 2007 15:46:10 +0200 Bruno STEVANT <bruno.stevant@enst- 
> bretagne.fr> wrote:
>>>
> I don't see how we can have interoperable implementations if the  
> document allows an implementor to pick any solution. Look back at  
> the thread <http://www1.ietf.org/mail-archive/web/softwires/current/ 
> msg00524.html>. I was working under the assumption that IKEv2 was  
> the consensus moving forward (?).
>
> As for tunnel vs. transport, why would IPsec tunnel mode be used to  
> protect L2TPv2, which already established a p2p tunnel?
>
> architecture/IKEv2. That is covered in draft-ietf-softwire-security- 
> requirements.
>
>>
>> solution
> My take is that 1460 is fine as is (using my suggested change). A  
> reference to draft-ietf-softwire-security-requirements can be added  
> for information on considerations when IPsec is used.
>
> Florent
>
>
>
>

---

From: Bruno STEVANT <[email-masked]>
Date: Fri, 10 Aug 2007 17:59:03 +0200

Hi all,

Pre-version -06 for h&s is available here:
http://rsm.enstb.fr/~bstevant/softwire/hs-l2tpv2.txt

    Changes between -05 and -06:

    o  Swapped Section 4.1 and Section 4.2.  Renamed Section 4.2
       "Securing Softwire Transport".

    o  In Section 5.2.1, added a mention that MTU should be lower than
       1460 when using IPsec.

    o  In Section 10, added pointers to [RFC4301] and [RFC4306].

One point from Florent's comments:

   In the Softwire model, an L2TPv2 packet MUST be carried over UDP.
FP> In the case where UDP encapsulation of IPsec ESP packets [RFC3948]
FP> is used to protect L2TPv2, this 'MUST' becomes too strong.

Actually not too strong. UDP is mandated for NAT-traversal. But we do  
not
state that UDP must be the immediate layer for L2TP transport.
When using IPsec with NAT-traversal, UDP is used but at a lower layer.
In this case, the MUST here still apply...

Le 8 août 07 à 10:50, Bruno STEVANT a écrit :

> traversal is mentioned in 3.5 but not documented in the  
> encapsulation table (3.5.4.1) and IPsec without UDP encap (port  
> 500) is still documented. Does the requirements of H&S forbid IPsec  
> port 500 ?
> * Should the security document mention the MTU to be used when  
> using IPsec ?
> * FD encap (IP/UDP/ESP/L2TPv2/PPP) is not documented anywhere.  
> Since this may be possible, should we document it in the security  
> document and make the requirement of UDP encap for L2TPv2 a SHOULD  
> instead of a MUST ?
>
>> the thread <http://www1.ietf.org/mail-archive/web/softwires/ 
>> current/msg00524.html>. I was working under the assumption that  
>> IKEv2 was the consensus moving forward (?).
>>
>> As for tunnel vs. transport, why would IPsec tunnel mode be used  
>> to protect L2TPv2, which already established a p2p tunnel?
>>
>> architecture/IKEv2. That is covered in draft-ietf-softwire- 
>> security-requirements.
>>
>>>
>> reference to draft-ietf-softwire-security-requirements can be  
>> added for information on considerations when IPsec is used.
>>
>> Florent
>>
>>
>>
>>
>
> --

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 10 Aug 2007 13:35:52 -0400

Bruno, Florent,

Please find my 2¢ inline.

> http://rsm.enstb.fr/~bstevant/softwire/hs-l2tpv2.txt

HTML diffs here:
http://carlos.homeunix.net/svn/softwire/hs-framework-l2tpv2/submissions/06/draft-ietf-softwire-hs-framework-l2tpv2-06-from-5.diff.html

>     o  In Section 5.2.1, added a mention that MTU should be lower than

I agree with these, they clarify. Thanks.

>     o  In Section 10, added pointers to [RFC4301] and [RFC4306].

Should this be (instead or in addition) a pointer added to Section 3.5
of draft-ietf-softwire-security-requirements?

> FP> is used to protect L2TPv2, this 'MUST' becomes too strong.

expanding this comment:
FP> : NAT

I think that this encap overhead optimization fits better in the
subsequent phase with L2TPv3, since it's not documented and goes against
some existing assumptions. For example, from RFC3931:

   L2TPv3 over IP (both versions) utilizes the IANA-assigned IP protocol
   ID 115.

 4.1.1.1. L2TPv3 Session Header Over IP

   Unlike L2TP over UDP, the L2TPv3 session header over IP is free of
   any restrictions imposed by coexistence with L2TPv2 and L2F.

And the text in sections 4.1.2 and 4.7.1 of RFC3931. There are
co-existence and fall-back considerations for L2TPv2 <-> L2TPv3 over
UDP, that don't exist over IP 115.

> In this case, the MUST here still apply...

I agree that this MUST still applies.

Thanks,

--Carlos.

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