draft-ietf-hip-hiccups-04.txt   draft-ietf-hip-hiccups-05.txt 
HIP Working Group G. Camarillo HIP Working Group G. Camarillo
Internet-Draft J. Melen Internet-Draft J. Melen
Intended status: Experimental Ericsson Intended status: Experimental Ericsson
Expires: January 13, 2011 July 12, 2010 Expires: January 13, 2011 July 12, 2010
HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper-
layer Protocol Signaling (HICCUPS) layer Protocol Signaling (HICCUPS)
draft-ietf-hip-hiccups-04 draft-ietf-hip-hiccups-05
Abstract Abstract
This document defines a new HIP (Host Identity Protocol) packet type This document defines a new HIP (Host Identity Protocol) packet type
called DATA. HIP DATA packets are used to reliably convey called DATA. HIP DATA packets are used to reliably convey
authenticated arbitrary protocol messages over various overlay authenticated arbitrary protocol messages over various overlay
networks. networks.
Status of this Memo Status of this Memo
skipping to change at page 7, line 36 skipping to change at page 7, line 36
linked to the appropriate upper-layer protocol by storing the upper- linked to the appropriate upper-layer protocol by storing the upper-
layer protocol number, 8 octets of payload data, and by calculating a layer protocol number, 8 octets of payload data, and by calculating a
hash sum (MIC) over the data. The HIP DATA packet MAY contain one or hash sum (MIC) over the data. The HIP DATA packet MAY contain one or
more PAYLOAD_MIC parameters each bound to different next header type. more PAYLOAD_MIC parameters each bound to different next header type.
The hash algorithm used to generate MIC is same as the algorithm used The hash algorithm used to generate MIC is same as the algorithm used
to generate the Host Identity Tag [RFC5201]. to generate the Host Identity Tag [RFC5201].
Upper-layer protocol messages, such as overlay network control Upper-layer protocol messages, such as overlay network control
traffic, sent in HIP DATA messages may need to be matched to traffic, sent in HIP DATA messages may need to be matched to
different transactions. For this purpose, a DATA message MAY also different transactions. For this purpose, a DATA message MAY also
contain a TRANSACTION_ID parameter. The identifier value is a 64-bit contain a TRANSACTION_ID parameter. The identifier value is a
unsigned integer in network-byte-order that is unique for each variable length bit string in network-byte-order that is unique for
transaction. A response to a request uses the same identifier value each transaction. A response to a request uses the same identifier
allowing the receiver to match requests to responses. value allowing the receiver to match requests to responses.
4.1. Definition of the SEQ_DATA Parameter 4.1. Definition of the SEQ_DATA Parameter
The following is the definition of the SEQ_DATA parameter: The following is the definition of the SEQ_DATA parameter:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 29 skipping to change at page 14, line 29
executed at the first encounter of hosts that have not communicated executed at the first encounter of hosts that have not communicated
before. This may add additional RTTs (Round Trip Time) to protocols before. This may add additional RTTs (Round Trip Time) to protocols
based on a single message exchange. However, the four-message based on a single message exchange. However, the four-message
exchange is essential to preserve the DoS protection nature of the exchange is essential to preserve the DoS protection nature of the
base exchange. The use of the HIP DATA packet defined in this base exchange. The use of the HIP DATA packet defined in this
document reduces the initial overhead in the communications between document reduces the initial overhead in the communications between
two hosts. However, the HIP DATA packet itself does not provide any two hosts. However, the HIP DATA packet itself does not provide any
protection against DoS attacks. Therefore, the HIP DATA packet MUST protection against DoS attacks. Therefore, the HIP DATA packet MUST
only be used in environment whose policies provide protection against only be used in environment whose policies provide protection against
DoS attacks. For example, a HIP-based overlay may have policies in DoS attacks. For example, a HIP-based overlay may have policies in
place to control which nodes can join the overlay. Any particular place to control which nodes can join the overlay. However,
node in the overlay may want to accept HIP DATA packets from other authorization who is allowed to join the overlay is beyond the scope
nodes in the overlay given that those other nodes were authorized to of this specification. Any particular node in the overlay may want
join the overlay. However, the same node will not accept HIP DATA to accept HIP DATA packets from other nodes in the overlay given that
packets from random nodes that are not part of the overlay. those other nodes were authorized to join the overlay. However, the
Additionally, the HIP DATA packet itself does not provide same node will not accept HIP DATA packets from random nodes that are
confidentiality for its payload. Therefore, the HIP DATA packet MUST not part of the overlay. Additionally, the HIP DATA packet itself
NOT be used in environments that do not provide an appropriate level does not provide confidentiality for its payload. Therefore, the HIP
of confidentiality (e.g., a HIP-based overlay MUST NOT send HIP DATA DATA packet MUST NOT be used in environments that do not provide an
packets unless the connections between overlay nodes are encrypted). appropriate level of confidentiality (e.g., a HIP-based overlay MUST
NOT send HIP DATA packets unless the connections between overlay
nodes are encrypted).
The type of data to be sent is also relevant to whether the use of a The type of data to be sent is also relevant to whether the use of a
HIP DATA packet is appropriate. HIP itself does not support HIP DATA packet is appropriate. HIP itself does not support
fragmentation but relies on underlying IP-layer fragmentation. This fragmentation but relies on underlying IP-layer fragmentation. This
may lead to reliability problems in the case where a message cannot may lead to reliability problems in the case where a message cannot
be easily split over multiple HIP messages. Therefore, applications be easily split over multiple HIP messages. Therefore, applications
in environments where fragmentation could be an issue SHOULD NOT in environments where fragmentation could be an issue SHOULD NOT
generate too large HIP DATA packets that may lead to fragmentation. generate too large HIP DATA packets that may lead to fragmentation.
The implementation SHOULD check the MTU of the link before sending The implementation SHOULD check the MTU of the link before sending
the packet and if the packet size is larger than MTU it SHOULD signal the packet and if the packet size is larger than MTU it SHOULD signal
 End of changes. 3 change blocks. 
15 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/