Francis Dupont writes and Jari Arkko responds: > - 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 , 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 > . > > => 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, www.itl.nist.gov/fipspubs/fip180-1.htm>. > > => Standard", FIPS PUB 180-1, April 1995, > . 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. -------------- Pekka Nikander: Issue 16 is all editorial. Some of the remarks have been obsoleted by other changes to the draft, and the others have now been applied with the exception of one comment, which I am discussing privately with Jari and Francis. The details of the issue are available at http://www.arkko.com/publications/send/issues/issue16.txt The comments to the ND overview section were quite extensive, leading to (at least almost) substantial changes. Therefore I am including the new text here: The NDP messages are always meant to be used within a link, and never intended to leak outside of it. The destination and source addresses used in these messages are as follows: o Neighbor Solicitation: The destination address is either the solicited-node multicast address, a unicast address, or an anycast address. The source address is either the unspecified address (in DAD) or a unicast address assigned to the sending interface. In a typical case, the source address is equal to the source address of the outgoing packet, locally triggering the need to send the solicitation. o Neighbor Advertisement: The destination address is either a unicast address or the all nodes multicast address [13]. The source address is a unicast address assigned to the sending interface. o Router Solicitation: The destination address is typically the all routers multicast address [13]. The source address is either the unspecified address or a unicast address assigned to the sending interface. An unspecified source address does not have any special semantics; it is just an optimization for startup. o Router Advertisement: The destination address can be either a unicast or the all nodes multicast address [13]. The source address is a link-local address assigned to the sending interface. o Redirect: This message is always sent 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 [13] dictate that anycast, or multicast addresses may not be used as source addresses. If the source address is an unspecified address, it is impossible to send a Redirect, since the unspecified address is forbidden as the destination address. Therefore, the destination address must always be a unicast address. The source address is a link-local address assigned to the sending interface. Comments? [13] is RFC 3513. Once I get the one remaining comment resolved, I will send another e-mail, and close the issue, unless there are further comments. -------------- -------------- -------------- --------------