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

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





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

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