Internet DRAFT - draft-jokela-hip-service-discovery
draft-jokela-hip-service-discovery
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]
