One document matched: draft-ylitalo-multi6-wimp-00.txt
J. Ylitalo
Internet-Draft V. Torvinen
Expires: July 28, 2004 Ericsson Research Nomadiclab
E. Nordmark
Sun Microsystems, Inc.
January 28, 2004
Weak Identifier Multihoming Protocol (WIMP)
draft-ylitalo-multi6-wimp-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 July 28, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This draft defines a Weak Identifier Multihoming Protocol (WIMP) for
IPv6 hosts. WIMP uses a new logical layer between networking and
transport layers that separates the end-point identifier and locator
roles from each other. The identifiers are used to name the
end-points, while IPv6 addresses are used for routing purposes. WIMP
is based on opportunistic security principles, and it does not
require any pre-configured security infrastructure. The protocol
consists of context establishment and re-addressing exchanges. The
context establishment exchange creates a state for both hosts. The
re-addressing exchange is used to update locator information at the
Ylitalo, et al. Expires July 28, 2004 [Page 1]
Internet-Draft WIMP January 2004
peer host. Used cryptographic operations are light and efficient.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Requirements language . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Cryptographic techniques . . . . . . . . . . . . . . . . . . 5
2.1.1 Reverse hash chain . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Reverse hash chain and message authentication . . . . . . . 6
2.1.3 Chained bootstrapping . . . . . . . . . . . . . . . . . . . 7
2.1.4 Secret splitting . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Notational Conventions . . . . . . . . . . . . . . . . . . . 8
3. Protocol overview . . . . . . . . . . . . . . . . . . . . . 10
3.1 WIMP layer . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Host-Pair Context . . . . . . . . . . . . . . . . . . . . . 11
3.3 Generating reverse hash chains . . . . . . . . . . . . . . . 12
3.4 Context establishment exchange . . . . . . . . . . . . . . . 13
3.5 Re-addressing exchange . . . . . . . . . . . . . . . . . . . 14
4. Packet processing . . . . . . . . . . . . . . . . . . . . . 17
4.1 Processing outgoing application data . . . . . . . . . . . . 17
4.2 Processing incoming application data . . . . . . . . . . . . 18
5. Packets . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1 INIT - the context initiator packet . . . . . . . . . . . . 19
5.2 CC - the context check packet . . . . . . . . . . . . . . . 20
5.3 CCR - the context check reply packet . . . . . . . . . . . . 20
5.4 CONF - the context confirm packet . . . . . . . . . . . . . 21
5.5 RESYNCH - the re-synchronization packet . . . . . . . . . . 21
5.6 REA - The re-addressing packet . . . . . . . . . . . . . . . 22
5.7 AC - The address check packet . . . . . . . . . . . . . . . 22
5.8 ACR - The address check reply packet . . . . . . . . . . . . 23
6. Message formats . . . . . . . . . . . . . . . . . . . . . . 24
6.1 Payload format . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.1 WIMP Controls . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.2 Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2.1 TLV format . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.3 HASH-INIT . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.4 HASH-CC . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.5 HASH-REA . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.6 ANCHOR . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.7 HASHVAL . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.8 HASHKEY . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.9 FLOWID . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.10 CHALLENGE . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.11 LSET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.12 KEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7. State Machine . . . . . . . . . . . . . . . . . . . . . . . 36
Ylitalo, et al. Expires July 28, 2004 [Page 2]
Internet-Draft WIMP January 2004
7.1 States . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.2 State Processes . . . . . . . . . . . . . . . . . . . . . . 36
7.3 State Loss . . . . . . . . . . . . . . . . . . . . . . . . . 38
8. Security Considerations . . . . . . . . . . . . . . . . . . 40
8.1 Context establishment exchange . . . . . . . . . . . . . . . 40
8.1.1 Man-in-the-Middle attacks . . . . . . . . . . . . . . . . . 40
8.1.2 Denial-of-Service attacks . . . . . . . . . . . . . . . . . 40
8.2 Re-addressing exchange . . . . . . . . . . . . . . . . . . . 41
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 43
Normative references . . . . . . . . . . . . . . . . . . . . 44
Informative references . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45
A. Example of secure reverse hash chain generation . . . . . . 46
B. Goals for IPv6 Site-Multihoming Architectures . . . . . . . 47
B.1 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . 47
B.2 Load Sharing . . . . . . . . . . . . . . . . . . . . . . . . 47
B.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . 47
B.4 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
B.5 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.6 Transport-Layer Survivability . . . . . . . . . . . . . . . 48
B.7 Impact on DNS . . . . . . . . . . . . . . . . . . . . . . . 48
B.8 Packet Filtering . . . . . . . . . . . . . . . . . . . . . . 48
B.9 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 48
B.10 Impact on Routers . . . . . . . . . . . . . . . . . . . . . 48
B.11 Impact on Hosts . . . . . . . . . . . . . . . . . . . . . . 48
B.12 Interaction between Hosts and the Routing System . . . . . . 48
B.13 Operations and Management . . . . . . . . . . . . . . . . . 49
B.14 Cooperation between Transit Providers . . . . . . . . . . . 49
B.15 Security compared to IPv4 multihoming . . . . . . . . . . . 49
C. Things MULTI6 Developers should think about . . . . . . . . 50
C.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 50
C.2 Identifiers and locators . . . . . . . . . . . . . . . . . . 50
C.3 On The Wire . . . . . . . . . . . . . . . . . . . . . . . . 50
C.4 Names, Hosts, Endpoints, or none of the above? . . . . . . . 51
Intellectual Property and Copyright Statements . . . . . . . 53
Ylitalo, et al. Expires July 28, 2004 [Page 3]
Internet-Draft WIMP January 2004
1. Introduction
The goal of the IPv6 multihoming work is to allow a site to take
advantage of multiple attachments to the global Internet without
having a specific entry for the site visible in the global routing
table. Specifically, a solution should allow users to use multiple
attachments in parallel, or to switch between these attachment points
dynamically without an impact on the upper layer protocols.
This draft defines a Weak Identifier Multihoming Protocol (WIMP) for
IPv6 hosts. WIMP uses reverse hash chains and secret splitting to
perform enough validation to prevent redirection attacks.
The goals for WIMP are:
o Have no impact on upper layer protocols in general and on
transport protocols in particular.
o Address the security threats in [6].
o Allow routers rewriting the (source) locators as a means of
quickly detecting which locator is likely to work for return
traffic.
o Minimal per-packet overhead.
o No extra round trip for setup through optional piggy-backing.
o Take advantage of multiple locators for load spreading.
1.1 Requirements language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [1].
Ylitalo, et al. Expires July 28, 2004 [Page 4]
Internet-Draft WIMP January 2004
2. Terminology
Upper Layer Protocol (ULP)
A protocol layer immediately above IP. Examples are transport
protocols such as TCP and UDP, control protocols such as ICMP,
routing protocols such as OSPF, and internet or lower-layer
protocols being "tunneled" over (i.e., encapsulated in) IP such as
IPX, AppleTalk, or IP itself.
Interface
A node's attachment to a link.
Locator
An IP layer topological name for an interface. The 128 bit
locators are carried in the IP address fields as the packets
traverse the network.
Identifier
An IP layer identifier for an IP layer endpoint (stack name in
[7]). The transport endpoint is a function of the transport
protocol and would typically include the IP identifier plus a port
number.
Address field
The source and destination address fields in the IPv6 header.
This draft separates identifiers from locators, and therefore
these fields contain locators.
FQDN
Fully Qualified Domain Name
2.1 Cryptographic techniques
2.1.1 Reverse hash chain
Reverse hash chain is cryptographically generated list of data
entities with some interesting characteristics. It is practically
impossible to calculate or otherwise figure out the next value in the
chain even when you know the previous value. However, it is very
easy to verify whether some given value is the next value or not.
Ylitalo, et al. Expires July 28, 2004 [Page 5]
Internet-Draft WIMP January 2004
The chain is created by recursively computing a hash function over a
result of the same function. The initial argument for the first hash
value computation is typically a large random number. The last
generated value of the chain is called as the "anchor" or "root"
value. The hash values are revealed in the reverse order starting
from the anchor value.
Hn = Hash(challenge)
Hn-1 = Hash(Hn)
...
H0 = anchor = Hash(H1)
CHAIN: H0,..,Hn
This technique is usually applied based on an assumption that only an
authentic end-point knows the correct successor values of the chain.
In the bootstrapping process, the end-point computes a new hash chain
and reveals the anchor value of the chain to its peer.
Each hash chain can be used only once.
2.1.2 Reverse hash chain and message authentication
Hashed message authentication codes (HMAC; RFC2104) are typically
used to authenticate messages with a symmetric key. This requires,
naturally, that all communicating peers share a secret.
Example: HMAC(key, Message).
Reverse hash chain values can be used as keys in the message
authentication. This is different from the shared secret scheme
because anybody who is able to receive the subsequent messages is
able to verify that the messages belong together. The reverse hash
chain value (key) used in message authentication is not revealed
before the next message. In other words, the peer is able verify the
message only after it has received the next message. This procedure
can be used to verify that all subsequent messages come from the same
entity than the first message. In other words, the hash chain binds
the messages together.
A Man-in-the-Middle (MitM) attacker is not able to (unnoticeably)
modify the messages after the first message in the exchange. However,
an attacker may spoof the first message and use own hash chain. The
protocol is based on opportunistic principle where the first message
must be sent by an authentic node. The last message should contain
only the last hash value, Hn.
Ylitalo, et al. Expires July 28, 2004 [Page 6]
Internet-Draft WIMP January 2004
Message_1: Message, HMAC(H1, Message)
Message_2: Message, H1, HMAC(H2, Message)
Message_3: Message, H2, HMAC(H3, Message)
...
Message_n: Message, Hn-1, HMAC(Hn, Message)
Message_n+1: Hn
2.1.3 Chained bootstrapping
In the basic model, each reverse hash chain is an independent entity.
This is not a problem if the anchor of the chain can be
authenticated, and if the hash chain is known to be long enough to
have values to every message in the communication session. However,
it is possible to use short hash chains to avoid extra computation.
Basically, the bootstrapping message can be authenticated using
public keys. In the opportunistic mode, the peers do not authenticate
the bootstrapping message with signatures, but rely that all
subsequent messages are coming from the same peer. Two independently
created reverse hash chains can be linked together with a Hash
computation. The last value of the first reverse hash chain is used
to authenticate the first value of the second chain:
...
Message_n: Message, H1_new, Hn-1, HMAC(Hn, Message)
Message_n+1: Message, Hn, HMAC(H2_new, Message)
Message_n+2: Message, H2_new, HMAC(H3_new, Message)
...
2.1.4 Secret splitting
In secret splitting, the secret is divided into several pieces. Any
piece alone does not give enough information for an attacker to
create the original secret. The only way to create the secret is to
posses all the pieces of the key.
The simplest scheme splits a secret into two pieces. The splitting is
done by generating a random-bit string, the same length as the
secret, that will represent one piece of the split. The secret is
then XORed with the random string to generate the other piece.
Essentially, the secret is encrypted with a one-time pad. The pieces
are the encrypted message, and the pad.
Ylitalo, et al. Expires July 28, 2004 [Page 7]
Internet-Draft WIMP January 2004
Example:
secret XOR random_string = encrypted_message
secret_piece_1 = random_string
secret_piece_2 = encrypted_message
The original secret can be reconstructed by XORing the pieces
together. However, each piece alone can not be used to reconstruct
the secret, not even with the highest possible computing power. One
secret can very easily be divided into more than two pieces. What is
needed is just more random-bit strings that are XORed into the
secret.
Secret splitting is useful technique for storing secrets in two
physical places, or for sending a secret to the other end-point using
two or more parallel communication paths.
2.2 Notational Conventions
- I is an initiating host, i.e. an initiator.
- R is a responding host, i.e. a responder.
- ID(I) is an identifier for I.
- ID(R) is an identifier for R.
- FQDN(R) is the domain name for R.
- Ls(I) is the locator set for I, which consists of L1(I), L2(I),
... Ln(I).
- Ls(R) is the locator set for R.
- F(I) is a flowid assigned by the initiator and used by the
responder. The responder uses F(I) in packets going to the
initiator. F(I) is a tag for the host-pair context at the
initiator.
- F(R) is a flowid assigned by the responder and used by the
initiator.
- Hk(I) is k:th hash value in a initiator's reverse hash chain.
The 'H0(I)' is the first revealed value, i.e. the "anchor" of the
reverse hash chain. Note that the parameter k defines the
revealing order, not the computation order.
Ylitalo, et al. Expires July 28, 2004 [Page 8]
Internet-Draft WIMP January 2004
- Hk(R) is k:th hash value in a responder's reverse hash chain.
Ylitalo, et al. Expires July 28, 2004 [Page 9]
Internet-Draft WIMP January 2004
3. Protocol overview
In order to prevent redirection attacks WIMP relies on the ability to
verify that the entity requesting redirection indeed holds the
successor values of a hash chain and is able to combine a divided
secret that is sent via parallel paths. WIMP can be divided into two
exchanges: context establishment and re-addressing exchange. The
former exchange establishes a state for both communication
end-points. The re-addressing exchange is used to update the
locators belonging to the communicating parties. WIMP layer hides
multiple addresses from the upper layer protocols.
3.1 WIMP layer
WIMP layer is located between IP and the ULPs, as shown in figure 1,
in order to provide ULP independence. Conceptually the WIMP layer
behaves as if it is an extension header, which would be ordered
immediately after any hop-by-hop options in the packet.
+-----------------------------------+
| Transport Protocols |
+-----------------------------------+
| AH | ESP | Frag/reass | Dest opts |
+-----------------------------------+
| WIMP layer |
+-----------------------------------+
| IP |
------------------------------------+
Figure 1: Protocol stack
All protocols above WIMP layer use 128 bit identifiers (IDs). The
IDs are non-routable by their nature and never used in the IPv6
header in the network. An ID consists of an initial 2 bit prefix of
01, followed by 126 bits suffix that is a hash. The suffix in the
initiator's identifier, ID(I), is a hash of a nonce. The suffix in
the responder's identifier, ID(R), is constructed taking a hash of
the responder's FQDN(R).
Applications and upper layer protocols use IDs which the WIMP layer
will map to/from locators (see figure 2). The WIMP layer maintains
state, called host-pair context, in order to perform this mapping.
The mapping is performed consistently at the initiator and the
responder, thus from the perspective of the upper layer protocols
packets appear to be sent using IDs from end to end, even though the
packets travel through the network containing locators in the IP
address fields, and even though those locators might be rewritten in
flight. The result of this consistent mapping is that there is no
Ylitalo, et al. Expires July 28, 2004 [Page 10]
Internet-Draft WIMP January 2004
impact on the ULPs. In particular, there is no impact on
pseudo-header checksums and connection identification.
---------------------- ----------------------
| Initiator | | Responder |
| | | |
| ULP | | ULP |
| | src ID(I) | | ^ |
| | dst ID(R) | | | src ID(I) |
| v | | | dst ID(R) |
| WIMP | | WIMP |
| | src L1(I) | | ^ |
| | dst L1(R) | | | src L1(I) |
| v | | | dst L1(R) |
| IP | | IP |
---------------------- ----------------------
| ^
-- cloud with some routers -------
Figure 2: Mapping identifiers to locators.
Layering AH and ESP above the WIMP means that IPsec can be made to be
unaware of locator changes the same way that transport protocols can
be unaware. Thus the IPsec security associations remain stable even
though the locators are changing. Layering the fragmentation header
above the WIMP makes reassembly robust in the case that there is
broken multi-path routing which results in using different paths,
hence potentially different source locators, for different fragments.
3.2 Host-Pair Context
The initiator creates a host-pair context based on IDs and the
locator set learned from the DNS. The responder establishes a state
after receiving the second message from the initiator.
The context state contains the following information:
- Context identifiers (e.g. identities and flow id's)
- Locator and locator status (e.g. if locator has been verified,
and which locators are preferred for communication)
- Hash chain information (e.g. parameters needed in the
construction of hash chains, last used local chains values, and
last known peer chain values)
Every IP packet must contain information about the related host-pair
context. Basically, every packet could contain an extra extension
Ylitalo, et al. Expires July 28, 2004 [Page 11]
Internet-Draft WIMP January 2004
header including the IDs. However, that would add extra overhead to
the packets. Instead, we use flowid field in the IPv6 header to
represent the host-pair context. Conceptually one could view the
approach as if both IDs being present in every packet, but with a
header compression mechanism applied that removes the need for the
IDs once the state has been established. The flowid serves as a
convenient "compression tag" without increasing the packet size.
Flowids are used in regular IPv6 packets to find the right context
for received packets. Each host selects for itself the flowid it
wants to see in packets received from its peer. This allows it to
select different flowids for different peers.
The problem related to flowid selection is identical with the IPSEC
SPI selection. A host cannot select a flowid for IP packets going to
its peer. Otherwise, two different hosts might select the same flowid
and the peer could not uniquely identify the correct host-pair
context using the received flowid.
Selected flowid is communicated to the peer in the third (CCR) and
fourth (CONF) packets of the context creation exchange.
3.3 Generating reverse hash chains
In general, the way by which the reverse hash chains are generated is
a local matter. The hash chains are needed by the initiator and the
responder during the context establishment exchange. Also, the
initiator of the re-addressing exchange needs to construct a new hash
chain.
This document sets the following requirements for the hash chains
generation:
- Each reverse hash chain MUST be unique for each host-pair
context establishment and re-addressing exchange.
- The responder MUST be able to reconstruct the same reverse hash
chain based on the parameters that are present in the context
check reply message (CCR) in order to be stateless at the
beginning of context establishment exchange.
- The responder MUST be able to reconstruct the same reverse hash
chain based on the parameters that are present in the context
check reply message (CCR) even if the system boots.
- The initial argument of the hash chain is never revealed to
other parties.
Ylitalo, et al. Expires July 28, 2004 [Page 12]
Internet-Draft WIMP January 2004
- The length of the hash chain is implementation specific but must
be the same every time a chain is constructed.
Theoretically speaking, the minimum length of the hash chain is three
(3) hash values. This will last for one context establishment
exchange, and one re-addressing exchange for both direction (note
that re-addressing exchange includes a bootstrapping procedure where
a new hash chain is created for the initiator). However, each
unsuccessful re-addressing exchange attempt will require one more
hash chain value. Failures in re-addressing exchange may be due to
connection loss in some of the locators, or an active attack.
Appendix A gives one example of secure hash chain generation.
3.4 Context establishment exchange
The context establishment exchange serves to manage the establishment
of state between an initiator and a responder. The procedure uses
delayed authentication principle where initial message exchange are
verified with the parameters included in the latter messages. The
procedure is designed to be stateless for the responder side. At the
end of the exchange both parties have a uniquely identifiable
host-pair context containing the peer's anchor value.
Initiator Responder
compute hash chain
generate random ID(I)
select flowid F(I)
INIT: IDs, challenge_I,
HMAC_INIT{H0(I), (IDs|challenge_I|F(I))}
-------------------------->
compute temporary hash chain
CC: IDs, HMAC_INIT, HMAC_CC{H0_R, (IDs|HMAC_INIT)}
<-------------------------
remain stateless
CCR: IDs, H0(I), challenge_I, F(I), HMAC_INIT, HMAC_CC
-------------------------->
recompute the hash chain
verify HMAC_INIT and HMAC_CC
select flowid F(R)
CONF: IDs, H0(R), F(R)
<--------------------------
verify HMAC_CC
Ylitalo, et al. Expires July 28, 2004 [Page 13]
Internet-Draft WIMP January 2004
The initiator first sends a context initiator message, INIT, to the
responder. The INIT message contains the IDs, a challenge and a keyed
hash. The hash, having the anchor value as a key, is computed over
the IDs, challenge and flowid. The flowid is sent later in the
context check reply message (CCR).
Once the responder receives the INIT message, it must check that it
does not already have a host-pair context with the ID pair. If the
context is not found, the responder continues with the negotiation.
However, it does not want to establish a state because it is not able
to verify the origin of the message. In order to remain stateless,
the responder computes a temporary hash chain using the initiator's
challenge in the INIT packet, and sends a context check message (CC)
to the initiator. The CC message is protected with the anchor value
of responder hash chain.
The initiator replies to the CC message with a context check reply
message (CCR) and proves that it was reachable at the specific
location by disclosing the anchor value. The CCR message includes the
flowid that uniquely identifies the host pair context to the
initiator.
Again, the responder does not accept CCR packets with an ID pair that
already has a host pair-context. If the context is not found, the
responder recomputes its own hash chain and verifies the keyed hashes
(HMAC_INIT and HMAC_CC). The anchor value of the initiator hash chain
binds the INIT and CCR messages together, and in this way the
responder is able to verify that messages are coming from the same
host. If the keyed hashes were valid, the responder names the host
pair context by generating a flowid for it, and replies with a
context confirmation message (CONF) revealing its anchor value.
The initiator verifies the keyed hash in the CC message with the
anchor value received in the CONF message, and finalizes its state.
The context establishment exchange has been designed in the way that
it can be reused for secure resynchronisation. If the initiator
receives a RESYNC message, it SHOULD start a new handshake with the
INIT message by including the latest disclosed responder's hash chain
value. In this way, the initiator can be sure that the RESYNC message
really originated from the responder, and not from an attacker. In
this case, the responder discloses the successor hash chain value in
the CONF message, instead of the anchor value.
3.5 Re-addressing exchange
Once the state has been completed, both hosts have a host-pair
context. At this point, the initiator has received the responder's
Ylitalo, et al. Expires July 28, 2004 [Page 14]
Internet-Draft WIMP January 2004
locator set from the DNS. However, it is possible that the responder
has published only one IP address in the DNS, but it is still able to
multihome, and has several IP addresses. Basically, both hosts may
send to their peers the locator sets. A host may verify the peer's
addresses on demand basis or all at once.
Initiator Responder
compute new hash chain
REA: IDs, Ls(I), H1(I), H0_new(I), challenge,
HMAC_REA{H2(I), (IDs|Ls(I)|H1(I)|H0_new(I)|challenge}
-------------------------->
verify H1(I)
generate a divided secret using H1(R)
send AC per new locator
AC1: IDs, Key_count, Key_mask, key_piece, challenge
... <-------------------------
ACn <-------------------------
combine the key pieces
verify the combined key
ACR: IDs, Key_combined, Key_mask, H2(I)
-------------------------->
verify the combined key H1(R)
verify HMAC_REA
The re-addressing exchange is a three way handshake. The
re-addressing message (REA) has two purposes. First, it contains the
initiator's locator set. Second, it bootstraps a new hash chain.
Once the responder receives a REA message, it verifies that the hash
chain value H1(I) belongs to the initiator (this example assumes that
the previously revealed hash chain value was the anchor, H0). In
addition, the responder stores the initiator's new anchor value
H0_new(I) and the new challenge value into the host-pair context.
The responder divides its own next unused hash chain value into
pieces using the secret splitting technique. The hash chain value is
divided into as many parts as there were locators in the received
locator set. The responder defines a key mask for each of the key
pieces (see Section 6.12). The key mask will later allow the
responder to check if all pieces found their way to the initiator. It
is possible that the initiator is not reachable via all of the
locators in the locator set.
Ylitalo, et al. Expires July 28, 2004 [Page 15]
Internet-Draft WIMP January 2004
The responder sends one address check message (AC) per locator in the
received locator set. Each AC message contains one piece of the hash
chain value. The initiator must have a local policy on how long it
waits for the upcoming AC messages.
If the initiator receives all pieces of the hash chain value, it
verifies that it is a successor value of the responder's hash chain.
Otherwise, the initiator MAY stop the re-addressing exchange
procedure. The initiator makes an OR operation with all of the
received key masks and includes the result of the operation with the
combined key to the address check reply message (ACR).
The responder verifies the combined key using the key mask that
indicates the key pieces that the initiator was able to receive. In
addition, the responder uses the received initiator's hash chain
value to authenticate the earlier received REA message. Finally, the
responder marks the corresponding locators in the initiator's locator
set as verified.
Ylitalo, et al. Expires July 28, 2004 [Page 16]
Internet-Draft WIMP January 2004
4. Packet processing
Each host is assumed to have a separate WIMP implementation that
manages the host's host-pair context and handles requests for new
ones. Each host-pair context is governed by a state machine, with
states defined in Section 7. WIMP implementation can simultaneously
maintain host-pair contexts with more than one host. Furthermore,
WIMP implementation may have more than one active host-pair context
with another host; in this case, host-pair contexts are distinguished
by their respective IDs and flowids. It is not possible to have more
than one host-pair contexts between any given pair of IDs.
Consequently, the only way for two hosts to have more than one
parallel associations is to use different IDs, at least in one end.
The processing of packets depends on the state of the host-pair
context(s) with respect to the originator of the packet. A WIMP
implementation determines whether it has an active association with
the originator of the packet based on the IDs or the flowid of the
packet.
4.1 Processing outgoing application data
In an WIMP host, an application can send application level data using
IDs as source and destination identifiers. The IDs can be specified
via a backwards compatible API. However, whenever there is such
outgoing data, the stack has to send the resulting datagram using
appropriate source and destination IP addresses.
The following steps define the conceptual processing rules for
outgoing datagrams destinated to a ID(R).
1. If the datagram has a specified source address, it MAY be a
ID(I). If it is not, the implementation MAY replace the source
address with a ID(I). Otherwise it MUST send the packet using
the given IP addresses and bypass the WIMP layer.
2. If the datagram has an unspecified source address, the
implementation MUST choose a suitable source ID(I) for the
datagram. In selecting a proper ID(I), the implementation MUST
consult the table of currently active WIMP sessions, and
preferably select a ID(I) that already has an active session with
the target ID(R).
3. If there is no active WIMP session with the ID(R), one must be
created by running the context establishment exchange. The
implementation MAY piggy-pack ULP payload to the exchange
packets.
Ylitalo, et al. Expires July 28, 2004 [Page 17]
Internet-Draft WIMP January 2004
4. Once there is an active WIMP session for the given ID(R), the
outgoing datagram does not contain WIMP headers. Instead, the
IDs are represented by flowids in the IP headers.
5. The IDs in the datagram are replaced with suitable IP addresses.
The rules defined in [2] MAY be followed.
4.2 Processing incoming application data
Incoming WIMP datagrams arrive as normal IP packets containing WIMP
flowids. In the usual case the receiving host has a corresponding
host-pair context, identified by the flowid in the packet. However,
if the host has crashed or otherwise lost its WIMP state, it may not
have such a host-pair context.
The following steps define the conceptual processing rules for
incoming datagrams targeted to a WIMP host-pair context.
1. Detect the proper host-pair context, using the flowid. If there
are no host-pair context identified with the flowid, the host MAY
reply with a RESYNC packet. Sending such RESYNCs MUST be rate
limited. However, if the receiver has an open socket
corresponding the IP addresses in the IP header it MUST process
the packet as standard IP datagram.
2. If a proper host-pair context is found, the packet is processed
by WIMP. The IP addresses in the datagram are replaced with the
IDs associated with the host-pair context.
3. The datagram is delivered to the upper layer. Demultiplexing the
datagram the right upper layer socket is based on the IDs.
Ylitalo, et al. Expires July 28, 2004 [Page 18]
Internet-Draft WIMP January 2004
5. Packets
There are eight basic WIMP packets. Four are for the context
establishment exchange, three are for re-addressing, and one is for
state loss.
Packets consist of the fixed header as described in Section 6.1,
followed by the parameters. The parameter part, in turn, consists of
zero or more TLV coded parameters.
Packet representation uses the following operations:
() parameter
[] optional parameter
An upper layer payload MAY follow the WIMP header. The payload proto
field in the header indicates if there is additional data following
the WIMP header. The WIMP packet, however, MUST NOT be fragmented.
This limits the size of the possible additional data in the packet.
5.1 INIT - the context initiator packet
The WIMP header values for the INIT packet:
Header:
Packet Type = 1
SRC ID = Initiator's ID
DST ID = Responder's ID
IP( WIMP ( CHALLENGE, HASH-INIT ))
Valid control bits: P
The INIT packet contains the fixed WIMP header, initiator's
challenge, and HASH-INIT TLV (Section 6.3).
If the INIT message is a response to a RESYNC packet the initiator
SHOULD replace the challenge with the responder's old challenge. In
this way, the initiator is able to verify later that the responder
has really lost its state.
The Initiator generates the Responder's identifier, ID(R), using the
the Responder's FQDN. If the Initiator does not know the Responder's
FQDN, it MUST use IP addresses for the application identifiers in the
socket API and by pass the WIMP protocol.
Ylitalo, et al. Expires July 28, 2004 [Page 19]
Internet-Draft WIMP January 2004
5.2 CC - the context check packet
The WIMP header values for the CC packet:
Header:
Packet Type = 2
SRC ID = Responder's ID
DST ID = Initiator's ID
IP ( WIMP ( HASH-INIT, HASH-CC ))
Valid control bits: P
The IDs MUST be the same received in INIT. (If the Responder has
multiple IDs, the responder ID used MUST match Initiator's request.)
The Responder copies the HASH-INIT TLV from INIT message to the CC
message
The Responder computes a temporary hash chain using the received
initiator's challenge and IDs (see Section 3.3). The responder uses
the generated anchor value of the temporary hash chain as a key for
the HASH-CC computation Section 6.4). (Note: The responder does not
store the temporary hash chain values.)
5.3 CCR - the context check reply packet
The WIMP header values for the CCR packet:
Header:
Type = 3
SRC ID = Initiator's ID
DST ID = Responder's ID
IP ( WIMP ( ANCHOR, FLOWID, CHALLENGE, [HASHVAL,] HASH-INIT, HASH-CC )
Valid control bits: P
The IDs used MUST match the ones used in the previous messages.
If the initiator already has a host-pair context for the responder,
but responder has lost its state, the initiator SHOULD sent the
latest known responder's hash value, HASHVAL, and the old challenge,
to the responder.
The Initiator reveals the anchor value that was used in HASHKEY TLV
in the HASH-INIT computation in the INIT message.
Ylitalo, et al. Expires July 28, 2004 [Page 20]
Internet-Draft WIMP January 2004
Initiator copies the HASH-INIT, and HASH-CC TLVs from the CC message
to the CCR message. In addition, CCR message includes the anchor,
flowid, challenge, and responder's latest hash value. .The Initiator
selects a flowid that the responder uses to send packets to the
Initiator (Section 3.2)
5.4 CONF - the context confirm packet
The WIMP header values for the CONF packet:
Header:
Packet Type = 4
SRC ID = Responder's ID
DST ID = Initiator's ID
IP ( WIMP ( ANCHOR, FLOWID ))
Valid control bits: P
The Responder reveals the anchor value that was used in HASHKEY TLV
in the HASH-CC computation in the CC message.
The Responder selects a flowid that the initiator uses to send
packets to the Responder.
5.5 RESYNCH - the re-synchronization packet
The WIMP header values for the RESYNC packet:
Header:
Packet Type = 5
SRC ID = Responder's ID
DST ID = (zero)
IP ( WIMP ( FLOWID ))
Valid control bits: -
Once a responder receives an IP packet with an unknown flowid it
replies with RESYNC packet and copies the received flowid into the
message. However, if the responder has an open socket corresponding
the IP addresses in the IP header it MUST process the packet as a
standard IP datagram.
Ylitalo, et al. Expires July 28, 2004 [Page 21]
Internet-Draft WIMP January 2004
5.6 REA - The re-addressing packet
The WIMP header values for the REA packet:
Header:
Packet Type = 10
SRC ID = Initiator's ID
DST ID = Responder's ID
IP ( WIMP ( LSET, HASHVAL, ANCHOR, CHALLENGE, HASH-REA ))
Valid control bits: P
The REA message contains initiator's locator set. The node that was
the responder during the context establishment exchange is the
initiator when it initiates a re-addressing exchange. The initiating
party of re-addressing exchange is called the initiator in the REA
context.
The Initiator revels a successor hash value (HASHVAL TLV) of its
current hash chain. In addition, it bootstraps a new hash chain by
revealing a new anchor value (ANCHOR TLV). The challenge used to
generate a new hash chain is included into the message. Hash chain
generation for the initiator is discussed in Section Section 3.3.
Section 6.5 describes how the HASH-REA is computed.
5.7 AC - The address check packet
The WIMP header values for the AC packet:
Header:
Packet Type = 11
SRC ID = Responder's ID
DST ID = Initiator's ID
IP ( WIMP ( KEY, CHALLENGE ))
Valid control bits: P
The responder divided a secret into as many pieces as there were
addresses in locator set in the received REA message. The key count
contains the total number of the key pieces. The key mask is an
identifier for a key piece in the KEY TLV. The challenge TLV includes
the challenge received in the REA message. The initiator is able to
bind the received AC to the correct exchange using the challenge. The
Ylitalo, et al. Expires July 28, 2004 [Page 22]
Internet-Draft WIMP January 2004
responder sends one AC packet per locator in the received locator
set. (Note: Each AC contains one key piece.)
5.8 ACR - The address check reply packet
The WIMP header values for the AC packet:
Header:
Packet Type = 12
SRC ID = Initiator's ID
DST ID = Responder's ID
IP ( WIMP ( KEY, HASHVAL ))
Valid control bits: P
The KEY TLV is constructed of the received key pieces and their key
masks. The HASHVAL TLV contains the hash value that was used as a key
in the REA packet in HASH-REA TLV.
Ylitalo, et al. Expires July 28, 2004 [Page 23]
Internet-Draft WIMP January 2004
6. Message formats
6.1 Payload format
All WIMP packets start with a fixed header.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | Type | VER. | RES. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Controls | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Identifier (ID) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's Identifier (ID) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ WIMP Parameters /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The WIMP header is logically an IPv6 extension header followed by a
next header that is defined in Next Header field. If no next headers
follow, the decimal 59, IPPROTO_NONE, the IPV6 no next header value,
is used.
The Header Length field contains the length of the WIMP header and
the length of parameters in 8 bytes units, excluding the first 8
bytes. Since all WIMP headers MUST contain the sender's and
receiver's ID fields, the minimum value for this field is 4, and
conversely, the maximum length of the WIMP Parameters field is
(255*8)-32 = 2008 bytes.
The Packet Type indicates the WIMP packet type. The individual
packet types are defined in the relevant sections. If a WIMP host
receives a packet that contains an unknown packet type, it MUST drop
the packet.
Ylitalo, et al. Expires July 28, 2004 [Page 24]
Internet-Draft WIMP January 2004
The Version is four bits. The current version is 1. The version
number is expected to be incremented only if there are incompatible
changes to the protocol. Most extensions can be handled by defining
new packet types, new parameter types, or new controls.
The following four bits are reserved for future use. They MUST be
zero when sent, and they SHOULD be ignored when handling a received
packet.
The ID fields are always 128 bits (16 bytes) long.
6.1.1 WIMP Controls
The WIMP control section transfers information about the structure of
the packet and capabilities of the host.
The following fields have been defined:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | |P| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P - Piggy backing The sending host is capable of sending and
receiving additional data (e.g. ESP) in WIMP packets.
The rest of the fields are reserved for future use and MUST be set to
zero on sent packets and ignored on received packets.
6.1.2 Checksum
The checksum field is located at the same location within the header
as the checksum field in UDP packets, enabling hardware assisted
checksum generation and verification. Note that since the checksum
covers the source and destination addresses in the IP header, it must
be recomputed on WIMP based middle-boxes.
The pseudo-header [3] contains the source and destination IPv6
addresses, WIMP packet length in the pseudo-header length field, a
zero field, and the WIMP protocol number (TBD) in the Next Header
field. The length field is in bytes and can be calculated from the
WIMP header length field: (WIMP Header Length + 1) * 8.
6.2 Parameters
The parameters are used to carry the hash chain values associated
with the sender's ID, together with other related security
information. The parameters consists of ordered parameters, encoded
in TLV format.
Ylitalo, et al. Expires July 28, 2004 [Page 25]
Internet-Draft WIMP January 2004
The following parameter types are currently defined.
TLV Type Length Data
(TBD)
6.2.1 TLV format
The TLV encoded parameters are described in the following
subsections. The type-field value also describes the order of these
fields in the packet. The parameters MUST be included into the
packet so that the types form an increasing order. If the order does
not follow this rule, the packet is considered to be malformed and it
MUST be discarded.
All the TLV parameters have a length which is a multiple of 8 bytes.
When needed, padding MUST be added to the end of the parameter so
that the total length becomes a multiple of 8 bytes. This rule
ensures proper alignment of data. If padding is added, the Length
field MUST NOT include the padding. Any added padding bytes MUST be
set zero by the sender, but their content SHOULD NOT be checked on
the receiving end.
Consequently, the Length field indicates the length of the Contents
field (in bytes). The total length of the TLV parameter (including
Type, Length, Contents, and Padding) is related to the Length field
according to the following formula:
Total Length = 11 + Length - (Length + 3) % 8;
Ylitalo, et al. Expires July 28, 2004 [Page 26]
Internet-Draft WIMP January 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |C| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Contents /
/ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type code for the parameter
C Critical. One if this parameter is critical, and
MUST be recognized by the recipient, zero otherwise.
The C bit is considered to be a part of the Type field.
Consequently, critical parameters are always odd
and non-critical ones have an even value.
Length Length of the parameter, in bytes.
Contents Parameter specific, defined by Type
Padding Padding, 0-7 bytes, added if needed
Critical parameters MUST be recognized by the recipient. If a
recipient encounters a critical parameter that it does not recognize,
it MUST NOT process the packet any further.
Non-critical parameters MAY be safely ignored. If a recipient
encounters a non-critical parameter that it does not recognize, it
SHOULD proceed as if the parameter was not present in the received
packet.
Ylitalo, et al. Expires July 28, 2004 [Page 27]
Internet-Draft WIMP January 2004
6.3 HASH-INIT
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HASH |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65500
Length 20
HASH
160 bit SHA1 is computed over:
- WIMP common header.
- HASHKEY TLV, Initiator's second hash value, H1(I)
- FLOWID TLV, initiator.
- CHALLENGE TLV, 128 challenge generated by the initiator.
excluding the HASH-INIT parameter. The checksum field MUST
be set to zero and the WIMP header length in the WIMP common
header MUST be calculated to cover all the included
parameters when the SHA1 is calculated.
HASH-INIT calculation and verification process:
INIT message sender:
1. Create the INIT message, containing HASHKEY, FLOWID, and
CHALLENGE TLVs, without the HASH-INIT TLV.
2. Calculate the length field in the WIMP header.
3. Compute the SHA1.
4. remove the HASHKEY, and FLOWID TLVs.
5. Add the HASH-INIT TLV to the packet.
6. Recalculate the length field in the WIMP header.
CCR message receiver:
1. reconstruct the INIT message, containing HASHKEY, FLOWID, and
Ylitalo, et al. Expires July 28, 2004 [Page 28]
Internet-Draft WIMP January 2004
CHALLENGE TLVs, without the HASH-INIT TLV.
2. Calculate the WIMP packet length in the WIMP header and clear the
checksum field (set it to all zeros).
3. Compute the HASH-INIT and verify it against the received
HASH-INIT.
6.4 HASH-CC
The TLV structure is the same as in Section 6.3. The fields are:
Type 65502
Length 20
HASH 160 bit SHA1 is computed over:
- WIMP common header.
- HASHKEY TLV, the responder's hash chain value.
- HASH-INIT TLV, received in the INIT message,
excluding the HASH-CC parameter. The checksum field MUST
be set to zero and the WIMP header length in the WIMP common
header MUST be calculated to cover all the included
parameters when the SHA1 is calculated.
HASH-CC calculation and verification process:
CC message sender:
1. Create the CC message, containing HASHKEY, and HASH-INIT TLVs,
without HASH-CC TLV.
2. Calculate the length field in the WIMP header.
3. Compute the SHA1.
4. remove the HASHKEY TLV.
5. Add the HASH-CC TLV to the packet.
6. Recalculate the length field in the WIMP header.
CCR and CONF message receiver:
1. reconstruct the CC message, containing HASHKEY, and HASH-INIT
TLVs, without the HASH-CC TLV.
2. Calculate the WIMP packet length in the WIMP header and clear the
Ylitalo, et al. Expires July 28, 2004 [Page 29]
Internet-Draft WIMP January 2004
checksum field (set it to all zeros).
3. Compute the HASH-CC and verify it against the received HASH-CC.
6.5 HASH-REA
The TLV structure is the same as in Section 6.3. The fields are:
Type 65504
Length 20
HASH 160 bit SHA1 is computed over:
- WIMP common header,
- LSET TLV, Initiator's locator set.
- HASHVAL TLV, a hash value, Hk, of the initiator's
hash chain
- HASHKEY TLV, a successor hash value, Hk+1, of the
initiator's hash chain
- ANCHOR TLV, the anchor value, H0, of the initiator's
new hash chain
- CHALLENGE TLV, the challenge used in the new hash chain
generation.
excluding the HASH-REA parameter. The checksum field MUST
be set to zero and the WIMP header length in the WIMP common
header MUST be calculated to cover all the included
parameters when the SHA1 is calculated.
HASH-REA calculation and verification process.
REA message sender:
1. Create the REA message, containing LSET, HASHVAL, ANCHOR, HASHKEY
and CHALLENGE TLVs, without HASH-REA TLV.
2. Calculate the length field in the WIMP header.
3. Compute the SHA1.
4. remove the HASHKEY TLV.
5. Add the HASH-CC TLV to the packet.
6. Recalculate the length field in the WIMP header.
REA message receiver:
1. Add HASHKEY TLV
Ylitalo, et al. Expires July 28, 2004 [Page 30]
Internet-Draft WIMP January 2004
2. Remove and store HASH-REA TLV.
3. Calculate the WIMP packet length in the WIMP header and clear the
checksum field (set it to all zeros).
4. Compute the HASH-REA and verify it against the received HASH-REA.
6.6 ANCHOR
The TLV structure is the same as in Section 6.3. The fields are:
Type 10
Length 20
HASH 160 bit SHA1. An anchor value of a hash chain.
6.7 HASHVAL
The TLV structure is the same as in Section 6.3. The fields are:
Type 12
Length 20
HASH 160 bit SHA1 hash value. It is generated by computing
a hash over a successor hash chain value.
6.8 HASHKEY
The TLV structure is the same as in Section 6.3. The fields are:
Type 14
Length 20
HASH 160 bit SHA1 hash value that is used as a key in
HASH-INIT, HASH-CC and HASH-REA TLV computation.
The key value is never revealed in the
same message as the corresponding authentication hash.
6.9 FLOWID
The FLOWID parameter contains the flowid that the receiving host must
use when sending data to the sending host.
Ylitalo, et al. Expires July 28, 2004 [Page 31]
Internet-Draft WIMP January 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flowid | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 16
Length 4
Reserved Zero when sent, ignored when received
Flowid 20 bit flowid
6.10 CHALLENGE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| challenge |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 20
Length 20
Reserved Zero when sent, ignored when received
challenge 128 bit random number
Ylitalo, et al. Expires July 28, 2004 [Page 32]
Internet-Draft WIMP January 2004
6.11 LSET
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address #1 |
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address #n |
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 22
Length variable
Reserved Zero when sent, ignored when received
Address IPv6 address
Ylitalo, et al. Expires July 28, 2004 [Page 33]
Internet-Draft WIMP January 2004
6.12 KEY
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC ID | Hash ID | Key Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key piece 160 bit (AC message) / |
/ Combined key 160 bit (ACR message) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 26
Length variable
AC ID An increasing counter that identifies the exchange for
the responder.
Hash ID The order number of a hash chain value in the responder's
hash chain. The hash chain value that is divided into key
pieces.
Key count The total number of key pieces sent/received
Key Mask
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The responder defines a bit in the mask for a key piece.
Key piece A hash chain value is divided into (160 bit) key pieces
by the responder.
Combined key The initiator constructs a combined key using the key
pieces.
The AC ID is related to a divided secret, i.e. a hash chain value.
Every key piece related to that value must have the same AC ID.
Responder sending AC message:
The key count field value in the AC packet is the total number of key
pieces sent by the responder. I.e. the total number of sent AC
packets. Each KEY-MASK TLV in one AC packet contains a key piece and
corresponding bit on in the key mask field
(Note: The responder is able to make a return routability test
maximum for 32 addresses per divided key.)
Ylitalo, et al. Expires July 28, 2004 [Page 34]
Internet-Draft WIMP January 2004
Initiator sending ACR message:
The initiator makes an OR operation for all received key masks in the
AC packets. The result of the operation is included in the KEY-MASK
TLV in ACR message.The key count field in KEY-MASK TLV in the ACR
message indicates the number of key pieces the initiator received
from the responder. The combined key is included into the KEY-MASK
TLV.
Ylitalo, et al. Expires July 28, 2004 [Page 35]
Internet-Draft WIMP January 2004
7. State Machine
The initiator of the context establishment exchange is called the
initiator. Once the host-pair contexts are established, this initial
distinction is lost. The sender of the REA message is called the
initiator of the re-addressing exchange. In a case of state loss, the
sender of the RESYNCH message becomes a responder. .
The state machine is presented in a single system view, representing
either an Initiator or a Responder. There is not a complete overlap
of processing logic here and in the packet definitions. Both are
needed to completely implement WIMP.
Implementors must understand that the state machine, as described
here, is informational. Specific implementations are free to
implement the actual functions differently.
7.1 States
START , state machine start
INIT-sent , INIT sent by initiator
CCR-sent , CCR sent by initiator
ESTABLISHED , host-pair context established
ESTABLISHED-REA-sent , REA sent
FAILED , host-pair context establishment failed
7.2 State Processes
+---------+
| START |
+---------+
Datagram to send, send INIT and go to INIT-send
Receive INIT, send CC and stay at START
Receive CCR, process
if successful, send CONF and go to ESTABLISHED
if fail, stay at START
Receive IP packet with unknown flowid, send RESYNC and stay at START
Receive ANYOTHER, drop and stay at START
+-----------+
| INIT-sent |
Ylitalo, et al. Expires July 28, 2004 [Page 36]
Internet-Draft WIMP January 2004
+-----------+
Receive INIT, send CC and stay at INIT-sent
Receive CCR, process
if successful, send CONF and go to ESTABLISHED
if fail, stay at INIT-sent
Receive CC, process
if successful, send CCR and go to CCR-sent
if fail, stay at INIT-sent
Receive ANYOTHER, drop and stay at INIT-sent
Timeout, increment timeout counter
If counter is less than INIT_RETRIES_MAX, send INIT and stay at INIT-sent
If counter is greater than INIT_RETRIES_MAX, go to FAILED
+----------+
| CCR-sent |
+----------+
Receive INIT, send CC and stay at CCR-sent
Receive CCR, process
if successful, send CONF and go to ESTABLISHED
if fail, stay at CCR-SENT
Receive CONF, process
if successful, go to ESTABLISHED
if fail, stay at CCR-SENT
Receive ANYOTHER, drop and stay at CCR-sent
Timeout, increment timeout counter
If counter is less than CCR_RETRIES_MAX, send CCR and stay at CCR-sent
If counter is greater than CCR_RETRIES_MAX, go to FAILED
+-------------+
| ESTABLISHED |
+-------------+
REA to send, go to ESTABLISHED-REA-sent
Receive RESYNC, send INIT and cycle at ESTABLISHED
Receive CC, process
if successful, send CCR and stay at ESTABLISHED
if fail, drop, and stay at ESTABLISHED
Receive CONF, process
if successful, update host-pair context and cycle at ESTABLISHED
if fail, drop, and stay at ESTABLISHED
Receive REA, process
if successful, update host-pair context, send ACs,
and cycle at ESTABLISHED
if fail, drop, and stay at ESTABLISHED
Receive ACR, process
if successful, update host-pair context, and cycle at ESTABLISHED
Ylitalo, et al. Expires July 28, 2004 [Page 37]
Internet-Draft WIMP January 2004
if fail, drop, and stay at ESTABLISHED
Receive IP packet for host-pair context, process and stay at ESTABLISHED
Receive ANYOTHER, drop and stay at ESTABLISHED
+-----------------------+
| ESTABLISHED-REA-sent |
+-----------------------+
Receive RESYNC, send INIT and go to ESTABLISHED
Receive REA, process
if successful, update host-pair context, send ACs,
and cycle at ESTABLISHED-REA-sent
if fail, drop, and cycle at ESTABLISHED-REA-sent
Receive AC, process
if successful, send ACR, and go to ESTABLISHED
if fail, sent REA, and cycle at ESTABLISHED-REA-sent
Receive ACR, process
if successful, update host-pair context,
and cycle at ESTABLISHED-REA-sent
if fail, drop, cycle at ESTABLISHED-REA-sent
Receive IP packet for host-pair context, process,
and stay at ESTABLISHED-AC-sent
Receive ANYOTHER, drop and stay at ESTABLISHED-AC-sent
Timeout, increment timeout counter
If counter is less than REA_RETRIES_MAX, send REA,
and stay at ESTABLISHED-REA-sent
If counter is greater than REA_RETRIES_MAX, go to FAILED
7.3 State Loss
WIMP protocol and state machine is designed to recover from one of
the parties crashing and losing its state. The following scenarios
describe the main use cases covered by the design.
No prior state between the two systems.
The system with data to send is the Initiator. The process
follows standard 4 packet context establishment exchange,
establishing the host-pair context.
The initiator has no state with the responder, but the responder
has an earlier host-pair context.
Initiator acts as in no prior state, sending INIT. The
Initiator selects a new random ID(I) and the responder finally
establishes a new host-pair context with the initiator. The old
context will expire due to timers (TBD).
Ylitalo, et al. Expires July 28, 2004 [Page 38]
Internet-Draft WIMP January 2004
The initiator has a host-pair context, but the responder does not.
The responder 'detects' the situation when it receives a packet
that contains an unknown flowid. The responder sends a RESYNC
with received flowid and a NULL (zero) initiator ID. The
initiator gets the RESYNC and initiates a new context
establishment exchange to re-establish the host-pair context
with the existing IDs. The initiator generates a new hash
chain but sends the old challenge, to the responder.
If a host reboots or times out, it has lost its host-pair context.
If the system that lost state has a datagram to deliver to its peer,
it simply restarts the context establishment exchange with INIT
message containing a new ID(I). The responder replies with CC packet.
If a system receives an IP packet for an unknown flowid, the
assumption is that it has lost the state and its peer did not. In
this case, the system replies with a RESYNCH packet. The ID(I) is
typically NULL in the RESYNCH, since the system usually does not know
the peer's ID any more.
The system receiving the RESYNCH packet first checks to see if it has
an established and recently used host-pair context with the party
sending the RESYNCH. If such a context exists, the initiator
initiates a new context establishment exhange by sending INIT
message. Note that the process will result in a new host-pair
context at the responder site, while the initiator is able to use the
existing host-pair context.
Ylitalo, et al. Expires July 28, 2004 [Page 39]
Internet-Draft WIMP January 2004
8. Security Considerations
The initial design choice was to use reverse hash chains instead of
public key technology. The reason for this was that there exists
already a group of authenticated Diffie-Hellman key exhange
protocols. However, protocols using public key technology are
vulnerable for different kind of CPU related denial-of-service
attacks. The trade-off between hash chain based message
authentication and signatures is that hash chains are vulnerable for
a class of man-in-the-middle attacks. However, if we accept that the
first round-trip of the context establishment exchange is open for
such attacks we obtain several advantages. The hash chain computation
is a lightweight operation compared to signature verification.
8.1 Context establishment exchange
8.1.1 Man-in-the-Middle attacks
The context establishment exchange is based on opportunistic
authentication. In other words, both hosts, the initiator and
responder, have to trust the first message comes from the authentic
peer. The responder trusts that the INIT message comes from an
authentic initiator. In a similar way, the initiator trusts that the
CC message comes from an authentic responder. Therefore, the first
round-trip is vulnerable for the MitM attacks.
The second round-trip of the exchange bootstraps the hash chains and
bounds the messages together. The anchor values revealed during the
second round-trip are used to authenticate the first round-trip
messages. A MitM attacker cannot change any values in the CCR
message, because the message is authenticated with the responder's
HMAC. The responder's HMAC, in turn, is computed over the initiator's
HMAC. In this way, the responder does not need to establish a state
once it receives INIT message. In addition, a MitM attacker cannot
reserve a host-pair context by sending CCR message with initiator's
ID because the messages are bound together. Finally, the hash chains
have two main purposes. They bind messages together, and they are
used to authenticate the messages. The hash chain properties were
discussed in more detail in Section 2.1.
8.1.2 Denial-of-Service attacks
The initiator may use any identifier, ID(I), it wants with the
responder. This property protects the initiator from a specific form
of DoS attack. That is, the attacker is not able to establish a
context with the responder using the initiator's identifier if the
initiator chooses its identifier randomly.
Ylitalo, et al. Expires July 28, 2004 [Page 40]
Internet-Draft WIMP January 2004
On the other hand, the beginning of the context establishment
exchange is stateless for the responder in order to avoid attacks
where the attacker is trying to create inconsistent states in the
responder. The responder does a kind of return-routability test
before establishing a state. The initiator has to prove that is
reachable in the location where it sent the initial packet. The
responder may optionally restrict establishing a host-pair context
for an initiator if the responder already has several host-pair
contexts related to same IP addresses.
Basically, the context establishment protocol is vulnerable for a
flowid related attack. The only value that is not protected with HMAC
is the responder's flowid in the last message. The reason for this is
that the responder cannot reserve any values before it creates a
state. The state is created after receiving the CCR message. As a
consequence, the responder cannot include the flowid into its HMAC in
the CC message. a MitM attacker may change the responder's flowid on
the fly in the last message and course a denial-of-service situation.
In other words, the initiator will send IP packets with wrong flowid
to the responder. However, the main objective of the protocol was to
protect the hosts from the re-direction attacks and the presented
attack does not open new vulnerabilities for that part.
8.2 Re-addressing exchange
When a site renumbers, a host inside the site must inform its peers
about the new IP address(es). The sender of the new locator set is
called an initiator. Once the responder receives REA message it
cannot trust that the initiator is reachable at the new locations. To
avoid different kind of DoS and redirection attacks the responder
must verify that the initiator indeed is reachable at the claimed
locations.
the proposed protocol takes advantage of parallel paths between the
hosts. The responder splits its hash chain value into pieces and
protects each challenge (AC) message with one piece. Each of
challenge messages is sent to different location. As a consequence,
an attacker has to locate at different topological locations, at the
same time, to be able to answer to the challenge. The initiator, in
turn, is able to verify that all of the pieces came from the
authentic responder. The secret splitting works only if there are
more than one AC messages to be sent and the messages are routed via
different paths to the initiator. (Note: To increase the security of
the challenge message, the responder could protect the AC message
with HMAC. The key in each message would then be a divided secret,
i.e. a hash value.)
Ylitalo, et al. Expires July 28, 2004 [Page 41]
Internet-Draft WIMP January 2004
9. IANA Considerations
IANA has assigned IP Protocol number TBD to WIMP.
Ylitalo, et al. Expires July 28, 2004 [Page 42]
Internet-Draft WIMP January 2004
10. Acknowledgments
This draft is a result of the discussion between the authors, Pekka
Nikander and Jari Arkko at the 58th IETF. The idea was to write a
Multi6 draft using reverse hash chains and secret splitting. The main
objective in this draft has been on identifying the hosts to their
peers with reverse hash chains. Instead of inventing the wheel once
again, we took several ideas from the existing protocol proposals.
Therefore, there are certain similarities with SIM and HIP design
factors. We would like to thank all contributers in those drafts that
have affect the work.
Ylitalo, et al. Expires July 28, 2004 [Page 43]
Internet-Draft WIMP January 2004
Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[4] Abley, J., Black, B. and V. Gill, "Goals for IPv6
Site-Multihoming Architectures", RFC 3582, August 2003.
[5] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-05 (work in progress), April 2003.
[6] Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming
solutions", draft-nordmark-multi6-threats-00.txt (work in
progress), October 2003.
[7] Lear, E. and R. Droms, "What's In A Name: Thoughts from the
NSRG", draft-irtf-nsrg-report-09.txt (work in progress), March
2003.
Ylitalo, et al. Expires July 28, 2004 [Page 44]
Internet-Draft WIMP January 2004
Informative references
Authors' Addresses
Jukka Ylitalo
Ericsson Research Nomadiclab
Jorvas FIN-02420
FINLAND
Phone: +358 9 299 1
EMail: jukka.ylitalo@ericsson.com
Vesa Torvinen
Ericsson Research Nomadiclab
Turku FIN-20520
FINLAND
Phone: +358 9 299 1
EMail: vesa.torvinen@ericsson.com
Erik Nordmark
Sun Microsystems, Inc.
17 Network Circle
Mountain View, CA
USA
Phone: +1 650 786 2921
EMail: erik.nordmark@sun.com
Ylitalo, et al. Expires July 28, 2004 [Page 45]
Internet-Draft WIMP January 2004
Appendix A. Example of secure reverse hash chain generation
This Appendix gives an example for secure hash chain generation.
Initiator (context establishment and re-addressing exchanges):
Hn(I) = SHA1(secret(I)|ID(I)|ID(R)|challenge(I))
...
H1(I) = SHA1(H2(I))
H0(I) = SHA1(H1(I))
Responder (context establishment exchange):
Hn(R) = SHA1(secret(R)|ID(R)|ID(I)|challenge(I))
Note: challenge(I) is generated by the initiator
...
H1(R) = SHA1(H2(R))
H0(R) = SHA1(H1(R))
The default length of both of the hash chains is n=10.
secret(I) = 256 bit secret random number generated by the initiator
secret(R) = 256 bit secret random number generated by the responder
challenge(I) = 128 bit public random number generated by the initiator
Hk(I/R) = initiator's/responder's 160 bit hash chain value
ID(I/R) = initiator's/responder's 128 bit identifier
The secret(I/R) is not revealed to the peers. The long term
secret(R) MUST survive when the system boots. The responder SHOULD
use the same secret(R) for different hash chains generated during the
lifetime of the secret(R).
Ylitalo, et al. Expires July 28, 2004 [Page 46]
Internet-Draft WIMP January 2004
Appendix B. Goals for IPv6 Site-Multihoming Architectures
This section compares the proposed solution with the goals of IPv6
site multihoming architecture [4].
B.1 Redundancy
The proposed end-to-end protocol allows applications to use multiple
IPv6 addresses. Furthermore, the WIMP layer is able to receive events
from different sources: from upper and lower layers. L2 may inform
WIMP, e.g, if the local link is down. L4, in turn, may launch a
trigger due to TCP time-outs. Finally, the redundancy is a question
of local triggers, implementation and address selection policy. (The
address selection policy should be separated from the core protocol
draft)
B.2 Load Sharing
The identifier and locator-set separation makes it possible to
implement dynamic load sharing. The sender is able to select source
and destination IP addresses on packet basis. The sender and receiver
may have several parallel paths between then; both of the hosts being
multi-homed at the same time. (Note: However, sending TPC packets via
alternative paths may lead to poor performance.)
B.3 Performance
The protocol defined in this draft does not directly interoperate
with Internet routing protocols. However, the implementation should
follow source address routing principles. In other words, the next
hop router, and its prefix, defines the used source address. However,
a host with one interface typically receives multiple prefixes from
one access router. Congestion related to a path should be identified
using RTT and bandwidth values as triggers for hand-offs between
addresses.
B.4 Policy
The proposed solution does not take a stand on the reason why
multihoming is used. The solution provides support for
site-multihoming for external policy reasons. If the responder has
stored several IP addresses to the DNS, the initiator may assume that
the responder supports multihoming. (Note: there are several other
ways using DNS to inform the initiator that the peer supports
multihoming.)
Ylitalo, et al. Expires July 28, 2004 [Page 47]
Internet-Draft WIMP January 2004
B.5 Simplicity
Proposed solution is straightforward to deploy and maintain. It is
not more complex to deploy and operate than current IPv4 multihoming
practices. The protocol supports legacy IPv6 socket API.
B.6 Transport-Layer Survivability
The proposed solution provides re-homing transparency for
transport-layer sessions. The existing transport-layer sessions are
able to use the new path because the upper layer identities are
separated from the network topology.
B.7 Impact on DNS
No impacts on DNS RR records.
B.8 Packet Filtering
The solution does not preclude filtering.
B.9 Scalability
The proposed protocol is responsible for changing the default path,
source and destination IP addresses, to another if the peer is not
reachable via some route. The routing desicion is made at the
end-host.
B.10 Impact on Routers
The proposed solution does not require changes to IPv6 router
implementations.
B.11 Impact on Hosts
A host that has not implemented the proposed solution can still work
in a multihomed site. The solution requires changes to the end-host
stack, however, these changes are logically separate functions that
can be added to existing functions. The solution does not require
changes to the socket API or the transport layer.
B.12 Interaction between Hosts and the Routing System
The solution does not require interaction between a site's hosts and
its routing system.
Ylitalo, et al. Expires July 28, 2004 [Page 48]
Internet-Draft WIMP January 2004
B.13 Operations and Management
The staff responsible for the operation of a site is able to
advertise any prefixes it wants for the hosts. The site multihoming
system can be configured advertising different set of prefixes.
B.14 Cooperation between Transit Providers
The solution does not require cooperation between transit providers.
B.15 Security compared to IPv4 multihoming
The proposed solution is vulnerable for man-in-the-middle attack in
the first message exchange because it relies on opportunistic
security principles. The security properties are analyzed in Section
8.
Ylitalo, et al. Expires July 28, 2004 [Page 49]
Internet-Draft WIMP January 2004
Appendix C. Things MULTI6 Developers should think about
This section answers to the questions presented in the
draft-lear-multi6-things-to-think-about-00.
C.1 Routing
"How will your solution solve the multihoming problem?"
By definining a new logical layer between networking (L3) and
transport (L4) layers. The logical layer separates identifiers from
locators. The dynamic one-to-many binding between an identifier and
IP addresses makes multihoming possible. The identifiers are used by
upper layers, while the IP addresses are used on the wire.
"Does your solution address mobility?"
The proposal does not define any rendevouz server, but allows dynamic
address updates between hosts.
C.2 Identifiers and locators
"Does your solution provide for a split between identifiers and
locators?"
Yes. The responder's identifier is a 128-bit hash of FQDN. The
initiator's identifier, in turn, is a hash of a nonce for security
reasons.
"What is the lifetime of a binding from an identifier to a locator?"
The lifetime of a binding is the lifetime of open sockets. As long as
there are open connections between end-points, the corresponding
host-pair context should not be deleted. However, the binding can be
dynamically updated.
"How is the binding updated?"
By re-addressing exchange.
"Will transport connections remain up?"
Yes.
C.3 On The Wire
"At what layer is your solution applied, and how?"
Ylitalo, et al. Expires July 28, 2004 [Page 50]
Internet-Draft WIMP January 2004
At logical layer between networking (L3) and tranport (L4) layers.
"Is it applied in every packet? If so, what fields are used?"
It is applied in every packet by using flowid field in the IPv6
header
"Why is the layer you chose the correct one?"
The implementation does not affect the upper layers nor applications.
"Does your solution expand the size of an IP packet?"
Only during the context establishment and re-addressing exchanges.
The IP payload packets use flowid field to identify packets.
"Do you change the way fragmenting is handled?"
Not in the normal IPv6 packets. The packets carrying context
establishment or re-addressing exchange messages must not be
fragmented.
"Are there any changes to ICMP error semantics?"
No. However, the presented packet formats can be implemented as ICMP
extension fields.
C.4 Names, Hosts, Endpoints, or none of the above?
"Please explain the relationship of your solution to DNS"
The proposal assumes that a host is multi-homed if it has several
AAAA RR entries in the DNS.
"Please explain interactions with "2-faced" DNS"
No effect
"Does your solution require centralized registration?"
Every server (responder) must have a basic DNS entry, containing FQDN
and locator set, as nowadays
"Have you checked for DNS circular dependencies?"
The solution is dependent of FDQN and locator set mapping
"What if a DNS server itself is multihomed?"
Ylitalo, et al. Expires July 28, 2004 [Page 51]
Internet-Draft WIMP January 2004
No effect.
"What application/API changes are needed?"
None.
"Is this solution backward compatible with "old" IP version 6?"
Yes. The new identifiers are identified with two highest bits in the
128-bit identifier, like in the HIP.
"Is your solution backward compatible with IPv4?"
The 6to4 gateway must work as an authentication proxy. TBD.
"How will your solution interact with other middle-boxes?"
TBD.
"Are there any implications for scoped addressing?"
TBD.
"Are there any layer 2 implications to your proposal?"
None.
"How will your solution handle referrals, such as those within FTP?"
TBD.
"Are you introducing a namespace that might involve mnemonics?"
No.
Ylitalo, et al. Expires July 28, 2004 [Page 52]
Internet-Draft WIMP January 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Ylitalo, et al. Expires July 28, 2004 [Page 53]
Internet-Draft WIMP January 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ylitalo, et al. Expires July 28, 2004 [Page 54]
| PAFTECH AB 2003-2026 | 2026-04-22 06:24:36 |