draft-ietf-v6ops-ipsec-tunnels-02 review

[Pekka Savola <pekkas@netcore.fi>]

FYI, as a co-author, I solicited one extra IPsec expert review from 
Pasi Eronen for draft-ietf-v6ops-ipsec-tunnels-02.  Unfortanately, 
the document still needs a bit of work.

---------- Forwarded message ----------

I have three major comments (which I believe require significant
further work), and a couple of minor comments (that should be easy
to address). The major ones first:

1) I found it very difficult to reconcile the "generic SPD" described
   in this document with the IPsec architecture in RFC4301.

   An SPD is an ordered database, so having one SPD contain multiple
   entries with just "match everything" selectors doesn't seem to make
   much sense. So it looks like either we have to consider each
   interface (IPv6-in-IPv4 tunnel) having its own SPD, or the
   interface is used as a selector in the SPD. There's nothing wrong
   with this -- and I guess it can be made to work if the IPsec SAs
   are configured manually --  but it does cause complications with
   IKE.

   In particular, when the IKE responder receives a request to create
   a new IPsec SA, how does it know which interface this corresponds
   to? For "real" interfaces, an obvious answer would be "the
   interface where the IKE packets came from" -- but I guess in this
   case, the IKE packets are sent using the normal IPv4 interface, not
   the tunnel "pseudo-interface".

   I guess there are ways how this can be handled, especially if the
   host/gateway has only a single IPv6-in-IPv4 tunnel. But the
   document needs much more text about this.

2) Section 8 and Security Considerations: Simply knowing the tunnel
   endpoint's IP address is not sufficient: the initiator also needs
   to know how it should authenticate itself to the remote peer, and
   what kind of authentication to expect from the remote peer.  For
   example, if the responder is authenticated using certificates,
   the initiator has to know what the right subject name is. In
   other words: how do we discover the PAD identities and peer
   authentication data?

3) PAD "Child SA Authorization Data" needs to be described, for
   all three cases (transport, tunnel with specific SPD, tunnel
   with SPD).

Minor comments:

4) Section 4: "[RFC2401] does not support transport mode SAs
   between hosts and security gateways."

   This is a misunderstanding of RFC2401: these IP packets are
   destined to the "gateway" (they have the gateway's IP address as
   the destination IP address), so at the point where this SA is
   relevant, it's acting as a host, and using transport mode is
   allowed. Decapsulating the IP-in-IP packet happens higher up in
   the stack (and for this purpose, it doesn't matter whether the
   tunneling protocol is IP-in-IP or GRE or MIP-over-UDP or SOCKS
   or something else).

5) Section 7:  "IKEv2 can detect the presence of a NAT automatically
   by sending an Informational exchange with NAT_DETECTION_SOURCE_IP
   and NAT_DETECTION_DESTINATION_IP payloads before establishing an
   IPsec SA."

   No such functionality is described in RFC4306; the NAT detection
   notifications are always placed in IKE_SA_INIT exchange, not
   INFORMATIONAL (MOBIKE adds this functionality, though).

6) Section 7: "The IETF MOBIKE working group is looking into providing
   a solution for IKEv2 but the work is still in progress". MOBIKE WG
   has been closed (the document is in RFC editor's queue).

7) I'd suggest using RFC4301's bi-directional SPD notation instead
   of the separate SPD-in and SPD-out.

Best regards,
Pasi