draft-ietf-hip-hiccups-03.txt   draft-ietf-hip-hiccups-04.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 8, 2011 July 7, 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-03 draft-ietf-hip-hiccups-04
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 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 8, 2011. This Internet-Draft will expire on January 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
4.3. Definition of the PAYLOAD_MIC Parameter . . . . . . . . . 9 4.3. Definition of the PAYLOAD_MIC Parameter . . . . . . . . . 9
4.4. Definition of the TRANSACTION_ID Parameter . . . . . . . . 10 4.4. Definition of the TRANSACTION_ID Parameter . . . . . . . . 10
5. Generation and Reception of HIP DATA Packets . . . . . . . . . 10 5. Generation and Reception of HIP DATA Packets . . . . . . . . . 10
5.1. Handling of SEQ_DATA and ACK_DATA . . . . . . . . . . . . 10 5.1. Handling of SEQ_DATA and ACK_DATA . . . . . . . . . . . . 10
5.2. Generation of a HIP DATA packet . . . . . . . . . . . . . 11 5.2. Generation of a HIP DATA packet . . . . . . . . . . . . . 11
5.3. Reception of a HIP DATA packet . . . . . . . . . . . . . . 12 5.3. Reception of a HIP DATA packet . . . . . . . . . . . . . . 12
5.3.1. Handling of SEQ_DATA in a Received HIP DATA packet . . 13 5.3.1. Handling of SEQ_DATA in a Received HIP DATA packet . . 13
5.3.2. Handling of ACK_DATA in a Received HIP DATA packet . . 13 5.3.2. Handling of ACK_DATA in a Received HIP DATA packet . . 13
6. Use of the HIP DATA Packet . . . . . . . . . . . . . . . . . . 14 6. Use of the HIP DATA Packet . . . . . . . . . . . . . . . . . . 14
7. Security considerations . . . . . . . . . . . . . . . . . . . 15 7. Security considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative references . . . . . . . . . . . . . . . . . . 16 10.2. Informative references . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Two hosts can use HIP [RFC5201] to establish a Security Association Two hosts can use HIP [RFC5201] to establish a Security Association
(SA) between them in order to exchange arbitrary protocol messages (SA) between them in order to exchange arbitrary protocol messages
skipping to change at page 13, line 21 skipping to change at page 13, line 21
The following steps define the conceptual processing rules for The following steps define the conceptual processing rules for
handling a SEQ_DATA parameter in a received HIP DATA packet. handling a SEQ_DATA parameter in a received HIP DATA packet.
The system MUST verify the SIGNATURE in the HIP DATA packet. If the The system MUST verify the SIGNATURE in the HIP DATA packet. If the
verification fail, the packet SHOULD be dropped and an error message verification fail, the packet SHOULD be dropped and an error message
logged. logged.
If the value in the received SEQ_DATA and MIC value received If the value in the received SEQ_DATA and MIC value received
PAYLOAD_MIC corresponds to a HIP DATA packet that has recently been PAYLOAD_MIC corresponds to a HIP DATA packet that has recently been
processed, the packet is treated as a retransmission. The SIGNATURE processed, the packet is treated as a retransmission. It is
verification (next step) MUST NOT be skipped. (A byte-by-byte recommended that a host cache HIP DATA packets with ACKs to avoid the
comparison of the received and a stored packet would be adequate, cost of generating a new ACK packet to respond to a retransmitted HIP
though.) It is recommended that a host cache HIP DATA packets sent DATA packet. The host MUST acknowledge, again, such (apparent) HIP
with ACKs to avoid the cost of generating a new ACK packet to respond DATA packet retransmissions but SHOULD also consider rate-limiting
to a retransmitted HIP DATA packet. The host MUST acknowledge, such retransmission responses to guard against replay attacks.
again, such (apparent) HIP DATA packet retransmissions but SHOULD
also consider rate-limiting such retransmission responses to guard
against replay attacks.
The system MUST verify the PAYLOAD_MIC by calculating MIC over the The system MUST verify the PAYLOAD_MIC by calculating MIC over the
PAYLOAD which the Next Header field indicates. For calculating the PAYLOAD which the Next Header field indicates. For calculating the
MIC the host will use the same hash algorithm that has been used to MIC the host will use the same hash algorithm that has been used to
generate the sender's HIT as defined in Section 3.2. of [RFC5201]. generate the sender's HIT as defined in Section 3.2. of [RFC5201].
If the packet carried multiple PAYLOAD_MIC parameters each of them If the packet carried multiple PAYLOAD_MIC parameters each of them
are verified as described above. If one or more of the verification are verified as described above. If one or more of the verification
fails, the packet SHOULD be dropped and an error message logged. fails, the packet SHOULD be dropped and an error message logged.
If a new SEQ parameter is being processed, the parameters in the HIP If a new SEQ parameter is being processed, the parameters in the HIP
skipping to change at page 14, line 40 skipping to change at page 14, line 36
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. Any particular
node in the overlay may want to accept HIP DATA packets from other node in the overlay may want to accept HIP DATA packets from other
nodes in the overlay given that those other nodes were authorized to nodes in the overlay given that those other nodes were authorized to
join the overlay. However, the same node will not accept HIP DATA join the overlay. However, the same node will not accept HIP DATA
packets from random nodes that are not part of the overlay. packets from random nodes that are not part of the overlay.
Additionally, the HIP DATA packet itself does not provide Additionally, the HIP DATA packet itself does not provide
confidentiality for its payload. Therefore, the HIP DATA packet MUST confidentiality for its payload. Therefore, the HIP DATA packet MUST
only be used in environments that provide a level of confidentiality NOT be used in environments that do not provide an appropriate level
that is appropriate for the data to be transferred. For example, a of confidentiality (e.g., a HIP-based overlay MUST NOT send HIP DATA
HIP-based overlay may only send HIP DATA packets over encrypted packets unless the connections between overlay nodes are encrypted).
connections between overlay nodes.
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
to the upper-layer protocol if the packet results in to a ICMP error to the upper-layer protocol if the packet results in to a ICMP error
message. Note that there are environments where fragmentation is not message. Note that there are environments where fragmentation is not
an issue. For example, in some HIP-based overlays, nodes can an issue. For example, in some HIP-based overlays, nodes can
exchange HIP DATA packets on top of TCP connections that provide exchange HIP DATA packets on top of TCP connections that provide
transport-level fragmentation and, thus, avoid IP-level transport-level fragmentation and, thus, avoid IP-level
fragmentation. fragmentation.
HIP currently requires that all messages excluding I1s but including HIP currently requires that all messages excluding I1s but including
 End of changes. 7 change blocks. 
18 lines changed or deleted 13 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/