Network Working Group G. Daley Internet-Draft Monash University CTIE Expires: May 30, 2005 November 29, 2004 Nonce response matching for router reachability in IPv6 draft-daley-dna-nonce-resp-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 30, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract IPv6 Neighbour Discovery does not provide a mechanism which allows a node to match its router solicitations to advertised responses. The Nonce Neighbour Discovery Option was originally defined for Secured Neighbour Discovery. This draft describes the use of the Nonce Option for generic router reachability testing. Daley Expires May 30, 2005 [Page 1] Internet-Draft Nonce response matching November 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Necessity of nonces . . . . . . . . . . . . . . . . . . . . . 3 3. SEND response matching . . . . . . . . . . . . . . . . . . . . 4 4. Sending Nonce Options for router response . . . . . . . . . . 4 5. Router responses to unicast destinations . . . . . . . . . . . 4 6. Nonces and unspecified source addresses . . . . . . . . . . . 5 7. Duplicate MAC Frames . . . . . . . . . . . . . . . . . . . . . 5 8. Deferred responses . . . . . . . . . . . . . . . . . . . . . . 6 9. Multiple nonce response . . . . . . . . . . . . . . . . . . . 6 10. Interaction with legacy routers . . . . . . . . . . . . . . . 6 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 12. Security Considerations . . . . . . . . . . . . . . . . . . . 7 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 14.2 Informative References . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 A. Implementation status . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Daley Expires May 30, 2005 [Page 2] Internet-Draft Nonce response matching November 2004 1. Introduction Secured Neighbour Discovery (SEND) defines an extension to IPv6 Neighbour Discovery which supports signed message exchanges between neighbours, in order to secure neighbour cache construction [2][3]. In SEND, nodes must copy a Nonce Option from a solicitation into a responding advertisement, in order to identify that an advertisement is fresh and generated due to a particular solicitation. This property of unambiguous router response detection is useful when detecting network reachability changes, and may be used as part of a configuration change detection scheme, even for non-SEND hosts and routers. 2. Necessity of nonces Responses to Router Solicitations are often multicast (section 6.2.6 of [2]). Although procedures for responding to solicitations require transmission of all configuration options in solicited Router Advertisements, In many cases the contents of Router Advertisements will not substantially change between solicited and unsolicited messages. Therefore it is impossible for a host to determine between a solicited and an unsolicited RA. Even if a host can tell between multicast solicited and unsolicited router advertisements, it may not know which host solicited it, if multiple nodes exist on the same link. For example, a host may believe that its own router solicitation was received and processed to create the RA, even if its solicitation was lost. Therefore some form of response matching is valuable. It is possible for a router to identify either the origin of the solicitation by its address, or to match a chosen random number from the solicitation. While each approach is viable, both have have drawbacks. Address based matches require addresses to already be configured on the solicitor, whereas random number matching schemes have the potential for solicitation identifier collision if the matching space is too small. SEND nonces are an existing non-address dependent response matching mechanism which allow a host to ask that a router if their solicitation was seen. They provide a large enough identifier space to ensure very low numbers of identifier collisions, and may be used even without completed address configuration on solicitors. Daley Expires May 30, 2005 [Page 3] Internet-Draft Nonce response matching November 2004 3. SEND response matching Existing SEND nodes will send Nonce Options in response to options received in solicitations. A nonce received in a signed SEND message is therefore a response to a solicitation, if the nonce contained in the option matches. This occurs regardless of whether the response is unicast or multicast, a Neighbour Advertisement or a Router Advertisement. 4. Sending Nonce Options for router response In order to provide response matching for hosts performing router discovery, hosts MAY send Nonce Options containing a random number as described in [3] section 5.3.2 and 5.3.3, even if it has not been configured to use SEND. When receiving a Nonce Option in an RS message which causes an advertisement, a router SHOULD copy the nonce into the response RA in order to provide response matching for solicitors. Upon reception of a Nonce Option with a random number matching that which was transmitted, a host knows that the router received the message, and that bidirectional packet flow was successful. When processing a SEND host's solicitation, a router can send a Nonce Option in responding Router Advertisements, even if it cannot sign the message, or prove its right to be a router. This will not affect the security of the message, still resulting in an unsecured neighbour cache entry, but provides analogous router reachability proofs to SEND in the absence of a SEND capable router. When a SEND router processes a Nonce Option in an unsecured RS, it SHOULD include the Nonce Option into a secured Router Advertisement if it responds to the solicitation. If the length of the received Nonce Option in this case is more than 16 Octets, the router MUST NOT transmit the responding nonce. In most cases, the additional load of transmitting 16 extra solicited octets and performing a hash over these values is unlikely to be problematic. In order to protect SEND resources though, priority MAY be given to computation of responses to soliciting SEND nodes. 5. Router responses to unicast destinations In most cases, it is possible to identify that a Router Advertisement is solicited if received at a unicast address, since unicast Router Advertisements are typically only sent in response to solicitation. Daley Expires May 30, 2005 [Page 4] Internet-Draft Nonce response matching November 2004 It may not be possible to identify if the received Router Advertisement is a fresh one though. In order to provide a weak liveness proof, it is valuable to include received nonces in Router Advertisements. This doesn't prove message authenticity, origin or authorization, although it requires a live responder. Since the router has a choice to respond either unicast or multicast, where the solicitor's source address is specified in the Router Solicitation, a host does not know if it is going to receive a unicast response. In this case, a host SHOULD send a Nonce Option in its solicitation anyway. In order to prove the freshness of its response, a router SHOULD include a received Nonce Option into a Router Advertisement, even if it is unicast. 6. Nonces and unspecified source addresses Except for on Duplicate Address Detection (DAD) Neighbour Solicitations (NSs), SEND is not used where the source IPv6 address of a message is unspecified [4][3]. Responses to router solicitations from unspecified source addresses are therefore not typically covered by SEND nonces. Since any RA response to an unspecified address is multicast, this is exactly where Nonce Options would be useful. In detection of network attachment, it is important not to harm any existing hosts when detecting connection to a new network. In performing router discovery it is therefore possible that hosts will treat existing addresses as unconfirmed, and transmit solicitations from unspecified addresses. Nonce Options in packets transmitted from unspecified source addresses allow response matching for hosts which solicit on a particular link, even though they do not yet have any non-tentative addresses. Hosts SHOULD send Nonce Options in Router Solicitations from the unspecified address, even though these cannot be protected using SEND. Routers SHOULD respond to Nonce Options from the unspecified address, this aids in response matching from tentatively addressed hosts. 7. Duplicate MAC Frames In wireless environments with MAC layer acknowledgments, it is possible that ACKs at the MAC layer are not received for packets, Daley Expires May 30, 2005 [Page 5] Internet-Draft Nonce response matching November 2004 causing successful transmission of the same frame multiple times. Where this occurs for Router Solicitations, it is possible that a host can cause multiple Router Advertisements to be sent based on a single solicitation being enqueued at the transmitter. In order to ensure that a particular solicitation packet is not already responded to, a router MAY keep a small cache of received nonces (or nonces and public keys for SEND routers), to ensure that responses aren't transmitted multiple times for the same solicitation. This cache SHOULD time out quickly (possibly dependent on the MAC) in order to ensure that the number of Nonce collisions (where nodes each choose the same nonce) is small. 8. Deferred responses In section 6.2.6 of the IPv6 Neighbour Discovery RFC [2], cancellation of a Router Advertisement responding to solicitation is described, considering that the next scheduled Router Advertisement is sufficiently close. Where a router decides to defer responding to the next scheduled multicast RA, it MAY include the solicitor's Nonce Option into the scheduled advertisement. 9. Multiple nonce response Particularly where multiple solicitations have been deferred due to close scheduling of a multicast RA, a router MAY include more than one Nonce Option into a multicast Router Advertisement. This allows the router to indicate reception of multiple Router Solicitations with only one Router Advertisement. In order to prevent resource depletion attacks, routers SHOULD ensure that only limited resources are used for storage of Nonce Options. In order to limit resource utilization, and prevent unfair nonce buffer utilization, Nonce Options of greater than 16 octets SHOULD NOT be stored in this manner and cannot be deferred for multiple nonce response. This may mean that no nonce response is given for large nonces, if resources are otherwise unavailable. 10. Interaction with legacy routers Legacy routers which do not recognise Nonce Options will not provide responding nonces when router advertising. Daley Expires May 30, 2005 [Page 6] Internet-Draft Nonce response matching November 2004 A host SHOULD not assume that a router is sending an unsolicited Router Advertisement if a received multicast advertisement contains no Nonce Options and the solicitor has never seen a nonce from that router before. In this case, legacy procedures (i.e. guesswork) or ND probing may be required to confirm reachability with a router. 11. IANA Considerations This document defines another use case for an existing allocated IPv6 Neighbour Discovery Option. No IANA action is needed. 12. Security Considerations It is important to consider that Nonce Options were designed for security purposes within a framework which supplied robust message authenticity and authorization. Using these nonces in unsecured messages will not provide any additional security over messages without nonces. Additional procedures defining interactions between SEND and non-SEND nodes are outlined above. Since SEND was not designed to interact with non-SEND nodes using its option formats, there is a possibility that SEND nodes may interpret Nonce Option presence in non-SEND RS or RA incorrectly. As there are no known field deployments of SEND today, the effect of this issue is unknown at this time. Inclusion of additional text into a SEND message may cause additional computation on a router, at limited computational cost to the soliciting hosts. SEND routers MAY make use of deferred transmissions and multiple nonce responses to mitigate this effect, potentially reducing the number of signatures to be performed, as well as the number of packet and bit transmissions. As mentioned above, it may be possible to separate the responses to nonces from secured and unsecured devices. Responses to secured devices MAY be given priority in order to prevent resource starvation for SEND Routers. The addition of generic text (a reflected Nonce Option) for inclusion into SEND Router Advertisement messages lowers the cost, and potentially widens the scope for chosen-plaintext attacks on SEND Daley Expires May 30, 2005 [Page 7] Internet-Draft Nonce response matching November 2004 routers. Currently this is limited due to an SHA-1 hash over the SEND message contents. Nevertheless, SEND Routers SHOULD monitor their secured and unsecured nonce reception, and SHOULD log unusually high levels of nonce activity to the administrator. 13. Acknowledgments 14. References 14.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [3] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 (work in progress), July 2004. 14.2 Informative References [4] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. Author's Address Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 4655 EMail: greg.daley@eng.monash.edu.au Appendix A. Implementation status A simple implementation of this operation without SEND is under development for RADVD. Currently multiple nonce responses in a single RA are not supported. Daley Expires May 30, 2005 [Page 8] Internet-Draft Nonce response matching November 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Daley Expires May 30, 2005 [Page 9]