Subject: Closing issue 05: Clarifications and inconsistency fixes

From: Pekka Nikander <[email-masked]>
Date: Tue, 14 Oct 2003 13:59:07 +0300

I have now edited in Dave Thaler's comments as follows:

> 1) Section 6 states:
>    > Similarly, the router, which is already connected to the network, can
>    > if necessary communicate off-link and construct the certificate
>    > chain.
> 
> This should be clarified with "in some cases".  If the router is
> not connected to the Internet, this may not be possible.

The new text now reads:

                         In the typical case, a router, which is
       already connected to beyond the link, can (if necessary)
       communicate with off-link nodes and construct such a certificate
       chain.

> 2) Sections 6.1 and 6.2 describe an Identifier field, but does not
>    specify how it is set in a solicitation or in an unsolicited
>    advertisement.  E.g.  if it is always set to 1, it doesn't seem
>    very useful.  Likewise, if each host starts with 1 and increments,
>    it's also less useful since hosts can collide.  I think it should
>    be randomly generated if possible.

The new text now reads:

       A 16-bit unsigned integer field, acting as an
       identifier to help matching advertisements to
       solicitations.  The Identifier field MUST NOT be zero,
       and its value SHOULD be randomly generated.  (This
       randomness does not need to be cryptographically hard,
       though.  Its purpose is to avoid collisions.)

> 3) Sections 6.3 and 6.4 both specify options with a variable-length
>    field followed by padding.  However, they use two different encodings
>    for no good reason.  One specifies the length of the field, and the
>    other specifies the length of the padding.  Instead, both options
>    should be consistent.

Changed now so that both sections have an explicit pad length.

> 4) Section 6.4 says:
>    >  When the Name Type field is set to 1, the Name field contains the
>    >  Fully Qualified Domain Name of the trusted root, for example
>    >  "trustroot.operator.com".
> 
>    More guidance is needed to prevent interoperability problems.  Is the
>    string null-terminated (I assume no)?  Are internationalized domain
>    names legal?  What is the encoding?  (UTF-8?  Unicode? ...)

The new text now reads:

       When the Name Type field is set to 1, the Name field
       contains a Fully Qualified Domain Name of the trusted
       root, for example, "trustroot.example.com". The name is
       stored as a string, in the "preferred name syntax" DNS
       format, as specified in RFC1034 Section 3.5.
       Additionally, the restrictions discussed in RFC 3280
       Section 4.2.1.7 apply.

> 5) Section 6.5 says:
>    > RFC 3281.  If the GeneralName attribute is a dNSName, it MUST be
>    > resolvable to a global unicast address assigned to the router.  If
>    > the GeneralName attribute is an iPAddress, it MUST be a global
>    > unicast address assigned to the router.  For purposes of facilitating
> 
>    For people not familiar with X.509, is it easy to explain in 1-2
>    sentences what it is used for?  (That is, why is it a MUST above?) 
>    As is, it sounds suspiciously like a security hole.

This issue has disappeared since we no longer use RFC3281.

> 6) Section 6.5.1 says:
>    >  This field MUST contain a list of prefixes that the router is
>    >  authorized to route, or the  unspecified  prefix  if  the  router
> 
>    This wording is particularly problematic.  Routers route packets
>    not prefixes.  They _advertise_ prefixes in RA's and in routing protocols.
>    It's similarly unclear whether the prefix list is what remote
>    prefixes it's allowed to advertise as off-link routes in RA's (e.g.
>    ::/0 if it can be a default router on the link), or whether the prefix
>    list is what local prefixes it's allowed to advertise as on-link routes
>    in RA's.  I'm guessing the latter, but I can think of arguments for
>    restricting both.

This issue has disappeared since we no longer use RFC3281.

> 
> 7) Sections 6.6 and 6.7 appear to contradict each other.
>    6.6 says:
>    > SHOULD send an advertisement without any certificates.  In this case
>    > the router SHOULD include the Trusted Root options which were
>    > solicited.
> 
>    Hence the Trusted Root option is legal in an advertisement.
> 
>    6.7 says:
>    > packet processed in the normal manner.  The only defined option that
>    > may appear is the Certificate option.  An advertisement that passes
> 
>    Hence the Trusted Root option is not legal in an advertisement.

6.7 fixed to allow Trusted Root option.

> 8) Section 7.1.2 and reference [27] contradict each other.
>    7.1.2 says:
> 
>    >    CGAParameters ::= SEQUENCE {
>    >      publicKey      SubjectPublicKeyInfo,
>    >      auxParameters  CGAAuxParameters OPTIONAL }
> 
>    whereas [27] now has the opposite order.  It would be better to not
>    copy the definition here at all, and just refer to [27] for the
>    definition.

This issue has diappeared since we no longer use ASN.1 here.

> 9) Section 7.1.3 talks about a minbits parameter.  It doesn't really
>    say how the value should be determined.  Some guidance would be
>    helpful.

The new text now reads:

     The minimum acceptable key length for the public keys
     used in the generation of the CGA address.  The default
     SHOULD be 1024 bits.  Implementations MAY also set an
     upper limit in order to limit the amount of computation
     they need to perform when verifying packets that use
     these security associations.  Any implementation should
     follow prudent cryptographic practise in determining the
     appropriate key lengths.

I don't think whether it is good to give any reference, since
references in this field tend to get obsoleted fairly soon.

Unless there are any more comments, I will consider this issue closed.

--Pekka Nikander

--------------------------------------------------------------------
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
--------------------------------------------------------------------