Re: [Softwires] WG last call on the security document

[Florent Parent <[e-mail]>]

Hi Tero,

Comments inline.

Le 07-12-03 à 10:22, Tero Kivinen a écrit :
>
> Here is my comments:
>
> 1) There needs to be paragraph somewhere explaining the problem with
>   NAT-T combined transport mode and UDP checksums. The problem is
>   that the UDP header of the L2TPv2 is inside the ESP packets, which
>   means that NATs themselves cannot fix the UDP checksum when they do
>   the address translation on the outer header. The RFC3948 (NAT-T)
>   provides 3 options for Transport mode decapsulation: "Incremental
>   update of checksum", "Recompute checksum" and "Do not check".
>
>   The first option "incremental update of checksum" CANNOT be used
>   with IKEv2, because the IKEv2 does not have the information
>   required for it (I.e. IKEv2 does not have NAT-OA payloads, and the
>   text saying that use information from traffic selectors of the
>   IKEv2 does not work).

OK. I was not aware of that issue.

>
>
>   So there is only options to recompute checksum (might be
>   expensive), or make the implementation so it will not check the UDP
>   checksum of the L2TPv2 packet. This should not matter, as we do
>   have ESP outside providing much better validation of the received
>   packet and there is also another checksum inside the packet inside
>   the L2TPv2+PPP packet.

In the scenario where IPv4 over IPv6 is used (3.5.4.2), L2TP/UDP is  
transported over IPv6, so UDP checksum must be enabled:

            BEFORE APPLYING ESP/UDP
       --------------------------------------------
IPv6  |orig IPv6 hdr  |     |      |      |      |
       |(any options)  | UDP | L2TP | PPP  | IPv4 |
       --------------------------------------------

            AFTER APPLYING ESP/UDP
        
-----------------------------------------------------------------------
IPv6  |orig IPv6 hdr  | UDP | ESP |     |      |      |      |   ESP    
| ESP|
       |(any options)  | Hdr | Hdr | UDP | L2TP | PPP  | IPv4 |  
Trailer |Auth|
        
-----------------------------------------------------------------------
                                   |<------------ encrypted ----------- 
 >|
                             |<-------------- authenticated ----------- 
 >|

So from the available alternatives, looks like we need to pick  
"recompute checksum".

>
>
>   The reason I think this issue should be brough up is that you
>   cannot use that "incremental update" method specified in the
>   RFC3948 with IKEv2, and if people try to do it they will end up
>   implementation problems.
>

OK

>
> 2) I think the Section 3.5.4.1 and 3.5.4.2 should most likely use
>   exactly same terminology as RFC 4301 for the selectors, i.e. use
>   "Next Layer Protocol" instead "Proto".

Will fix.

>
>
> 3) The section 4.4.2 Security Protection Mechanism for Data Plane
>   says:
>
>                ...   In this scenario, public-key digital signature
>   or key encryption authentication in IKE should be used, assuming  
> that
>   the peers have the necessary computation available.
>
>   If the peer has enough computation available to do Diffie-Hellman,
>   there should be no problems to do public key signature operations
>   too. So I think the ", assuming that the peers have the necessary
>   computation available." should be removed. Also perhaps the
>   "should" there should be "SHOULD".

OK

>
>
>
> Here is also some nits:
> ----------------------------------------------------------------------
> 1.  Introduction
> ...
>   composed of differing address families.  This document provides the
>   security Guidelines for such two Softwire solution spaces such as
>   "Hubs and Spokes" and "Mesh" scenarios "Hubs and Spokes" and "Mesh"
>   problems described in [RFC4925] Section 2 and Section 3,
>   respectively.  The protocols selected for Softwire connectivity
> ----------------------------------------------------------------------
>
> I think there is period missing between the ... "Hubs and Spokes" and
> "Mesh" scenarios "Hubs and Spokes" and "Mesh" problems ...

Yes

>
>
> In section 3.5.4. there i s [RFC4306] twice:
> ----------------------------------------------------------------------
> 3.5.4.  IPsec filtering details
> ...
>                       ... The Internet Key Exchange (IKE) has also
>   been revised and simplified in IKEv2 [RFC4306], [RFC4306].   ...

Yes. I also noted some ID-nits from the tools web site which I will  
fix in -05.

Many thanks for your review.

Florent



_______________________________________________
Softwires mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/softwires