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

[Bruno STEVANT <[e-mail]>]

Florent,

I am integrating your comments to the draft.
See inline for other comments ...

Le 25 juil. 07 à 21:11, Florent Parent a écrit :

> 4.1.  Softwire Transport Related
>
> FP>  Should be title "L2TPv2 Security Related"? Also would probably
> FP> make sense to put 4.2 "L2TPv2" before this section.
>
>   RFC 3193   "Securing L2TP using IPsec" [RFC3193].
>
>   RFC 3948   "UDP Encapsulation of IPsec ESP Packets" [RFC3948].
>
>              *  IPSec supports both IPv4 and IPv6 transports.

OK

>
> 5.1.  L2TPv2 Tunnel Setup
>
> ...
>   In the Softwire model, an L2TPv2 packet MUST be carried over UDP.
>   The underlying version of the IP protocol may be IPv4 or IPv6,
>   depending on the Softwires scenario.
>
> 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 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 ?

BTW, FD proposal was : IP/UDP/ESP/L2TPv2/PPP/IP ?


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


> 10.  Security Considerations
>
>   A detailed discussion of Softwires security is contained in
>   [I-D.ietf-softwire-security-requirements].
>
>   The L2TPv2 Softwires solution provides the following tools for
>   security:
>
>   o  IPsec [RFC3193] provides the highest level of security.
>
> FP> Since it was decided to use the new IPsec architecture and IKEv2,
> FP> we should reference RFC4301 and 4306. RFC3193 is still relevant
> FP> w.r.t. interaction of L2TPv2 and IPsec.
>
>   o  PPP CHAP [RFC1994] provides basic user authentication.
>
>   o  L2TP Tunnel Authentication [RFC2661] provides authentication at
>      tunnel setup.  It may be used to limit DoS attacks by
>      authenticating the tunnel before L2TP session and PPP resources
>      are allocated.

OK


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