HIP H. Tschofenig
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track D. Wing
Expires: December 23, 2007 Cisco
June 21, 2007
Utilizing Interactive Connectivity Establishment (ICE) for the Host
Identity Protocol (HIP)
draft-tschofenig-hip-ice-00.txt
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 23, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes how the Interactive Connectivity
Establishment (ICE) methodology can be used for the Host Identity
Protocol (HIP) to determine whether end-to-end communication is
possible. ICE makes use of the Session Traversal Utilities for NAT
(STUN) protocol in addition to mechanisms for checking connectivity
between peers. After running the ICE the two HIP end points will be
Tschofenig & Wing Expires December 23, 2007 [Page 1]
Internet-Draft HIP-ICE June 2007
able to communicate directly or through a relay via Network Address
Translators (NATs), Network Address and Port Translators (NAPTs) and
firewalls .
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 5
1.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 5
1.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . . 5
1.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 6
1.5. Security for Checks . . . . . . . . . . . . . . . . . . . 6
1.6. Concluding HIP-ICE . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 8
5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 8
6. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 8
7. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 9
8. Generating the Offer . . . . . . . . . . . . . . . . . . . . . 9
9. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Attribute Encoding . . . . . . . . . . . . . . . . . . . . . . 9
11. Demultiplexing HIP and STUN . . . . . . . . . . . . . . . . . 10
12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
13. Security Considerations . . . . . . . . . . . . . . . . . . . 11
13.1. Attacks on Connectivity Checks . . . . . . . . . . . . . . 11
13.2. Attacks on Address Gathering . . . . . . . . . . . . . . . 14
13.3. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 15
13.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 15
13.4.1. HIP Amplification Attack . . . . . . . . . . . . . . 15
13.4.2. STUN Amplification Attack . . . . . . . . . . . . . . 15
14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 16
14.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 16
14.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 17
14.3. Brittleness Introduced by HIP-ICE . . . . . . . . . . . . 17
14.4. Requirements for a Long Term Solution . . . . . . . . . . 18
14.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 19
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
16.1. Normative References . . . . . . . . . . . . . . . . . . . 20
16.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Tschofenig & Wing Expires December 23, 2007 [Page 2]
Internet-Draft HIP-ICE June 2007
1. Introduction
This document describes how the Interactive Connectivity
Establishment (ICE [I-D.ietf-mmusic-ice]) methodology can be used for
the Host Identity Protocol (HIP) to determine whether end-to-end
communication is possible. We call this usage HIP-ICE. ICE makes
use of the Session Traversal Utilities for NAT (STUN [RFC3489],
STUNbis [I-D.ietf-behave-rfc3489bis]) protocol to learn candidate
transport addresses and to verify connectivity between peers. After
running the ICE methodology, the two HIP end points will be able to
communicate as directly possible -- directly with each other, through
a HIP relay, via Network Address Translators (NATs), Network Address
and Port Translators (NAPTs), and firewalls.
In a typical deployment, there are two endpoints, Agent L and Agent
R, which want to communicate. These two agents play the role of HIP
initiators and HIP responders. They are able to communicate
indirectly via a combination of HIP and traversal via a HIP
rendezvous server.
At the beginning of the HIP-ICE process, the end points are ignorant
of their own topologies. They might or might not be behind a NAT (or
multiple tiers of NATs) and might be behind firewalls that limit the
ability to communicate in different ways between the end points.
HIP-ICE allows these end points to discover enough information about
their topologies to potentially find one or more paths by which they
can communicate.
Figure 1 shows a typical environment for HIP-ICE deployment. The two
end points are labelled L and R (for left and right). Both L and R
are behind their own respective NATs or firewalls though they may not
be aware of it. The type of NAT or firewall and their properties are
also unknown. L and R are capable of engaging in an end-to-end
protocol exchange with the help of HIP rendezvous servers.
If desired, TURN [I-D.ietf-behave-turn] could be used for relaying
IPsec traffic rather than relying on dedicated HIP rendezvous
servers. This would allow HIP DNS [I-D.ietf-hip-dns] to be used.
This aspect is for further study.
In Figure 1 the STUN server is co-located with the HIP rendezvous
servers for editorial reasons. From a solution point of view this
is, however, not necessary.
Tschofenig & Wing Expires December 23, 2007 [Page 3]
Internet-Draft HIP-ICE June 2007
HIP
+----------+ Signalling +----------+
|Rendezvous|<---------------------->|Rendezvous|
|Server A | |Server B |
+----------+ +----------+
^ ^
| |
| |
| |
HIP | |HIP
Signalling| |Signalling
| |
| |
+---v----+ Optimal HIP/IPsec path +---v----+
| FW/NAT |<-------------------------->| FW/NAT |
+---^----+ +---^----+
| |
| |
v v
+--------+ +--------+
| Agent | | Agent |
| L | | R |
+--------+ +--------+
Figure 1: Overview
The basic idea behind HIP-ICE is as follows: each end point has a
variety of candidate TRANSPORT ADDRESSES (combination of IP address,
transport protocol (UDP), and port) it could use to communicate with
the other end point.
To avoid unnecessary UDP encapsulation of IPsec traffic, it is
also possible to consider using IP addresses rather than focusing
exclusively on TRANSPORT ADDRESSES. For example, two HIP hosts
behind the same NAT do not need to use UDP encapsulation. As
another example, a HIP host behind a HIP-friendly NAT or HIP-
friendly firewall does not need UDP encapsulation. The need and
desire for this functionality will be analysed in a future version
of this document.
Potentially, any of L's candidate transport addresses can be used to
communicate with any of R's candidate transport addresses. In
practice, however, many combinations do not work. For instance, if L
and R are both behind NATs, their directly attached interface
addresses (e.g., 192.168.1.100) are unlikely to be able to
communicate. The purpose of HIP-ICE is to discover which pairs of
addresses will work. The way that HIP-ICE does this is to
systematically try all possible pairs (in a carefully sorted order)
Tschofenig & Wing Expires December 23, 2007 [Page 4]
Internet-Draft HIP-ICE June 2007
until it finds one or more that works. Once found, the best pair is
used for subsequent communication between the hosts.
1.1. Gathering Candidate Addresses
In order to execute ICE, an agent has to identify all of its address
candidates. A CANDIDATE is a transport address - a combination of IP
address and port for a particular transport protocol.
This document uses three types of candidates:
1. One viable candidate is a transport address obtained directly
from a local interface. Such a candidate is called a HOST
CANDIDATE.
2. Translated addresses on the public side of a NAT (called SERVER
REFLEXIVE CANDIDATES). This address is obtained via STUN.
3. Addresses obtained via relaying traffic through the rendezvous
server, called RELAYED CANDIDATES.
1.2. Connectivity Checks
Once L has gathered all of its candidates, it orders them in highest
to lowest priority and sends them to R over the signalling channel.
We refer to the signaling channel to the end-to-end HIP exchange.
The extension to exchange candidates can be found in Section 10.
When R receives the L's HIP I2 message, R performs the same candidate
gathering process and responds with its own list of candidates. At
the end of this process, each agent has a complete list of both its
candidates and its peer's candidates. It pairs them up, resulting in
CANDIDATE PAIRS. To see which pairs work, each agent schedules a
series of connectivity CHECKS. Each check is a STUN transaction that
the client will perform on a particular candidate pair by sending a
STUN request from the local candidate to the remote candidate; a
response indicates there is connectivity to the peer using that
candidate address.
It is important to note that the STUN requests are sent to and from
the exact same IP addresses and ports that will be used for
subsequent data traffic.
1.3. Sorting Candidates
Because the algorithm above searches all candidate pairs, if a
working pair exists it will eventually find it no matter what order
the candidates are tried in. In order to produce faster (and better)
results, the candidates are sorted in a specified order. The
resulting list of sorted candidate pairs is called the CHECK LIST.
Tschofenig & Wing Expires December 23, 2007 [Page 5]
Internet-Draft HIP-ICE June 2007
1.4. Frozen Candidates
The concept of frozen candidates is not applicable when ICE is
applied to HIP.
1.5. Security for Checks
Because the ICE algorithm is used to discover which addresses can be
used to send traffic between two end points, it is important to
ensure that the process cannot be hijacked to send traffic to the
wrong location. Each STUN connectivity check is covered by a message
authentication code (MAC) generated based on passwords exchanged via
the HIP exchange. This MAC provides message integrity and data
origin authentication, thus stopping an attacker from forging or
modifying connectivity check messages.
1.6. Concluding HIP-ICE
ICE checks are performed in a specific sequence, so that high
priority candidate pairs are checked first, followed by lower
priority ones.
2. 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 RFC 2119 [RFC2119].
This document heavily relies on the terminology introduced in
[I-D.ietf-mmusic-ice].
3. Design Choices
The work in this document is guided by the following design choices,
namely:
o The offer/answer exchange described in ICE [I-D.ietf-mmusic-ice]
is mapped to the end-to-end HIP exchange. An initial offer is
carried inside the I2 message and an initial answer is carried
inside the R2 message. A later offer/answer exchange is conveyed
in a NOTIFY packet (inside the NOTIFICATION parameter). When
Network Address Translators and firewalls are located along the
path then direct end-to-end communication between the two end
point is typically not possible and hence this protocol
interaction is provided via HIP rendezvous nodes.
Tschofenig & Wing Expires December 23, 2007 [Page 6]
Internet-Draft HIP-ICE June 2007
o We assume that HIP initiators and HIP responders implement and use
STUN. For performing connectivity checks a couple of other
alternatives are, however, possible:
It would be possible to utilize REAP
[I-D.ietf-shim6-failure-detection] but STUN provides the same
support with a more likely chance for widespread deployment.
REAP currently only provides IPv6 support.
Custom HIP messages could be created as described in
[I-D.ietf-hip-nat-traversal].
HIP multi-homing and mobility support [I-D.ietf-hip-mm]
provides a basic support for address checks.
o If one peer does not support STUN then the optimal results of HIP-
ICE cannot be provided. There is, however, the ability to make
use of STUN LITE when a host is on the public address space and
not behind a firewall.
o Obtaining Relay Addresses from STUN [I-D.ietf-behave-turn],
formerly known as TURN, is intentionally not used. For HIP, a HIP
rendezvous server reverse tunneling functionality is used instead
of TURN.
o This document makes use of the UDP-encapsulated of HIP packets, as
specified in [I-D.ietf-hip-nat-traversal].
o This document focuses only on the data exchange between the two
end points rather than on the communication between a HIP end
point and a rendezvous server or on the ability to allow HIP
signaling messages to traverse NATs and firewalls.
o Each STUN connectivity check is covered by a message
authentication code (MAC) generated based on passwords exchanged
via the HIP exchange. This is similar to how ICE exchanges
username and password fragments in the offer/answer exchange.
Alternatively, it is also possible to generate keying material
for the message authentication code used in STUN based on the
key derivation procedure described in Section 6.5 of
[I-D.ietf-hip-base].
Note that the ICE description assumes usage within a VoIP environment
where individual flows are controlled. However, the protocol
interaction described in this document operates at a lower layer
where application specific message flows are not visible. When a
CANDIDATE PAIR, consisting of two TRANSPORT ADDRESSES, is created
then it will typically refer to multiple flows then traffic between
two end points experiences UDP encapsulation (due to the need to
traverse a NAT or a stateful packet filtering firewall).
The descriptions in the ICE specification related to SIP, ANAT, RTP,
RTCP, third party call control, preconditions, forking, etc. are not
Tschofenig & Wing Expires December 23, 2007 [Page 7]
Internet-Draft HIP-ICE June 2007
applicable to HIP and are not included in this document.
From an editorial point of view it would be possible to copy-and-
paste relevant parts of the ICE specification and to remove VoIP
specific descriptions but for this version of the document we did
not follow this approach.
The main accomplishment of this document is the reuse of the well-
established ICE specification that builds on STUN. STUN enjoys
widespread implementation support and maximum code re-use was one of
the design criteria for this document.
4. Sending the Initial Offer
In order to send the initial offer in an offer/answer exchange, an
agent must (1) gather candidates, (2) prioritize them, (3) choose
default candidates, and then (4) formulate and send them to the other
peer.
Section 4 of ICE [I-D.ietf-mmusic-ice] is applicable to this document
with the following two exceptions: First, TURN is not used in this
document but instead the same functionality is accomplished via the
HIP rendezvous mechanism. Second, the description regarding encoding
of candidates in SDP is not applicable and replaced by a HIP specific
encoding described in Section 10.
5. Receiving the Initial Offer
When an agent receives an initial offer, it will check if the offerer
supports sufficient ICE functionality to proceed (i.e., if both
offerer and answerer are lite implementations, ICE cannot proceed),
determine its own role, gather candidates, prioritize them, choose
default candidates, encode and send an answer, and for full
implementations, form the check lists and begin connectivity checks.
Again, the description regarding encoding of candidates in SDP is not
applicable to this document and is replaced by a HIP specific
encoding described in Section 10. Note that only the encoding is
different but not the semantic. As such, the description in Section
5 of [I-D.ietf-mmusic-ice] is applicable to this document.
6. Receiving the Initial Offer
Section 6 of ICE [I-D.ietf-mmusic-ice] describes the procedures that
Tschofenig & Wing Expires December 23, 2007 [Page 8]
Internet-Draft HIP-ICE June 2007
an agent follows when it receives the answer from the peer. It
verifies that its peer supports ICE, determines its role, and for
full implementations, forms the check list and begins performing
periodic checks.
7. Concluding ICE Processing
The description in Section of ICE [I-D.ietf-mmusic-ice] illustrates
processing rules that apply only to full implementations. Concluding
ICE involves nominating pairs by the controlling agent and updating
of state machinery
8. Generating the Offer
Either agent may generate a subsequent offer at any time. The rules
in Section 8 of ICE [I-D.ietf-mmusic-ice] will cause the controlling
agent to send an updated offer at the conclusion of ICE processing
when ICE has selected different candidate pairs from the default
pairs. Section 9 of ICE [I-D.ietf-mmusic-ice] defines rules for
construction of subsequent offers and answers.
Note that the term "media stream" in Section 9 of ICE
[I-D.ietf-mmusic-ice] translates to an individual UDP-encapsulated
data flow exchanged between the two HIP peers.
9. Keepalives
Section 10 of ICE [I-D.ietf-mmusic-ice] describes a keepalive
mechanism. The RTP description, such as RTP No-Op and RTP comfort
noise, is not applicable to this document. Other useful keepalive
techniques are described in [I-D.marjou-behave-app-rtp-keepalive] and
may be useful for HIP; a recommendation will be made in a subsequent
version of this document.
10. Attribute Encoding
This specification reuses seven SDP attributes, the "candidate",
"remote-candidates", "ice-lite", "ice-mismatch", "ice- ufrag", "ice-
pwd" and "ice-options" attributes, and places them in a single HIP
TLVs.
For this version of the document we decided to utilize the same gamma
as used in Section 15 of ICE [I-D.ietf-mmusic-ice].
Tschofenig & Wing Expires December 23, 2007 [Page 9]
Internet-Draft HIP-ICE June 2007
All HIP TLV parameters have a length (including Type and Length
fields) which is a multiple of 8 bytes. When needed, padding MUST be
added to the end of the parameter so that the total length becomes a
multiple of 8 bytes.
Section 15.1 to Section 15.5 of ICE [I-D.ietf-mmusic-ice] describe
the content of the attributes.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ICE attribute ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD
Length variable
ICE attribute Attributes specified in ICE
Figure 2: Attribute Encoding
This TLV MUST be protected by the ENCRYPTED TLV.
11. Demultiplexing HIP and STUN
When HIP and STUN are run over the same port it is necessary to
demultiplex them.
A STUN packet always has the fixed value 0x2112A442 in its Magic
Cookie field (bits 32-64 from the beginning of the UDP payload):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 0 1 0 0 0 1 0 0 1 0 1 0 1 0 0 1 0 0 0 1 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
Figure 3: STUN Header
Tschofenig & Wing Expires December 23, 2007 [Page 10]
Internet-Draft HIP-ICE June 2007
In this same offset from the UDP header, the HIP header has its
Checksum field and its Controls field. The Controls field currently
only defines its last bit (bit 64); the rest of the bits in the
Control field are for extensions and must be 0.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Header Length |0| Packet Type | VER. | RES.|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Controls |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
Figure 4: HIP Header
Bit 16 of STUN's magic cookie is 1. To ensure HIP and STUN can
always be demultiplexed, HIP should require the first bit in the same
position always be 0. That bit is first bit of the HIP Controls
field, which is currently undefined and currently must be zero
[I-D.ietf-hip-base].
12. Example
[Editor's Note: We will provide a message flow in a future version of
this document.]
13. Security Considerations
There are several types of attacks possible in an HIP-ICE system.
This section considers these attacks and their countermeasures.
13.1. Attacks on Connectivity Checks
An attacker might attempt to disrupt the STUN connectivity checks.
Ultimately, all of these attacks fool an agent into thinking
something incorrect about the results of the connectivity checks.
The possible false conclusions an attacker can try and cause are:
False Invalid:
An attacker can fool a pair of agents into thinking a candidate
pair is invalid, when it isn't. This can be used to cause an
agent to prefer a different candidate (such as one injected by the
attacker), or to disrupt a call by forcing all candidates to fail.
Tschofenig & Wing Expires December 23, 2007 [Page 11]
Internet-Draft HIP-ICE June 2007
False Valid:
An attacker can fool a pair of agents into thinking a candidate
pair is valid, when it isn't. This can cause an agent to proceed
with a session, but then not be able to receive any data traffic.
False Peer-Reflexive Candidate:
An attacker can cause an agent to discover a new peer reflexive
candidate, when it shouldn't have. This can be used to redirect
data traffic to a DoS target or to the attacker, for eavesdropping
or other purposes.
False Valid on False Candidate:
An attacker has already convinced an agent that there is a
candidate with an address that doesn't actually route to that
agent (for example, by injecting a false peer reflexive candidate
or false server reflexive candidate). It must then launch an
attack that forces the agents to believe that this candidate is
valid.
Of the various techniques for creating faked STUN messages described
in [I-D.ietf-behave-rfc3489bis], many are not applicable for the
connectivity checks. Compromises of STUN servers are not much of a
concern, since the STUN servers are embedded in endpoints and
distributed throughout the network. Thus, compromising the peer's
embedded STUN server is equivalent to compromising the end point, and
if that happens, far more problematic attacks are possible than those
against ICE. When a rendezvous server that also operators a STUN
server is compromised then various attacks are possible since the
rendezvous server maintains also mappings between identifiers and
locators.
Injection of fake responses and relaying modified requests all can be
handled in ICE with the countermeasures discussed below.
To force the false invalid result, the attacker has to wait for the
connectivity check from one of the agents to be sent. When it is,
the attacker needs to inject a fake response with an unrecoverable
error response, such as a 600. However, since the candidate is, in
fact, valid, the original request may reach the peer agent, and
result in a success response. The attacker needs to force this
packet or its response to be dropped, through a DoS attack, layer 2
network disruption, or other technique. If it doesn't do this, the
success response will also reach the originator, alerting it to a
possible attack. Fortunately, this attack is mitigated completely
through the STUN message integrity mechanism. The attacker needs to
Tschofenig & Wing Expires December 23, 2007 [Page 12]
Internet-Draft HIP-ICE June 2007
inject a fake response, and in order for this response to be
processed, the attacker needs the password. If the candidates are
exchange in HIP messages and therefore secured, the attacker will not
have the password.
Forcing the fake valid result works in a similar way. The agent
needs to wait for the Binding Request from each agent, and inject a
fake success response. The attacker won't need to worry about
disrupting the actual response since, if the candidate is not valid,
it presumably wouldn't be received anyway. However, like the fake
invalid attack, this attack is mitigated completely through the STUN
message integrity and offer/answer security techniques.
Forcing the false peer reflexive candidate result can be done either
with fake requests or responses, or with replays. We consider the
fake requests and responses case first. It requires the attacker to
send a Binding Request to one agent with a source IP address and port
for the false candidate. In addition, the attacker must wait for a
Binding Request from the other agent, and generate a fake response
with a XOR-MAPPED-ADDRESS attribute containing the false candidate.
Like the other attacks described here, this attack is mitigated by
the STUN message integrity mechanisms and secure offer/answer
exchanges.
Forcing the false peer reflexive candidate result with packet replays
is different. The attacker waits until one of the agents sends a
check. It intercepts this request, and replays it towards the other
agent with a faked source IP address. It must also prevent the
original request from reaching the remote agent, either by launching
a DoS attack to cause the packet to be dropped, or forcing it to be
dropped using layer 2 mechanisms. The replayed packet is received at
the other agent, and accepted, since the integrity check passes (the
integrity check cannot and does not cover the source IP address and
port). It is then responded to. This response will contain a XOR-
MAPPED-ADDRESS with the false candidate, and will be sent to that
false candidate. The attacker must then receive it and relay it
towards the originator.
The other agent will then initiate a connectivity check towards that
false candidate. This validation needs to succeed. This requires
the attacker to force a false valid on a false candidate. Injecting
of fake requests or responses to achieve this goal is prevented using
the integrity mechanisms of STUN and the offer/answer exchange.
Thus, this attack can only be launched through replays. To do that,
the attacker must intercept the check towards this false candidate,
and replay it towards the other agent. Then, it must intercept the
response and replay that back as well.
Tschofenig & Wing Expires December 23, 2007 [Page 13]
Internet-Draft HIP-ICE June 2007
This attack is very hard to launch unless the attacker is identified
by the fake candidate. This is because it requires the attacker to
intercept and replay packets sent by two different hosts. If both
agents are on different networks (for example, across the public
Internet), this attack can be hard to coordinate, since it needs to
occur against two different endpoints on different parts of the
network at the same time.
If the attacker them self is identified by the fake candidate the
attack is easier to coordinate. However, since HIP utilizes IPsec
ESP to protect the data traffic end-to-end, the attacker will not be
able to inspect any application data, they will only be able to
discard them. However, this attack requires the agent to disrupt
packets in order to block the connectivity check from reaching the
target. In that case, if the goal is to disrupt the end-to-end
communication, its much easier to just disrupt it with the same
mechanism, rather than attack ICE.
13.2. Attacks on Address Gathering
ICE endpoints make use of STUN for gathering candidates from a STUN
server in the network. This is corresponds to the Binding Discovery
usage of STUN described in [I-D.ietf-behave-rfc3489bis]. As a
consequence, the attacks against STUN itself that are described in
that specification can still be used against the binding discovery
usage when utilized with ICE.
However, the additional mechanisms provided by ICE actually
counteract such attacks, making binding discovery with STUN more
secure when combined with ICE.
Consider an attacker which is able to provide an agent with a faked
mapped address in a STUN Binding Request that is used for address
gathering. This is the primary attack primitive described in
[I-D.ietf-behave-rfc3489bis]. This address will be used as a server
reflexive candidate in the ICE exchange. For this candidate to
actually be used for media, the attacker must also attack the
connectivity checks, and in particular, force a false valid on a
false candidate. This attack is very hard to launch if the false
address identifies a fourth party (neither the offerer, answerer, or
attacker), since it requires attacking the checks generated by each
agent in the session.
If the attacker elects not to attack the connectivity checks, the
worst it can do is prevent the server reflexive candidate from being
used. However, if the peer agent has at least one candidate that is
reachable by the agent under attack, the STUN connectivity checks
themselves will provide a peer reflexive candidate that can be used
Tschofenig & Wing Expires December 23, 2007 [Page 14]
Internet-Draft HIP-ICE June 2007
for the exchange of media. Peer reflexive candidates are generally
preferred over server reflexive candidates. As such, an attack
solely on the STUN address gathering will normally have no impact on
a session at all.
13.3. Attacks on the Offer/Answer Exchanges
An attacker that can modify or disrupt the offer/answer exchanges
themselves can readily launch a variety of attacks with HIP-ICE.
They could direct data traffic to a target of a DoS attack, they
could insert themselves into the data exchange, and so on. The
security considerations of HIP [I-D.ietf-hip-base] apply.
13.4. Insider Attacks
In addition to attacks where the attacker is a third party trying to
insert fake offers, answers or STUN messages, there are several
attacks possible with ICE when the attacker is an authenticated and
valid participant in the HIP-ICE exchange.
13.4.1. HIP Amplification Attack
In this attack, the attacker initiates communication to other agents,
and maliciously includes the IP address and port of a DoS target as
the destination for data traffic signaled in the HIP exchange.
This could causes substantial amplification; a single offer/answer
exchange can create a continuing flood of data packets, possibly at
high rates (consider video sources). This attack is not specific to
ICE, but ICE can help provide remediation.
Specifically, if ICE is used, the agent receiving the malicious SDP
will first perform connectivity checks to the target of media before
sending media there. If this target is a third party host, the
checks will not succeed, and media is never sent.
Unfortunately, ICE doesn't help if its not used, in which case an
attacker could simply send the offer without the ICE parameters.
However, in environments where the set of clients are known, and
limited to ones that support ICE, the server can reject any offers or
answers that don't indicate ICE support.
13.4.2. STUN Amplification Attack
The STUN amplification attack is similar to the HIP amplification
attack. However, instead of data packets being directed to the
target, STUN connectivity checks are directed to the target. The
attacker sends an offer with a large number of candidates, say 50.
Tschofenig & Wing Expires December 23, 2007 [Page 15]
Internet-Draft HIP-ICE June 2007
The answerer receives the offer, and starts its checks, which are
directed at the target, and consequently, never generate a response.
The answerer will start a new connectivity check every 20ms, and each
check is a STUN transaction consisting of 7 transmissions of a
message 65 bytes in length (plus 28 bytes for the IP/UDP header) that
runs for 7.9 seconds, for a total of 58 bytes/second per transaction
on average. In the worst case, there can be 395 transactions in
progress at once (7.9 seconds divided by 20ms), for a total of 182
kbps, just for STUN requests.
It is impossible to eliminate the amplification, but the volume can
be reduced through a variety of heuristics. Agents SHOULD limit the
total number of connectivity checks they perform to 100.
Additionally, agents MAY limit the number of candidates they'll
accept in an offer or answer.
14. IAB Considerations
The IAB has studied the problem of "Unilateral Self Address Fixing",
which is the general process by which a agent attempts to determine
its address in another realm on the other side of a NAT through a
collaborative protocol reflection mechanism [RFC3424]. HIP-ICE is an
example of a protocol that performs this type of function.
Interestingly, the process for HIP-ICE is not unilateral, but
bilateral, and the difference has a significant impact on the issues
raised by IAB. HIP-ICE can be considered a B-SAF (Bilateral Self-
Address Fixing) protocol, rather than an UNSAF protocol. Regardless,
the IAB has mandated that any protocols developed for this purpose
document a specific set of considerations. This section meets those
requirements.
14.1. Problem Definition
From RFC 3424 [RFC3424] any UNSAF proposal must provide:
Precise definition of a specific, limited-scope problem that is to be
solved with the UNSAF proposal. A short term fix should not be
generalized to solve other problems; this is why "short term fixes
usually aren't".
The specific problems being solved by HIP-ICE are:
Provide a means for two peers to determine the set of transport
addresses which can be used for communication.
Provide a means for resolving many of the limitations of other UNSAF
mechanisms by wrapping them in an additional layer of processing (the
Tschofenig & Wing Expires December 23, 2007 [Page 16]
Internet-Draft HIP-ICE June 2007
HIP-ICE methodology).
Provide a means for a agent to determine an address that is reachable
by another peer with which it wishes to communicate.
14.2. Exit Strategy
From RFC 3424, any UNSAF proposal must provide:
Description of an exit strategy/transition plan. The better short
term fixes are the ones that will naturally see less and less use as
the appropriate technology is deployed.
HIP-ICE itself doesn't easily get phased out. However, it is useful
even in a globally connected Internet, to serve as a means for
detecting whether communication paths are disrupted. HIP-ICE also
helps prevent certain security attacks which have nothing to do with
NAT. However, what HIP-ICE does is help phase out other UNSAF
mechanisms. HIP-ICE effectively selects amongst those mechanisms,
prioritizing ones that are better, and deprioritizing ones that are
worse. Local IPv6 addresses can be preferred. As NATs begin to
dissipate as IPv6 is introduced, server reflexive and relayed
candidates (both forms of UNSAF mechanisms) simply never get used,
because higher priority connectivity exists to the native host
candidates. Therefore, the servers get used less and less, and can
eventually be remove when their usage goes to zero.
Indeed, HIP-ICE can assist in the transition from IPv4 to IPv6. It
can be used to determine whether to use IPv6 or IPv4 when two dual-
stack hosts communicate. It can also allow a network with both 6to4
and native v6 connectivity to determine which address to use when
communicating with a peer.
14.3. Brittleness Introduced by HIP-ICE
From RFC3424, any UNSAF proposal must provide:
Discussion of specific issues that may render systems more "brittle".
For example, approaches that involve using data at multiple network
layers create more dependencies, increase debugging challenges, and
make it harder to transition.
HIP-ICE uses ICE that is utilizes [I-D.ietf-behave-rfc3489bis]
instead of traditional STUN, RFC 3489 [RFC3489]). RFC 3489 has
several points of brittleness. One of them is the discovery process
which requires a agent to try and classify the type of NAT it is
behind. This process is error-prone. With HIP-ICE, that discovery
process is simply not used. Rather than unilaterally assessing the
Tschofenig & Wing Expires December 23, 2007 [Page 17]
Internet-Draft HIP-ICE June 2007
validity of the address, its validity is dynamically determined by
measuring connectivity to a peer. The process of determining
connectivity is very robust.
Another point of brittleness in any other unilateral mechanism is its
absolute reliance on an additional server on the public Internet,
namely the rendezvous server. ICE makes use of a server for
allocating unilateral addresses, but allows agents to directly
connect if possible. Therefore, in some cases, the failure of a STUN
server would still allow data packets to be exchanged in an end-to-
end fashion when ICE is used.
Another point of brittleness in traditional STUN is that it assumes
that the STUN server is on the public Internet. Interestingly, with
HIP-ICE, that is not necessary. There can be a multitude of STUN
servers in a variety of address realms. ICE will discover the one
that has provided a usable address.
The most troubling point of brittleness in traditional STUN is that
it does not work in all network topologies. In cases where there is
a shared NAT between each agent and the STUN server, traditional STUN
may not work. With ICE, that restriction is removed.
Traditional STUN also introduces some security considerations.
Fortunately, those security considerations are also mitigated by ICE.
Consequently, ICE serves to repair the brittleness introduced in
other UNSAF mechanisms, and does not introduce any additional
brittleness into the system.
With HIP-ICE rendezvous servers are used and they are assumed to be
located on the public Internet to allow HIP to work. Without the
usage of TURN servers it is, however, not possible to allow HIP usage
without rendezvous server and solely with HIP DNS [I-D.ietf-hip-dns]
to work in presence of NATs and firewalls.
14.4. Requirements for a Long Term Solution
From RFC 3424, any UNSAF proposal must provide:
Identify requirements for longer term, sound technical solutions --
contribute to the process of finding the right longer term solution.
HIP-ICE provides a long term solution by utilizing ICE concepts that
have received a lot of peer review in the VoIP community and to apply
them to HIP. The only other possible long term solutions are (a) to
get rid of middleboxes, such as NATs and firewalls or to (b) interact
with them. Regarding (b) extensions for STUN to allow the protocol
Tschofenig & Wing Expires December 23, 2007 [Page 18]
Internet-Draft HIP-ICE June 2007
to be deployed on NATs and firewalls is currently being investigated
in [I-D.wing-behave-nat-control-stun-usage].
14.5. Issues with Existing NAPT Boxes
From RFC 3424, any UNSAF proposal must provide:
Discussion of the impact of the noted practical issues with existing,
deployed NA[P]Ts and experience reports.
A number of NAT boxes are now being deployed into the market which
try and provide "generic" ALG functionality. These generic ALGs hunt
for IP addresses, either in text or binary form within a packet, and
rewrite them if they match a binding. This interferes with
traditional STUN. However, the update to STUN
[I-D.ietf-behave-rfc3489bis] uses an encoding which hides these
binary addresses from generic ALGs.
Existing NAPT boxes have non-deterministic and typically short
expiration times for UDP-based bindings. This requires
implementations to send periodic keepalives to maintain those
bindings. ICE uses a default of 15s, which is a very conservative
estimate. Eventually, over time, as NAT boxes become compliant to
behave [RFC4787], this minimum keepalive will become deterministic
and well-known, and the ICE timers can be adjusted. Having a way to
discover and control the minimum keepalive interval would be far
better still.
15. Acknowledgments
The authors would like to thank Jonathan Rosenberg for his work on
the ICE specification. This document copy-and-pastes text from the
ICE specification.
We would also like to thank the authors of
[I-D.ietf-hip-nat-traversal] for the discussions on the IETF HIP
mailing list. Note, however, that the approach described in this
document is considerably different than the approach outlined in
[I-D.ietf-hip-nat-traversal].
Finally, we would like to thank Thomas Schreck for his help on
discussions various aspects in this document.
16. References
Tschofenig & Wing Expires December 23, 2007 [Page 19]
Internet-Draft HIP-ICE June 2007
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-16 (work in progress), June 2007.
16.2. Informative References
[I-D.ietf-behave-turn]
Rosenberg, J., "Obtaining Relay Addresses from Simple
Traversal Underneath NAT (STUN)",
draft-ietf-behave-turn-03 (work in progress), March 2007.
[I-D.ietf-shim6-failure-detection]
Arkko, J. and I. Beijnum, "Failure Detection and Locator
Pair Exploration Protocol for IPv6 Multihoming",
draft-ietf-shim6-failure-detection-07 (work in progress),
December 2006.
[I-D.ietf-hip-nat-traversal]
Schmitt, V., "HIP Extensions for the Traversal of Network
Address Translators", draft-ietf-hip-nat-traversal-01
(work in progress), March 2007.
[I-D.ietf-hip-mm]
Henderson, T., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-05 (work in
progress), March 2007.
[I-D.ietf-hip-dns]
Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions",
draft-ietf-hip-dns-09 (work in progress), April 2007.
[I-D.ietf-hip-base]
Moskowitz, R., "Host Identity Protocol",
draft-ietf-hip-base-08 (work in progress), June 2007.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
Tschofenig & Wing Expires December 23, 2007 [Page 20]
Internet-Draft HIP-ICE June 2007
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., "Session Traversal Utilities for (NAT)
(STUN)", draft-ietf-behave-rfc3489bis-06 (work in
progress), March 2007.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[I-D.wing-behave-nat-control-stun-usage]
Wing, D. and J. Rosenberg, "Discovering, Querying, and
Controlling Firewalls and NATs using STUN",
draft-wing-behave-nat-control-stun-usage-02 (work in
progress), June 2007.
[I-D.marjou-behave-app-rtp-keepalive]
Marjou, X., "Application Mechanism for maintaining alive
the Network Address Translator (NAT) mappings associated
to RTP flows.", draft-marjou-behave-app-rtp-keepalive-01
(work in progress), February 2007.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
Authors' Addresses
Hannes Tschofenig
Nokia Siemens Networks
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
Dan Wing
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: dwing@cisco.com
Tschofenig & Wing Expires December 23, 2007 [Page 21]
Internet-Draft HIP-ICE June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Tschofenig & Wing Expires December 23, 2007 [Page 22]