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

From: Alain Durand <[email-masked]>
Date: Mon, 03 Dec 2007 09:08:31 -0800

The softwires chairs would like to initiate a 2 week working group last call
on the security document. As usual, send editorial comments to the authors
and substantive comments to the list.

The last call will end on 12/18/2007.

http://www.ietf.org/internet-drafts/draft-ietf-softwire-security-requirement
s-04.txt

   - Alain & David.

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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 3 Dec 2007 20:22:51 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-softwire-security-requirement

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

   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.

   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.

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

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

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

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].   ...
-- 
[email-masked]

---

From: Florent Parent <[email-masked]>
Date: Mon, 3 Dec 2007 22:27:06 -0800

Hi Tero,

Comments inline.

>   text saying that use information from traffic selectors of the

OK. I was not aware of that issue.

>   packet and there is also another checksum inside the packet inside

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

>   RFC3948 with IKEv2, and if people try to do it they will end up

OK

>   "Next Layer Protocol" instead "Proto".

Will fix.

>   "should" there should be "SHOULD".

OK

> Here is also some nits:

Yes

> In section 3.5.4. there i s [RFC4306] twice:

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

Many thanks for your review.

Florent

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 4 Dec 2007 19:48:51 +0200

> transported over IPv6, so UDP checksum must be enabled:

Not necessarely.

What happens there is that packet comes in:

IPV6 hdr, UDP(4500,4500), ESP, UDP(1701,1701), L2TP, PPP, IPv4, ESP AUTH

There is now multiple checksums. The UDP(4500, 4500) header do have
checksum, and that is checked and is correct. The ESP covers the
packet from UDP(1701, 1701) to the end, so it knows there cannot be
bit errors in that part.

The UDP(1701 1701) header has wrong UDP checksum as it is not fixed by
the NAT (it is inside the ESP). The IPv4 packet inside has also more
checksums. When we strip the UDP encapsulation and ESP, we get packet:

IPV6 hdr, UDP(1701,1701), L2TP, PPP, IPv4

which have wrong checksum for the UDP(1701, 1701) header, but we are
not really interested in that, as we are going to give that the local
L2TP application, that will throw the IPv6 header, UDP(1701, 1701)
header away, and take the IPv4 packet from inside. What we can do
there,  is to simply set the bit on in the kernel internal packet
context saying that UDP checksum is already checked, and there is no
need to recheck it anymore (there is usuallu such bit because the same
thing is used when the ethernet hardware does UDP/TCP checksum
calculations instead of IP stack. If there is no such option in the
kernel, then we must use the "recompute checksum", but in most
environments it is very easy to do the "do not check".

The recompatation does not help at all, as it does not protect againts
any errors or attacks.

Anyways, in the IPv4 we can set UDP checksum to 0, and IPv6 NATs are
not that common, so if you really want you can force them do
recomputations if you want. Or just say that RFC 3948 section 3.1.2
option 1 cannot be done, so either option 2 or 3 MUST be used. 
-- 
[email-masked]

---

From: Florent Parent <[email-masked]>
Date: Tue, 4 Dec 2007 10:12:55 -0800

> environments it is very easy to do the "do not check".

Understood.

> option 1 cannot be done, so either option 2 or 3 MUST be used.

This is also a very valid point: UDP encapsulation of ESP may very  
well not by used on IPv6 networks. But if it is, the above  
considerations on UDP checksum will provide the implementation  
guidelines.

Thanks for the comprehensive response.

Florent