Network Working Group P. Jokela Internet-Draft J. Melen Expires: December 20, 2006 J. Ylitalo Ericsson Research NomadicLab June 18, 2006 HIP Service Discovery draft-jokela-hip-service-discovery-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 December 20, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo specifies a service discovery mechanism to be used with the Host Identity Protocol (HIP). Jokela, et al. Expires December 20, 2006 [Page 1] Internet-Draft HIP Service Discovery June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Terminology . . . . . . . . . . . . . . . . . 4 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Service Discovery Mechanism . . . . . . . . . . . . . . . 5 3.1. Different Discovery methods . . . . . . . . . . . . . . . 5 3.2. On-the-Path Service Discovery . . . . . . . . . . . . . . 5 3.2.1. Passive discovery . . . . . . . . . . . . . . . . . . 6 3.3. Regional Service Discovery . . . . . . . . . . . . . . . . 7 4. Parameter and Packet Formats . . . . . . . . . . . . . . . . . 9 4.1. Service Discovery Packet . . . . . . . . . . . . . . . . . 9 4.2. Service Announcement Packet . . . . . . . . . . . . . . . 9 5. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Initiating an HIP Service Discovery . . . . . . . . . . . 11 5.1.1. Using Regional Service Discovery . . . . . . . . . . . 11 5.1.2. Using On-Path Service Discovery . . . . . . . . . . . 11 5.2. Processing an Incoming SD Packet . . . . . . . . . . . . . 12 5.3. Processing an Incoming SA . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Normative References . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Jokela, et al. Expires December 20, 2006 [Page 2] Internet-Draft HIP Service Discovery June 2006 1. Introduction In the Host Identity Protocol Architecture [5], hosts are identified with public keys. The Host Identity Protocol [6] base exchange allows any two HIP-supporting hosts to authenticate each other and to create a HIP association between themselves. During the base exchange, the hosts generate a piece of shared keying material using an authenticated Diffie-Hellman exchange. The Host Identity Protocol (HIP) Registration Extension [4] document specifies how a HIP host can register to use a service provided by another HIP node, typically a middle-box, or a server. However, the registration specification does not specify how a HIP host can locate such nodes providing services. This document specifies a method that can be used by HIP hosts to find nodes in the local network that are providing services for HIP hosts. A HIP host can discover the available services in two ways. In the first case, the service provider on the end-to-end communication path listens to traffic. Once the HIP host sends either I1, UPDATE or Service Discover Packet (SDP) message to the peer node, the service provider replies back to the HIP host with a Service Announcement Packet. In the second case, the HIP host may initiate the service discovery by sending a Service Discovery packet to the network, either using a link-local or site-local address. This makes it also possible to find service providers which are not located on the packet forwarding path. This document describes only the service discovery. How the host registers to services is defined in the "HIP Registration Extension" [4] specification. Jokela, et al. Expires December 20, 2006 [Page 3] Internet-Draft HIP Service Discovery June 2006 2. Terms and Definitions 2.1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [1]. 2.2. Definitions IP_TTL: The TTL in IPv4 or hop limit in IPv6 field in the IP header. SDP_MAX_TTL: The maximum TTL that is used in on-path discovery mechanism. The value is implementation specific. SD_MAX_WAIT: The maximum time the host waits in the SD_SENT state after sending a Service Discovery message to the network. Jokela, et al. Expires December 20, 2006 [Page 4] Internet-Draft HIP Service Discovery June 2006 3. The Service Discovery Mechanism The provided services can vary from services that are located at the end-host to services that are provided by middle-boxes, e.g. Rendezvous type services. Depending on the service the HIP host is willing to locate, it may use different service discovery scopes. 3.1. Different Discovery methods A HIP host can initiate a service discovery with different target scopes. It can detect services that are provided on the forwarding path to a certain host located in another network (e.g. towards its own Rendezvous Server), or it can detect services in a certain network area. The figure below illustrates a simplified example of a Service Discovery Packet (SDP) and Service Announcement Packet (SAP) exchange. The SD packet may contain the REG_INFO parameter where the sending host can define the services that it wants to get information about. In the SA packet message, the REG_INFO is mandatory containing the services provided by the sending node. Additionally, the SA packet may contain R1-packet parameters, allowing the requesting HIP host to continue the Base Exchange and service registration directly with an I2 packet. HIP host Service Provider SDP: [REG_INFO] --------------------------> verify conditions create response SAP: REG_INFO [+ R1 parameters] <------------------------- remain stateless possible service registration completion I2 ---------------------------> R2 <--------------------------- 3.2. On-the-Path Service Discovery A HIP host that is willing to locate service providers on the end-to- end packet forwarding path initiates a service discovery process by generating an SD packet with an optional REG_INFO parameter. The destination IP address of the SD packet is set to the IP address of the peer node towards which the service discovery is done. Jokela, et al. Expires December 20, 2006 [Page 5] Internet-Draft HIP Service Discovery June 2006 The HIP host sets the local IP_TTL value to one, and sets the IP packets TTL to this value. When it gets the ICMP Time Exceeded response, it increases the IP_TTL value by one, sets the TTL in the IP packet to this new value, and resends the SD packet to the network. This continues, until the value of the IP_TTL exceeds the SDP_MAX_TTL value, or the HIP host has received SA packet(s) from service providers. Each host on the path that is providing services, responds to an incoming request with an SA packet containing all the services it provides, or if the SD packet contained the REG_INFO parameter, only the intersection of provided and requested services. In addition to the REG_INFO parameter, the SA packet MAY optionally contain all parameters that are provided in an R1 packet. This enables the Initiator to use that packet as an R1 packet and continue base exchange and service registration with the service provider by sending an I2 packet to it. If successful, the R2 packet from the service provider finalizes the connection setup and service registration. 3.2.1. Passive discovery In some cases, the HIP host may not want to actively query services. One such a situation is when a mobile host moves behind a mobile router. It is not feasible to do mobile router discovery every time the host moves. In this case it is better to let the service providing node to send the service announcement based on passing by HIP packets, for example I1 or UPDATE packet. The figure below shows a passive service discovery message exchange between the HIP host and the service provider. The outgoing I1 packet is sent to peer HIP host, and the service providing node MAY verify the I1 source HIT and compare it to the nodes it is currently serving. If that particular host is not yet served, the service provider MAY send an SA packet to the original I1 sender containing information about the services it can provide. NOTE: In this case, the Initiator does not have any state related to the incoming SA packet and the state machine must allow it to accept and process such a packet. Jokela, et al. Expires December 20, 2006 [Page 6] Internet-Draft HIP Service Discovery June 2006 HIP host Service Provider Destination Host I1: srcHIT, dstHIT ----------------------------------/\-----------> - check passing I1 packet - verify conditions - verify server's "served nodes" information - create response, if needed SAP: REG_INFO [+ R1 parameters] <------------------------- remain stateless possible service registration completion I2 ---------------------------> R2 <--------------------------- 3.3. Regional Service Discovery When the HIP host is trying to discover services in a certain network region, it sends one or more SD packets to the network multicast addresses. It creates an SD packet, with an optional REG_INFO parameter, sets the destination HIT to NULL (all zeros), and selects the destination multicast / broadcast address depending on the region from where services are discovered. The service providing nodes respond to such a requests with an SA packet, where the source HIT is the server's HIT, destination HIT the requesting HIP node's HIT, and source IP address the server's IP address. The REG_INFO parameter contains services provided by the server, and if the SD packet contained the REG_INFO parameter, only the intersection of services provided and requested. The SA packet can optionally contain R1 parameters that the requesting node can use for faster Base Exchange and service registration. In IPv6, the host can use the following destination addresses (RFC4291 [2]): All nodes multicast address FF02:0:0:0:0:0:0:1 (link-local) All routers multicast address FF02:0:0:0:0:0:0:2 (link-local) All routers multicast address FF05:0:0:0:0:0:0:2 (site-local) Typically, when a host is looking for a server providing rendezvous service, it must be aware that the server is not necessarily on the same link. In that case it can use the "All routers multicast" site- Jokela, et al. Expires December 20, 2006 [Page 7] Internet-Draft HIP Service Discovery June 2006 local address as the destination address of the SD packet. In IPv4, the service discovery is limited to local link, where the following destination address is used (RFC0919 [3]): All nodes on the link 255.255.255.255 Jokela, et al. Expires December 20, 2006 [Page 8] Internet-Draft HIP Service Discovery June 2006 4. Parameter and Packet Formats The Service Discovery defines one new HIP packet to be used for searching services provided by hosts at the local link, or at the local site. The service information is transferred in the REG_INFO parameter, defined in [4]. 4.1. Service Discovery Packet The Service Discovery packet resembles the I1 packet. In basic form, when the HIP host does not want to send any specific information about the services it is looking for, the SD packet contains only the HIP header information. However, in some cases the HIP host may want to send information about the service it is searching for by adding a REG_INFO parameter in the packet, listing the services of which it is willing to receive offers. The HIP header values for the SD packet: Header: Packet Type = TBD SRC HIT = Initiator's HIT DST HIT = NULL IP ( HIP ( [ REG_INFO ] ) ) Valid control bits: none 4.2. Service Announcement Packet The Service Announcement packet is sent by a server as a response to the SD packet (active service detection) or as a response to a passing-by I1 or UPDATE packet (passive service detection). The HIP header values and packet format for the SA packet (with connection initialization parameters): Jokela, et al. Expires December 20, 2006 [Page 9] Internet-Draft HIP Service Discovery June 2006 Header: Packet Type = TBD SRC HIT = Service Provider's HIT DST HIT = Initiator's HIT IP ( HIP ( [ R1_COUNTER, ] PUZZLE, DIFFIE_HELLMAN, HIP_TRANSFORM, HOST_ID, [ ECHO_REQUEST, ] REG_INFO, HIP_SIGNATURE_2 [, ECHO_REQUEST ] ) ) The HIP header values and packet format for the SA packet (without connection initialization parameters): Header: Packet Type = TBD SRC HIT = Service Provider's HIT DST HIT = Initiator's HIT IP ( HIP ( REG_INFO ) ) Valid control bits: none If the sending host included the connection initialization parameters in the SA packet, then the sending host MUST considers the sent SA packet as a sent R1 packet. All parameters (except the REG_INFO parameter) are described in the "Host Identity Protocol" [6] document. The REG_INFO parameter is defined in the "HIP Registration Extension" [4] document. Jokela, et al. Expires December 20, 2006 [Page 10] Internet-Draft HIP Service Discovery June 2006 5. Packet Processing 5.1. Initiating an HIP Service Discovery When a HIP host is willing to receive service information from the network, it creates an SD packet to be sent to the local network. The SD packet header consists of the HIP header, where the destination HIT field is set to NULL (all zeros). The source HIT is the sending node's HIT. The destination IP address can be selected from the set defined in Section 3. To which address the packet is sent, depends on the IP version used in the network and type of the service that the host is requesting: The host may use heuristics to decide if a certain service is provided by a host or by a router and send the packet using an appropriate destination address. The sending host moves to an SD_SENT state, which resembles the state of I1_SENT ([6]). The difference is that in SD_SENT state, the host must handle and store the required service information provided by the server, and it must make the decision to continue the Base Exchange by sending I2, or just wait for additional SAPs, until the SD_MAX_WAIT timer expires. 5.1.1. Using Regional Service Discovery 1. A host creates an SD packet, sets the destination HIT to NULL (all zeros), and its local HIT as the source HIT. It MAY insert a list of services that it is interested in into an optional REG_INFO parameter. 2. The host decides the area that is needed to be probed for services. The host can select between link-local services (IPv4 and IPv6), on-path services (IPv4 and IPv6), or site-local services (IPv6 only). 3. If the desired area scanned is either link- or site-local, the host inserts the respective destination IP-address to the packet and sends it to the network. 5.1.2. Using On-Path Service Discovery When the host is willing to probe for services on a packet forwarding path (e.g. towards its home rendezvous server), it starts the On-the- Path Service Discovery Process. Jokela, et al. Expires December 20, 2006 [Page 11] Internet-Draft HIP Service Discovery June 2006 1. A host creates an SD packet, sets the destination HIT to NULL (all zeros), and its local HIT as the source HIT. It MAY insert a list of services that it is interested in into an optional REG_INFO parameter. 2. The host initializes the IP_TTL counter to one, and sets the value in to the IP header. The packet's destination IP address must be such that it is routed outside the network. The host sends the packet towards the destination host. 3. If an SA packet is received from the network, the host may have found an service provider on the path. The packet is processed according to Section 5.3. The Service Discovery process may continue simultaneously, unless the host decides otherwise. 4. When the host receives an ICMP Time Exceeded message from the network, it increases the IP_TTL counter, verifies that the counter hasn't exceeded the SDP_MAX_TTL limit, and resends the packet to the same address. 5.2. Processing an Incoming SD Packet A host receiving an SD packet, MUST drop the packet if the IP_TTL has exceeded and reply with ICMP Time Exceeded. 1. The receiver of the SD packet MUST verify that the source IP address is a unicast address. If it is not, the packet is silently dropped. 2. The receiver of the SD packet MUST verify that the destination HIT is NULL. If this is not the case, the packet is forwarded if IP_TTL has not been exceeded. If the IP_TTL was exceeded, the receiver either send's ICMP Time Exceeded as a reply to a SD packet if the IP header contained a unicast source address or silently drop's the SD packet if the source address was not unicast address. NOTE: if the HIP host is trying to find out services provided by a known host, it can send an SD packet to the host with the correct destination HIT as defined in [4]. 3. The receiver MAY verify if local policy allows it to respond to such a service discovery request. If it does not, the packet is forwarded if IP_TTL has not been exceeded. If the IP_TTL was exceeded, the receiver either send's ICMP Time Exceeded as a reply to a SD packet if the IP header contained a unicast source address or silently drop's the SD packet if the source address was not unicast address. Jokela, et al. Expires December 20, 2006 [Page 12] Internet-Draft HIP Service Discovery June 2006 4. If the request in the SD packet doesn't contain the REG_INFO parameter, the receiver creates an SA packet containing all the services that can be provided for the requesting host in the enclosed REG_INFO parameter. The destination IP address of that SA packet is the sender of the original SD packet, source IP address is the one of IP addresses on that interface from where the SD packet arrived, Initiator HIT is the HIT of the SD packet sender, and the Responder HIT is the hit of itself. 5. The service provider waits a random time (between zero and TBD maximum time) before sending the SA packet to the requesting host. This prevents all SAs from different service providers arriving at the same time to the requesting host. 6. The service provider MUST rate limit the outgoing SA packets, to avoid reflection attacks. 7. Note: It is possible that the source IP address in the SD packet is spoofed. In this case, the Service Announcement packet is sent to a host that has not requested it. 5.3. Processing an Incoming SA When a host has sent either an SD, I1 or UPDATE packet, it may receive an SA packet announcing services. 1. The incoming SA packet is verified: The destination HIT in the SA packet must match the local HIT and the destination IP address MUST be a unicast address. Otherwise the packet is silently dropped. 2. The host may be in 1. SD_SENT state, if it has initiated an active service discovery process. 2. UNESTABLISHED state, if the SA packet is a result of passive service detection or the SA has been sent unsolicited. 3. If the host is in SD_SENT state, it verifies the incoming SA packet, and stores the required information from the incoming packet. 4. If the host is not in SD_SENT state, the SA packet is a result of passive service detection, or the service provider has sent it unsolicited. In that case the host MAY store the required information from the incoming packet depending on its own policy. NOTE: A service provider can announce services without any Jokela, et al. Expires December 20, 2006 [Page 13] Internet-Draft HIP Service Discovery June 2006 trigger. This MAY open the HIP host that receives the SA packet to an attack where the attacker can establishes security association with the HIP host. To protect from this kind of attack, the HIP host different alternatives. In the first case, the host may have access control list (ACL) for HITs of the trusted service providers. In the second case, the host may accept incoming unsolicited SA packets during TBD milliseconds after each outgoing I1 or UPDATE packet. Or the host MAY decline to send I2 message as a reply to an unsolicited SA packet. 5. If the incoming SA packet contains all R1 parameters, the host may choose to continue base exchange and service registration with the service provider. If the host did not receive all R1 parameters the host MUST start the registration by sending I1 to service provider. The host MAY continue all other tasks meanwhile registering to the service discovered from the received SA packet. 6. If the host chooses to register to use a service from that service provider, it creates and sends an I2 packet with a service registration parameter (REG_REQUEST) as described in [4], forks the processing and goes to the I2_SENT state to wait for the R2 packet from the server. Jokela, et al. Expires December 20, 2006 [Page 14] Internet-Draft HIP Service Discovery June 2006 6. Security Considerations When a HIP host receives a REG_INFO parameter from the network, either as a result of an active service discovery, or passively, it cannot know if the service provider is trustworthy. The SD packet is unprotected, which makes it vulnerable. An attacker can modify the packet, or an attacker can send the packet using someone else's IP address and HIT. Jokela, et al. Expires December 20, 2006 [Page 15] Internet-Draft HIP Service Discovery June 2006 7. IANA Considerations This document defines additional packets for the Host Identity Protocol [6]. o SD packet is TBD. o SA packet is TBD. 8. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [3] Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC 919, October 1984. [4] Laganier, J., "Host Identity Protocol (HIP) Registration Extension", draft-ietf-hip-registration-02 (work in progress), June 2006. [5] Moskowitz, R. and P. Nikander, "Host Identity Protocol Architecture", draft-ietf-hip-arch-03 (work in progress), August 2005. [6] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-05 (work in progress), March 2006. Jokela, et al. Expires December 20, 2006 [Page 16] Internet-Draft HIP Service Discovery June 2006 Authors' Addresses Petri Jokela Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 Email: petri.jokela@nomadiclab.com Jan Melen Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 Email: jan.melen@nomadiclab.com Jukka Ylitalo Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 Email: jukka.ylitalo@nomadiclab.com Jokela, et al. Expires December 20, 2006 [Page 17] Internet-Draft HIP Service Discovery June 2006 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 (2006). 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. Jokela, et al. Expires December 20, 2006 [Page 18]