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

From: Pekka Savola <[email-masked]>
Date: Mon, 22 May 2006 14:30:10 +0300 (EEST)

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

---

From: Fred Baker <[email-masked]>
Date: Mon, 22 May 2006 13:34:25 -0700

Thanks for doing that. I take it that we can expect an updated  
version of the draft?