[IPsec] Comments on draft-ietf-ipsecme-roadmap-03

[Tero Kivinen <[e-mail]>]

Yaron Sheffer writes:
> - I would have liked to see ESP BEET mode referenced, since it's more widely
> implemented than other docs that we do mention. But as far as I know it is
> not on track to becoming an RFC.

I agree on that, and I think it might also be good to mention other
very widely implemented (expired) drafts which will never come out as
RFCs, namely IKEv1 configuration mode (draft-dukes-ike-mode-cfg-02)
and IKEv1 xauth (draft-beaulieu-ike-xauth-02).

> - 4.1.1: if RFC 2409 is N/A for IPsec-v3, how come RFC 4304 defines the use
> of ESN in IKEv1? But you can't expect a Roadmap document to resolve all
> issues.

As RFC4303 says ESP does not have version number, thus version is only
known by the signaling methods or out of band configuration. Use of
IKEv2 automatically implies ESP-v3. If IKEv1 is used then that would
imply ESP-v2, but RFC4304 explictly defines method of negotiating
ESP-v3 feature in IKEv1, thus if that feature is used, then ESP-v3 is
also assumed.

That is at least my interpretation of the situation...

Of course everybody should stop using already obsoleted IKEv1
protocol :-)

> - 7.5: I would describe the history differently (I was there...). IPSRA
> attempted to tack user authentication onto IKEv1 with no change to IKE. This
> indeed proved cumbersome, and the result was the brand new IKEv2, which in
> fact adopted some of the IPSRA ideas, primarily the use of EAP.

Agree... 

> - Table 1: There is nothing that limits the Heuristics draft to ipsec-v3. In
> facts legacy devices are a major reason for publishing these heuristics.

True, altough in IPsec-v2 things are bit easier, as there is no
combined mode ciphers i.e. no GMAC, thus no need to detect IV. The
draft does not limit itself to either version.

BTW, the latest draft is draft-ietf-ipsecme-esp-null-heuristics-01.txt
not draft-kivinen-ipsecme-esp-null-heuristics.

Other comments:

--

It would be much easier to read the document if each document would be
easier to detect from each other. Now when moving from one document to
next is indicated by even more indented bulletpoint text than the
actual text it does not provide good visual feedback to search
documents. It might be better to change all document headers to
sections (and perhaps exclude them from toc (i.e. add toc="exclude" to
them if using xml to rfc)).

--

In section 5.2 covering RFC3686 document says:

	 ... AES-CTR is a stream cipher with a 32-bit random nonce
   (1/SA) and a 64-bit IV, both of which are sent in the packet along
   with the encrypted data.  

The description of the random noise and 64-bit IV is correct, but only
the 64-bit IV is sent along the packet. The nonce is provided by the
IKE with the keying material.

There is also draft-ietf-ipsecme-aes-ctr-ikev2-02 to define how that
is used in IKEv2 (and as IKEv2 and ESP-v3 share same iana registry
there is already number for it).

--

For RFC5529 I do not think we need separate RFC to use Camellia-CBC in
IKEv2. It is just normal CBC mode algorithm and the generic rules in
RFC4306 covers it. As it also already has IANA number I do not see any
reason why it cannot be used in IKEv2 too.

For the Camellia-CTR the situation is different as generic RFC4306
text only covers CBC mode ciphers, not counter mode ciphers. Perhaps
the draft-ietf-ipsecme-aes-ctr-ikev2-02 should be expanded to include
more of the counter mode ciphers (i.e. provide generic rules how
counter mode ciphers are used in IKEv2)?

For the Camellia-CCM there is the RFC5282 which describes how combined
mode ciphers are used in the IKEv2. I think that document along with
RFC5529 should be enough to specify how Camellia-CCM is used in IKEv2.
-- 
[e-mail]