WDIFF

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

Internet Engineering Task Force Eddie Kohler
INTERNET-DRAFT UCLA
draft-kohler-dccp-mobility-01.txt 29 January
draft-kohler-dccp-mobility-02.txt 25 June 2006
Expires: 29 July 25 December 2006

Generalized Connections in the Datagram Congestion Control Protocol Mobility and Multihoming

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 29 July 25 December 2006.

Abstract

This document lays out requirements and describes a preliminary design for
transport-level mobility and multihoming support in mechanism by which the set of addresses
bound to an application-level Datagram Congestion Control Protocol
(DCCP) [DCCP]. connection [RFC4340] can change over that connection's
lifetime. The essential abstraction is the Generalized Connection,
which combines multiple distinct transport-level DCCP connections
into a single application-level entity.

Kohler [Page 1]

INTERNET-DRAFT Expires: 29 July 25 December 2006 January June 2006

Table of Contents

1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 Introduction ...................................................3
2. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 3 Conventions and Terminology ....................................3
3. Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Requirements ...................................................3
4. Protocol .......................................................4
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. ..................................................4
4.2. Gencon Option. . . . . . . . . . . . . . . . . . . . . . 5
3.3. Option .............................................5
4.3. Initiate Gencon Message. . . . . . . . . . . . . . . . . 6
3.4. Message ...................................6
4.4. Approve Gencon Message . . . . . . . . . . . . . . . . . 8
3.5. ....................................8
4.5. Attach Gencon Message. . . . . . . . . . . . . . . . . . 9
3.6. Message .....................................9
4.6. Challenge Gencon Message . . . . . . . . . . . . . . . . 10
3.7. .................................10
4.7. Confirm Gencon Message . . . . . . . . . . . . . . . . . 11
3.8. ...................................12
4.8. Detach Gencon Message. . . . . . . . . . . . . . . . . . 12
3.9. Message ....................................13
4.9. Prefer Gencon Message ....................................14
4.10. Gencon Reset Code .......................................14
4.11. Unexpected Options . . . . . . . . . . . . . . . . . . . 13
4. ......................................15
5. Using Generalized Connections . . . . . . . . . . . . . . . . 14
5. Concerns. . . . . . . . . . . . . . . . . . . . . . . . . . . 15 .................................17
6. Crypto Suites .................................................18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. .......................................18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 ...........................................19
9. Thanks ........................................................19
Normative References . . . . . . . . . . . . . . . . . . . . . . 17 .............................................19
Informative References . . . . . . . . . . . . . . . . . . . . . 17 ...........................................19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 ...............................................20
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 19 .........................................20
Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 19 Property ............................................20

Kohler [Page 2]

INTERNET-DRAFT Expires: 29 July 25 December 2006 January June 2006

1. Introduction

The Datagram Congestion Control Protocol (DCCP) [DCCP] did as currently
specified [RFC4340] does not
originally contain support for mobility or multihoming. address rebinding. Each DCCP
connection was is 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 However, there are good
arguments for supporting address rebinding, such as mobility and multihoming
multihoming, at the transport layer -- layer, not least required interactions
with congestion control. This
document, therefore, presents one potential design for DCCP mobility is an unreliable protocol; its
application-level semantics allow packet reordering, loss, and multihoming support. It relaxes one of
duplication. This allows DCCP mobility's original
requirements by using cryptography. to address the address rebinding
problem in a particularly simple way. Multiple transport-level DCCP
connections, with different sequence number spaces, congestion
control state, and so forth, are simply aggregated in the relevant
endpoints into a single application-level entity, called a
Generalized Connection. Little coordination is required among a
generalized connection's components.

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

All multi-byte numerical quantities in DCCP, such as port numbers,
Sequence Numbers, and arguments to options, are transmitted in
network byte order (most significant byte first).

Random numbers in DCCP Generalized Connections are used for their
security properties and SHOULD be chosen according to the guidelines
in [RFC4086].

3. Requirements

DCCP mobility and multihoming support should

The generalized connection mechanism was designed to 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 may not know a new address until a move
completes; and by that time, the old address may not be usable.

Kohler Section 2. [Page 3]

INTERNET-DRAFT Expires: 29 July 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].

Kohler Section 3. [Page 3]

INTERNET-DRAFT Expires: 25 December 2006 June 2006

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. Therefore, we choose to allow a 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.

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.

4. Protocol

3.1.

4.1. Overview

DCCP mobility and multihoming support is based on generalized
connections.

A generalized connection groups one or more transport connections,
called component connections, into a single application-level
entity. To move addresses, a host attaches a new component
connection, then detaches the old component connection.

Kohler Section 3.1. [Page 4]

INTERNET-DRAFT Expires: 29 July 2006 January 2006 To
implement multihoming, a host maintains multiple component
connections with different endpoint addresses.

The multiple component connections that make up a generalized
connection are treated independently at the transport level. They
maintain independent sequence number spaces and congestion control

Kohler Section 4.1. [Page 4]

INTERNET-DRAFT Expires: 25 December 2006 June 2006

state, for example. The application, however, sees only one socket,
which corresponds to the generalized connection. Data received on
any component connection is sent to that socket, and data sent via
the socket may be transmitted over any component connection.

The first connection handshake in a generalized connection must
register the intention to set up a generalized connection. The
generalized connection's identifier is then agreed upon by the two
endpoints (assuming they both support mobility). generalized connections).
Thereafter, new component connections specify the intended
generalized connection in 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 connection, as
is also possible in the absence of this extension.

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

(2) Adding a new connection component to the 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 component from the generalized connection:
A --> DCCP-Sync with Detach Gencon --> B
A <-- DCCP-SyncAck <-- B

3.2.

(4) Marking a component as preferred for data transfer:
A --> any packet with Prefer Gencon --> B

4.2. Gencon Option

The Gencon option, for Generalized Connection, is used to implement
the subprotocols that create and update generalized connections.
These subprotocols may contain messages that exceed the 253-byte
option length limit. Therefore, the payloads from all of a packet's
Gencon options on a packet are concatenated to specify form a single Gencon message.

Gencon messages follow a common format, as follows.

Kohler Section 3.2. 4.2. [Page 5]

INTERNET-DRAFT Expires: 29 July 25 December 2006 January June 2006

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

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

Type

GCType 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
6 Prefer -
7-255 Reserved

Table 1: Gencon Types

Gencon ID: 64 bits (8 bytes)
The Gencon ID uniquely identifies the generalized connection at
both endpoints, and is used to identify new component
connections for an existing generalized connection. To ensure
uniqueness at both endpoints, the Gencon ID is defined in two
parts: the client defines the upper 32 bits in its Initiate
Gencon message, which is sent on the first DCCP-Request, and the
server adds the lower 32 bits in its Initiate Approve Gencon message,
which is sent on the corresponding DCCP-Response. Neither the
upper nor the lower 32 bits of the Gencon ID may equal zero.

Component ID: 32 bits (4 bytes)
The Component ID identifies a component connection within a
generalized connection. It MUST NOT equal zero.

3.3.

4.3. Initiate Gencon Message

The client sends an Initiate Gencon message on the DCCP-Request
packet that initiates a new generalized connection. This message
contains half of the Gencon ID that will define the generalized
connection, and the client's public key that will be used to
validate later Gencon messages. The server's DCCP-Response packet
will include an Approve Gencon message to complete the handshake.

Kohler Section 3.3. 4.3. [Page 6]

INTERNET-DRAFT Expires: 29 July 25 December 2006 January June 2006

The Initiate Gencon message has the following format:

+--------+----- ... -----+----- ... -----+
|00000000| Gencon ID | Component ID | (continued)
+--------+----- ... -----+----- ... -----+
GCType=0 (8 bytes) (4 bytes)

+--------+--------+--------+--------

+--------+--------+--------+--------+------ ... ------+
| Key Type Crypto Suite | Length | Key | ...
+--------+--------+--------+--------
+--------+--------+--------+--------+------ ... ------+
(Length-4 bytes)

Gencon ID
The client specifies the upper 32 bits (4 bytes) of the
generalized connection's Gencon ID in its Initiate Gencon
message. These bits MUST NOT equal zero, while the lower 32
bits MUST equal zero. They also MUST NOT equal the upper 32
bits of the 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 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 a perfectly reasonable choice for this first component
connection.

Key Type:

Crypto Suite: 16 bits
Defines the public-key cryptographic protocol to be used by
other Gencon messages to validate future component connections.
This value identifies the protocol, not its key length;
The Crypto Suite defines how certain other fields, such as Key,
are interpreted.

Length: 16 bits
Equals the byte length of the Gencon message itself should be used to infer the
key length. following Key, plus four.

Key: arbitrary variable length
The client's public key in the cryptosystem defined by Key Type.
This specified Crypto Suite. The
receiving endpoint uses this public key is used only for this
generalized connection, although an endpoint MAY reuse a public
key on multiple generalized connections. The format of There is no way to
change this field depends key on
the value of Key Type. an existing generalized connection; if a
client suspects that a generalized connection's key has been

Kohler Section 3.3. 4.3. [Page 7]

INTERNET-DRAFT Expires: 29 July 25 December 2006 January June 2006

3.4.

compromised, the client should shut down all corresponding
generalized connections. The format of this field depends on
the value of Crypto Suite.

Remainder of message
The Initiate message MAY contain more than one Crypto
Suite/Length/Key triple, allowing the receiving endpoint to
select a Crypto Suite it understands.

The Crypto Suite/Key pair resembles a DCCP feature. We do not use
the existing DCCP feature negotiation mechanism for several reasons:
(1) Crypto Suite/Key negotiation can take place only on connection
initiation. (2) Keys in some Crypto Suites may exceed the 255-byte
feature length limitation.

4.4. Approve Gencon Message

On receiving a DCCP-Request containing an acceptable Initiate Gencon
message, the server responds with a DCCP-Response packet containing
an Approve Gencon message. This serves three purposes: it
acknowledges the creation of a generalized connection, it completes
the specification of the Gencon ID, and it defines the server's
public key.

The Approve message has the following format:

+--------+----- ... -----+----- ... -----+
|00000001| Gencon ID | Component ID | (continued)
+--------+----- ... -----+----- ... -----+
GCType=1 (8 bytes) (4 bytes)

+--------+--------+--------+--------
| Key Type Crypto Suite | Key ...
+--------+--------+--------+--------

Gencon ID
The upper 32 bits of this field MUST equal the value specified
by the client in its Initiate Gencon message. The lower 32 bits
are newly provided by the server, and MUST NOT equal zero. The
result -- a 64-bit number, neither of whose halves equals zero
-- is the connection's complete Gencon ID. The server MUST
choose these lower 32 bits so that no other currently-active
connection with the same endpoint has the same Gencon ID.
Furthermore, it SHOULD choose these bits so as to minimize
duplication, ensuring that new connections receive Gencon IDs
that have not been seen before.

Kohler Section 4.4. [Page 8]

INTERNET-DRAFT Expires: 25 December 2006 June 2006

Component ID
MUST equal the value specified by the client in its Initiate
message.

Key Type

Crypto Suite
MUST equal one of the value Crypto Suites specified by the client in
its Initiate message.

Key The server's public key in the cryptosystem defined by Key Type. specified Crypto Suite. 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. No Length field is
necessary as this Gencon message will contain exactly one Key.

4.5. Attach Gencon Message

To add a component connection to a generalized connection, one of
the endpoint hosts opens a new DCCP connection to the other in the
conventional way -- that is, using a DCCP-Request packet. This
DCCP-Request packet contains an Attach Gencon message with the
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 the mobile endpoint host's private key
approves of the move.

Note that the "client" of the new component connection need not be
the same endpoint as the "client" of the original component
connection. The original server is the endpoint that received the
original DCCP-Request containing an Initiate Gencon message; to add
a new component connection, it sends a DCCP-Request Gencon message
to the original client, and is thus the client for the new component
connection. Alternatively, the server could convince the client to
open a new connection using application messages of some kind.

The Attach message has the following format:

Gencon ID
The Gencon ID of the generalized connection.

Component ID
The Component ID of this new component connection. This value
is chosen by the component client; it MUST NOT have been used
for any previous successful component connection, and MUST NOT

Kohler Section 4.5. [Page 9]

INTERNET-DRAFT Expires: 25 December 2006 June 2006

equal zero. The value of the most significant bit is set based
on 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
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 endpoints will not pick the
same Component ID if they try to attach new component
connections simultaneously.

Nonce:

C-Nonce: 64 bits
Nonce fields are used as challenges to verify that the other
protocol endpoint knows the expected private key. The special
value zero indicates the lack of a nonce. Nonce values MUST be
chosen apparently randomly, and MUST NOT be reused on the same
generalized connection ID. (That is, given an endpoint and a
Gencon ID, the multiset of Nonce values contained in Gencon
messages with that endpoint and Gencon ID must contain no
duplicates, except possibly for zero.) Thus, attackers should
not be able to predict the next nonce an endpoint will use.
Endpoints can obtain apparently-random Nonce values either with
sources of true randomness (as long as values are not reused),
through encryption operations (for example, using a block cipher
to encrypt a value that increases by one per Nonce), or possibly
in other ways. If an endpoint uses encryption, it MUST include
a random salt generated specifically for the generalized
connection, ensuring that attackers cannot predict the next
Nonce even given the value of the current Nonce. Random numbers

The component client MAY include an 8-byte Nonce Nonce, called the C-
Nonce, in the Attach Gencon message. This expresses a desire to
verify that the component server is valid, i.e. knows the
expected private key.

3.6.

4.6. Challenge Gencon Message

The DCCP-Response packet sent in response to a new component
connection -- that is, to a DCCP-Request packet containing an Attach
Gencon message -- MUST contain a Challenge Gencon message. This
message is effectively an Init Cookie; the component server MUST NOT
accept the new component connection until the Challenge is correctly
confirmed with a Confirm Gencon message.

Kohler Section 4.6. [Page 10]

INTERNET-DRAFT Expires: 25 December 2006 June 2006

The Challenge Gencon message has the following format:

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

+----- ... -----+--------+--------
| Nonce S-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

S-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, C-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. The format for the Token depends on the specified
Crypto Suite. Most Crypto Suites will construct Tokens using
the following general procedure.

To create a Token in response to a particular Nonce, an endpoint
constructs the following 40-byte Generic Token Message
structure:

Byte Index Contents
---------- --------

Kohler Section 4.6. [Page 11]

INTERNET-DRAFT Expires: 25 December 2006 June 2006

Bytes +--------+--------+--------+--------+
0 | GCType |00000000| Sequence Number . 3
+--------+--------+--------+--------+
4 . Sequence Number (low bits) | 7
+--------+--------+--------+--------+
8 |00000000|00000000| Ack. Number . 11
+--------+--------+--------+--------+
12 . Acknowledgement Number (low bits) | 15
+--------+--------+--------+--------+
16 | Gencon ID (high bits) . 19
+--------+--------+--------+--------+
20 . Gencon ID (low bits) | 23
+--------+--------+--------+--------+
24 | Component ID | 27
+--------+--------+--------+--------+
28 | Component ID | 31
+--------+--------+--------+--------+
32 | Nonce (high bits) . 35
+--------+--------+--------+--------+
36 . Nonce (low bits) | 39
+--------+--------+--------+--------+

GCType is the Gencon Type of the Gencon message containing the Token
1 zero
2-7
Token. Sequence Number is the Sequence Number of the packet
that will contain this message. Acknowledgement Number is the Token
8-9 zero
10-15
Acknowledgement Number of the packet that will contain the Token, this
message, which must equal the Sequence Number of the packet that
contained the Nonce
16-23 Gencon ID
24-27 Component ID
28-31 Nonce. Note that the Component ID
32-39 Nonce is included
twice.

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

3.7.

The Nonce in a Challenge Gencon message's Token shall equal the
C-Nonce included in the corresponding Attach Gencon message.

4.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. 4.7. [Page 11] 12]

INTERNET-DRAFT Expires: 29 July 25 December 2006 January June 2006

The Confirm message has the following format:

+--------+----- ... -----+----- ... -----+--------+--------
|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 S-Nonce from the Challenge
Gencon message.

3.8.

4.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 component 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. The receiver treats the named
component connection(s) as if they had received a sequence-valid
DCCP-Reset message, with Reset Reason 1, "Closed". Detach Gencon
messages MUST be sent only on DCCP-Sync packets, which may be sent at any time during a
connection. DCCP-Sync, DCCP-CloseReq, DCCP-Close,
and DCCP-Reset packets. Since a packet can contain at most one
Gencon message,
only one component connection can be detached per packet. packet
(unless the Component ID is set to zero, in which case all component
connections are detached except the current component connection).

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.

Kohler Section 4.8. [Page 13]

INTERNET-DRAFT Expires: 25 December 2006 June 2006

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. message appears. The special value of 0
indicates that all component connections of the given
generalized connection should be shut down EXCEPT for the
component connection on which the message appears.

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

4.9. Prefer Gencon Message

The Prefer Gencon message asks the receiving endpoint to send its
data over the named component connection. This allows an endpoint
to manage how it receives data in case that, for example, different
simultaneously-active component connections have different costs or
varying reliability. This information is treated as a hint; the
receiving endpoint need not actually change how it sends data.

The Prefer message has the following format:

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

Gencon ID
The Gencon ID of the generalized connection.

Component ID
The Component ID of the component connection that the receiving
endpoint should use to send data.

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

4.10. Gencon Reset Code

DCCP Reset Code 12 is allocated for resets relating to Generalized
Connections. The Data 1 field corresponds to the Gencon Type of the
Gencon message that caused the reset. The Nonce field used Data 2 & 3 fields default
to construct the Token zero, or are set as described below.

Kohler Section 3.8. 4.10. [Page 12] 14]

INTERNET-DRAFT Expires: 29 July 25 December 2006 January June 2006

equals zero.

3.9.

4.11. 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). [RFC4340], 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 Crypto Suites are not
understood, whose Length values are invalid (less than four or
too large for the Gencon message) or inappropriate for the
corresponding Crypto Suite, or whose corresponding Key does not
meet the requirements of the corresponding Key
Type, selected Crypto Suite, MUST be ignored. result
in connection reset. The receiver will reset the connection with
Reset Code 12. The Data 2 & 3 fields of the DCCP-Reset packet are
set to the problematic Crypto Suite.

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 Crypto Suite does
not equal the client's Key Type some Crypto Suite from its client's Initiate message,
or whose Key does not meet the requirements of its Key Type, the Crypto Suite,
MUST be ignored.

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

Kohler Section 4.11. [Page 15]

INTERNET-DRAFT Expires: 25 December 2006 June 2006

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 Detach Gencon message received on any packet other than a DCCP-
Sync
Sync, DCCP-CloseReq, DCCP-Close, or DCCP-Reset packet MUST be
ignored.

o A Detach Gencon message whose Gencon ID does not correspond to
the expected Gencon ID, or whose nonzero Component ID does not
equal that of a currently active component connection, MUST be
ignored.

o A Detach Gencon message whose Component ID equals that of the
component connection on which the message appears MUST be
ignored.

o A Detach Gencon message whose Token is missing or invalid MUST be
ignored.

o A Prefer Gencon message whose Gencon ID does not correspond to
the expected Gencon ID, or whose Component ID does not equal that

Kohler Section 4.11. [Page 16]

INTERNET-DRAFT Expires: 25 December 2006 June 2006

of a currently active component connection, MUST be ignored.

o A Prefer Gencon message whose Token is missing or invalid MUST be
ignored.

5. Using Generalized Connections

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

Kohler Section 4. [Page 14]

INTERNET-DRAFT Expires: 29 July 2006 January 2006 active connection. This section
describes how that association is managed.

A generalized connection lasts as long as it has at least one
associated component connection. When a generalized connection's
last component connection is closed (moves to TIMEWAIT or CLOSED
state), either through an explicit termination handshake or because
of a timeout, the application-level connection MUST also be closed.
APIs that report a reason for connection closure SHOULD use 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 generalized connection has multiple components, the endpoint
must decide which connection to use to send data. Unless there is
some external basis for choice, such as cost, the endpoint SHOULD
send its data on the last connection on for which it received data. a valid
Prefer message.

An endpoint SHOULD NOT use generalized connections simply to improve
its throughput with parallel connections. There SHOULD be a
substantive difference between the component connections, such as
different network access technologies or failure dependencies. An
endpoint 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 application in the order it is received. There
is no way, other than simple delay, to enforce ordering among data
received on different component connections. This is intentional;
application-level sequence numbers are easily layered on top of
DCCP, and lack of sequencing may discourage aggressive use of
parallel component connections.

Kohler Section 5. Concerns

Using multiple parallel connections to improve throughput. [Page 17]

INTERNET-DRAFT Expires: 25 December 2006 June 2006

6. Crypto Suites

One Crypto Suite is currently recognized for use with Generalized
Connections. Crypto Suite 1, RSA-SHA512, implies the RSASSA-
PKCS1-v1_5 signature scheme described in [RFC3447], Section 9.2.1,
using the SHA-512 hash function. Key values are represented in
ASN.1 using the RSA public key syntax described in [RFC3447],
Appendix A.1.1. Only the encoded RSAPublicKey sequence is
transmitted, not the rsaEncryption OID. Valid Keys MUST have
modulus "n" greater than or equal to 2^1536, and publicExponent "e"
greater than or equal to 65537. Token values are signatures output
from the RSASSA-PKCS1-V1_5-SIGN function defined in [RFC3447],
Section 8.2.1, where the EMSA-PKCS1-v1_5-ENCODE function uses the
SHA-512 hash function and the SHA-512 DigestInfo value. The message
signed to create the Token equals the Generic Token Message
construct described in Section 4.6.

7. Security Considerations

The base DCCP protocol is intended to protect against some classes
of attacks, and explicitly declares itself vulnerable to 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 DCCP attacker must snoop on

Kohler Section 6. [Page 15]

INTERNET-DRAFT Expires: 29 July 2006 January 2006
data packets to get any reasonable probability of success.
Sequence number validity checks provide this guarantee. [DCCP]
(Section 18) See
Section 18 of [RFC4340].

The mobility and multihoming address rebinding support described in this document preserves
this security model for existing connection features. Generalized
connections, however, enlarge the possible semantics of DCCP
interactions. This section describes the security consequences of
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 generalized connection. For example,
consider a generalized connection between hosts 1.0.0.1 and 2.0.0.2.
An attacker with IP address 3.0.0.3 would execute a full hijacking
attack by adding itself as an endpoint to the generalized
connection. Any attacker
that resides on the path, and can control the delivery of messages,
thus faking the ownership of an endpoint's IP address
1.0.0.1, address, can execute a
full hijacking attack; this is true in unextended DCCP, and
multihoming and mobility support does not change this fact. DCCP
multihoming and mobility support aims to provide the following
security guarantee: guarantee for other attackers: An attacker cannot
successfully execute a full hijacking attack unless it (1) can snoop
the channel, and (2) knows an endpoint's private key.

Kohler Section 7. [Page 18]

INTERNET-DRAFT Expires: 25 December 2006 June 2006

Assume that the attacker does not know an 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
connection handshake. Thus, the only way for it to execute a full
hijacking attack is by replaying a previous Gencon Confirm message.
That message must have the same Gencon ID as the connection to be
hijacked. The current connection must not have successfully used
the replayed message's Component ID. The attacker must use the same
Sequence Number as in the replayed message, and 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 this is difficult, but not impossible. However, the attacker
must also arrange for the other endpoint to use the same Nonce as in
the previously replayed message, and the protocol explicitly forbids
this.

8. IANA Considerations

IANA is requested to reserve the value 45 for the Gencon option from
the DCCP Option Types registry, and to create a new registry for
DCCP Gencon Types, populated initially with the values in Table 1.

Kohler Section 7. [Page 16]

INTERNET-DRAFT Expires: 29 July 2006 January 2006

9. Thanks

Thanks to Pasi Sarolahti for comments that inspired revisions to the
specification.

Normative References

[DCCP] E. Kohler, M. Handley, and S. Floyd. Datagram Congestion
Control Protocol, draft-ietf-dccp-spec-13.txt, work

[RFC2119] Bradner, S., "Key words for use in progress,
December 2005.

[RFC 793] J. Postel, editor. Transmission Control Protocol. RFCs to indicate
requirement levels", BCP 14, RFC 793.

[RFC 1191] 2119, March 1997.

[RFC3447] Jonsson, J. C. Mogul and S. E. Deering. Path MTU Discovery. B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 1191.

[RFC 1750] D. 3447, February 2003.

[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, and J. Schiller. Randomness
Recommendations
"Randomness Requirements for Security. RFC 1750.

[RFC 2119] S. Bradner. Key Words For Use in RFCs to Indicate
Requirement Levels. Security", BCP 106, RFC 2119.

[RFC 2460] S. Deering
4086, June 2005.

[RFC4340] Kohler, E., Handley, M., 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 "Datagram
Congestion Notification (ECN) to IP. RFC 3168.

[RFC 3309] J. Stone, R. Stewart, and D. Otis. Stream Control
Transmission Protocol (SCTP) Checksum Change. Protocol", 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. 4340, March 2006.

Informative References

[ANC04] Tuomas Aura, Pekka Nikander, and Gonzalo Camarillo.
Effects of Mobility and Multihoming on Transport-Protocol 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 17]

INTERNET-DRAFT Expires: 29 July 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 18] 19]

INTERNET-DRAFT Expires: 29 July 25 December 2006 January June 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.

Privacy.

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 (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 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

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 20]

----