Agenda IETF105: hotrfc
agenda-105-hotrfc-00

HotRFC @ IETF-105, Montreal
Sunday, July 21, 2019, 1800-2000
Info: https://www.ietf.org/how/meetings/105/hotrfc/
Materials: https://datatracker.ietf.org/meeting/105/session/hotrfc

=====================================================================

1. Service Oriented IP

Brian E Carpenter <brian.e.carpenter@gmail.com>

Service Oriented Internet Protocol (SOIP) proposes a new,
backwards-compatible, approach to packet forwarding, where the service
required rather than the IP address required acts as the vector for
routing packets at the edge of the network. There's a draft
(draft-jiang-service-oriented-ip) and there's even some toy code, at
https://github.com/becarpenter/tlv.

=====================================================================

2. Asymmetric IPv6

Brian E Carpenter <brian.e.carpenter@gmail.com>

Asymmetric IPv6 is a new approach to IPv6 header compression for use
in IoT scenarios where minimizing packet size is crucial but routing
performance must be maximized. There's a draft
(draft-jiang-asymmetric-ipv6). The idea is to make packets shorter
without needing a decompression step.

=====================================================================

3. iCAN Do It

Liubing (Leo) <leo.liubing@huawei.com>

iCAN (instant Congestion Assessment Network) is a mechanism running
directly on network nodes:

o To adjust the flows paths based on real-time measurement of the
  candidate paths.

o The measurement is to reflect the congestion situation of each path,
  so that the ingress nodes could decide which flows need to be
  switched from a path to another.  This is something that current SDN
  and TE technologies can hardly achieve:

o Controller is slow and far from the data plane, it is neither able
  to assess the real-time congestion situation of each path, nor able
  to assure the data plane always go as expected (especially in SRv6
  scenarios). However, iCAN can work with SDN perfectly: controller
  planning multi-path transmission, and iCAN does the flow
  optimization automatically.

o Traditional TE is not able to adjust the flow paths in real-time.
 
Aim: call for attention and partners
Relevance to IETF: This work might be related to TEAS/SPRING/IPPM WGs.

=====================================================================

4. Trustworthy Multipurpose RemoteID (TM-RID)

Bob Moskowitz <rgm@labs.htt-consult.com>
Stuart Card <stu.card@axenterprize.com>

To mitigate the risks presented by Unmanned Aircraft Systems (UAS),
the US FAA and other government agencies internationally soon will
require, and various bodies are drafting standards for, remote
identification. ASTM's proposed Broadcast Remote ID specifies how
Unmanned Aircraft (UA) within Line Of Sight (LOS) of an observer can
use a one-way RF broadcast to identify themselves and provide other
latency-sensitive safety-critical information. ASTM's proposed Network
Remote ID specifies how this same information can be obtained,
starting from an observed UA's location, via the Internet. All such
proposals hinge on a unique ID for each UA, a method whereby this ID
(along with operator contact information etc.) can be registered, and
a method by which a subsequent ID assertion can be authenticated by
authorized parties.

Network RemoteID uses the Internet to map current aircraft locations
to identities. To avoid being deceived by malicious spoofing of these
critical mappings, we need strong authentication. To maintain privacy
(from unauthorized eavesdroppers, not from legitimate authorities), we
need strong encryption. HIP provides both of these. Thus, we propose
to consolidate the 4-tuple of (UA ID, UA physical location, UA onboard
host ID, UA onboard host logical location [IP address list]) to a
3-tuple by standardizing the HIP Host Identity Tag (HIT) as a 4th
RemoteID type. Depending upon the level of adoption by a given UAS
operator, this can provide 3 levels of benefit:

  1. Use of the Internet Domain Name System (DNS, the world’s largest
     distributed database, with well-established update procedures) as
     a RemoteID registry

  2. Strong authentication of not only Network RemoteID but also
     Broadcast RemoteID messages

  3. Rapid establishment of authenticated and encrypted communications
     with any observed UA that is suitably equipped.

We call this “Trustworthy Multipurpose RemoteID (TM-RID)” and have
begun preparations for prototyping and experimentation at the New York
UAS Test Site.

A sidebof is planned.

=====================================================================