draft-ietf-v6ops-ipsec-tunnels-02.txt review (resent)

[Francis Dupont <Francis.Dupont@point6.net>]

(This never reached the mailing-list so I resend it)

Here is my review of draft-ietf-v6ops-ipsec-tunnels-02.txt:
 - perhaps the Abstract is too narrow in scope because the document
   is applicable to any IPv6-in-IPv4 tunnels secured by IPsec?
   IMHO the problem comes from the term "manually" which is
   more "controlled", i.e., we'd like to exclude 6to4 but not L2TP.
 - Introduction (and further): PAD (Peer Authorization Database)
   is important too. BTW SAD is not because it is supposed to be
   filled automatically.
 - section 2 (explanation/introduction comment). From an IPsec
   point of view, the main difference between a tunnel mode and
   a transport mode applied to a tunnel is over which addresses
   traffic selectors apply: for tunnel mode they are the inner
   addresses, so you get the (2) with a filter from the points 4/5
   of RFC 4301 inbound processing, for transport mode they are
   the outer (and only visible) addresses.
   BTW what is valuable and provided by IPsec is the data origin
   authentication (origin here is the peer tunnel end-point).
 - section 4: IMHO we should not pay too much attention to IPsec v2
   (RFC 2401) which is known to be not consitent with IKEv1 or
   the reality.
 - section 4: the remark about RFC 4301 bound to IKEv2 is important!
 - section 5.1: even I know some GSPD implementations SSPD is far
   more common. More important, we *should not*  rely on one of
   the two models if we want credible interoperability.
   GSPD is not consistent with strict RFC 2401 because we can't apply
   a per interface SPD to select the interface... This is why RFC 3776
   gives SPD entries only as example (:-), and why 5.3.1 assumption
   doesn't make sense (but remember the issue is from RFC 2401).
 - section 5.2: I really prefer the RFC 4301 style:
   * SPD IN / OUT -> SPD-S with bidirectional entries
   * SRC -> local, DST -> remote for selectors
   * IDci -> TSi, IDcr -> TSr
   * no phase 2
   BTW please postpone the SPD per interface issue (i.e., we have to
   talk about it but not here)
 - section 5.3.1: the outbound processing assumption doesn't work
   with RFC 2401, this is not really a problem because RFC 2401 is
   basically flawn so nothing can be really correct...
   More critical, RFC 4301 was fixed and the forwarding box in the
   outbound processing is in the unprotected side so not only the
   assumption is wrong but the crossing of the IPsec boundary
   between the red and black space is something the security area
   directors will inflexibility and deeply review.
   I am really afraid that fixing this will just give the same than
   transport mode but in a very complex way...
 - section 7 (explanation/introduction comment). IKE manages two pairs
   of addresses, the addresses it runs over, called the peer addresses,
   which are the outer addresses too in our context. And addresses
   in traffic selectors. There are three ways to "update" the peer
   addresses but none without re-establishing SAs to update traffic
   selectors (and a proposal to recharter mobike to do that was
   rejected with a 12 vs 10 majority some days ago).
   The first way is NAT traversal where the used peer address is simply
   the last seen address in a valid (== checked by IPsec) packet. This
   is the implicit update and it was designed to keep IPsec alive
   through a NAT changing its mapping, but it works perfectly well
   in our context as described in the document.
   The second way is MOBIKE which provides an explicit (i.e., controlled
   by the peer) update mechanism for peer addresses. The protocol spec
   is in the RFC editor queue (so the document should be updated).
   This is a common misconception about MOBIKE: even if transport mode
   is not in the charter it is not true MOBIKE can't be used with
   transport mode: we should only be in a case where the traffic selectors
   don't need to be updated. Our context is one of theses cases when
   a SPD is attached to the tunnel interface and traffic selectors
   contain "any" for addresses: i.e., the interface selection is enough
   so there is no need to look at the outer addresses because they are
   enforced by the interface. Note the peer addresses still need to be
   managed, at least because they are critical parameters of the IKE SA
   we'd like to keep alive.
   The last way is to update directly (i.e., outside IPsec/IKE) the SA
   and SPD entries and to warn IKE to update its internal state, including
   the IKE SA. This is the Mobile IPv6 solution, the warning mechanism
   is the (in)famous K flag and there is a proposed API (PF_KEY extension)
   to implement it (and even working code for IKEv1 and IKEv2 :-).
 - section 8: this is a place where the IPsec WG never really proposed
   something and IMHO as there are many vendor based solutions it won't)
 - section 8: I'd like to get a good DNS SRV RR example for the DNS option.
 - section 9: needs update according to previous points.
 - section 11: BTW only IKEv2 maintains IPsec SAs.
 - section 11: if we can't find a better place, this is where to add some
   words about the PAD.
 - appendix A.x: please keep source and dest for the action description
   (i.e., the end-point addresses of the SAs) when SRC and DST are replaced
   by local and remote.

Regards

Francis.Dupont@point6.net