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

[Bruno STEVANT <[e-mail]>]

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 :

> 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

-- 
Bruno STEVANT - ENST Bretagne



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