[Ipsec] Some (hopefully final) comments to thedraft-ietf-ipsec-ikev2-15.txt

[Tero Kivinen <kivinen@iki.fi>]

I just finished reading the draft-ietf-ipsec-ikev2-15.txt completely
again. I found some small points, which probably can either be left as
they are or fixed during the authors 48 hours notice...

Perhaps the area directors can confirm whether we can fix those in
last edit phase, if not, then I think we can just leave the changes
out (the only real issue is the issue number 3 below, as it will
affect interoperability).

----------------------------------------------------------------------

1) Section 3.6 Certificate Payload refers X.509 certificates and CLRs
   as a BER encoded x.509 certificate / CRL. I think it should use DER
   instead of BER. Of course DER is a subset of BER, so all DER
   encoded objects are also BER encoded, but not other way around, and
   the certificates etc must always DER encoding, as it must be same
   regardless who encoded it.

   I have seen some LDAP servers who took DER encoded certificate, and
   re-encoded it using BER when sending it out, and that of course
   caused the signatures to fail etc.

so change

      X.509 Certificate - Signature (4) contains a BER encoded X.509
      certificate whose public key is used to validate the sender's AUTH
      payload.

      Certificate Revocation List (7) contains a BER encoded X.509
      certificate revocation list.

to

      X.509 Certificate - Signature (4) contains a DER encoded X.509
      certificate whose public key is used to validate the sender's AUTH
      payload.

      Certificate Revocation List (7) contains a DER encoded X.509
      certificate revocation list.


and 

      Hash and URL encodings (12-13) allow IKE messages to remain short
      by replacing long data structures with a 20 octet SHA-1 hash of
      the replaced value followed by a variable length URL that resolves
      to the BER encoded data structure itself. ...

to

      Hash and URL encodings (12-13) allow IKE messages to remain short
      by replacing long data structures with a 20 octet SHA-1 hash of
      the replaced value followed by a variable length URL that resolves
      to the DER encoded data structure itself. ...

----------------------------------------------------------------------

2) Section 3.7 Certificate Request Payload refers still in one place
   to CA name instead of the hash of the CA public key.

so change

   means. Thus the processing of a CERTREQ CA name should be seen as a
   suggestion for a certificate to select, not a mandated one. If no
   certificates exist then the CERTREQ is ignored. This is not an error

to

   means. Thus the processing of a CERTREQ should be seen as a
   suggestion for a certificate to select, not a mandated one. If no
   certificates exist then the CERTREQ is ignored. This is not an error

There is also extra " at the end of that paragraph, which can be
removed at the same time...

----------------------------------------------------------------------

3) Section 3.15.1 Configuration Attributes has a table listing which
   of the attributes are multivalued and which are not. The
   INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET are listed in the table
   as NO (i.e. not multivalued), but the describing text later says
   "The responder MAY respond with zero or more sub-network
   attributes.", which indicates that they should be multivalued.

   As it do make sense to send multiple subnets, I think the text is
   correct and the table is incorrect.

so change:

         INTERNAL_IP4_SUBNET     13    NO    0 or 8 octets
         SUPPORTED_ATTRIBUTES    14    NO    Multiple of 2
         INTERNAL_IP6_SUBNET     15    NO    17 octets

to

         INTERNAL_IP4_SUBNET     13    YES   0 or 8 octets
         SUPPORTED_ATTRIBUTES    14    NO    Multiple of 2
         INTERNAL_IP6_SUBNET     15    YES   17 octets

----------------------------------------------------------------------

4) RFC2401bis reference should have the draft name, as it would make
   rfc-editors life easier when finding the correct reference, and
   fixing it to match the rfc number.

so change:

   [RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture
              for the Internet Protocol", un-issued Internet
              Draft, work in progress.

to

   [RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture
              for the Internet Protocol", draft-ietf-ipsec-
	      rfc2401bis-02.txt, April 2004, work in progress.
-- 
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec