draft-ietf-6lo-minimal-fragment-07.txt   draft-ietf-6lo-minimal-fragment-08.txt 
6lo T. Watteyne, Ed. 6lo T. Watteyne, Ed.
Internet-Draft Analog Devices Internet-Draft Analog Devices
Intended status: Standards Track P. Thubert, Ed. Intended status: Standards Track P. Thubert, Ed.
Expires: 31 May 2020 Cisco Systems Expires: 2 August 2020 Cisco Systems
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
28 November 2019 30 January 2020
On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network
draft-ietf-6lo-minimal-fragment-07 draft-ietf-6lo-minimal-fragment-08
Abstract Abstract
This document introduces the capability to forward 6LoWPAN fragments. This document introduces the capability to forward 6LoWPAN fragments.
This method reduces the latency and increases end-to-end reliability This method reduces the latency and increases end-to-end reliability
in route-over forwarding. It is the companion to using virtual in route-over forwarding. It is the companion to using virtual
reassembly buffers which is a pure implementation technique. reassembly buffers which is a pure implementation technique.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on 31 May 2020. This Internet-Draft will expire on 2 August 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
skipping to change at page 7, line 37 skipping to change at page 7, line 37
one of the packets, lowering end-to-end reliability. one of the packets, lowering end-to-end reliability.
5. Forwarding Fragments 5. Forwarding Fragments
A 6LoWPAN Fragment Forwarding technique makes the routing decision on A 6LoWPAN Fragment Forwarding technique makes the routing decision on
the first fragment, which is always the one with the IPv6 address of the first fragment, which is always the one with the IPv6 address of
the destination. Upon a first fragment, a forwarding node (e.g. node the destination. Upon a first fragment, a forwarding node (e.g. node
B in a A->B->C sequence) that does fragment forwarding MUST attempt B in a A->B->C sequence) that does fragment forwarding MUST attempt
to create a state and forward the fragment. This is an atomic to create a state and forward the fragment. This is an atomic
operation, and if the first fragment cannot be forwarded then the operation, and if the first fragment cannot be forwarded then the
state MUST be removed. When a forwarding node receives a fragment state MUST be removed.
other than a first fragment, it MUST look up state based on the
source Link-Layer address and the datagram_tag in the received Since the datagram_tag is uniquely associated to the source Link-
fragment. If no such state is found, the fragment MUST be dropped; Layer address of the fragment, the forwarding node MUST assign a new
otherwise the fragment MUST be forwarded using the information in the datagram_tag from its own namespace for the next hop and rewrite the
state found. Since the datagram_tag is uniquely associated to the fragment header of each fragment with that datagram_tag.
source Link-Layer address of the fragment, the forwarding node MUST
assign a new datagram_tag from its own namespace for the next hop and When a forwarding node receives a fragment other than a first
rewrite the fragment header of each fragment with that datagram_tag. fragment, it MUST look up state based on the source Link-Layer
address and the datagram_tag in the received fragment. If no such
state is found, the fragment MUST be dropped; otherwise the fragment
MUST be forwarded using the information in the state found.
Compared to Section 3, the conceptual reassembly buffer in node B now Compared to Section 3, the conceptual reassembly buffer in node B now
contains, assuming that node B is neither the source nor the final contains, assuming that node B is neither the source nor the final
destination: destination:
* a datagram_tag as received in the incoming fragments, associated * a datagram_tag as received in the incoming fragments, associated
to Link-Layer address of node A for which the received to Link-Layer address of node A for which the received
datagram_tag is unique, datagram_tag is unique,
* the Link-Layer address that node B uses as source to forward the * the Link-Layer address that node B uses as source to forward the
fragments fragments
* the Link-Layer address of the next hop C that is resolved on the * the Link-Layer address of the next hop C that is resolved on the
first fragment first fragment
* a datagram_tag that node B uniquely allocated for this datagram * a datagram_tag that node B uniquely allocated for this datagram
and that is used when forwarding the fragments of the datagram and that is used when forwarding the fragments of the datagram
* a datagram_size,
* a buffer for the remainder of a previous fragment left to be sent, * a buffer for the remainder of a previous fragment left to be sent,
* a timer that allows discarding the stale FF state after some * a timer that allows discarding the stale FF state after some
timeout. timeout. The duration of the timer should be longer than that
which covers the reassembly at the receiving end point.
A node that has not received the first fragment cannot forward the A node that has not received the first fragment cannot forward the
next fragments. This means that if node B receives a fragment, node next fragments. This means that if node B receives a fragment, node
A was in possession of the first fragment at some point. In order to A was in possession of the first fragment at some point. In order to
keep the operation simple, it makes sense to be consistent with keep the operation simple, it makes sense to be consistent with
[RFC4944] and enforce that the first fragment is always sent first. [RFC4944] and enforce that the first fragment is always sent first.
When that is done, if node B receives a fragment that is not the When that is done, if node B receives a fragment that is not the
first and for which it has no state, then node B treats this as an first and for which it has no state, then node B treats this as an
error and refrain from creating a state or attempting to forward. error and refrain from creating a state or attempting to forward.
This also means that node A should perform all its possible retries This also means that node A should perform all its possible retries
skipping to change at page 10, line 13 skipping to change at page 10, line 13
allows fragment recovery. allows fragment recovery.
7. Security Considerations 7. Security Considerations
Secure joining and the Link-Layer security that it sets up protects Secure joining and the Link-Layer security that it sets up protects
against those attacks from network outsiders. against those attacks from network outsiders.
"IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security "IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security
threats that are linked to using IP fragmentation. The 6LoWPAN threats that are linked to using IP fragmentation. The 6LoWPAN
fragmentation takes place underneath, but some issues described there fragmentation takes place underneath, but some issues described there
may still apply to 6lo fragments. may still apply to 6LoWPAN fragments.
* Overlapping fragment attacks are possible with 6LoWPAN fragments * Overlapping fragment attacks are possible with 6LoWPAN fragments
but there is no known firewall operation that would work on but there is no known firewall operation that would work on
6LoWPAN fragments at the time of this writing, so the exposure is 6LoWPAN fragments at the time of this writing, so the exposure is
limited. An implementation of a firewall SHOULD NOT forward limited. An implementation of a firewall SHOULD NOT forward
fragments but recompose the IP packet, check it in the fragments but recompose the IP packet, check it in the
uncompressed form, and then forward it again as fragments if uncompressed form, and then forward it again as fragments if
necessary. necessary.
* Resource exhaustion attacks are certainly possible and a sensitive * Resource exhaustion attacks are certainly possible and a sensitive
issue in a constrained network. An attacker can perform a Denial- issue in a constrained network. An attacker can perform a Denial-
of-Service (DoS) attack on a node implementing VRB by generating a of-Service (DoS) attack on a node implementing VRB by generating a
large number of bogus first fragments without sending subsequent large number of bogus first fragments without sending subsequent
fragments. This causes the VRB table to fill up. When hop-by-hop fragments. This causes the VRB table to fill up. When hop-by-hop
reassembly is used, the same attck can be more damaging if the reassembly is used, the same attack can be more damaging if the
node allocates a full datagram_size for each bogus first fragment. node allocates a full datagram_size for each bogus first fragment.
With the VRB, the attack can be performed remotely on all nodes With the VRB, the attack can be performed remotely on all nodes
along a path, but each node suffers a lesser hit. this is because along a path, but each node suffers a lesser hit. this is because
the VRB does not need to remember the full datagram as received so the VRB does not need to remember the full datagram as received so
far but only possibly a few octets from the last fragment that far but only possibly a few octets from the last fragment that
could not fit in it. An implementation MUST protect itself to could not fit in it. An implementation MUST protect itself to
keep the number of VRBs within capacity, and that old VRBs are keep the number of VRBs within capacity, and that old VRBs are
protected by a timer of a reasonable duration for the technology protected by a timer of a reasonable duration for the technology
and destroyed upon timeout. and destroyed upon timeout.
skipping to change at page 11, line 10 skipping to change at page 11, line 10
8. IANA Considerations 8. IANA Considerations
No requests to IANA are made by this document. No requests to IANA are made by this document.
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Carles Gomez Montenegro, Yasuyuki The authors would like to thank Carles Gomez Montenegro, Yasuyuki
Tanaka, Ines Robles and Dave Thaler for their in-depth review of this Tanaka, Ines Robles and Dave Thaler for their in-depth review of this
document and improvement suggestions. Also many thanks to Georgies document and improvement suggestions. Also many thanks to Georgies
Papadopoulos and Dominique Barthel for their own reviews. Papadopoulos and Dominique Barthel for their own reviews, and to
Joerg Ott who helped through the IESG steps.
10. Normative References 10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
skipping to change at page 11, line 37 skipping to change at page 11, line 38
[LWIG-VRB] Bormann, C. and T. Watteyne, "Virtual reassembly buffers [LWIG-VRB] Bormann, C. and T. Watteyne, "Virtual reassembly buffers
in 6LoWPAN", Work in Progress, Internet-Draft, draft-ietf- in 6LoWPAN", Work in Progress, Internet-Draft, draft-ietf-
lwig-6lowpan-virtual-reassembly-01, 11 March 2019, lwig-6lowpan-virtual-reassembly-01, 11 March 2019,
<https://tools.ietf.org/html/draft-ietf-lwig-6lowpan- <https://tools.ietf.org/html/draft-ietf-lwig-6lowpan-
virtual-reassembly-01>. virtual-reassembly-01>.
[FRAG-RECOV] [FRAG-RECOV]
Thubert, P., "6LoWPAN Selective Fragment Recovery", Work Thubert, P., "6LoWPAN Selective Fragment Recovery", Work
in Progress, Internet-Draft, draft-ietf-6lo-fragment- in Progress, Internet-Draft, draft-ietf-6lo-fragment-
recovery-07, 23 October 2019, recovery-08, 28 November 2019,
<https://tools.ietf.org/html/draft-ietf-6lo-fragment- <https://tools.ietf.org/html/draft-ietf-6lo-fragment-
recovery-07>. recovery-08>.
11. Informative References 11. Informative References
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007, RFC 4919, DOI 10.17487/RFC4919, August 2007,
<https://www.rfc-editor.org/info/rfc4919>. <https://www.rfc-editor.org/info/rfc4919>.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
skipping to change at page 13, line 4 skipping to change at page 13, line 7
Authors' Addresses Authors' Addresses
Thomas Watteyne (editor) Thomas Watteyne (editor)
Analog Devices Analog Devices
32990 Alvarado-Niles Road, Suite 910 32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587 Union City, CA 94587
United States of America United States of America
Email: thomas.watteyne@analog.com Email: thomas.watteyne@analog.com
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D, 45 Allee des Ormes - BP1200 Building D
45 Allee des Ormes - BP1200
06254 Mougins - Sophia Antipolis 06254 Mougins - Sophia Antipolis
France France
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
D-28359 Bremen D-28359 Bremen
 End of changes. 15 change blocks. 
23 lines changed or deleted 28 lines changed or added

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