Subject: send-ndopt review

From: Pekka Savola <[email-masked]>
Date: Mon, 9 Feb 2004 15:10:44 +0200 (EET)

Hi,

Below are the comments based on my WGLC review of send-ndopt document.  
You may treat these either as late WGLC or early IETF LC comments :).

In general, I think the document is in a pretty good shape, very 
readable etc. -- thanks!

But of course, there are a lot of tiny details to iron out :)

bigger architectural considerations
-----------------------------------

1)

The SEND model requires the model that if a host sends a solicitation,
the router must remember and respect that solicitation, even if it wanted to
respond using multicast to all the nodes.  That is, if the algorithm is set
so that if a host sends a solicitation, the router always replies with a
multicast "non-solicited response" in return, there must be both the nonce 
and timestamp to the multicast advertisement.

I don't have strong objections to this model, but I just thought it might be
something that some implementations (if those exist, not sure) might find
objectionable.

2) How exactly can you check for revoked certificates if you don't have
off-link network access yet?  Does every node have to contain a database of
these, and the possible disconnection time is the window of opportunity for
the attacker?  As stated in the spec:

   When processing the three certificates, the usual RFC 3280
   certificate path validation is performed, for instance by checking
   for revoked certificates.

(This will probably need a bit of discussion in security 
considerations as well..)

3) Looking up RFC 3280, from the Trust Anchor option (6.2.3), it
strikes me that the FQDN part (at least) may be something that may be
subject to the i18n requirements for strings in the specifications
(something that always comes up in IESG review, and is in ID nits).  
I know very little about this myself, but this may be something that a
subject matter expert from apps area (for example) might be able to
help with.

substantial
-----------

5.1.1 Processing Rules for Senders
                                                                               
   The CGA option MUST be present in all Neighbor Solicitation and
   Advertisement messages, and in Router Solicitation messages not sent
   with the unspecified source address.

==> if I read this correctly, using CGA with RS messages is a MAY? (I guess
the intent is a MUST)
==> is the non-unspecified source address a MUST?  Might be good to make it
an uppercase/clarify slightly in any case.

(That is, which parts of the RS sentence is a MUST (or not) should be made
clearer.)
[[ Note: the intent is clearer from the rest of 5.1.1 and 5.1.2]]

.....

   A message containing a CGA option MUST be checked as follows:
                                                                               
      If the interface has been configured to use CGA, the receiving
      node MUST verify the source address of the packet using the
      algorithm described in Section 5 of [12].  The inputs for the
      algorithm are the contents of the Collision Cnt, Modifier, and the
      Key Information fields, the claimed address in the packet (as
      discussed in the previous section), and the minimum acceptable Sec
      value.  If the CGA verification is successful, the recipient
      proceeds with the cryptographically more time consuming check of
      the signature.

==> as the CGA verification gives you no increase of security in itself, the
last sentence should be more balanced, or add something like, "However,
even if the CGA verification succeeds, no claims about the validity of the
use can be made, until the signature has been checked."

Similar in 3rd paragtaph of 9.3:

   When CGA protection is used, SEND deals with the DoS attacks using
   the verification process described in Section 5.2.2.  In this
   process, a simple hash verification of the CGA property of the
   address is performed before performing the more expensive signature
   verification.

...........

   Pad Length
                                                                               
      An 8-bit integer field, giving the length of the Pad field in
      units of an octet.
[...]

==> I see zero need for this option. Isn't it enough that the signature is
padded up to 8 bytes automatically? (The same issue in 6.2.3 and 6.2.4
with Trust Anchor and Certificate options.)

5.3.2 Nonce Option
                                                                               
==> the padding requirement must be spelled out, if the nonce is not 6+8n
bytes long.

5.3.3 Processing rules for senders
                                                                               
   All solicitation messages MUST include a Nonce.  All solicited-for
   advertisements MUST include a Nonce, copying the nonce value from the
   received solicitation.

[and:]

5.3.4.1 Processing solicited-for advertisements
[...]
   Otherwise, if the message does not contain a Nonce option, it MAY be
   considered as a non-solicited-for advertisement, and processed
   according to Section 5.3.4.2.

==> note that for senders, putting in a Nonce is a MUST, but here the lack
of it MAY be ignored.  Is this intentional (could be)?

5.3.4.2 Processing all other messages
[...]
      The receive time of the last received, accepted SEND message.
      This is called RDlast.
                                                                               
      The time stamp in the last received, accepted SEND message.  This
      is called TSlast.

==> AFAICS, "receive time" has only defined in 5.3.4.1, which doesn't apply
here.  Further, it may be worth spelling out what exactly constitutes an
"_accepted_ SEND message".

6.2.5 Processing Rules for Routers
                                                                               
   Routers SHOULD possess a key pair and a certificate from at least one
   certificate authority.

==> this is an operational requirement, not an implementation requirement,
so I would use lower-case for this, or put it in an operational
considerations section. (Same in the last paragraphs of section 7.3.)

   Hosts SHOULD store certificate chains retrieved in Delegation Chain
   Discovery messages if they start from an anchor trusted by the host.
   The certificate chains SHOULD be verified, as defined in Section 6.1,
   before storing them.
[[and the similar in section 6.1]]

==> isn't the usefulness of these certificates nullified, unless it can be
guaranteed that they have been verified?  Why isn't this a MUST?  If the
reason is only to support temporary storage of certificate chains, those
should be treated as separate from the rest of the certificates -- 
perhaps there should be a notion of verified certificate storage and 
unverified temporary storage.

7.1 CGA Addresses
                                                                               
   Nodes that use stateless address autoconfiguration, SHOULD generate a
   new CGA as specified in Section 4 of [12] for each new
   autoconfiguration run.

==> what is the definition of "each new autoconfiguration run"? :)

   o  The node SHOULD have a configuration option that causes it to
      ignore insecure advertisements even when performing Duplicate
      Address Detection for the first tentative address.  This
      configuration option SHOULD be disabled by default.  This is
      recovery mechanism, in case attacks against the first address
      become common.

==> I'd lean towards a "MAY have".. because this seems irrelevant.  
You can optimize away the cost of just one CGA generation (unless Sec
> 0), which is a lightweight process, and then the insecure
advertisements are ignored.  So, I don't think this is really needed,
but if it, we could strengthen the requirement later to a SHOULD (or
the like) if we think this threat becomes significant.

   When a SEND node is used on a link that also connects to non-SEND
   nodes, the SEND node ignores any insecure Neighbor Solicitations or
   Advertisements that may be send by the non-SEND nodes.

==> Based on section 8 on transition, this is not 100% correct -- the SEND
node will allow the first DAD response, correct?

    The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

==> actually, there hasn't been.  Only about CGA and the old send-ipsec.  Is
Send-IPSEC still valid for this document now that CGA is out?

   [26]  International Organization for Standardization, "The Directory
         - Authentication Framework", ISO Standard X.509, 2000.
                                                                                 
   [27]  Institute of Electrical and Electronics Engineers, "Local and
         Metropolitan Area Networks: Port-Based Network Access Control",
         IEEE Standard 802.1X, September 2001.

==> there are some references, at least these, which haven't been used in
the body.  Use or remove.

semi-editorial
--------------

   Internet Control Message Protocol version 6 (ICMPv6)
                                                                               
      The IPv6 control signaling protocol.  Neighbor Discovery Protocol
      is a part of ICMPv6.

==> I'd avoid the rathole of defining ICMPv6 (the two ugly words, to
"control" and "signaling").  Shouldn't it be enough just assume this
is known? If needed, one could mention, under NDP, that NDP messages
are ICMPv6.

   non-SEND node
                                                                               
      An IPv6 node that does not implement this specification but uses
      the legacy RFC 2461 and RFC 2462 mechanisms.

==> I would consider removing "legacy" here, as it may cause controversy
and doesn't add much, but either way works for me. (A bit more difficult
similar issue in section 8, 3rd paragraph; maybe "non-SEND" there?)

   Router Discovery (RD)
                                                                               
      The Router Discovery function of the Neighbor Discovery Protocol.

==> this definition doesn't really say anything, maybe add a sentence
describing what RD does?  [[ The same happens with Neighbor Discovery
definition but that's a bit larger can of worms .. ]]

   Length
                                                                               
      The length of the option, in units of 8 octets.

==> do these lengths include the Type and Length value as well, or just the
option "payload"?  Should be clear from RFC2461, but might not hurt if a
non-ambiguous wording could  be found.

   entity is allowed to route any prefix, the used IPv6 address prefix
   is the null prefix, 0/0.  The addressFamily element of the containing
 
==> in this case, there is no danger of confusion, but I'd reword this to be
correct RFC3513-wise, to ::/0.

  ispgroup.com is the trust anchor.  The host has this certificate for
[...]
                Issuer: isp_group.com
 
==> one is ispgroup, the other isp_group
==> these have to be converted to be under example.com/net. (A bit difficult
to do as one must illustrate different ISPs, but maybe e.g. isp1.example.com vs
isp2.example.com could be used.)

   Type
                                                                               
      TBD <To be assigned by IANA> for CGA.

==> Was this intentional or should all of these have been like:

      TBD <To be assigned by IANA for CGA>.

?

.....

    |     Type      |    Length     |  Name Type    |  Pad  Length  |
[...]
   Length
                                                                               
      The length of the option, (including the Type, Length, Name Type,
      Name Length, and Name fields,) in units of 8 octets.

==> above, this was Pad Length, here it's Name Length.
==> a few editorial nits in the above text as well s/,)/)/

   Name Type
                                                                               
      The type of the name included in the Name field.  This
      specification defines only one legal value for this field:
                                                                               
               1        DER Encoded X.501 Name
               2        FQDN

==> Well, I think you already defined two :)

.....
                                                                If the
   source address was a unicast address, the router MUST send the
   response to the Solicited-Node multicast address corresponding to the
   source address.  Routers SHOULD NOT send Delegation Chain
   Advertisements more than MAX_DCA_RATE times within a second.  When
   there are more solicitations than this, the router SHOULD send the
   response to the All-Nodes multicast address regardless of the source
   address that appeared in the solicitation.

==> as these MUST and SHOULD are in conflict, it might make sense to reword
the MUST sentence to be a little softer, e..g, add at the end: ", except
when under load, as specified below."

   1.  Entries made as a side effect of a Neighbor Solicitation or
       Router Solicitation.  A router receiving a Router Solicitation
       with a firm IPv6 source address and a Target Link-Layer Address
       extension inserts an entry for the IPv6 address into its Neighbor
       Cache.  Also, a node performing Duplicate Address Detection (DAD)

==> what is a "_firm_ IPv6 source address" ?  :)

editorial
---------

  IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
   other nodes on the link, to determine each the link-layer addresses
   of the nodes on the link, to find routers, and to maintain
   reachability information about the paths to active neighbors.

==> remove "each" ? (see introduction first paragraph)

   Duplicate Address Detection (DAD)
                                                                               
      A mechanism that assures that two IPv6 nodes on the same link are
      not using the same addresses.

==> s/addresses/address/ (not sure, I guess either way is fine)

   Router Authorization Certificate
                                                                               
      An X.509v3 [10] PKC certificate using the profile specified in
      Section 6.1.1.

==> spell out PKC?

      information is necessary in order to know whether a packet should
      be sent to a router or to the destination node directly.

==> s/to the .. directly/directly to the .../ (slightly better?)

   Reserved
                                                                               
      An an 8-bit field reserved for future use.  The value MUST be
 
==> s/an//

  to mobility requirements.  Still, the number of required signature
   operations is on the order of a few dozen ones per second, some of
   which can be precomputed as discussed below.  A large number of

==> s/ones//

      indicates the number of seconds since January 1,, 1970 00:00 UTC,
 
==> s/1,/1/

   If the message is accepted, the receiver SHOULD store the receive
   time of the message and the time stamp time in the message, as
   specified in Section 5.3.4.2

==> s/2/2./

      be updated.  Independent on whether TSlast is updated or not,
      RDlast is updated in any case.

==> s/on/of/

 Because authorization chains are not a common practice
   in the Internet at the time this specification is being written,

==> s/is being/was/? (or other such minor reword :)

   Router Authorization Certificates be X.509v3 certificates, as defined
 
==> s/be/are/

   Care should be taken if the certificates used in SEND are re-used to
   provide authorization in other circumstances, for example with
   routing gateway protocols.

==> remove "gateway" ?!!? :)

        which this message is sent.  Note that routers may use multiple
         addresses, and therefore this address not sufficient for the
         unique identification of routers.

==> s/not sufficient/is not sufficient/

   and they MAY posses a certificate from the above mentioned
 
==> s/posses/possess/

   Nodes that use stateless address autoconfiguration, SHOULD generate a
   new CGA as specified in Section 4 of [12] for each new

==> s/,//

   o  All solicitations sent by SEND nodes MUST be secured.
                                                                               
   o  Unsolicited advertisements sent by a SEND node MUST be secured.

==> s/SEND nodes/a SEND node/ (or a different kind of consistent style.)

   This document defines a new name space for the Name Type field in the
   Trust Anchor option.  Future values of this field can be allocated
   using standards action [6].  The current values for this field are:

==> s/standards action/Standards Action/ (two times)

  [23]  Droms, R., "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),
         November 2002.

==> RFC3315 now

   [25]  Nikander, P., "IPv6 Neighbor Discovery trust models and
         threats", draft-ietf-send-psreq-00 (work in progress), October
         2002.

==> why hasn't this been updated to -04?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.