WDIFF

draft-kohler-dccp-mobility-00.txt --> draft-kohler-dccp-mobility-01.txt

INTERNET-DRAFT UCLA
draft-kohler-dccp-mobility-00.txt 12 July 2004
Expires:
draft-kohler-dccp-mobility-01.txt 29 January 2005 2006
Expires: 29 July 2006

Datagram Congestion Control Protocol Mobility and Multihoming

Status of this Memo

This document is an Internet-Draft.

Status of this Memo

By submitting this Internet-Draft, we certify each author represents that any
applicable patent or other IPR claims of which we are he or she is aware
have been
disclosed, or will be disclosed, and any of which we become he or she becomes
aware will be disclosed, in accordance with RFC 3668 (BCP 79).

By submitting this Internet-Draft, we accept the provisions of Section 3 6 of RFC 3667 (BCP 78). 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 a as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
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 29 July 2006.

Abstract

This document lays out requirements and a preliminary design for
transport-level mobility and multihoming support in the Datagram

Kohler [Page 1]

INTERNET-DRAFT Expires: January 2005 July 2004
Congestion Control Protocol (DCCP) [DCCP].

Kohler [Page 2] 1]

INTERNET-DRAFT Expires: January 2005 29 July 2004 2006 January 2006

Table of Contents

1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4 3
2. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 4 3
3. Design Overview Protocol. . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Details. . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . 7
4.1. DCCP-Move Header . . . . . 4
3.2. Gencon Option. . . . . . . . . . . . . . . . . 7
5. Multihoming and Mobility. . . . . . 5
3.3. Initiate Gencon Message. . . . . . . . . . . . . . 9
5.1. Mobility Capable Feature . . . 6
3.4. Approve Gencon Message . . . . . . . . . . . . . 9
5.2. Mobility ID Feature. . . . . 8
3.5. Attach Gencon Message. . . . . . . . . . . . . . . 10
5.3. Mobile Host Processing . . . 9
3.6. Challenge Gencon Message . . . . . . . . . . . . . . . . 10
5.4. Stationary Host Processing
3.7. Confirm Gencon Message . . . . . . . . . . . . . . . . . 11
5.5. Congestion Control State
3.8. Detach Gencon Message. . . . . . . . . . . . . . . . . . 12
5.6.
3.9. Unexpected Options . . . . . . . . . . . . . . . . . . . 13
4. Using Generalized Connections . . . . . . . . . . . . . . . . 14
5. Concerns. . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations. Considerations . . . . . . . . . . . . . . . . 12 . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
Normative References . . . . . . . . . . . . . . . . . . . . . . 13 17
Informative References . . . . . . . . . . . . . . . . . . . . . 13 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 15 19
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 15 19

Kohler [Page 3] 2]

INTERNET-DRAFT Expires: January 2005 29 July 2004 2006 January 2006

1. Introduction

The Datagram Congestion Control Protocol (DCCP) [DCCP] did not
originally contain support for mobility or multihoming. Each DCCP
connection was associated with exactly two network-level addresses
over its lifetime, one per endpoint. At the very first DCCP BoF
session, at the 51st IETF in London, we got some feedback
criticizing this decision, so we added mobility and multihoming
support as of November 2001. This decision was supported by the
eventual DCCP working group charter:

Prior to the final development of the protocol, the working
group will investigate areas of functionality that should be
integrated into DCCP because they are difficult or impossible to
layer above it. These areas include security and multi-
homing/mobility, at a minimum.

Thus began our quest for a mechanism that would support mobility and
multihoming, at the DCCP level, with reasonable security and DoS-
prevention, without using cryptography. (The DCCP working group's
charter has been interpreted as preventing DCCP from including
cryptography, even MD5 hashes.) DCCP's mobility support changed,
often fundamentally, in every succeeding draft.

Unsurprisingly, we did not find a suitable mechanism, and I now
believe no such mechanism exists. Even seemingly trivial
multihoming mechanisms like SCTP's can cause security problems in
practice [ANC04]. Mobility and multihoming have been removed from
the main DCCP specification.

Unfortunately, mobility and multihoming support can't easily be
implemented at a higher-level layer, and there are good arguments
for supporting mobility and multihoming at the transport layer --
not least required interactions with congestion control. This
document, therefore, presents one potential design for DCCP mobility
and multihoming support. It relaxes one of DCCP mobility's original
requirements by using cryptography.

2. Requirements

DCCP mobility and multihoming support should fulfill the following
requirements and non-requirements.

o An endpoint does not need to announce a new address before moving
to that address.

RATIONALE: Mobile hosts usually cannot may not know a new address before until a move completes. Multihomed hosts *can* know each of their
completes; and by that time, the old address may not be usable.

Kohler Section 2. [Page 4] 3]

INTERNET-DRAFT Expires: January 2005 29 July 2004 2006 January 2006

Some multihomed hosts can know each of their addresses, but
announcing addresses before using them does not prevent all
attacks; see, for example, the "address squatting" attacks in
[ANC04].

o Move requests must be safe against hijacking. Even attackers
that can snoop on part or all of data traffic must not be able to
move a connection. However, move requests need not be safe
against man-in-the-middle attackers with control over which
packets get delivered (such as routers).

RATIONALE: Moving a connection is in some ways the worst possible
attack: An attacker takes over a user's identity, without the
user becoming aware of the attack or being able to stop the
attack. We must prevent this. However, an endpoint with full
control over the path could carry out this kind of attack even
without mobility support. An attacker that can snoop Therefore, we choose to allow a packet
sent by DCCP
mobility mechanism to be vulnerable to attackers that can snoop a
packet sent by the mobile host, then prevent that snooped packet
from being delivered to the stationary host, can subvert our mobility
mechanism. host.

o Mobility must not create new, large opportunities for denial-of-
service attacks.

o Endpoints must be able to move freely between different NAT
domains using the mobility mechanism.

o Simultaneous moves need not be supported.

o Cryptography is allowed.

It is difficult, perhaps impossible, to fulfill both the NAT
traversal and hijacking prevention requirements. Natural mechanisms
for preventing hijacking, such as cryptographically signing the
packet's network headers, fail in the presence of NATs, which change
those headers. NATs essentially hijack connections by definition;
we want to allow that, but prevent malicious hijacking. The
solution below represents one attempt.

3. Design Protocol

3.1. Overview

The mobility design described here has the following features.

0. Support for

DCCP mobility is optional and defaults to off.

1. Each endpoint of a mobility-capable multihoming support is based on generalized
connections. A generalized connection has groups one or more transport
connections, called component connections, into a public
128-bit Mobility ID. single
application-level entity. To move addresses, a host attaches a new
component connection, then detaches the old component connection.

Kohler Section 3. 3.1. [Page 5] 4]

INTERNET-DRAFT Expires: January 2005 29 July 2004

2. The endpoints share a Mobility Secret, a key communicated over 2006 January 2006

To implement multihoming, a
secure channel. The Secret is either transmitted out-of-band,
or via public-key cryptography or Diffie-Hellman exchange. It
is changed on every successful move.

3. A Mobility Sequence number increases monotonically host maintains multiple component
connections with moves,
and identifies which Mobility Secret a packet is using.

The two mobility identifiers, Mobility ID and Mobility Secret, are
used for different purposes. Mobility ID lets the stationary endpoint (and any NATs on the stationary endpoint's side) map addresses.

The multiple component connections that make up a move
announcement to an existing connection, even though generalized
connection are treated independently at the source
address and port have changed. (The original source address transport level. They
maintain independent sequence number spaces and
port cannot be used congestion control
state, for this purpose, since NATs in the original
path may cause the two endpoints example. The application, however, sees only one socket,
which corresponds to disagree the generalized connection. Data received on their values.)
Mobility Secret
any component connection is used during sent to that socket, and data sent via
the move socket may be transmitted over any component connection.

The first connection handshake to prevent most
hijackings.

Moving in a generalized connection progresses through must
register the following four steps,
which will take approximately two round-trip times.

1. intention to set up a generalized connection. The mobile host moves,
generalized connection's identifier is then sends a DCCP-Move-Request packet
from its agreed upon by the two
endpoints (assuming they both support mobility). Thereafter, new address. This packet contains (1)
component connections specify the stationary
host's Mobility ID, intended generalized connection in the clear, and (2) a mobility token,
encrypted
their handshakes. A public-key cryptographic protocol prevents
connection hijacking by passive attackers. However, attackers who
can prevent packets from being delivered, or alter packets in
flight, can hijack the Mobility Secret. Each mobility token consists
of a portion of connection, as is also possible in the DCCP header (Sequence Number,
Acknowledgement Number, Mobility ID, and so forth) and
absence of this extension.

(1) Connection initiation with preparation for generalized
connections:
A --> DCCP-Request with Initiate Gencon --> B
A <-- DCCP-Response with Accept Gencon <-- B

(2) Adding a new
half-Mobility Secret.

This packet serves connection to inform the stationary endpoint of generalized connection:
A' --> DCCP-Request with Attach Gencon --> B
A' <-- DCCP-Response with Challenge Gencon <-- B
A' --> DCCP-Ack with Confirm Gencon --> B

(3) Removing a connection from the
move.

2. generalized connection:
A --> DCCP-Sync with Detach Gencon --> B
A <-- DCCP-SyncAck <-- B

3.2. Gencon Option

The stationary host maps the DCCP-Move-Request packet Gencon option, for Generalized Connection, is used to implement
the old
connection using the Mobility ID, then checks the token against subprotocols that create and update generalized connections.
These subprotocols may contain messages that exceed the packet data. If this check succeeds, it sends 253-byte
option length limit. Therefore, all Gencon options on a DCCP-Move-
Response packet are
concatenated to the DCCP-Move-Request packet's source
address, including specify a similar token. The stationary host
remembers both the new Mobility Secret and the old Mobility
Secret.

Together, the initial DCCP-Move-Request and this Response define single Gencon message.

Gencon messages follow a new Mobility Secret, which is used common format, as a nonce. This ensures
that (1) Mobility Secrets are not terribly vulnerable to attack,
since they frequently change, and (2) the mobile endpoint
receives partial confirmation that its packets are getting
through to the stationary endpoint. follows.

Kohler Section 3. 3.2. [Page 6] 5]

INTERNET-DRAFT Expires: January 2005 29 July 2004

3. 2006 January 2006

+--------+------ ... ------+------ ... ------+-------- ...
| GCType | Gencon ID | Component ID | Payload
+--------+------ ... ------+------ ... ------+-------- ...
(8 bytes) (4 bytes)

Gencon Type (GCType): 8 bits
Defines the Gencon message type. Six types are currently
defined, as follows:

Type Meaning Payload
---- ------- -------
0 Initiate Public Key
1 Approve Public Key
2 Attach Optional Nonce
3 Challenge Nonce and Optional Token
4 Confirm Token
5 Detach Token
6-255 Reserved

Table 1: Gencon Types

Gencon ID: 64 bits (8 bytes)
The mobile host sends a DCCP-Move-Confirm packet. This time, Gencon ID uniquely identifies the token generalized connection at
both endpoints, and is encrypted with the used to identify new Mobility Secret. The
token's New Mobility Sequence and half-secret fields equal those
from the DCCP-MoveRequest. Receiving component
connections for an existing generalized connection. To ensure
uniqueness at both endpoints, the DCCP-Move-Response
packet informs Gencon ID is defined in two
parts: the mobile host that client defines the stationary host received upper 32 bits in its move request.

This packet proves to the stationary endpoint that the true
mobile endpoint received its DCCP-Move-Response. This Initiate
Gencon message, which is
because sent on the token is encrypted with first DCCP-Request, and the new Secret,
server adds the lower 32 bits in its Initiate Gencon message,
which could
only have been obtained by a party that new is sent on the old Secret.

4. The stationary host receives corresponding DCCP-Response. Neither the DCCP-Move-Confirm packet,
removes its old Mobility Secret(s), and sends a DCCP-Move-
Complete packet back to
upper nor the sender, both to end this episode lower 32 bits of
mobility and to inform NATs and middleboxes that the
connection's endpoints have definitively changed. The token's
New Mobility Sequence and half-secret fields Gencon ID may equal those from
the DCCP-MoveResponse.

4. Protocol Details

DCCP mobility and multihoming support requires one more packet type,
DCCP-Move; two new DCCP features, Mobility Capable (server-priority
boolean, defaults to 0) and Mobility zero.

Component ID: 32 bits (4 bytes)
The Component ID (non-negotiable 128-bit
number); one new Reset Code, "Move Refused"; and two new connection
properties, Mobility Sequence and Mobility Secret. Additionally,
any plausible mechanism for establishing identifies a Mobility Secret in-band
would also use features to do it.

4.1. DCCP-Move Header

Mobility handshakes take place using the DCCP-Move packet type.
DCCP A sends component connection within a DCCP-Move packet to DCCP B after changing its address
and/or port number.
generalized connection. It MUST NOT equal zero.

3.3. Initiate Gencon Message

The DCCP-Move client sends an Initiate Gencon message on the DCCP-Request
packet requests that DCCP B start
sending packets to initiates a new address and port number, which are read off generalized connection. This message
contains half of the packet's network header Gencon ID that will define the generalized
connection, and generic DCCP header. the client's public key that will be used to
validate later Gencon messages. The old
address and port are defined through server's DCCP-Response packet
will include an Approve Gencon message to complete the Mobility ID. handshake.

Kohler Section 4.1. 3.3. [Page 7] 6]

INTERNET-DRAFT Expires: January 2005 29 July 2004

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Generic DCCP Header (12 or 16 2006 January 2006

The Initiate Gencon message has the following format:

+--------+----- ... -----+----- ... -----+
|00000000| Gencon ID | Component ID | (continued)
+--------+----- ... -----+----- ... -----+
GCType=0 (8 bytes) /
/ with Type=8 (DCCP-Move) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Acknowledgement Number |
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)X=1
(. Acknowledgement Number (low bits) | Reserved |)only
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Mobility Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility ID (high bits) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Mobility ID (bits 64-95) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Mobility ID (bits 32-63) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Mobility ID (low bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options / Padding |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Encrypted Message (4 bytes)

+--------+--------+--------+--------
| Key Type | Key ... |

Subtype: 8
+--------+--------+--------+--------

Gencon ID
The client specifies the upper 32 bits
Used to distinguish between different message types (4 bytes) of the
generalized connection's Gencon ID in its Initiate Gencon
message. These bits MUST NOT equal zero, while the
mobility handshake.

Mobility Sequence: 16 lower 32
bits
Defines MUST equal zero. They also MUST NOT equal the Mobility Secret used to encrypt upper 32
bits of the token. Its
initial value for Gencon ID of any other generalized connection
currently active at the server. Furthermore, they SHOULD be
chosen so as to minimize duplication: that is, no recently-
active generalized connection from this endpoint should have had
the same upper 32 bits.

Component ID
This field is 0.

Mobility ID: 128 chosen by the client to identify this component
connection. It MUST NOT equal zero, and its most significant
bit MUST equal zero; thus, values 1-2147483647 are acceptable.
One is perfectly reasonable choice for this first component
connection.

Key Type: 16 bits
The value of
Defines the receiver's Mobility ID feature. public-key cryptographic protocol to be used by
other Gencon messages to validate future component connections.
This value
uniquely identifies the current connection among protocol, not its key length; the set
length of
connections terminating at the receiver (meaning, Gencon message itself should be used to infer the stationary
endpoint); it MUST have been set
key length.

Key: arbitrary length
The client's public key in the cryptosystem defined by Key Type.
This public key is used only for this generalized connection,
although an earlier exchange. See
Section 5.2. endpoint MAY reuse a public key on multiple
generalized connections. The application data area format of a DCCP-Move packet contains a Mobility
Token, a message encrypted by this field depends on
the Mobility Secret. This message
consists value of the following fields, packed together: Key Type.

Kohler Section 4.1. 3.3. [Page 8] 7]

INTERNET-DRAFT Expires: January 2005 29 July 2004

1. The third, fourth, and subsequent words of 2006 January 2006

3.4. Approve Gencon Message

On receiving a DCCP-Request containing an acceptable Initiate Gencon
message, the DCCP
header, up to, but not including, any options. server responds with a DCCP-Response packet containing
an Approve Gencon message. This includes serves three purposes: it
acknowledges the Sequence Number, Acknowledgement
Number, Type, Subtype, Mobility Sequence, creation of a generalized connection, it completes
the specification of the Gencon ID, and
Mobility it defines the server's
public key.

The Approve message has the following format:

+--------+----- ... -----+----- ... -----+
|00000001| Gencon ID fields, among others.
2. New Mobility Sequence.
3. New half-Mobility Secret (format not specified yet).
4-6. Same as 1-3.

An endpoint | Component ID | (continued)
+--------+----- ... -----+----- ... -----+
GCType=1 (8 bytes) (4 bytes)

+--------+--------+--------+--------
| Key Type | Key ...
+--------+--------+--------+--------

Gencon ID
The upper 32 bits of this field MUST ignore any DCCP-Move packet whose application data
area doesn't have equal the proper format.

Regarding sequence-validity, DCCP-Move Sequence and Acknowledgement
Numbers value specified
by the client in its Initiate Gencon message. The lower 32 bits
are not strongly checked because moves might likely happen
after long loss periods, and newly provided by the mandatory Mobility ID provides good
protection against unexpected packets. A DCCP-Move packet is
sequence-valid if "seqno >= SWL" and "GAR <= ackno <= AWH".
Sequence-invalid DCCP-Move packets MUST be ignored.

5. Multihoming server, and Mobility

THIS SECTION IS MUST NOT IN ITS FINAL FORM. SOME TEXT IS OLD.

DCCP provides primitive support for multihoming and mobility via a
mechanism for transferring equal zero. The
result -- a connection endpoint from one address to
another. 64-bit number, neither of whose halves equals zero
-- is the connection's complete Gencon ID. The moving endpoint must negotiate mobility support
beforehand. When server MUST
choose these lower 32 bits so that no other currently-active
connection with the moving same endpoint gets a new address, has the same Gencon ID.
Furthermore, it sends a
DCCP-Move packet from that address SHOULD choose these bits so as to minimize
duplication, ensuring that new connections receive Gencon IDs
that have not been seen before.

Component ID
MUST equal the stationary endpoint. The
stationary endpoint then changes value specified by the client in its Initiate
message.

Key Type
MUST equal the value specified by the client in its Initiate
message.

Key The server's public key in the cryptosystem defined by Key Type.
See the comments above on the client's public key.

Kohler Section 3.4. [Page 8]

INTERNET-DRAFT Expires: 29 July 2006 January 2006

3.5. Attach Gencon Message

To add a component connection state to use a generalized connection, one of
the endpoint hosts opens a new
address.

DCCP's support for mobility is intended DCCP connection to solve only the simplest
multihoming and mobility problems; for instance, there's no support
for simultaneous moves. Applications requiring more complex
mobility semantics, or more stringent security guarantees, should
use an existing solution like Mobile IP or [SB00]. DCCP mobility may
not be useful other in the context of IPv6,
conventional way -- that is, using a DCCP-Request packet. This
DCCP-Request packet contains an Attach Gencon message with its mandatory support for
Mobile IP.

5.1. Mobility Capable Feature

A DCCP uses the Mobility Capable feature to inform its partner
generalized connection's Gencon ID. This initial message is
unverified; a protocol consisting of a Challenge Gencon message,
sent on the DCCP-Response, and a Confirm Gencon message, sent on the
DCCP-Ack, verifies that
it would like to the mobile endpoint host's private key
approves of the move.

Note that the "client" of the new component connection need not be able to change its address and/or port during
the course same endpoint as the "client" of the original component
connection. DCCP B sends a "Change R(Mobility
Capable, 1)" option to DCCP A to inform it that B might like to move
later.

Kohler Section 5.1. [Page 9]

INTERNET-DRAFT Expires: January 2005 July 2004

Mobility Capable has feature number , and The original server is server-priority. It
takes one-byte Boolean values. DCCP A agrees in principle the endpoint that received the
original DCCP-Request containing an Initiate Gencon message; to accept
DCCP-Move packets from DCCP B when Mobility Capable/A is one.
DCCP A MUST reject any DCCP-Move packet for add
a connection whose
Mobility Capable/A feature is zero, although new component connection, it MAY reject sends a valid
DCCP-Move packet even when Mobility Capable/A is one. Values of two
or more are reserved. New connections start with Mobility Capable 0
(that is, mobility DCCP-Request Gencon message
to the original client, and is not allowed) thus the client for both endpoints.

5.2. Mobility ID Feature

A DCCP uses the Mobility ID feature new component
connection. Alternatively, the server could convince the client to inform its partner of
open a
128-bit number that will act as identification, should the partner
change its address and/or port during new connection using application messages of some kind.

The Attach message has the course following format:

Gencon ID
The Gencon ID of the generalized connection.
DCCP A sends a "Change L(Mobility ID, N)" option to notify DCCP B

Component ID
The Component ID of this new component connection. This value
is chosen by the ID component client; it has chosen MUST NOT have been used
for B's use.

Mobility ID has feature number , any previous successful component connection, and is non-negotiable. Its values
are sixteen-byte integers. MUST NOT
equal zero. The Mobility ID/A feature equals value of the
identifier that DCCP B should use most significant bit is set based
on DCCP-Move packets whether the component client (the endpoint sending this DCCP-
Request) is the original client (the endpoint that sent the
first DCCP-Request in the generalized connection), according to A.
DCCP A chooses Mobility ID/A to uniquely identify
this table:

Component Client Component ID MSB Component ID Range
---------------- ---------------- ------------------
Original Client 0 1-2147483647
Original Server 1 2147483648-4294967295

Kohler Section 3.5. [Page 9]

INTERNET-DRAFT Expires: 29 July 2006 January 2006

This restriction ensures that the connection
among all endpoints will not pick the
same Component ID if they try to attach new component
connections simultaneously.

Nonce: 64 bits
Nonce fields are used as challenges to verify that terminate at A. For security, DCCP A
MUST choose Mobility ID/A randomly. New connections start with
Mobility ID 0 for both endpoints. However, Mobility IDs of the other
protocol endpoint knows the expected private key. The special
value zero indicates the lack of a nonce. Nonce values MUST be
chosen randomly, and MUST NOT be accepted reused on DCCP-Move packets; the same generalized
connection ID. (That is, given an endpoint cannot
successfully move until and a Gencon ID, the relevant Mobility
multiset of Nonce values contained in Gencon messages with that
endpoint and Gencon ID has been set must contain no duplicates, except
possibly for zero.) Thus, attackers should not be able to
predict the next nonce an endpoint will use.

The component client MAY include an 8-byte Nonce in the Attach
Gencon message. This expresses a
nonzero value.

5.3. Mobile Host Processing

When DCCP A changes its address and/or port, it MUST signal this by
sending DCCP B desire to verify that the
component server is valid, i.e. knows the expected private key.

3.6. Challenge Gencon Message

The DCCP-Response packet sent in response to a DCCP-Move-Request new component
connection -- that is, to a DCCP-Request packet with enclosed Mobility
Token. Of special interest containing an Attach
Gencon message -- MUST contain a Challenge Gencon message. This
message is effectively an Init Cookie; the New Mobility Sequence in component server MUST NOT
accept the
token. The Mobility Sequence for each new component connection until the Challenge is 0.
Thereafter, it increases monotonically as endpoints try to move.
Every time DCCP correctly
confirmed with a Confirm Gencon message.

The Challenge Gencon message has the following format:

+--------+----- ... -----+----- ... -----+
|00000011| Gencon ID | Component ID | (continued)
+--------+----- ... -----+----- ... -----+
GCType=3 (8 bytes) (4 bytes)

+----- ... -----+--------+--------
| Nonce | Token ...
+----- ... -----+--------+--------
(8 bytes) (optional)

Gencon ID
The Gencon ID of the generalized connection.

Component ID
The Component ID of the new component connection; MUST equal the
Component ID from the corresponding Attach Gencon message.

Kohler Section 3.6. [Page 10]

INTERNET-DRAFT Expires: 29 July 2006 January 2006

Nonce
This Nonce is used to verify that the component client knows the
relevant private key. It follows the restrictions described
above, and MUST NOT be zero.

Token: variable length
If the Attach Gencon message contained a nonzero Nonce, then the
component server MUST include a signed Token in its Challenge
Gencon message. This Token will prove to the component client
that the component server knows the relevant private key. To
create a Token in response to a particular Nonce, an endpoint
constructs the following 40-byte structure:

Byte Index Contents
---------- --------
0 Gencon Type of the message containing the Token
1 zero
2-7 Sequence Number of the packet that will contain
the Token
8-9 zero
10-15 Acknowledgement Number of the packet that will
contain the Token, which must equal the Sequence
Number of the packet that contained the Nonce
16-23 Gencon ID
24-27 Component ID
28-31 Component ID
32-39 Nonce

This structure is then encrypted using the endpoint's private
key: the encrypted result is the Token. The other endpoint can
decrypt the Token using the corresponding public key; if the
contents match, then some party that knows the relevant private
key approved of those contents.

3.7. Confirm Gencon Message

After receiving the DCCP-Request containing a Challenge Gencon
message, the component client MUST send a DCCP-Ack packet containing
a Confirm Gencon message in response. This message contains a token
that the component server will use to verify the client's identity.

The Confirm message has the following format:

Kohler Section 3.7. [Page 11]

INTERNET-DRAFT Expires: 29 July 2006 January 2006

+--------+----- ... -----+----- ... -----+--------+--------
|00000100| Gencon ID | Component ID | Token ...
+--------+----- ... -----+----- ... -----+--------+--------
GCType=4 (8 bytes) (4 bytes) (variable)

Gencon ID
The Gencon ID of the generalized connection.

Component ID
The Component ID of the new component connection; MUST equal the
Component ID from the corresponding Attach and Challenge Gencon
messages.

Token
A Token created in response to the Nonce from the Challenge
Gencon message.

3.8. Detach Gencon Message

A component connection may be closed in the usual way, via DCCP-
CloseReq, DCCP-Close, and DCCP-Reset packets. Sometimes, however,
an endpoint loses control of a generalized connection before getting
a chance to close it; this may particularly happen in mobile hosts.
The Detach Gencon message allows an endpoint to close a different
component connection by Component ID. Detach Gencon messages MUST
be sent on DCCP-Sync packets, which may be sent at any time during a
connection. Since a packet can contain at most one Gencon message,
only one component connection can be detached per packet.

The Detach message has the following format:

+--------+----- ... -----+----- ... -----+--------+--------
|00000101| Gencon ID | Component ID | Token ...
+--------+----- ... -----+----- ... -----+--------+--------
GCType=5 (8 bytes) (4 bytes) (variable)

Gencon ID
The Gencon ID of the generalized connection.

Component ID
The Component ID of the component connection that should be
closed. This MUST NOT equal the Component ID of the component
connection on which the message appears.

Token
A Token, as above. The Nonce field used to construct the Token

Kohler Section 3.8. [Page 12]

INTERNET-DRAFT Expires: 29 July 2006 January 2006

equals zero.

3.9. Unexpected Options

Endpoints MUST handle invalid, unexpected, and otherwise malformed
Gencon options in the following way.

o A Gencon message is Mandatory when any of its component Gencon
options is marked Mandatory. If a Mandatory Gencon message is
"ignored" according to the following list, then the receiving
endpoint MUST reset the connection using Reset Code 6, "Mandatory
Failure", as described in [DCCP] (Section 5.8.2).

o Any Gencon message that does not meet basic formatting
requirements, such as message length, MUST be ignored.

o Any Gencon message with unrecognized Gencon Type MUST be ignored.

o An Initiate Gencon message received on any packet other than a
DCCP-Request MUST be ignored.

o An Initiate Gencon message whose Gencon ID and/or Component ID do
not meet the specified requirements MUST be ignored.

o An Initiate Gencon message whose Key Type is not understood, or
whose Key does not meet the requirements of the corresponding Key
Type, MUST be ignored.

o An Approve Gencon message received on any packet other than a
DCCP-Response MUST be ignored.

o An Approve Gencon message received on a DCCP-Response, where the
corresponding DCCP-Request did not contain an Initiate Gencon
message, MUST be ignored.

o An Approve Gencon message whose Gencon ID and/or Component ID do
not meet the specified requirements, or whose Key Type does not
equal the client's Key Type from its Initiate message, or whose
Key does not meet the requirements of its Key Type, MUST be
ignored.

o An Attach Gencon message received on any packet other than a
DCCP-Request MUST be ignored.

o An Attach Gencon message whose Gencon ID does not correspond to a
current connection, or whose Component ID is zero, or whose
Component ID was used by a previous successful component
connection on this generalized connection, MUST be ignored. (A

Kohler Section 3.9. [Page 13]

INTERNET-DRAFT Expires: 29 July 2006 January 2006

component connection is "successful" once a suitable Confirm
Gencon message has been received.)

o A Challenge Gencon message received on any packet other than a
DCCP-Response MUST be ignored.

o A Challenge Gencon message received on a DCCP-Response, where the
corresponding DCCP-Request did not contain a Challenge Gencon
message, MUST be ignored.

o A Challenge Gencon message whose Gencon ID and/or Component ID do
not correspond to the Attach message's, or whose Nonce is zero,
MUST be ignored.

o A Challenge Gencon message sent in response to an Attach message
with a Nonce, whose Token is missing or invalid, MUST be ignored.

o A Confirm Gencon message received on any packet other than a
packet whose Acknowledgement Number equals that of a DCCP-
Response packet that contained a Challenge message, MUST be
ignored.

o A Confirm Gencon message whose Gencon ID and/or Component ID do
not correspond to the Attach message's, or whose Token is missing
or invalid, MUST be ignored.

o A sends a DCCP-Move-Request from Detach Gencon message received on any packet other than a new address, it DCCP-
Sync packet MUST increment New Mobility Sequence.

Once DCCP be ignored.

o A receives a DCCP-Move-Response, it calculates the new
Mobility Secret from the fragments stored in the two tokens; throws
away all prior Mobility Secrets; sets its Mobility Sequence and
Secret fields from Detach Gencon message whose Gencon ID does not correspond to
the packet; and sends expected Gencon ID, or whose Component ID does not equal that
of a DCCP-Move-Confirm,
confirming currently active component connection, MUST be ignored.

o A Detach Gencon message whose Component ID equals that it has done these things.

DCCP of the
component connection on which the message appears MUST be
ignored.

o A SHOULD retransmit its DCCP-Move-Request and -Confirm packets
until it receives some confirmation. The retransmission strategy
SHOULD Detach Gencon message whose Token is missing or invalid MUST be similar
ignored.

4. Using Generalized Connections

A client that expects to use multihoming or mobility, or that for retransmitting DCCP-Requests; for
instance, a first timeout wants
to support servers that use multihoming or mobility, SHOULD send an
Initiate Gencon message on its DCCP-Request. If the order of server responds
with a valid Approve Gencon message, then the connection is
multihoming/mobility-enabled; and as a second, consequence, the
application's data stream may be associated with an more than one

Kohler Section 5.3. 4. [Page 10] 14]

INTERNET-DRAFT Expires: January 2005 29 July 2004

exponential backoff timer.

DCCP A MUST reset its congestion control state after sending a DCCP-
Move, since nothing is known about conditions on the new path.
Essentially, DCCP 2006 January 2006

active connection. This section describes how that association is
managed.

A must "slow start" up to its new fair rate, generalized connection lasts as long as
appropriate for its congestion control mechanism.

DCCP A SHOULD NOT send non-DCCP-Move packets to DCCP B until the
move is confirmed. If it did so, and the DCCP-Move packet was lost
or reordered, then DCCP B would react by sending DCCP-Resets with
Reset Code 3, "No Connection". DCCP A might implement special
handling for such resets to avoid any post-move quiet period, but
this has at least one
associated component connection. When a generalized connection's
last component connection is NOT RECOMMENDED.

DCCP B MAY refuse closed (moves to accept a move, perhaps because of address
policy. In this case, DCCP A will receive a DCCP-Reset with Reset
Code "Move Refused", rather than TIMEWAIT or CLOSED
state), either through an explicit termination handshake or because
of a confirming DCCP-Sync. DCCP A MAY
react by tearing down timeout, the connection, or by trying another DCCP-Move
-- application-level connection MUST also be closed.
APIs that report a reason for instance, back to the old address, if possible.

DCCP endpoints connection closure SHOULD NOT use an old address-port pair after sending the
reason associated with the last-closed component connection; if more
than one connection closes at the same time, the choice is
arbitrary.

When a DCCP-Move. If it becomes necessary generalized connection has multiple components, the endpoint
must decide which connection to switch back use to the old
address-port pair, send data. Unless there is
some external basis for choice, such as cost, the endpoint MUST do so explicitly using another
DCCP-Move.

DCCP-Move packets SHOULD NOT be sent until
send its data on the last connection is
established; on which it is illegal received data.

An endpoint SHOULD NOT use generalized connections simply to send improve
its throughput with parallel connections. There SHOULD be a DCCP-Move in REQUEST
substantive difference between the component connections, such as
different network access technologies or RESPOND
state. If an failure dependencies. An
endpoint moves during connection establishment, it
SHOULD abandon that suspects that its partner is "cheating" with
generalized connections MAY reset one or more component connections
with Reset Code 11, "Aggression Penalty".

When multiple component connections are sending data, that data MUST
be enqueued for the old connection and initiate a new one. No
connection exists to move until application in the three-way handshake has
completed.

5.4. Stationary Host Processing

The stationary endpoint, DCCP B, uses DCCP-Move packets' destination
address, destination port, and Mobility ID fields order it is received. There
is no way, other than simple delay, to look up the
relevant connection. enforce ordering among data
received on different component connections. This differs from all other packet types,
which is intentional;
application-level sequence numbers are easily layered on top of
DCCP, and lack of sequencing may discourage aggressive use the source address/source port/destination
address/destination port 4-tuple. of
parallel component connections.

5. Concerns

Using multiple parallel connections to improve throughput.

6. Security Considerations

The base DCCP B MUST ignore DCCP-Moves whose Mobility ID protocol is zero, or whose
Mobility ID does not correspond to any active connection. It also
MUST ignore DCCP-Moves sent intended to sockets in CLOSED, LISTEN, REQUEST,
RESPOND, or TIMEWAIT state, protect against some classes
of attacks, and it MUST ignore DCCP-Moves with
invalid Sequence or Acknowledgement Numbers, Mobility Sequences,
Subtypes, or Mobility Tokens. DCCP B MUST NOT respond explicitly declares itself vulnerable to invalid
DCCP-Moves with DCCP-Reset or DCCP-Sync packets, since any active
response would leak information about other
classes of attacks. Specifically,
Attackers cannot hijack a DCCP connection (close the connection
unexpectedly, or cause attacker data to be accepted by an
endpoint as if it came from the sender) unless they can guess
valid sequence numbers. Thus, as long as endpoints choose
initial sequence numbers well, a possibly DCCP attacker must snoop on

Kohler Section 5.4. 6. [Page 11] 15]

INTERNET-DRAFT Expires: January 2005 29 July 2004

malicious host. After receiving an invalid DCCP-Move, DCCP B MAY
ignore subsequent DCCP-Move packets, valid or not, for a short
period of time, such as one second or one round-trip time. This
protects DCCP B against denial-of-service attacks from floods 2006 January 2006

data packets to get any reasonable probability of
invalid DCCP-Moves.

On receiving a valid DCCP-Move-Request or DCCP-Move-Confirm, DCCP B
first checks the Mobility success.
Sequence number validity checks provide this guarantee. [DCCP]
(Section 18)

The mobility and Secret against multihoming support described in this document
preserves this security model for existing connection features.
Generalized connections, however, enlarge the network
address. If two packets are ever received that have (1) possible semantics of
DCCP interactions. This section describes the same
Mobility Sequence; (2) valid tokens, indicating possession security consequences
of a
valid Mobility Secret for that Sequence; and (3) different network
addresses, then this the Gencon mechanism, as applied to those new semantics.

A "full hijacking" attack is defined as an attack where, using
mobility and multihoming support, an attacker transparently adds
itself as an endpoint to a strong indication of potential attack.
The generalized connection. For example,
consider a generalized connection MUST be reset, between hosts 1.0.0.1 and all state purged.

After this check, DCCP B will respond to 2.0.0.2.
An attacker with IP address 3.0.0.3 would execute a valid DCCP-Move-Request full hijacking
attack by (1) constructing a new half-key for Mobility Secret; (2) storing adding itself as an endpoint to the new Mobility Secret under generalized
connection. Any attacker that resides on the suggested Mobility Sequence (but
it also keeps path, and can control
the old Secret); (3) sending a DCCP-Move-Response,
encrypted using delivery of messages, thus faking the old Secret. ownership of IP address
1.0.0.1, can execute a full hijacking attack; this is true in
unextended DCCP, and multihoming and mobility support does not
change this fact.

DCCP B will respond multihoming and mobility support aims to a valid DCCP-Move-Confirm by provide the following
security guarantee: An attacker cannot successfully execute a full
hijacking attack unless it (1) deleting all
Mobility Secrets whose Sequences are lower than can snoop the confirmed
Sequence, channel, and (2) sending a DCCP-Move-Complete, encrypted using knows
an endpoint's private key.

Assume that the
new Secret.

5.5. Congestion Control State

Once attacker does not know an endpoint has transitioned endpoint's private key.
Such an attacker cannot generate correct Tokens, and in particular,
it cannot generate the Gencon Confirm Token required to complete a new address, the
connection handshake. Thus, the only way for it to execute a full
hijacking attack is effectively by replaying a new previous Gencon Confirm message.
That message must have the same Gencon ID as the connection in terms of its congestion control
state: to be
hijacked. The current connection must not have successfully used
the accumulated information about congestion between replayed message's Component ID. The attacker must use the old
endpoints no longer applies. Both DCCPs MUST initialize their
congestion control state (windows, rates, same
Sequence Number as in the replayed message, and so forth) convince the other
endpoint to use the same Sequence Number for its packets (ensuring
that the Acknowledgement Number in the replayed message is correct).
All of a
new connection. That is, they must "slow start".

Similarly, this is difficult, but not impossible. However, the endpoints' PMTUs SHOULD be reinitialized, and PMTU
discovery performed again, following an address change.

During attacker
must also arrange for the transition period between addresses, other endpoint to use the endpoints might
receive congestion feedback from both before same Nonce as in
the move previously replayed message, and after the
move. Congestion and loss events on packets sent before protocol explicitly forbids
this.

7. IANA Considerations

IANA is requested to reserve the move
SHOULD NOT affect value 45 for the Gencon option from
the DCCP Option Types registry, and to create a new connection's congestion control state.

5.6. Security Considerations

TBA registry for
DCCP Gencon Types, populated initially with the values in Table 1.

Kohler Section 5.6. 7. [Page 12] 16]

INTERNET-DRAFT Expires: January 2005 29 July 2004 2006 January 2006

Normative References

[DCCP] E. Kohler, M. Handley, and S. Floyd. Datagram Congestion
Control Protocol, draft-ietf-dccp-spec-07.txt, draft-ietf-dccp-spec-13.txt, work in progress,
July 2004.
December 2005.

[RFC 793] J. Postel, editor. Transmission Control Protocol.
RFC 793.

[RFC 1191] J. C. Mogul and S. E. Deering. Path MTU Discovery.
RFC 1191.

[RFC 1750] D. Eastlake, S. Crocker, and J. Schiller. Randomness
Recommendations for Security. RFC 1750.

[RFC 2119] S. Bradner. Key Words For Use in RFCs to Indicate
Requirement Levels. RFC 2119.

[RFC 2460] S. Deering and R. Hinden. Internet Protocol, Version 6
(IPv6) Specification. RFC 2460.

[RFC 3168] K.K. Ramakrishnan, S. Floyd, and D. Black. The Addition
of Explicit Congestion Notification (ECN) to IP. RFC 3168.

[RFC 3309] J. Stone, R. Stewart, and D. Otis. Stream Control
Transmission Protocol (SCTP) Checksum Change. RFC 3309.

[RFC 3692] T. Narten. Assigning Experimental and Testing Numbers
Considered Useful. RFC 3692.

[UDP-LITE] L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson
(editor), and G. Fairhurst (editor). The UDP-Lite Protocol.
draft-ietf-tsvwg-udp-lite-02.txt, work in progress, August 2003.

Informative References

[ANC04] Tuomas Aura, Pekka Nikander, and Gonzalo Camarillo. Effects
of Mobility and Multihoming on Transport-Protocol Security.
2004 IEEE Symposium Security and Privacy.

[BB01] S.M. Bellovin and M. Blaze. Cryptographic Modes of Operation
for the Internet. 2nd NIST Workshop on Modes of Operation,
August 2001.

[BEL98] S.M. Bellovin. Cryptography and the Internet. Proc. CRYPTO
'98 (LNCS 1462), pp46-55, August, 1988.

Kohler [Page 13] 17]

INTERNET-DRAFT Expires: January 2005 29 July 2004 2006 January 2006

[CCID 2 PROFILE] S. Floyd and E. Kohler. Profile for DCCP
Congestion Control ID 2: TCP-like Congestion Control. draft-
ietf-dccp-ccid2-05.txt, work in progress, February 2004.

[CCID 3 PROFILE] S. Floyd, E. Kohler, and J. Padhye. Profile for
DCCP Congestion Control ID 3: TFRC Congestion Control. draft-
ietf-dccp-ccid3-05.txt, work in progress, February 2004.

[LINK BCP] Phil Karn, editor. Advice for Internet Subnetwork
Designers. draft-ietf-pilc-link-design-13.txt, work in
progress, February 2003.

[M85] Robert T. Morris. A Weakness in the 4.2BSD Unix TCP/IP
Software. Computer Science Technical Report 117, AT&T Bell
Laboratories, Murray Hill, NJ, February 1985.

[PMTUD] Matt Mathis, John Heffner, and Kevin Lahey. Path MTU
Discovery. draft-ietf-pmtud-method-00.txt, work in progress,
October 2003.

[RFC 792] J. Postel, editor. Internet Control Message Protocol.
RFC 792.

[RFC 1948] S. Bellovin. Defending Against Sequence Number Attacks.
RFC 1948.

[RFC 2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H.
Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V.
Paxson. Stream Control Transmission Protocol. RFC 2960.

[RFC 3124] H. Balakrishnan and S. Seshan. The Congestion Manager.
RFC 3124.

[RFC 3360] S. Floyd. Inappropriate TCP Resets Considered Harmful.
RFC 3360.

[RFC 3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer. TCP
Friendly Rate Control (TFRC): Protocol Specification. RFC 3448.

[RFC 3517] E. Blanton, M. Allman, K. Fall, and L. Wang. A
Conservative Selective Acknowledgment (SACK)-based Loss Recovery
Algorithm for TCP. RFC 3517.

[RFC 3540] N. Spring, D. Wetherall, and D. Ely. Robust Explicit
Congestion Notification (ECN) Signaling with Nonces. RFC 3540.

[RFC 3550] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson.
RTP: A Transport Protocol for Real-Time Applications. RFC 3550.

Kohler [Page 14] 18]

INTERNET-DRAFT Expires: January 2005 29 July 2004 2006 January 2006

[SB00] Alex C. Snoeren and Hari Balakrishnan. An End-to-End
Approach to Host Mobility. Proc. 6th Annual ACM/IEEE
International Conference on Mobile Computing and Networking
(MOBICOM '00), August 2000.

[SHHP00] Oliver Spatscheck, Jorgen S. Hansen, John H. Hartman, and
Larry L. Peterson. Optimizing TCP Forwarder Performance.
IEEE/ACM Transactions on Networking 8(2):146-157, April 2000.

[SYNCOOKIES] Daniel J. Bernstein. SYN Cookies.
http://cr.yp.to/syncookies.html, as of July 2003.

Authors' Addresses

Eddie Kohler <kohler@cs.ucla.edu>
4531C Boelter Hall
UCLA Computer Science Department
Los Angeles, CA 90095
USA

Full Copyright Statement

Copyright (C) The Internet Society 2004. (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.

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.

Intellectual Property

The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.

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.

Kohler [Page 15]

INTERNET-DRAFT Expires: January 2005 July 2004
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

Kohler [Page 19]

INTERNET-DRAFT Expires: 29 July 2006 January 2006

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.

Kohler [Page 16] 20]
----