Subject: [Fwd: Re: SEND Protocol Document Review]

From: Pekka Nikander <[email-masked]>
Date: Tue, 17 Jun 2003 09:15:13 +0300

Please find enclosed Francis Dupond's comments on the
current drafts, forwarded with his permission.

Francis, thanks a lot for your review!

--Pekka & James

Subject: Re: SEND Protocol Document Review
From: Francis Dupont <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Pekka Nikander" <[email-masked]>
Date: Sat, 14 Jun 2003 18:15:54 +0200

Here are my comments about draft-ietf-send-ipsec-01.txt:

 - 1. Introduction (proposed improvement)

   security associations needed for protecting ND is impractically large

  => s/is/can be/ (rationale: it is not always the case, for instance
     p2p links can be protected with a pair of SAs).

 - same (comment)

   approach involves the use of IPsec AH [3] to secure all

  => don't forget than the IPsec WG still wants to phase out AH,
     that was voted at a previous IETF meeting. So I suggest you
     ask the IESG to *not* make AH historic in a close future.
     IMHO IPsec guys should be happy as soon as AH in no more
     mandatory...

 - 2. Terms (spelling)

      some other parameters using a one-way hash function.

  => s/a/an/ ?

 - same (comment)

      but not both.  A security association is uniquely identified by a
      triple consisting of a Security Parameter Index (SPI), an IP
      Destination Address, and a security protocol (AH or ESP)
      identifier [2].

  => (note that this is discussed in the document). RFC 2401bis is supposed
  to use only the SPI. IMHO you have to show this document to Stephen Kent
  in order to support both 2401 and 2401bis context. ESPv3 draft can give
  good hints if you don't want to read the whole IPsec mailing list archive.

 - same (comment)

   Security association database

      A nominal database containing parameters that are associated with
      each (active) security association.  For inbound and outbound
      IPsec processing, these databases are separate.

  => databases are per-interface too. IMHO this is not a problem if we
  ignore the multiple interfaces attached to the same link case...

 - 3. Neighbor and Router Discovery Overview (comment)

   how the messages should be treated.  Where this section and the
   original Neighbor Discovery RFCs are in conflict, the original RFCs
   take precedence.

  => I have a real concern with this statement. If this section is not
  normative, it should be made clearer. I have a proposal: explain that
  the section should be an appendix but for clarity it is at this place.

 - same (comment)

   o  The Redirect function is used for automatically redirecting hosts
      to an alternate router.  Redirect is specified in Section 8 of RFC
      2461 [6].  It is similar to the ICMPv4 Redirect message [19].

  => this is *not* true: IPv6 redirect has 3 functions:
   - change the router for a better one (the function you described)
   - change the link-layer address (target == destination). This should
     be in general by the peer itself with a NA at the exception of the
     last case.
   - give the link-layer address of an off-link destination which is
     in fact on-link. This "external redirect" is used for IPv6 over
     ATM to implement NHRP short cuts for instance.

 - same (wording)

   header consisting of ICMPv6 header and ND message-specific data, and
                       ^ an

 - same (improvement)

   The destination addresses used in these messages are as follows:

  => there are two missing things:
   - a global statement explaining that ND is local to the link
     (for all messages).
   - constraints over the source address too.

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

  => source in unspecified (DAD) or a unicast address assigned
  to the sending interface. Note that in general the source is
  the same than the one of the triggering packet.

   o  Neighbor Advertisement: The destination address is either a
      unicast address or the All Nodes multicast address [1].

  => source is a unicast address assigned to the sending interface.

   o  Router Solicitation: The destination address is typically the All
      Routers multicast address [1].

  => same than for NS but the unspecified source has no special
  meaning: it is just an optimization for startup.

   o  Router Advertisement: The destination address can be either a
      unicast or the All Nodes multicast address [1].  Like the
      solicitation message, the advertisement is also local to the link
      only.

  => source is a link-local address assigned to the sending interface
  (usually there is only one such address). Please make the second
  statement (local to the link only) more general.

   o  Redirect: This message is always sent from the router's link-local
      address to the source address of the packet that triggered the
      Redirect.  Hosts verify that the IP source address of the Redirect
      is the same as the current first-hop router for the specified ICMP
      Destination Address.  Rules in [1] dictate that unspecified,

  => unspecified source is not forbidden.

      anycast, or multicast addresses may not be used as source
      addresses.  Therefore, the destination address will always be a
      unicast address.

  => to deduce that the destination address in the IPv6 header of a redirect
  (there is a field named "destination address" to help us ;-) is always
  a unicast address the argument is:
   - anycasts and multicasts are forbidden as source
   - unspecified is forbidden as destination (all nodes is used when
     one'd like to reach any node).

 - 4. Secure Neighbor Discovery Overview (comment)

      Optionally, an authorization certificate can specify the prefixes
      for which the router is allowed to act as a router.

  => I don't understand at all this statement: prefix discovery
  is not bound to the default router function... I believe that
  you mean "is allowed to advertise"??

 - same (comment/request for improvement)

   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
      generated by all nodes before they can claim an address.

  => this suggests that all addresses should be CGAs. Of course this
  is only one of the two cases:
   - certified addresses (always the case for universal or static IID)
   - CGAs (which always give local IID)

 - same (comment)

   o  A new transform for IPsec AH allows public keys to be used on a
      security association directly without the involvement of a key...

  => I propose to talk about inline signature, look at SKIP documents.

 - 6. Authorization Delegation Discovery (wording)

   Since the newly-connected node likely can not communicate off-link,

  => s/the/a/ ?

 = same (same)

   the router; however, given a chain of appropriately signed
   ...
   Similarly, the router, which is already connected to the network, can

  => s/the/a/ ?

 - same (comment)

   The Authorization Delegation Discovery process does not exclude other
   forms of discovering the certificate chains.  For instance, during

  => IMHO this is the right place to introduce interaction with AAA systems.
  If you'd like to use SEND in 802.11 hot spots, you have to talk about
  this!

 - 6.1 Delegation Chain Solicitation Message Format (wording)

      Identifier

         This 16 bit unsigned integer field acts as an identifier to
         help match advertisements to solicitations.  The Identifier

  => either "help to match" or "help matching" ?

 - 6.3 Trusted Root Option (comment)

  => you don't support two root certificates for the same root...
  I propose to add a name type where one can put a hash of the
  certificate. For the hash itself the objectDigest seems perfect.

 - 6.4 Certificate Option (clarification)

   Cert Type

      The type of the certificate included in the Name field.  This
      specification defines only one legal value for this field:

               1        X.509 Certificate

  => s/X.509/X.509v3/

 - same (wording)

   Pad Length

      The amount of padding beyond the end of the Certificate field but
      within the length specified by the Length field.  Padding MUST be
      set to zero by senders and ignored by receivers.

  => broken... I propose something like:

   Pad Length

      The number of padding octets beyond the end of the Certificate
      field but within the length specified by the Length field.
      Padding octets MUST be set to zero by senders and ignored by
      receivers.

 - same (clarification)

   Certificate

      When the Cert Type field is set to 1, the Certificate field
      contains an X.509 certificate [16].

  => s/X.509/X.509v3/
  BTW I don't understand why we should not put PKIX certificates?
  IKEv2 does this, and it can make interoperability between implementations
  less problematic.

 - 6.5 Router Authorization Certificate Format (comment)

   MUST consist of standard Public Key Certificates (PKC, in the sense
   of [11]) for identity from the trusted root shared with the host to

 => [11] (PKIX) doesn't use this term... IMHO the right reference is [12]
 and the introduction text of [12] about PKC and AC should be copied!

 - 6.5.1 Field Values (comment)

  => please reorder (acinfo.holder together, etc)

 - same (comment)

   acinfo.attributes

      This field MUST contain a list of prefixes that the router is
      authorized to route

  => I disagree: a router is not authorized to route a prefix, it is
  authorized to advertise/annonce a prefix. About routing perhaps
  it should be useful to authorize (or not) a router to be a default
  router?

 - same (comment)

      If the router is authorized only to route specific prefixes, the
      ipAddress values consist of IPv6 addresses in standard RFC 3513
      [13] prefix format.

  => my problem is that ipAddress can't encode prefix in RFC 3513 format
  (i.e., ipAddress can get a mask but not <address>/<prefix_len>).
  Please clarify, for instance with an example. RFC 3280 one is:
    For example, a name
    constraint for "class C" subnet 10.9.8.0 is represented as the octets
    0A 09 08 00 FF FF FF 00, representing the CIDR notation
    10.9.8.0/255.255.255.0.

 - 6.6  Processing Rules for Routers (comment)

   their trusted root.  When such advertisements are sent, their timing
   MUST follow the rules given for Router Advertisements in RFC 2461
   [6].  The only defined option that may appear is the Certificate
   option.  At least one such option MUST be present.  Router SHOULD
   also include at least one Trusted Root option to indicate the trusted
   root on which the Certificate is based.

  => the wording is too loose about what to do if the chain doesn't fit
  inside one advertisement message:
   - fragment DCA in place of distributing certs in DCAs (of course
     the second is better)
   - back to back DCAs for long chains
   etc.

 - 6.7  Processing Rules for Hosts (comment)

   o  IP Source Address is a unicast address.  Note that routers may use
      multiple addresses, so this address not sufficient for the unique
      identification of routers.

  => RA sources are always link-local for this reason. Should we enforce
  routers to use only link-local source for DCAs?

 - same (same)

   attachments to the network.  In order to use an advertisement for the
   verification of a specific Neighbor Discovery message, the host
   matches the key hash in acinfo.Holder.objectDigestInfo to the public
   key carried in the IPsec AH Authentication Data field.

  => so we have a good ID for public keys!

 - same (same)

   A host MUST send Delegation Chain Solicitations either to the
   All-Routers multicast address, if it has not selected a default
   router yet, or to the default router's IP address if it has already
   been selected.

  => note that this address is always a link-local (but not fe80::
  if we don't want to make some implementers kill themselves :-).

 - same (wording)

   When processing a possible advertisement sent as a response to a

  => When processing possible advertisements sent as responses to a

 - 7.1 The AH_RSA_Sig Transform (wording)

   IPsec DOI [4] Transform ID TBD <To Be Assigned by IANA>, however.

  => s/TBD//

 - 7.1.1 Reserved SPI Number (same)

   The AH_RSA_Sig MUST be only be used with the reserved SPI number TBD
   <To Be Assigned by IANA>.

  => s/TBD//

 - 7.1.2 Authentication Data Format (same)

   chosen transform.  For the AH_RSA_Sig transform, the format is as
   follows:                                                    ^^^^^

 => missing word? (at least poor wording)

 - 7.1.3 AH_RSA_Sig Security Associations (wording)

   CGA flag

      A flag that indicates whether or not the CGA property must be
      verified.

  => IMHO the "whether or not" wording should be improved, for instance:

   CGA flag

      A flag that indicates whether the CGA property must be or not be
      verified.

  (many occurrences)

 - 7.1.4 Replay Protection (comments)

   The format is 64
   bits, and the contents are the number of milliseconds since January
   1, 1970 00:00 UTC.

  => the millisecond unit is too small for data but not for ND. Perhaps
  we should add a rationale saying it is not a problem to have no support
  for more than one ND message per ms.

   If anti-replay has been enabled, receivers MUST be configured with an
   allowed Delta value and maintain a cache of messages received within
   this time period from each specific source address.

  => is it really important to support not-in-order messages? Reordering
  link-layers are not so frequent, and we talk about ND...

      Recommended default value for the allowed Delta is 3,600 seconds.

  => this is far too large, especially for a single mechanism.

   o  A packet that passes both of the above tests MUST be registered in
      the cache for the given source address.

  => it is too soon to register it in the cache: the packet should pass
  the AH signature check too.

   o  If the cache becomes full, the receiver SHOULD temporarily reduce
      the Delta value for that source address so that all messages
      within that value can still be stored.

  => this doesn't solve the problem but opens doors to DoS...

  I propose for not reordering link-layers (the reordering case can be
  supported with small modifs but this should be clearer):
   - a per-peer (using the source address of received messages as the index)
     cache entry with:
    * last received time stamp (TSlast)
    * date of reception of last message (RDlast)

   - when a message is received from a new peer (i.e., a new source),
     the packet is accepted if the timestamp is in the range:
     - Max_delta < RDnew - TSnew < + Max_delta
     An entry is created when the signature check passes.
     
   - when a message is received from a known peer, the time stamp (TSnew)
     is checked against the last valid message:
      TSlast + (RDnew - RDlast) x (1 - allowed_drift) < TSnew and
      TSnew < TSlast + (RDnew - RDlast) x (1 + allowed_drif)

  - parameters are max_Delta and allowed_drift (10% ?)

  For reordering link-layer (i.e., complete rules) we need:
   - max_link_layer_delay in the last rules
   - retain only the valid message with the higher timestamp.

 - 7.1.5 Processing Rules for Senders (comment)

   o  Additionally, if the use of CGA has been specified for the
      security association, the source address of the packet MUST be
      constructed as specified in [27].

  => move this up: AH construction needs to know addresses.

 - 7.1.6 Processing Rules for Receivers (comment)

   Packets that do not pass all the above tests MUST be silently
   discarded.

  => this is the place where to update the timestamp cache. Note that
  "silently discarded" should imply "doesn't update the cache"...

 - 7.2.1 Destination Agnostic Security Associations (comment)

   Security associations that use the SPI value specified in
   Section 7.1.1 MUST be identified solely by the SPI and protocol
   numbers, not by the destination IP address.

  => RFc 2401bis removed the protocol number (50 ou 51) too
  with a very carefull wording (ask Stephen Kent or grep the archive).

  - 8.1.1 Sending Secure Neighbor Solicitations (comment)

   The source address of the message MUST NOT be the unspecified
   address.  A Neighbor Solicitation sent as a part of Duplicate Address
   Detection MUST use as a source address the tentative address for
   which the Duplicate Address Detection is being run.

  => NO: NS used in DAD are recognized because they are sent from
  the unspecified source. You are specifying a new DAD protocol...

 - same (same)

   When an interface is
   initialized, a node MUST join securely-solicited-node multicast
   address corresponding to each of the IP addresses assigned to the
   interface.

  => we need to specify more: what source address for MLD joins for
  instance...

 - 8.3 Other Requirements (comment)

   Hosts that use stateless address autoconfiguration MUST generate a
   new CGA as specified in Section 4 of [27] for each new
   autoconfiguration run.

  => I disagree: nodes should have the choice between using a certified
  IID or a CGA based IID. My main name-server is a host and I don't
  want to use CGA for it for many reasons. Of course, I use stateless
  autoconfig even I've switched from EID64 IID to ::1 IID some months
  ago.

   It is outside the scope of this specification to describe the use of
   trusted root authorization between hosts with dynamically changing
   addresses.  Such dynamically changing addresses may be the result of
   stateful or stateless address autoconfiguration or through the use of
   RFC 3041 [9].  If the CGA method is not used, hosts would be required
   to exchange certificate chains that terminate in a certificate
   authorizing a host to use an IP address having a particular interface
   identifier.  This specification does not specify the format of such
   certificates, since there are currently a few cases where such
   certificates are required by the link layer and it is up to the link
   layer to provide certification for the interface identifier.  This
   may be the subject of a future specification.

  => this is not sound with the MUST of the previous paragraph.
  And not with all the CGA=yes/no in next sections...
  Please fix this and don't forget that mandatory encumbered technologies
  like CGA won't pass last calls (so don't make them mandatory).

 - 9.2.1 Sending Secure Router Advertisements (comment)

   The source address of the message MUST NOT be the unspecified
   address.

  => change to in "MUST be a link-local address".

 - 9.2.2 Receiving Secure Router Advertisements (same)

   If source address of the Router Advertisement message is the
   unspecified address, the message MUST be silently discarded.

  => same: "is not a link-local address".

 - 9.3.1 Sending Redirects (same)

   The source address of the Redirect message MUST NOT be the
   unspecified address.

  => same...

 - 9.3.2 Receiving Redirects (same)

   If source address of the Redirect message is the unspecified address,
   the message MUST be silently discarded.

  => same. BTW IMHO the link-local address requirement should be
  integrated into the 2.

 - 10. Co-Existence of SEND and ND (comment)

  => another solution is to make the legacy ND prefixes off-link.
  The wording should clarify it is not the case.

 - 10.1 Behavior Rules (wording)

   o  Nodes configured for SEND MUST listen to the solicited-node
      multicast address in addition to the securely-solicited-node
      multicast address.  The messages received on the solicited-node
      multicast address are unprotected, but the SEND node MUST respond
      to them as follows.                    ^^^ s/the/a/

      Upon seeing a Neighbor Solicitation for an address which is
      currently assigned to its own interface, the SEND node sends as a
                                               ^^^ s/the/a
      response a Neighbor Solicitation with the following contents:

 - same (comment)

  => the standard response to a DAD NS probe is a NA, can you
  explain the change?

 - same (spelling)

   o  Hosts configured for SEND MUST use SEND for all of their
      addresses, including link local addresses.

  => link-local

 - same (comment)

      Secure Router and Neighbor Advertisements MUST use a source
      address that satisfies the security properties outlined in Section

  => don't forget that RAs are sent from a link-local address.

 - same (wording)

   the other prefixes are on-link.  Thus, these hosts will request the
                                                                   ^^^ a
   router to route packets destined to a host in the other group.  The
   rules regarding Redirect messages above have been provided to ensure
   that the router performs its routing task and does not instruct the
        ^^^ a                                                      ^^^
   hosts to communicate directly.

 - 11. Performance Considerations (comment)

   Given that the IPv6 header is
   covered by the AH integrity protection, it is typically not possible
   to precompute solicited advertisements.

  => IMHO anti-replay stuff is enough to make precomputation impossible (:-).

 - 13.1 Threats to the Local Link Not Covered by SEND (comment)

   To protect against such attacks,
   link layer security MUST be used.  An example of such for 802 type
   networks is port-based access control [34].

  => can you explain how 802.1X or any link-layer security can help here?
  I claim that you have no way in the layer 2 or 3 themselves to protect
  the layer 2 - layer 3 address binding! The only thing that SEND gives
  is the attacker must be a node one trusts.

 - same (wording)

   Solicited Node Multicast Group for the address that they are claiming
   RFC 2461 [6].

  => missing word(s) between the two lines?

 - 13.2.5 Replay Attacks (comment/wording)

   Since most SEND nodes are likely to use fairly coarse grained
   timestamps, as explained in Section 7.1.4, this may affect some
   nodes.

  => a millisecond is not so coarse grained. IMHO the statement
  is more about the fairly large one hour delta...

 - 13.3 Attacks against SEND Itself (comment)

   Security associations based on the use of asymmetric cryptography can
   be vulnerable to Denial-of-Service attacks, particularly when the
   attacker can guess the SPIs and destination addresses used in the
   security associations.  In SEND this is easy, as both the SPIs and

  => please avoid the page break here.

 - same (wording)

   The Authorization Delegation Discovery process may also be vulnerable
   to Denial-of-Service attacks.  An attack may target a router by
   request a large number of delegation chains to be discovered for

  => s/request/requesting/ or s//requiring/ ?

 - 14. IANA Considerations (wording)

   This document defines two new Neighbor Discovery [6] options, which

  => s/two/three/

 - Normative References (update)

   [1]   Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 2373, July 1998.

  => RFC 3513, April 2003.

 - same (presentation)

   [18]  National Institute of Standards and Technology, "Secure Hash
         Standard", FIPS PUB 180-1, April 1995, <http://
         www.itl.nist.gov/fipspubs/fip180-1.htm>.

  =>     Standard", FIPS PUB 180-1, April 1995,
         <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.

 - Informative References (update)

   [26]  Kent, S., "IP Encapsulating Security Payload (ESP)",
         draft-ietf-ipsec-esp-v3-04 (work in progress), March 2003.

  => -05, April 2003

Thanks

[email-masked]

PS: I can't find how to verify certified addresses, even for routers.
(this is not in 9.2)