Subject: Re: review of draft-ietf-send-ipsec-01.txt (editorials)

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Jul 2003 15:40:26 +0300

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

Agree.

 >  - 2. Terms (spelling)
 >
 >       some other parameters using a one-way hash function.
 >
 >   => s/a/an/ ?

Hmm... No.

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

Right. Should be fixed.

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

Yes, for clarity it needs to be here. How about this: we modify
the text as follows: "This section is not normative, and where the
original ...".

 >  - same (wording)
 >
 >    header consisting of ICMPv6 header and ND message-specific data, and
 >                        ^ an

Ok.

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

Agreed. Good suggestions!

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

Ok.

 >   => 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).

Thanks. This is very useful information.

 >  - 6. Authorization Delegation Discovery (wording)
 >
 >    Since the newly-connected node likely can not communicate off-link,
 >
 >   => s/the/a/ ?

I think the previous paragraph introduced this node, so "the"
is fine.

 >  = 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/ ?

Yes for the first case, not sure about the second.

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

Yes.

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

Ok.

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

Ok.

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

Ok.

 >  - 6.5.1 Field Values (comment)
 >
 >   => please reorder (acinfo.holder together, etc)

Ok.

 >  - 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 :-).

Right. Should be clarified that the message should be sent to the
link-local address of the router.

 >  - same (wording)
 >
 >    When processing a possible advertisement sent as a response to a
 >
 >   => When processing possible advertisements sent as responses to a

Right.

 >  - 7.1 The AH_RSA_Sig Transform (wording)
 >
 >    IPsec DOI [4] Transform ID TBD <To Be Assigned by IANA>, however.
 >
 >   => s/TBD//

Yes.

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

Yes.

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

"is the following" is better?

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

Yes. Thanks.

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

Ok.

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

Ok.

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

Ok.

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

Ok.

 >  - 9.3.1 Sending Redirects (same)
 >
 >    The source address of the Redirect message MUST NOT be the
 >    unspecified address.
 >
 >   => same...

Ok.

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

Ok.

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

Ok.

 >  - same (spelling)
 >
 >    o  Hosts configured for SEND MUST use SEND for all of their
 >       addresses, including link local addresses.
 >
 >   => link-local

Yes.

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

Or maybe "that routers perform their ..."

 >  - same (wording)
 >
 >    Solicited Node Multicast Group for the address that they are claiming
 >    RFC 2461 [6].
 >
 >   => missing word(s) between the two lines?

Yes. I think its "for their addresses".
 >  - 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.

I'll see if there's something for this in xml2rfc...

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

Requesting, I think.

 >  - 14. IANA Considerations (wording)
 >
 >    This document defines two new Neighbor Discovery [6] options, which
 >
 >   => s/two/three/

Right.

 >  - Normative References (update)
 >
 >    [1]   Hinden, R. and S. Deering, "IP Version 6 Addressing
 >          Architecture", RFC 2373, July 1998.
 >
 >   => RFC 3513, April 2003.

Ah, progress!

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

Thanks.

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

Ok.

--Jari

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 09 Jul 2003 17:30:15 +0200

=> fine.

   
=> IMHO it is (even in French the "is as follows" is not so good :-).

Thanks

[email-masked]

PS: I've detected an ASN.1 error (needed tag) when I read the second
document (CGA). I believe the issue is in both so please check this part
ASAP.
(the issue is SendKeyInformation is a SEQUENCE of two optional
elements which have the same type so without a tag a decoder cannot
decide which element it gets).
--------------------------------------------------------------------
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
--------------------------------------------------------------------