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

[Carlos Pignataro <[e-mail]>]

Bruno, Florent,

Please find my 2¢ inline.

On 8/10/2007 11:59 AM, Bruno STEVANT said the following:
> Hi all,
> 
> Pre-version -06 for h&s is available here:
> 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

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

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?

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

expanding this comment:
FP> : 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.

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.


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

I agree that this MUST still applies.

Thanks,

--Carlos.

> 
> Le 8 août 07 à 10:50, Bruno STEVANT a écrit :
> 
>> 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:
>>>>> 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 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?
>>>
>>>> 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 ?
>>> 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 :)
>>>
>>>>
>>>>> 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 ?
>>> 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
>>>
>>>
>>>
>>>
>> -- 
>> Bruno STEVANT - ENST Bretagne
>>
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/softwires
> 

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

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