AD review of draft-ietf-shim6-hba

[Jari Arkko <jari.arkko@piuha.net>]

Marcelo,

I have made my AD review of this document. Please
find comments below. There are a few substantial
issues, but I think they can be corrected fairly
easily. I noted also a number of editorial 
issues. I will expect a new revision before we
move forward with this.

This is part 1 of my Shim6-related AD reviews.
The protocol draft is in my queue to be read next;
this will probably take a week or two. Mark will 
review the failure detection draft, and I have 
also asked him to handle any IPR related discussions,
should they come up during IETF Last Call. We will
wait with the Last Call until all three drafts
can proceed to it.

Here are the comments:

Substantial:

>    Ext Type:  16-bit type identifier of the Multi-Prefix Extension (TBD
>       IANA) (Meanwhile, the 0x12 value is recommended for trails)

A better recommendation would probably be "... the 
0xFFFF value, reserved for experimental usage in [RFC 4581],
is recommended for trials before the official IANA
allocation has been granted."

Alternatively, do you want to recommend value 0x12 for the IANA,
*if* implementations have already started to use it?

>    P flag:  Set if a public key is included in the Public Key field of
>       the CGA Parameter Data Structure.  Reset if a additional Modifier
>       bits are included in the CGA Parameter Data Structure.

This is unclear. I think you mean that instead of the public key,
some additional random bits can also appear. But the above two
conditions (if ... if ...) make it hard for the reader to know
whether the two conditions are actually always the reverse of
each other. I think they are. But I would rewrite the above as:


P flag:  Set if a public key is included in the Public Key field of
      the CGA Parameter Data Structure, reset otherwise.


> Second, in the
> case that the address being generated is an HBA-only address, a
> random nonce (encoded in DER as an ASN.1 structure of the type
> SubjectPublicKeyInfo) will have to be used as input instead of a
> valid public key.

Which value would AlgorithmIdentifier take in the ASN.1 structure?
Is the nonce a legal value for that identifier?

>    3. Concatenate from left to right the Modifier, 9 zero octets, the
>       encoded public key or the encoded Extended Modifier (if no public
>       key was provided) and the Multi-Prefix Extension.  Execute the
>       SHA-1 algorithm on the concatenation.  Take the 112 leftmost bits
>       of the SHA-1 hash value.  The result is Hash2.
>
>    4. Compare the 16*Sec leftmost bits of Hash2 with zero.  If they are
>       all zero (or if Sec=0), continue with step (5).  Otherwise,
>       increment the modifier by one and go back to step (3).

RFC 4982 should be referenced here, as it updates the above procedure,
and the words about SHA-1 should be changed accordingly. I.e., SHA-1
is used only for some small Sec values, and other algorithms, to be
defined in the future, could be used for others.

May apply elsewhere in the document, too.

>    The protection against brute force attacks can be improved increasing
>    the Sec parameter.  A non zero Sec parameter implies that steps 3-4
>    of the generation process will be repeated O(2^(16*Sec)) times
>    (expected number of times).  If we assimilate the cost of repeating
>    the steps 3-4 to the cost of generating the HBA address, we can
>    estimate the number of times that the generation is to be repeated in
>    O(2^(59+16*Sec)).

As above.

>    HBA sets can be generated using any prefix set.  Actually, the only
>    particularity of the HBA is that they contain information about the
>    prefix set in the interface identifier part of the address in the
>    form of a hash, but no assumption about the properties of prefixes
>    used for the HBA generation is made.  This basically means that
>    depending on the prefixes used for the HBA set generation, it may or
>    may not be recommended to publish the resulting (HBA) addresses in
>    the DNS.

I am not sure how the third sentence follows from the second.

But more importantly, this seems to simplify the issues 
related to DNS implications. Basically, you must be able
to tell the DNS network manager what your IP addresses
are; its not possible for the manager to configure your
DNS entries and addresses.

>    In the case that both IPSec and CGA/HBA address are used
>    simultaneously, it is possible that two public keys are available in
>    a node, one for IPSec and another one for the CGA/HBA operation.  In
>    this case, an improved security can be achieved by verifying that the
>    keys are related somehow, (in particular if the same key is used for
>    both purposes).

Yes, but please state that such verification is outside the
scope of this spec.

Editorial:

>    in the security cosniderations section.

Typo.

>    is used is to inlcude a hash of the permitted prefixes in the low

Typo.


>    It particular, it would possible for an attacker to redirect

Typo.

>       IANA) (Meanwhile, the 0x12 value is recommended for trails)

Trials.

> Reset if a additional Modifier
>       bits are included in the CGA Parameter Data Structure
maybe: "an additional"? or just "additional"?

> 7.1. Verification that a particular HBA address corresponds to a given
>
>       CGA  Parameter Data Strcuture

Typo.

> 7.2. Verification that a particular HBA address belongs tto the HBA set
>
>       associated to a given CGA  Parameter Data Strcuture

Typo.

> However, this not means that this
>    HBA does not belong to the HBA set. 
Grammar.

>    o  An CGA Parameter Data Structure

A CGA

> In order to perform this
>    attack the attacker need to generate

Needs?

> In
>    order to do this, the attacker need to find the appropriate Modifier
>    value.
As above.

Jari