draft-moskowitz-drip-efficient-a2g-comm-01.txt		draft-moskowitz-drip-efficient-a2g-comm-02.txt
	DRIP R. Moskowitz		DRIP R. Moskowitz
	Internet-Draft HTT Consulting		Internet-Draft HTT Consulting
	Intended status: Standards Track S. Card		Intended status: Standards Track S. Card
	Expires: 31 March 2024 AX Enterprize		Expires: 27 September 2024 AX Enterprize
	A. Gurtov		A. Gurtov
	Linköping University		Linköping University
	28 September 2023		26 March 2024
	Efficient Air-Ground Communications		Efficient Air-Ground Communications
	draft-moskowitz-drip-efficient-a2g-comm-01		draft-moskowitz-drip-efficient-a2g-comm-02
	Abstract		Abstract
	This document defines protocols to provide efficient air-ground		This document defines protocols to provide efficient air-ground
	communications without associated need for aircraft to maintain		communications without associated need for aircraft to maintain
	stateful connection to ground-tower infrastructure. Instead, a		stateful connection to any tower infrastructure. Instead, a secure
	secure source-routed ground infrastructure will not only provide the		source-routed ground infrastructure will not only provide the needed
	needed routing intelligence, but also reliable packet delivery		routing intelligence, but also reliable packet delivery through
	through inclusion of Automatic Repeat reQuest (ARQ) and Forward Error		inclusion of Automatic Repeat reQuest (ARQ) and Forward Error
	Correction (FEC) to address both reliable wireless packet delivery,		Correction (FEC) protocols to address both reliable wireless packet
	and assured terrestrial packet delivery.		delivery, and assured terrestrial packet delivery.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 March 2024.		This Internet-Draft will expire on 27 September 2024.
	Copyright Notice		Copyright Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2024 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 Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	4.4. Improved uplink reliability . . . . . . . . . . . . . . . 7		4.4. Improved uplink reliability . . . . . . . . . . . . . . . 7
	4.5. Alternative dedicated Tower-GS tunneling . . . . . . . . 8		4.5. Alternative dedicated Tower-GS tunneling . . . . . . . . 8
	5. Aircraft to GS Messaging . . . . . . . . . . . . . . . . . . 8		5. Aircraft to GS Messaging . . . . . . . . . . . . . . . . . . 8
	5.1. The Tower to GS tunnel . . . . . . . . . . . . . . . . . 10		5.1. The Tower to GS tunnel . . . . . . . . . . . . . . . . . 10
	6. GS to Aircraft Messaging . . . . . . . . . . . . . . . . . . 11		6. GS to Aircraft Messaging . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . 12		9.2. Informative References . . . . . . . . . . . . . . . . . 12
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The goal of this design approach is to place minimal network		The goal of this design approach is to place minimal network
	intelligence in the aircraft and even the wireless towers.		intelligence in the aircraft and even the wireless towers.
	Practically all the networking intelligence is placed within the		Practically all the networking intelligence is placed within the
	Ground Station (GS). The justification for this approach is		Ground Station (GS). The target application is uncrewed aircraft
	intelligence in the aircraft has disproportional costs to that in the		communications, but could equally applied to all aircraft.
	GS; there are many factors in this claim. Lower intelligence
	requirements in the towers will make the technology more attractive		The justification for this approach is intelligence in the aircraft
	to tower owners, provided there is an associated functional payment		has disproportional costs to that in the GS; there are many factors
	mechanism for them for the service.		in this claim. Lower intelligence requirements in the towers will
			make the technology more attractive to tower owners, provided there
			is an associated functional payment mechanism for them for the
			service.
	The wireless downlink from the aircraft is treated as a broadcast		The wireless downlink from the aircraft is treated as a broadcast
	message, with every receiving tower forwarding messages to the GS.		message, with every receiving tower forwarding messages to the GS.
	The GS, in turns, notes which towers are in contact with the aircraft		The GS, in turns, notes which towers are in contact with the aircraft
	and sends uplink messages through them to the aircraft. There is no		and sends uplink messages through them to the aircraft. There is no
	need for complex aircraft/tower connection technologies. At most,		need for complex aircraft/tower connection technologies. At most,
	for billing purposes, the towers are aware of aircraft and GS that		for billing purposes, the towers are aware of aircraft and GS that
	will use their connectivity services via their source IP addresses.		will use their connectivity services via their source IP addresses.
	2. Terms and Definitions		2. Terms and Definitions
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 42 ¶
	3.1. Enabling Requirements		3.1. Enabling Requirements
	The aircraft:		The aircraft:
	* Support end-to-end secure communications with the GS and start the		* Support end-to-end secure communications with the GS and start the
	operation with the pre-configured GS IP address. The aircraft		operation with the pre-configured GS IP address. The aircraft
	sends the first message, to the GS, to establish the routing		sends the first message, to the GS, to establish the routing
	knowledge in the GS,		knowledge in the GS,
	* use a fixed IP address for itself for the duration of the		* Use a fixed IP address for itself for the duration of the
	operation, and		operation, and
	* be able to process multiple copies of messages from the GS,		* be able to process multiple copies of messages from the GS,
	received potentially from multiple towers.		received potentially from multiple towers.
	The tower:		The tower:
	* Support digital signing of messages from the aircraft, and the		* Support digital signing of messages from the aircraft, and the
	tower’s IP address, and forward these objects to the GS.		tower’s IP address, and forward these objects to the GS.
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 8 ¶
	received potentially from multiple towers.		received potentially from multiple towers.
	The tower:		The tower:
	* Support digital signing of messages from the aircraft, and the		* Support digital signing of messages from the aircraft, and the
	tower’s IP address, and forward these objects to the GS.		tower’s IP address, and forward these objects to the GS.
	The GS:		The GS:
	* Support end-to-end secure communications with the aircraft,		* Support end-to-end secure communications with the aircraft,
	* support processing multiple copies of messages from the aircraft,		* support processing multiple copies of messages from the aircraft,
	* support digital signing by the tower, and		* support digital signing by the tower, and
	* maintain a list/map of towers forwarding aircraft messages from		* maintain a list/map of towers forwarding aircraft messages from
	the aircraft for messaging to the aircraft. The list of trusted		the aircraft for messaging to the aircraft. The list of trusted
	tower IP addresses is constructed from within the tower signed		tower IP addresses is constructed from within the tower signed
	objects.		objects.
	3.2. Enhancing Security Requirement		3.2. Enhancing Security Requirement
	The GS should:		The GS should:
	* Support digital signing for the tower to trust messages from the		* Support digital signing for the tower to trust messages from the
	GS.		GS.
	3.3. Enhancing Performance Requirements		3.3. Enhancing Performance Requirements
	The aircraft may:		The aircraft may:
	* Support uplink usage optimizations like FEC and ARQ, and		* Support uplink usage optimizations like FEC and ARQ (e.g., NORM
			[RFC5740]), and
	* support GS IP address mobility (e.g. via HIP, [RFC7401]).		* support GS IP address mobility (e.g. via HIP, [RFC7401]).
	The tower may:		The tower may:
	* Include information like timestamp and its GPS-derived location		* Include information like timestamp and its GPS-derived location
	(and accuracy of same) in the signed object delivered to the GS,		(and accuracy of same) in the signed object delivered to the GS,
	* may be IP address mobile, if so, then MUST provide its IP address		* may be IP address mobile, if so, then MUST provide its IP address
	within the signed object,		within the signed object,
	* support multicast and DETNET (rfc8938) for efficient and reliable		* support multicast and DETNET [RFC8938] for efficient and reliable
	communications with the GS, and		communications with the GS, and
	* use a subscription model to filter messages supported for		* use a subscription model to filter messages supported for
	forwarding. If done with a list of registered IP addresses it		forwarding. If done with a list of registered IP addresses it
	MUST support GS IP address mobility.		MUST support GS IP address mobility.
	The GS may:		The GS may:
	* Support intelligent operation routing and tower contact		* Support intelligent operation routing and tower contact
	information to select towers to use to send messages to the		information to select towers to use to send messages to the
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 10 ¶
	forwarding. If done with a list of registered IP addresses it		forwarding. If done with a list of registered IP addresses it
	MUST support GS IP address mobility.		MUST support GS IP address mobility.
	The GS may:		The GS may:
	* Support intelligent operation routing and tower contact		* Support intelligent operation routing and tower contact
	information to select towers to use to send messages to the		information to select towers to use to send messages to the
	aircraft,		aircraft,
	* support tower subscription for tower communication filtering,		* support tower subscription for tower communication filtering,
	* support multicast and DETNET for efficient communications with the		* support multicast and DETNET for efficient communications with the
	towers,and		towers,and
	* support FEC and ARQ for efficient use of uplinks to the aircraft.		* support FEC and ARQ for efficient use of uplinks to the aircraft.
	4. Background Discussion		4. Background Discussion
	The following considers the possible technologies, some challenges,		The following considers the possible technologies, some challenges,
	and final proposed solution.		and final proposed solution.
	4.1. The problem and simple solution using IPnIP		4.1. The problem and simple solution using IPnIP
	Internet Protocol (IP) transmissions from the aircraft to ground,		Internet Protocol (IP) transmissions from the aircraft to ground,
	though unicast in construction (i.e. IP destination/source paired),		though unicast in construction (i.e. IP destination/source paired),
	are really broadcasts, as a practical matter, to all available ground		are really broadcasts, as a practical matter, to all available
	towers. Such towers can simply send the packets on their way and		towers. Such towers can simply send the packets on their way and
	they will naturally get routed, i.e. relayed, to the GS which		they will naturally get routed, i.e. relayed, to the GS which
	correspondingly simply recognizes and processes potential multiple		correspondingly simply recognizes and processes potential multiple
	receipts via the many relaying towers. The problem is only the		receipts via the many relaying towers. The problem is only the
	uplink: how to get IP transmissions from the GS to the aircraft.		uplink: how to get IP transmissions from the GS to the aircraft.
	The GS needs to ‘know’ which towers can likely transmit up to the		The GS needs to ‘know’ which towers can likely transmit up to the
	aircraft and how to route packets through them. A simple solution is		aircraft and how to route packets through them. A simple solution is
	to use IP-in-IP (IPnIP) tunneling protocol [RFC1853]. Here, each		to use IP-in-IP (IPnIP) tunneling protocol [RFC1853]. Here, each
	receiving tower wraps the downlink message in IPnIP with the outer		receiving tower wraps the downlink message in IPnIP with the outer
	skipping to change at page 5, line 50 ¶		skipping to change at page 6, line 8 ¶
	Though this approach works, it has security and traffic management		Though this approach works, it has security and traffic management
	challenges. First and foremost, the aircraft must know the GS IP		challenges. First and foremost, the aircraft must know the GS IP
	address. It either needs to be fixed or the aircraft needs a		address. It either needs to be fixed or the aircraft needs a
	separate process to update its knowledge of the GS address. The GS		separate process to update its knowledge of the GS address. The GS
	should have the aircraft address prior to operation start or can		should have the aircraft address prior to operation start or can
	simply learn them through received messages.		simply learn them through received messages.
	There are two security issues associated with the GS processing		There are two security issues associated with the GS processing
	messages from any random aircraft address:		messages from any random aircraft address:
	* Either these addresses are preset (e.g. registered DET), or there		* either these addresses are preset (e.g. registered DET), or there
	is some process for the GS to dynamically learn which to trust.		is some process for the GS to dynamically learn which to trust.
	* A larger security challenge is why should the GS trust the address		* a larger security challenge is why should the GS trust the address
	for the towers as a route to the aircraft. A malicious source		for the towers as a route to the aircraft. A malicious source
	could provide bad tower addresses resulting in loss of aircraft		could provide bad tower addresses resulting in loss of aircraft
	contact at worst, or consumption, through DOS attacks, of both GS		contact at worst, or consumption, through DOS attacks, of both GS
	processing resources and tower uplink bandwidth.		processing resources and tower uplink bandwidth.
	An additional challenge for the GS is determining which set of towers		An additional challenge for the GS is determining which set of towers
	to use to send messages uplinked to the aircraft. Which of the		to use to send messages uplinked to the aircraft. Which of the
	towers last sending messages from the aircraft are still in RF reach		towers last sending messages from the aircraft are still in RF reach
	of the aircraft and are there now towers better able to message the		of the aircraft and are there now towers better able to message the
	aircraft? If the GS can trust the towers and know their GPS location		aircraft? If the GS can trust the towers and know their GPS location
	skipping to change at page 13, line 8 ¶		skipping to change at page 13, line 8 ¶
	[RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,		[RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
	"DRIP Entity Tag (DET) for Unmanned Aircraft System Remote		"DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
	ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,		ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
	<https://www.rfc-editor.org/info/rfc9374>.		<https://www.rfc-editor.org/info/rfc9374>.
	9.2. Informative References		9.2. Informative References
	[drip-a2x-adhoc-session]		[drip-a2x-adhoc-session]
	Moskowitz, R., Card, S. W., and A. Gurtov, "Aircraft to		Moskowitz, R., Card, S. W., and A. Gurtov, "Aircraft to
	Anything AdHoc Broadcasts and Session", Work in Progress,		Anything AdHoc Broadcasts and Session", Work in Progress,
	Internet-Draft, draft-moskowitz-drip-a2x-adhoc-session-02,		Internet-Draft, draft-moskowitz-drip-a2x-adhoc-session-03,
	23 July 2023, <https://datatracker.ietf.org/doc/html/		23 October 2023, <https://datatracker.ietf.org/doc/html/
	draft-moskowitz-drip-a2x-adhoc-session-02>.		draft-moskowitz-drip-a2x-adhoc-session-03>.
	[drip-secure-nrid-c2]		[drip-secure-nrid-c2]
	Moskowitz, R., Card, S. W., Wiethuechter, A., and A.		Moskowitz, R., Card, S. W., Wiethuechter, A., and A.
	Gurtov, "Secure UAS Network RID and C2 Transport", Work in		Gurtov, "Secure UAS Network RID and C2 Transport", Work in
	Progress, Internet-Draft, draft-moskowitz-drip-secure-		Progress, Internet-Draft, draft-moskowitz-drip-secure-
	nrid-c2-13, 19 September 2023,		nrid-c2-14, 16 March 2024,
	<https://datatracker.ietf.org/doc/html/draft-moskowitz-		<https://datatracker.ietf.org/doc/html/draft-moskowitz-
	drip-secure-nrid-c2-13>.		drip-secure-nrid-c2-14>.
	[RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853,		[RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853,
	DOI 10.17487/RFC1853, October 1995,		DOI 10.17487/RFC1853, October 1995,
	<https://www.rfc-editor.org/info/rfc1853>.		<https://www.rfc-editor.org/info/rfc1853>.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, DOI 10.17487/RFC4303, December 2005,		RFC 4303, DOI 10.17487/RFC4303, December 2005,
	<https://www.rfc-editor.org/info/rfc4303>.		<https://www.rfc-editor.org/info/rfc4303>.
			[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
			"NACK-Oriented Reliable Multicast (NORM) Transport
			Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009,
			<https://www.rfc-editor.org/info/rfc5740>.
	[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.		[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
	Henderson, "Host Identity Protocol Version 2 (HIPv2)",		Henderson, "Host Identity Protocol Version 2 (HIPv2)",
	RFC 7401, DOI 10.17487/RFC7401, April 2015,		RFC 7401, DOI 10.17487/RFC7401, April 2015,
	<https://www.rfc-editor.org/info/rfc7401>.		<https://www.rfc-editor.org/info/rfc7401>.
	[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",		[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
	RFC 8152, DOI 10.17487/RFC8152, July 2017,		RFC 8152, DOI 10.17487/RFC8152, July 2017,
	<https://www.rfc-editor.org/info/rfc8152>.		<https://www.rfc-editor.org/info/rfc8152>.
	[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.		[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
	Zuniga, "SCHC: Generic Framework for Static Context Header		Zuniga, "SCHC: Generic Framework for Static Context Header
	Compression and Fragmentation", RFC 8724,		Compression and Fragmentation", RFC 8724,
	DOI 10.17487/RFC8724, April 2020,		DOI 10.17487/RFC8724, April 2020,
	<https://www.rfc-editor.org/info/rfc8724>.		<https://www.rfc-editor.org/info/rfc8724>.
			[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
			Bryant, "Deterministic Networking (DetNet) Data Plane
			Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
			<https://www.rfc-editor.org/info/rfc8938>.
	[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The		[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,		1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
	<https://www.rfc-editor.org/info/rfc9147>.		<https://www.rfc-editor.org/info/rfc9147>.
	Acknowledgments		Acknowledgments
	Adam Wiethuechter of AX Enterprize provided review and implementation		Adam Wiethuechter of AX Enterprize provided review and implementation
	insights. Michael Baum provided extensive review of the contents in		insights. Michael Baum provided extensive review of the contents in
	chapters 3 and 4 in a prior white paper.		chapters 3 and 4 in a prior white paper.
End of changes. 21 change blocks.
	29 lines changed or deleted		45 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/