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

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.stevantenst- 
>> 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
> Softwiresietf.org
> http
s://www1.ietf.org/mailman/listinfo/softwires

-- 
Bruno STEVANT - ENST Bretagne

_______________________________________________
Softwires mailing list
Softwiresietf.org
http
s://www1.ietf.org/mailman/listinfo/softwires

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

Thread: Re: I-D Action:draft-ietf-softwire-hs-framework-l2tpv2-05.txt