Subject: (fwd) Review of send-ndopt by Pasi Eronen (thanks Pasi!)

From: <[email-masked]>
Date: Tue, 11 Nov 2003 22:58:01 +0200

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

Hi,

Please find below some comments about draft-ietf-send-ndopt-00.

o  This is a reasonably complex draft; if you have any ideas
   how to simplify the text, please do implement them :-)

   One possibility would be to reorder sections 5-8 as 7,8,5,6
   (but I'm not 100% sure whether this would make it easier to 
   read or not).

o  There quite a lot of redundant text, since the same requirements 
   are stated several times (and it's difficult to see that they always
   match completely). For instance, the requirement that solicitations
   must include a Nonce option is stated a total of five (!) times
   with a MUST/REQUIRED keyword, and mentioned a couple of times
   without RFC2119 keywords.

o  It seems that the intent of Sections 7 and 8 would be to describe
   changes to the RFC2461/2462 processing model, but they don't
   actually contain all the changes (e.g. when receiving a
   solicitation with bogus timestamp, reply to the message but 
   don't update caches).

o  Section 5.1 seems to suggest that other options than CGA, Nonce,
   or Timestamp could be placed after the Signature option; however, 
   Section 5.3.1 says the Signature option MUST be the last option. 
   Perhaps 5.1 should be clarified?

o  Section 5.2: The Modifier field is 16 bits (2 octets), but
   in draft-ietf-send-cga-02, the modifier is 16 octets (128 bits)?

o  Section 5.4.2.2: The timestamp should also have some fuzz factor 
   taking the typical resolution of timestamps (e.g., 1 second)  
   into account. Otherwise we get a situation like this:

   (Let's assume that both hosts have perfectly synchronized and 
   accurate clocks, timestamp resolution is 1 second, and
   transmission delay is 100 ms.)

   10.100 Sender sends a message, with Timestamp value 10
   10.200 Packet is received (RDnew=10, TSnew=10).  
          This is a new message, so we store RDlast=10, TSlast=10.
   11.950 Sender sends another message, with Timestamp value 11
   12.050 Packet is received (RDnew=12, TSnew=11). This is a known 
          peer, so we compare 11 > 10 + (12-10)*(1-0.01). 
          Unfortunately, this fails!

o  Section 6.5.1: "The parent certificates in the certificate chain
   MUST contain one or more X.509 IP address extensions, back up to
   the delegating authority (the Regional Address Registry or IANA)
   that delegated the original IP address space block." I think
   it's much more likely that the trust anchor is something below,
   like ISP or company IT administrator.

o  Section 6.5.1: It's not 100% clear whether the certificate
   chain sent should also contain the CA certificate (in most 
   protocols, it's not sent since the client is assumed to have 
   it already).

o  Section 8.1.2: the last paragraph should be probably deleted, 
   because I guess we don't usually use trust anchor authorization
   for router _solicitations_?

o  Section 9 says that "Unsolicited Neighbor and Router Advertisements 
   sent by a SEND router MUST be secured.". I guess the text about
   unsolicited NAs applies also to non-router SEND nodes?

o  Section 11.2.1: Should this section also mention the case when
   cache entries are created as a side effect of non-DAD Neighbor
   Solicitation, or when cache entries are updated as a result of
   unsolicited Neighbor Advertisement? (BTW, I have a feeling that
   some parts of the document don't take unsolicited NAs into account)

Editorial nits:

o  Section 2: Should have reference to RFC2119 (keywords)
o  Section 3: s/preformed/performed/
o  Section 4: "To secure the various functions, a set of new Neighbor 
   Discovery options introduced." -> "...options is introduced."
o  Section 5.3: The name of the algorithm is "RSASSA-PKCS1-v1_5", 
   not "RSASSA-PKCS1-v2_1".
o  Section 5.3.2: s/TheDigital/The Digital/
o  Section 5.3.2: s/preceeding/preceding/
o  Section 5.4.2.2: s/dritf/drift/
o  Section 5.4.2.2: s/acepted/accepted/
o  Section 6.5.1: s/advertize/advertise/, twice
o  Section 6.5.1: s/AFI/Address Family Identifier/
o  Section 7.2.2: s/eighbor/neighbor/
o  References: are 9 (RFC3041) and 12 (RFC 3531) really normative?
o  References: 26 (draft-ietf-send-cga) is certainly normative
o  References: 10,14,28,29,30,31,32,33 are never cited anywhere;
o  Intellectual Property Statement: should contain the 
   boilerplate from Section 10.4(d) of RFC2026 
   (add <?rfc iprnotified='yes'?> for xml2rfc).

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