Cryptographic Suites for IPsec
RFC 4308

[Ballot discuss]
In section 4.1.1, please change 3DES-CBC to a MUST-.

In section 4.1.2, please change MODP group 2 to a MUST-.

In section 4.1.3, please change ENCR_3DES to a MUST-.

[Ballot comment]
In draft-ietf-ipsec-ikev2-algorithms-04.txt

The scope of this document could be a bit clearer, i.e, that the
transforms are about IKE, and not IPsec.

Rewording suggestion. Change:

> The Internet Key Exchange protocol provides for the negotiation of
> cryptographic algorithms between both end points of a cryptographic
> association. Different implementations of IPSec and IKE may provide
> different algorithms. However the IETF desires that all implementations
> should have some way to interoperate. This requires that some set of
> algorithms be specified as "mandatory to implement."

To something like:

The Internet Key Exchange protocol provides for the negotiation of
cryptographic algorithms between both end points of a cryptographic
association. Different implementations of IPSec and IKE may provide
different algorithms. However the IETF desires that all
implementations should have some way to interoperate. In particular,
this requires that IKE define a set of mandatory-to-implement
algorithms, since IKE itself uses such algorithms as part of its own
negotiations. This requires that some set of algorithms be specified
as "mandatory to implement" for IKE.


> Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to
> negotiate which algorithms should be used in any even association.

what does "in any even association" mean?

> is necessary to specify a set of mandatory to implement algorithms to

mandatory-to-implement (multiple places)

> available. This document defines the current set of mandatory to
> implement algorithms for use of IKEv2 as well as specifying algorithms
> that should be implemented because they made be promoted to mandatory
> at some future time.

what does it mean "for use of"? to allow IKEv2 itself to negotiate
phase II? Suggested reword:

This document defines the current set of algorithms that are mandatory
to implement as part of IKEv2, as well as algorithms that should be
implemented because they may be promoted to mandatory at some future
time.


> There are several MODP groups that are defined for use in IKEv2. They

expand/define MODP?

[Ballot comment]
The scope of this document could be a bit clearer, i.e, that the
transforms are about IKE, and not IPsec.

Rewording suggestion. Change:

> The Internet Key Exchange protocol provides for the negotiation of
> cryptographic algorithms between both end points of a cryptographic
> association. Different implementations of IPSec and IKE may provide
> different algorithms. However the IETF desires that all implementations
> should have some way to interoperate. This requires that some set of
> algorithms be specified as "mandatory to implement."

To something like:

The Internet Key Exchange protocol provides for the negotiation of
cryptographic algorithms between both end points of a cryptographic
association. Different implementations of IPSec and IKE may provide
different algorithms. However the IETF desires that all
implementations should have some way to interoperate. In particular,
this requires that IKE define a set of mandatory-to-implement
algorithms, since IKE itself uses such algorithms as part of its own
negotiations. This requires that some set of algorithms be specified
as "mandatory to implement" for IKE.


> Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to
> negotiate which algorithms should be used in any even association.

what does "in any even association" mean?

> is necessary to specify a set of mandatory to implement algorithms to

mandatory-to-implement (multiple places)

> available. This document defines the current set of mandatory to
> implement algorithms for use of IKEv2 as well as specifying algorithms
> that should be implemented because they made be promoted to mandatory
> at some future time.

what does it mean "for use of"? to allow IKEv2 itself to negotiate
phase II? Suggested reword:

This document defines the current set of algorithms that are mandatory
to implement as part of IKEv2, as well as algorithms that should be
implemented because they may be promoted to mandatory at some future
time.


> There are several MODP groups that are defined for use in IKEv2. They

expand/define MODP?

[Ballot discuss]
In:    - draft-ietf-ipsec-ui-suites-04.txt
      Cryptographic Suites for IPsec (Proposed Standard)

> A. IANA Considerations
>
> IANA will create a registry of strings used to identify cryptographic
> suites for IPsec. The entries in the registry will consist of a string
> and the RFC that defines the string.
>
> The initial values for the new registry are:
>
> Identifier    Defined in
> VPN-A        RFC [this document]
> VPN-B        RFC [this document]

IANA considerations needs to be clearer. Something like the following
would be more clear:

IANA is asked to create and maintain a registry entitled "IPsec
Cryptographic Suites". The registry consists of a string [XXX: does it
have any syntax or can it be literally anything??] and an RFC number defining
the associated transforms. New entries can be added to the registry
only through RFC publication [XXX: is there any review required? Can
anyone publishing any RFC ask to be listed?]

The initial values for the new registry are:

Identifier    Defined in
VPN-A        RFC [this document]
VPN-B        RFC [this document]

[Ballot discuss]
> A. IANA Considerations
>
> IANA will create a registry of strings used to identify cryptographic
> suites for IPsec. The entries in the registry will consist of a string
> and the RFC that defines the string.
>
> The initial values for the new registry are:
>
> Identifier    Defined in
> VPN-A        RFC [this document]
> VPN-B        RFC [this document]

IANA considerations needs to be clearer. Something like the following
would be more clear:

IANA is asked to create and maintain a registry entitled "IPsec
Cryptographic Suites". The registry consists of a string [XXX: does it
have any syntax or can it be literally anything??] and an RFC number defining
the associated transforms. New entries can be added to the registry
only through RFC publication [XXX: is there any review required? Can
anyone publishing any RFC ask to be listed?]

The initial values for the new registry are:

Identifier    Defined in
VPN-A        RFC [this document]
VPN-B        RFC [this document]

[Ballot comment]
draft-ietf-ipsec-ui-suites was reviewed by John Loughney, Gen-ART.
He pointed out that this document does NOT define an IANA registry for suite names, and that it's extremely unclear how (or if) suite names should be "registered" in the future.
Given the amount of "reservation" of the strings "VPN-A" and "VPN-B" the document tries to do, that's odd.
Complete review entered as a document comment.