Subject: DT's review of draft-ietf-send-ipsec-01.txt, part 2

From: "Dave Thaler" <[email-masked]>
Date: Thu, 19 Jun 2003 15:47:32 -0700

Typos and grammatical errors (see separate email for technical issues):

Abstract:
>   to active neighbors.  If not secured, ND protocol is vulnerable to
                                         ^
Insert "the".

>   securing ND.  Contrary to the original ND specifications that also
                  ^^^^^^^^
Should be "Unlike" (nothing in here is contrary to ND).

Section 1:
>   certified by a trusted root, and a zero-configuration mechanism for
                                                                   ^
Insert "is used".

>   to establish authorization delegation chain to a common trusted
root.
                ^
Insert "an". 

>   and Router Discovery.  A few small changes are required in the
>   Neighbor Discovery protocol and these are discussed in Section 5.

Move this last sentence to the beginning of the paragraph so the
sections
are mentioned in order.

Section 2:
>      of IP traffic encompassed by this policy entry.  Separate entries
>      for inbound and outbound traffic is required  [2].
                                        ^^
Should be "are".

Section 3:
>   how the messages should be treated.  Where this section and the
                                         ^^^^^
Should be "If" (Where implies there are definitely known
contradictions).

>      one of its interfaces runs first the DAD procedure to verify that
                             ^^^^^^^^^^
Should be "first runs".

>      Discovery and Duplicate Address Detection have an effect to the
                                                                ^^
Should be "on".  However, this whole bullet item seems to have forward 
references to things mentioned in the Router Discovery bullet item.  
Hence it would be good to move it down after that for readability.

>   header consisting of ICMPv6 header and ND message-specific data, and
                        ^
Insert "an".

>   o  Neighbor Solicitation: The destination address is either the
>      solicited-node multicast address, unicast address, or an anycast
                                        ^
Insert "a".

>       unicast or the All Nodes multicast address [1].  Like the
                      ^
Here, and for every other occurrence of All Nodes (and all-nodes, since
the draft is currently inconsistent in which syntax is used throughout),

insert "link-scoped".  Per RFC 3513, there are two All Nodes multicast 
addresses, and you mean the link-scoped one.

>   o  Router Solicitation: The destination address is typically the All
>      Routers multicast address [1].                               ^
Same thing.  Insert "link-scoped".  However, why is the wording
different
for this bullet item?  This one describes the "typical" case where all 
the others describe what is legal.

Section 4:
>   IPsec AH is used in to protect Neighbor and Router Discovery
                     ^^
Delete "in".

>   o  Cryptographically Generated Addresses are used to assure that the
>      sender of a Neighbor or Router Advertisement is the owner of an 
>      the claimed address.  A public-private key pair needs to be  ^^
Delete "an".  Also, other sections of this draft (e.g. 13.2.1.2) 
contradict this wording.  Here it says that CGA's are used (implying
it's unconditional).  Elsewhere it says that either CGAs or trusted
roots are used.

>   o  IPsec security policy database and security association database
      ^
Insert "The".

Section 5:
>   o  The use of the unspecified address as a source address is
>      discouraged.
Say why it's discouraged.  (E.g. to allow responses to go to just
the soliciting node rather than to all nodes).

Section 5.1:
>   Duplicate Address Detection uses the tentative address for which the
>   Duplicate Address Detection is being run.                        ^^^
Delete "the".

>   The use of the unspecified address is avoided in Router
>   Solicitations, if possible.  RFC 2461 requires that Router
>   Solicitations sent from the unspecified address do not cause a
>   modification in the Neighbor Cache.
This paragraph is unclear.  Is the point that you _want_ RS's to cause
a modification in the neighbor cache?  If so, say so.

Section 6:
>   Nodes multicast address.  These messages are separate from the rest
>   of the Neighbor Discovery in order to reduce the effect of the
       ^^^
Delete "the".

>   of the Neighbor Discovery in order to reduce the effect of the
>   potentially voluminous certificate chain information to other
                                                         ^^
Should be "on".

Section 6.1:
>         the address of the hosts' default router.
                             ^^^^^^
Should probably be "host's".

>         The ICMP checksum [8]..
                               ^^
Delete extra period.

Section 6.2:
>         The ICMP checksum [8]..
                               ^^
Delete extra period.

>         advertisement may be stored and taken in use before all the
                                          ^^^^^^^^^^^^
I don't know what that means.  Should this be "used"?

>         One certificate is provided in Certificate option, to
establish
                                        ^
Insert "each".

>         a (part of) certificate chain to a trusted root.
                     ^
Insert "a".

Section 6.5:
>   one AC corresponding to one trust root and all interfaces and
                                ^^^^^
Here and in many other places in this section the term is "trust" root,
whereas in other sections (2, 6.3, etc) it's "trusted" root.  Be
consistent 
throughout.

Section 6.6:
>   Routers MAY send unsolicited Delegation Chain Advertisements for
>   their trusted root.  When such advertisements are sent, their timing
                  ^^^^
Shouldn't this be "root(s)"?

>   Rate limitation of Delegation Chain Advertisements is performed as
         ^^^^^^^^^^
Should be "limiting".

Section 7.1.2:
>     The contents of the Key Information field are represented as ASN.1
>     DER-encoded data item of the following type:                ^
Insert "an".

>      (The normative definition of the type CGAParameters is in in
>      [27]).                                                 ^^^^^
Delete extra "in".  
Also, here it says "normative" but [27] is not listed as a normative 
reference.  This seems like a contradiction so a different term would be

better.

Section 7.1.3:
>      The minimum acceptable Sec value, if CGA verification is required
>      (see Section 2 in [27].
                             ^
Missing ")".

>      A flag that indicates whether or not the CGA is used.
                                            ^^^
Delete "the".

Section 7.1.4:
> If anti-replay has been enabled, receivers MUST be configured with an
> allowed Delta value and maintain a cache of messages received within
                                             ^
Insert "SEND".  (I assume you don't mean ALL packets.)

>      source with the same Timestamp field value MUST be silently
>      discard.
       ^^^^^^^
Should be "discarded".

Section 7.2.2:
>   using ICMP and ICMPv6 Type field as a selector.
         ^
Insert "the".

Section 8.1.1:
>   initialized, a node MUST join securely-solicited-node multicast
                                 ^
Insert "the".

Section 8.1.2:
>   Neighbor Solicitation messages received without an IPsec AH header
                                                                ^^^^^^
Delete "header".  The H already stands for Header.  Either use
"AH" or "Authentication Header", but never "AH header".  Many other
occurrences in this document (the CGA document is fine).
    
>   If source address of the Neighbor Solicitation message is the
      ^
Insert "the".

Section 8.2.2:
>   If source address of the Neighbor Advertisement message is the
      ^
Insert "the".

Section 8.3:
>   identifier.  This specification does not specify the format of such
>   certificates, since there are currently a few cases where such
                                            ^
Delete "a".

Section 8.4:
>   This section shows example security policy and security associations
>   database entries for the protection of Neighbor Solicitation and   ^
Should just be "association" not plural.

>   security policy data base along with the inbound security
                    ^^^^^^^^^
Should be "database" for consistency with the rest of the document.

>   The following table summarizes outbound security policy database:
                                  ^
Insert "the".

Section 9.2.2:
>   authorization mechanism (CGA or trusted root), the minimum allowable
>   key size, and optionally with the information related to the trusted
>   root and the acceptable minSec value.
         ^^^
Since minSec is specific to CGA, shouldn't this be "or", just like you
say "CGA or trusted root" as the mechanism?  Same in 9.1.2, 9.3.2.

Section 9.3.2:
>   If source address of the Redirect message is the unspecified
address,
      ^
Insert "the".

Section 10.1:
>      containing the insecure prefixes MUST be sent without AH header.
                                                            ^
Insert "an" (and delete "header").

Section 10.2:
>   data base configuration required for the co-existence of SEND and
    ^^^^^^^^^
Should be "database".

Section 13.2.4:
>   header be calculated using the public key of a host that can prove
                                                   ^^^^
Should be "node" (can be a router or a host).

>   Prefix Information Options.  The router proves it authorization by
                                                   ^^
Should be "its".

>   showing an attribute certificate containing the specific prefix or
               ^^^^^^^^^
Should be "authorization" (per the terminology section).

Section 13.3:
>   to Denial-of-Service attacks.  An attack may target a router by
>   request a large number of delegation chains to be discovered for
    ^^^^^^^
Should be "requesting".

>   certificate chains and their verification.  Hosts SHOULD also
>   prioritize advertisements sent as a response to their requests above
>   multicast advertisements.
    ^^^^^^^^^
Shouldn't this be "unsolicited"?

Finally, can the page breaks between Appendices A, B, C be removed?
(The page count can be decreased by several pages.)

-Dave

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