Subject: Comments from Francis DuPont on CGA Draft

From: "James Kempf" <[email-masked]>
Date: Wed, 25 Jun 2003 09:00:54 -0700

Francis DuPont is on the SEND review board. He sent the comments below on
the CGA draft.

Comments?

            jak

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

Everywhere: please remove trailing spaces at end of lines.

Abstract (wording)

  cryptographic one-way hash function from the address owner's public

=> "owner's" is an involuntary joke?

(same) (same)

  SEND protocol
  messages are protected with an Authentication Header (AH) that
  contains the public key and the auxiliary parameters and is signed

=> please add a "can" verb somewhere because CGA is not the only mechanism.

Table of Contents (wording, multiple)

  1. Introduction...................................................2
  2. The CGA Address Format.........................................3

=> s/The //

  3. The CGA Parameters and the Hash Values.........................4

=> s/The //

  4. CGA Generation.................................................5
  5. CGA Verification...............................................6
  6. The CGA Authorization Mechanism for SEND.......................8

=> s/The //

1. Introduction

  identifier (i.e. rightmost 64 bits) of the IPv6 address by
                  ^

=> i.e., (please add a comma after i.e. and e. g. everywhere)

(same) (wording)

  This kind of IPv6
  addresses are called cryptographically generated addresses (CGA).

=> singular/plural mismatch. I propose

  This kind of IPv6
  addresses is called a cryptographically generated address (CGA).

(same) (wording)

  More specifically, this document specifies
                                           ^:

2. The CGA Address Format (wording)

=> s/The //

(same) (forgotten update)

    Mask2 (64 bits)  = 0xfcfffffffffffff8

    Mask3 (64 bits)  = 0xfffffffffffffff8

=> I am afraid that the masks are for the previous version where the
Sec bits were right-most. If it is not the case, please explain the
trailing 8 (in place of f). BTW the masks are 0x1cff..f and 0x1ff..f

(same) (presentation)

           Hash1 & Mask2  ==  interface identifier & Mask3
         Hash2 & Mask1  ==  0x0000000000000000000000000000

=> please align the equations:

         Hash1 & Mask2  ==  interface identifier & Mask3
         Hash2 & Mask1  ==  0x0000000000000000000000000000

3. The CGA Parameters and the Hash Values (wording)

=> s/The //

(same) (remark)

               CGAParameters ::= SEQUENCE {
                 auxParameters  CGAAuxParameters,
                 publicKey      SubjectPublicKeyInfo }

=> SubjectPublicKeyInfo is a SEQUENCE so it can't be made optional
without a tag.

(same) (spelling)

  DER-encoding. The 64-bit Hash1 is obtained by taking the leftmost
  64 bits of then 160-bit SHA-1 hash value.
                ^

4. CGA Generation (wording)

  Sec values is infeasible with today's technology.

=> s/today's/current/ ?

5. CGA Verification (wording)

  specification may define situations where a it is acceptable for
                                            ^^^^
  the verifier to set higher minSec values.

6. The CGA Authorization Mechanism for SEND (wording)

=> s/The //

6.1 Sending SEND Messages (spelling)

  at least 1024 bits long.
                   ^

(same) (ASN.1 issue)

          SendKeyInformation ::= SEQUENCE {
            cgaParameters  CGAParameters OPTIONAL,
            signerInfo     SubjectPublicKeyInfo OPTIONAL }

=> both CGAParameters and SubjectPublicKeyInfo are SEQUENCEs so
a tag is needed. I recommend IMPLICIT tagging as:

          SendKeyInformation ::= SEQUENCE {
            cgaParameters  [0] IMPLICIT CGAParameters OPTIONAL,
            signerInfo     [1] IMPLICIT SubjectPublicKeyInfo OPTIONAL }

The effect is the SEQUENCE byte (30, constructed 10) will be replaced
by A0 or A1... Note that in fact only one member needs a tag but
by convention usually all optional members get one.

6.2 Receiving SEND messages (wording)

  verification of the CGA property, the receiver must verify the MUST
                                                 ^^^^^^^^^^^^^^^^^^^^
  verify the source address of the packet as described in Section 5.
  ^^^^^^

(same) (spelling)

  and the contents of the CGAParameters structure from the Key
                 ^
(same) (same)

  the SEND message and ignore its contents.
                                         ^

7.2 Hash extension (request)

  This increases the cost of address generation approximately by a
  factor of 2^(16*Sec). It also increases the cost of brute-force

=> I'd like to know what is the delay to compute a Sec 1, 2, ...
on current stock hardware (it takes 2 seconds or 2 hours).
This should go in appendix A.

Normative References (wording, multiple)

  [Bra97] Scott Bradner. Key words for use in RFCs to indicate
  requirement levels. RFC 2119, IETF Network Working Group, March
                                     ^^^^^^^^^^^^^^^^^^^^^

=> there are some comments in the IETF mailing list about this.
It seems the "Network Working Group" is old history...

Informative References (ascii)

  [AAK+02]    Jari Arkko, Tuomas Aura, James Kempf, Vesa-Matti
  M"ntyl", Pekka Nikander, and Michael Roe. Securing IPv6 neighbor

=> non ASCII characters, code 0204.

(same) (request)

  [Nik01] Pekka Nikander. A scaleable architecture for IPv6 address
  ownership. Internet-draft, March 2001. Work in Progress.

=> please add the name of the draft.

Appendix A.    Example of CGA Generation (request)

  TBW

=> yes, TBW!

Appendix B.    Changes since draft-aura-cga-pre01 (request)

     o Sec is now encoded in the three leftmost bits of the 64-bit
        interface identifier. Earlier, it was encoded in the three
        rightmost bits. Using the rightmost bits would distort the
        distribution of solicited-node multicast addresses.

=> please check the document has been updated *everywhere*.

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------