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

[Bruno STEVANT <[e-mail]>]

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