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

Florent Parent <Florent.Parent@beon.ca> Tue, 07 August 2007 19:22 UTC

Return-path: <softwires-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIUde-0000Tb-5e; Tue, 07 Aug 2007 15:22:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIUdc-0000TU-OQ for softwires@ietf.org; Tue, 07 Aug 2007 15:22:40 -0400
Received: from ns.beon.ca ([2001:5c0:8001::53] helo=mail.beon.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIUda-0007rP-C4 for softwires@ietf.org; Tue, 07 Aug 2007 15:22:40 -0400
Received: from [192.168.31.239] (unknown [192.168.77.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Florent.Parent@beon.ca", Issuer "Beon Solutions CA" (verified OK)) by mail.beon.ca (Postfix) with ESMTP id 5834EAD74E; Tue, 7 Aug 2007 15:22:36 -0400 (EDT)
Date: Tue, 07 Aug 2007 15:22:36 -0400
From: Florent Parent <Florent.Parent@beon.ca>
To: Bruno STEVANT <bruno.stevant@enst-bretagne.fr>
Subject: Re: [Softwires] I-D Action:draft-ietf-softwire-hs-framework-l2tpv2-05.txt
Message-ID: <654C08BF24F3246E8DAE7E5B@marbles.local>
In-Reply-To: <24F73DB4-C9CB-42C9-82D7-A617821E8DD2@enst-bretagne.fr>
References: <E1I47o2-0006Hs-Em@stiedprstage1.ietf.org> <4B041CD7E6110773160C80B9@blues.local> <24F73DB4-C9CB-42C9-82D7-A617821E8DD2@enst-bretagne.fr>
X-Mailer: Mulberry/4.0.9b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: softwires@ietf.org
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
Errors-To: softwires-bounces@ietf.org


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





_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www1.ietf.org/mailman/listinfo/softwires