Subject: Re: [Drip] HITs and HHITs as valid IPv6 addresses in 'draft-ietf-drip-rid'

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 28 Jan 2021 19:22:31 +0000

Bob and others, a fast way to get the general sense of what is being proposed
would be to check recent OMNI diffs before doing a read-from-scratch:

https://www.ietf.org/rfcdiff?url1=draft-templin-6man-omni-interface-68&url2=draft-templin-6man-omni-interface-71

Here is a log of recent changes:

1) Support for both Vehicle-to-Infrastructure (V2I) and Vehicle-to-Vehicle (V2V)
2) Hard sizing parameters for OAL fragmentation that avoids all path MTU issues
3) Allows IPv6 ND messages up to 9KB while avoiding RFC6980 issues.
4) Allows multiple OMNI options per IPv6 ND message
5) Allows up to 2047 bytes for each OMNI sub-option
6) Incorporates the HIP protocol for security, V2V, Host Identity, etc.

Thanks - Fred

From: Robert Moskowitz [mailto:[email-masked]]
Sent: Thursday, January 28, 2021 11:14 AM
To: Templin (US), Fred L <[email-masked]>; Card, Stu <[email-masked]>
Cc: [email-masked]
Subject:  Re: [Drip] HITs and HHITs as valid IPv6 addresses in 'draft-ietf-drip-rid'

EXT email: be mindful of links/attachments.

Fred,

I will reread your draft and respond.

I am sure there is a strong synergy here and can bring strong value to aviation.

I am a loud voice in ICAO TFSG and with you in other areas, we can begin to coordinate on strong solutions for aviation.

Bob
On 1/28/21 1:52 PM, Templin (US), Fred L wrote:
Stu, I will look forward to further inputs from others but IMHO it would make
for a powerful story if we were to learn we are all actually on the same team.
I suppose if that were not the case and our stories were divergent, Tom
Henderson may have kicked me out of our shared office when we were
together many years ago. But, let’s see what others say.

Fred

From: Card, Stu [mailto:[email-masked]]
Sent: Thursday, January 28, 2021 10:34 AM
To: Templin (US), Fred L <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [Drip] HITs and HHITs as valid IPv6 addresses in 'draft-ietf-drip-rid'

EXT email: be mindful of links/attachments.

Fred, again, thank you!

I can't comment on what the HIP authors originally intended, but Bob could.

Nor have I yet fully grokked your latest contribution here, but I am happy to see you make the effort, which at first quick read looks promising.

If we of IETF can present a consistent picture to ASTM, ICAO TFSG & WG-I, RTCA/EUROCAE, et al, that will help greatly.

On Thu, Jan 28, 2021, 1:13 PM Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Stu, turning back to this message from a couple of weeks ago I took it upon
myself to learn a bit more about HIP and based on what I learned I took the
concept one step further and said: “Why not form a complementary union
between HIP and AERO/OMNI and thereby get the best of both worlds?”.
I wrote this into the latest OMNI draft, which you can see here:

https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/

This would have AERO/OMNI inheriting not just the (H)HIT, but also all of
the protocol mechanisms of HIP as well. It would have the HIP Initiator
and Responder messages driven by IPv6 ND messages, which appears
to be consistent with what the HIP authors originally intended when
they designed the message formats.

Am I wrong?

Thanks - Fred

From: Card, Stu [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, January 12, 2021 9:47 AM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [Drip] HITs and HHITs as valid IPv6 addresses in 'draft-ietf-drip-rid'

EXT email: be mindful of links/attachments.

On 1st quick consideration of your idea, I _think_ you are right!

[H]HITs are artifacts emerging from HIP work, but neither require nor exclusively support running HIP.

Thanks for this novel idea!

On Tue, Jan 12, 2021, 12:29 PM Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Stu, I admittedly don’t know much about HIP (even though my officemate
was one of the authors), but it occurs to me that the HIT/HHIT could also be
used with AERO/OMNI instead of HIP.

With AERO/OMNI, there is always a virtual interface (the OMNI interface)
that the HIT/HHIT would be assigned to, i.e., even if there are multiple
underlying interfaces associated with the OMNI interface. The HIT/HHIT
could then be called a valid IPv6 address.

Another point is that the document at some points references HIP. If it
intends to continue to do so, please make sure that it is just an example
and not the exclusive potential user of HITs/HHITS, as others such as
AERO/OMNI are also candidate users.

Thanks - Fred

From: Card, Stu [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, January 12, 2021 9:14 AM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Dickson (US), Sean M <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Drip] HITs and HHITs as valid IPv6 addresses in 'draft-ietf-drip-rid'

Interesting point Fred.

One (sophist?) definition would be that a [H]HIT is associated with the set of virtual interfaces used by the host for HIP (e.g. hip0, hip1), with the caveat that these are not always up.

This is not really different from a DHCP reservation associated with a wireless interface on a mobile host, inc. one that connects to different routers so only gets that address when it connects to the router configured with that DHCP reservation.

Do you consider that sufficient?
On Tue, Jan 12, 2021, 11:57 AM Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi, in the draft it says in a couple of places that HITs and HHITs are "valid IPv6 addresses".
But, in RFC8200, "address" is defined as follows:

   address      an IPv6-layer identifier for an interface or a set of interfaces.

So, the HIT/HHIT cannot be called a "valid IPv6 address" unless it is also associated
with an interface or a set of interfaces.

The simple and effective fix for this is to, in the document, state that the HIT/HHIT
will always be assigned to a virtual interface of the device (e.g., loopback, etc.).
With that simple fix, I believe the statement that the HIT/HHIT is a valid IPv6
address is supported; without it, I do not believe the claim can be made.

Thanks - Fred

--
Tm-rid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tm-rid

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 28 Jan 2021 15:05:41 -0500

Ah, a diffs between proper versions is very welcome.  I was NOT looking 
forward to plowing through almost 70 pages.

Per origins of HIP and IPv6ND.  They were totally orthogonal, though 
some common discussions on how to secure ND later in the ND work.

The origins of HIP came out of discussions at IETF 43, Dec '98. IKEv1 
was just too expensive in terms of packets and time for others to 
consider it for use at the host level (as opposed to gateways). I looked 
at how to simplify, and I had Krawczyk's work on SIGMA from Mar '96 to 
guide me (I was at ISOC Security where he presented SIGMA and HMAC).  
The first paper in Mar '99 dealt with only the protocol and did not yet 
have HITs.  But remembering conversations with Bellovin in '94 (IETF 31) 
about implied trust in IP addresses through routablity, I "invented" 
HITs which is the sole invention in HIP.

IETF 45, where we were sweating in Oslo at 35C in a hotel not able to 
handle the IETF crowds, Simpson gave me the idea for the I1 packet, 
turning HIP into the final 4-packet exchange.

I was focused on trust in Addresses and Key Establishment, not 
leveraging (or securing) Neighbor Discovery.  Others picked it up and 
ran with it as I had health issues that eventually had me more in the 
background for a few years.

I would say that the HITs as trust in Identity in the form of addresses 
is really the focal point of HIP that many struggle with, as it resulted 
in an IP 'super-layer' that masked the network from the transport in a 
secure manner.  This required a rethink in kernel design that was a 
barrier for adoption.

Here in DRIP we have gone back to that fundamental part in HIP.  The 
HITs and reintroduced the Hierarchy that was removed around '03 for lack 
of use case (critical for DRIP).

But HIP is there in the background, so to speak, to leverage those HHITs 
into a secure layer for transport over any lower layer.

On 1/28/21 2:22 PM, Templin (US), Fred L wrote:
> <https://www.ietf.org/rfcdiff?url1=draft-templin-6man-omni-interface-68&url2=draft-templin-6man-omni-interface-71>
>
> *From:*Robert Moskowitz [mailto:[email-masked]]
> *Sent:* Thursday, January 28, 2021 11:14 AM
> *To:* Templin (US), Fred L <[email-masked]>; Card, Stu 
> <[email-masked]>
> *Cc:* [email-masked]
> *Subject:*  Re: [Drip] HITs and HHITs as valid IPv6 addresses in 
> 'draft-ietf-drip-rid'
>
>
> 	
>
> I am a loud voice in ICAO TFSG and with you in other areas, we can 
> begin to coordinate on strong solutions for aviation.
>
> Bob
>
>     *From:*Card, Stu [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Sent:* Thursday, January 28, 2021 10:34 AM
>     *To:* Templin (US), Fred L <[email-masked]>
>     <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Subject:* [EXTERNAL] Re: [Drip] HITs and HHITs as valid IPv6
>     addresses in 'draft-ietf-drip-rid'
>
>
>     	
>
>     Nor have I yet fully grokked your latest contribution here, but I
>     am happy to see you make the effort, which at first quick read
>     looks promising.
>
>     If we of IETF can present a consistent picture to ASTM, ICAO TFSG
>     & WG-I, RTCA/EUROCAE, et al, that will help greatly.
>
>     On Thu, Jan 28, 2021, 1:13 PM Templin (US), Fred L
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         <https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/>
>
>         *From:*Card, Stu [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         *Sent:* Tuesday, January 12, 2021 9:47 AM
>         *To:* Templin (US), Fred L <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc:* [email-masked] <mailto:[email-masked]>
>         *Subject:* [EXTERNAL] Re: [Drip] HITs and HHITs as valid IPv6
>         addresses in 'draft-ietf-drip-rid'
>
>
>         	
>
>         [H]HITs are artifacts emerging from HIP work, but neither
>         require nor exclusively support running HIP.
>
>         On Tue, Jan 12, 2021, 12:29 PM Templin (US), Fred L
>         <[email-masked] <mailto:[email-masked]>>
>         wrote:
>
>             *From:*Card, Stu [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             *Sent:* Tuesday, January 12, 2021 9:14 AM
>             *To:* Templin (US), Fred L <[email-masked]
>             <mailto:[email-masked]>>
>             *Cc:* [email-masked] <mailto:[email-masked]>; Dickson
>             (US), Sean M <[email-masked]
>             <mailto:[email-masked]>>
>             *Subject:* Re: [Drip] HITs and HHITs as valid IPv6
>             addresses in 'draft-ietf-drip-rid'
>
>
>             Interesting point Fred.
>
>             One (sophist?) definition would be that a [H]HIT is
>             associated with the set of virtual interfaces used by the
>             host for HIP (e.g. hip0, hip1), with the caveat that these
>             are not always up.
>
>             This is not really different from a DHCP reservation
>             associated with a wireless interface on a mobile host,
>             inc. one that connects to different routers so only gets
>             that address when it connects to the router configured
>             with that DHCP reservation.
>
>             On Tue, Jan 12, 2021, 11:57 AM Templin (US), Fred L
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>                 Hi, in the draft it says in a couple of places that
>                 HITs and HHITs are "valid IPv6 addresses".
>                 [email-masked] <mailto:[email-masked]>
>                 <https://www.ietf.org/mailman/listinfo/tm-rid>
>
>
>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit