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

From: <[email-masked]>
Date: Mon, 28 Jun 2021 12:15:34 +0000

Hi Bob, Fred,

Other than **insisting** that HHITs can be used independently of HIP, is there any other change to be made to draft-ietf-drip-rid as an outcome of this thread?

I don’t think that we need to talk about interfaces (even virtual/loopback) so that we can claim that HHITs are valid IPv6 addresses. Fred, please refer to RFC6052 to see an example of valid addresses that are not assigned to any interface.

I don’t know whether your off-list discussion identified any DRIP-related change. If so, please share them with the list. Thank you.

Cheers,
Med

De : Tm-rid [mailto:[email-masked]] De la part de Robert Moskowitz
Envoyé : vendredi 29 janvier 2021 05:24
À : Templin (US), Fred L <[email-masked]>; Card, Stu <[email-masked]>
Cc : [email-masked]
Objet : Re: [Drip] HITs and HHITs as valid IPv6 addresses in 'draft-ietf-drip-rid'

We need to move this discussion off the DRIP list.  We can talk directly or over on the HIPSEC list.

But the 'key' packets are R1 and I2.  Per 7401 sec 1.2, I2 and R2 can be have a Next Header such that data is included.  We should take any optimizations like this off the DRIP list as they are not germane here.

I will see what I can work up for you tomorrow.
On 1/28/21 6:22 PM, Templin (US), Fred L wrote:
Bob, I see security use cases for all three of:

1) Zero-message HIP exchange (for access networks with strong link-layer security)
2) Two-message HIP exchange (for V2I over an open Internetwork)
3) Four-message HIP exchange (for V2V over an open Internetwork or VANET)

Case 1) is what we see for civil aviation in ICAO.
Case 3) behaves exactly per RFC7401.
Case 2) would be a “SEND replacement” and would allow a mobile node
to associate with a fixed infrastructure element (i.e., a server) in the
open Internet in the same spirit as RFC4380.

But, I don’t see any provisions in RFC7401 for a “two-message HIP exchange”.
Wouldn’t it be possible to eliminate the “puzzle” exchange and have only the
I1/R1 messages with no I2/R2 and still have both parties verify each other’s
signatures? And, wouldn’t that be at least as secure as SEND – and even more
secure than what RFC4380 does?

Thanks - Fred

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

EXT email: be mindful of links/attachments.

this reminds me that I am suppose to provide the security layers model, developed in IEEE 802.1AE, for ICAO TFSG TRON.

Basically, security is done at multiple layers simultaneously as each layer has different owners and different liabilities.  So Network layer like in Cellular that is similar to the aviation DLSP proposals, does not really address the liabilities of the systems using the network, only the liabilities of the provider(s) of the network.

More later.
On 1/28/21 5:38 PM, Templin (US), Fred L wrote:
Bob, the security architecture is obviously central to all this, and it varies for various
forms of aviation. For manned aviation, data link service providers will often provide
a secure link layer “access network” model where providing network-layer security
for the network layer control messages may not be a pressing issue. But, even for this
case I see value in the (H)HIT and plan to add another OMNI sub-option to include it
for cases when a HIP message is not included. For UAS operating in the NAS, however,
the data link may not be secured and the “open Internet” access model may be
necessary. In that case, security for the network layer control messages will be
mandatory and can be provided by HIP operating in conjunction with OMNI.

I think also “Vehicle-to-Infrastructure (V2I)” and “Vehicle-to-Vehicle (V2V)” are
driving factors for the security model. For V2I, network layer security may not be
needed if the access networks are secured but will certainly be needed when
the “access network” is the open Internet. For V2V, certainly strong mutual
authentication at the network layer will be necessary. I still believe in all of
these cases we may have complimentary pieces of the big picture.

Fred

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

Fred,  I plan on getting through OMNI; only 70 pages...

I won't go too much into the history of CGA.  It is interesting effort.

A couple other pieces of history for context.  The week prior to IETF 45 was an IAB Namespace Research Group meeting in the Netherlands (Utrecht); HITs were one of the namespaces under discussion at the time.  I was being 'pushed' by the MIT gang to identify what I was naming, and with Steve Crocker's help came up with naming the protocol stack.

The puzzle also came out from my short discussions with Simpson at Oslo.  I never considered it an invention, as anyone conversant in the arts would see it.  But RSA Research did patent a puzzle mechanism for TCP shortly afterwards, not knowing about my drafts.

SEND did not want to go the full HIP route.  :)

I think HHITs on all aviation and then HIP for communications security, leveraging into OMNI will give aviation some significant provider agnostic technology.  Let's get on with it.

But first I have a couple drafts here to finish updating this week (prior to month-end reporting :) ).

Bob
On 1/28/21 3:25 PM, Templin (US), Fred L wrote:
Bob, I understand about trying to digest long drafts, but HIP RFC7401 is even longer
and I put in the effort to dig out the understanding I have come to which is bound
to be partial and not the whole story. I am glad the OMNI diffs gave a bit of insight,
and would encourage you to look further through the draft if you’d like more context.

To me, the HIT (and now HHIT) look like “cryptographically generated addresses
done right”. I had been going down the path of SEND/CGA but got discouraged
by what I saw as some antiquated and not very robust facilities, so when I got to
reading about (H)HIT and the strong security features of HIP I saw an opportunity.
I realize that HIP is about much more than just that, and I am sure we would find
areas of overlap between HIP and AERO/OMNI. But, I think we would find the
complimentary aspects would bear further investigation and understanding.

Thanks - Fred

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

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:
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]><mailto:[email-masked]>; Card, Stu <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[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

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

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

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

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.