One document matched: draft-moskowitz-hierarchical-hip-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-moskowitz-hierarchical-hip-02.txt" ipr="trust200902">
<front>
<title abbrev="Hierarchical HITs">Hierarchical HITs for HIPv2</title>
<author fullname="Robert Moskowitz" initials="R" surname="Moskowitz">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<city>Oak Park</city>
<region>MI</region>
<code>48237</code>
<country>USA</country>
</postal>
<email>rgm@labs.htt-consult.com</email>
</address>
</author>
<author fullname="Xiaohu Xu" initials="X." surname="Xu">
<organization>Huawei</organization>
<address>
<postal>
<street>Huawei Bld, No.156 Beiqing Rd.</street>
<city>Beijing</city>
<region>Hai-Dian District</region>
<code>100095</code>
<country>China</country>
</postal>
<email>xuxiaohu@huawei.com</email>
</address>
</author>
<author fullname="Bingyang Liu" initials="B." surname="Liu">
<organization>Huawei</organization>
<address>
<postal>
<street>Huawei Bld, No.156 Beiqing Rd.</street>
<city>Beijing</city>
<region>Hai-Dian District</region>
<code>100095</code>
<country>China</country>
</postal>
<email>xuxiaohu@huawei.com</email>
</address>
</author>
<date year="2016" />
<area>Internet</area>
<workgroup>HIP</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>HIP</keyword>
<abstract>
<t>
This document describes using a hierarchical HIT to facilitate large
deployments in mobile networks.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document expands on <xref target="RFC7401">HIPv2</xref> to
describe the structure of a hierarchical HIT, the Registry services
to support this hierarchy, and given a hierarchical HIT, how a device
is found in the network.
</t>
<t>
A separate document will further expand on the registry service and
how a device can advertise its availability and services provided.
</t>
</section>
<section anchor="terms" title="Terms and Definitions">
<section title="Requirements Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section title="Definitions">
<t>
<list style="hanging">
<t hangText="HDA (Hierarchical HIT Domain Authority):">
The 14 bit field identifying the HIT Domain Authority under a RAA.
</t>
<t hangText="HID (Hierarchy ID):">
The 32 bit field providing the HIT Hierarchy ID.
</t>
<t hangText="RAA (Registered Assigning Authority):">
The 18 bit field identifying the Hierarchical HIT Assigning
Authority.
</t>
</list>
</t>
</section>
</section>
<section anchor="prob-space" title="Problem Space">
<section title="Meeting the future of Mobile Networking">
<t>
The evolution of mobile networking to greater bandwidth and faster
mobility will favor IP mobility technologies that optimize shortest
routing paths for both mobile-to-stationary and mobile-to-mobile
applications. For this, devices will need to use the IP
address which provide the shortest path for where they are
physically in the mobile network. The mobile device
will need services that will discover this IP addresses for their
peer mobile devices and keep them connected to those peers even
when both devices move in the network at the same time (the
double-jump problem). In order to support these services, there
needs to be billable services to support the infrastructure.
In some area close tracking of mobile devices will be mandatory.
In other device obfuscation to protect privacy and/or safety will be the only
life-enabling approach.
</t>
<t>
These conflicting requirements can be met with the Host Identity
Protocol (HIP), provided its Rendezvous Server service is scaleable
and manageable. Providers of RVS will need both a viable and
scaleable business model.
</t>
</section>
<section title="Semi-permanency of Identities">
<t>
A device Identity has some degree of permanency. A device creates
its identity and registers it some 3rd-party that will assert a
level of trust for that identity. A device may have multiple
identities to use in different contexts, and it may deprecate an
identity for any number of reasons. The asserting 3rd-party may
withdraw its assertion of an identity for any number of reasons. An
identity system needs to facilitate all of this.
</t>
</section>
<section title="Managing a large flat address space">
<t>
For HIP to be successfully used in large mobile networks, it must
support an Identity per device, or at least 10 billion Identities.
Perhaps a Distributed Hash Table <xref target="I-D.irtf-hiprg-dht">
</xref> can scale this large. There is still the operational
challenges in establishing such a world-wide DHT implementation and
how <xref target="RFC8004">RVS</xref> works with such a large
population. There is also the challenge of how to turn this into a
viable business for the Mobile Network Providers.
</t>
<t>
Even though the probability of collisions with 7B HITs in a 96 bit
flat address space is 3.9E-10, it is still real. How are
collisions managed? It is also possible that weak key uniqueness,
as has been shown in deployed TLS certificates, results in a much
greater probability of collisions. Thus resolution of collisions
needs to be a feature in a globally mobile network.
</t>
</section>
<section title="Defense against fraudulent HITs">
<t>
How can a host protect against a fraudulent HIT? That is a second
pre-image attack on the HI hash that produces the HIT. A strong
defense would require every HIT/HI registered and openly
verifiable. This would best be done as part of the R1 and I2
validation.
</t>
</section>
<section title="Desire for administrative control by RVS providers">
<t>
An RVS provider may only be willing to provide discovery (RVS)
services to HIP devices it knows and trusts. A flat HIT space does
not provide any intrinsic functionality to support this. A
hierarchical HIT space can be mapped to the RVS provider. DNS can
effectively be used to provide the HIT to IP mapping without DHT.
</t>
<t>
A hierarchical HIT space also creates a type of a business labeling
for the RVS provider. "These are my customers."
</t>
</section>
</section>
<section anchor="HHIT" title="The Hierarchical Host Identity Tag (HIT)">
<t>
The Hierarchical HIT is a small but important enhancement over the
flat HIT space. It represents the HI in only a 64 bit hash and
uses the other 32 bits to create a hierarchical administration
organization for HIT domains. Hierarchical HITs are <xref
target="RFC7343">ORCHIDs</xref>. The change in construction rules
are in <xref target="HCGA"/>.
</t>
<t>
A Hierarchical HIT is built from the following fields:
<list style="symbols">
<t>
28 bit IANA prefix
</t>
<t>
4 bit HIT Suite ID
</t>
<t>
32 bit Hierarchy ID (HID)
</t>
<t>
64 bit ORCHID hash
</t>
</list>
</t>
<section anchor="HID" title="The Hierarchy ID (HID)">
<t>
The Hierarchy ID (HID) provides the structure to organize HITs into
administrative domains. HIDs are further divided into 2 fields:
<list style="symbols">
<t>
14 bit Registered Assigning Authority (RAA)
</t>
<t>
18 bit Hierarchical HIT Domain Authority (HDA)
</t>
</list>
</t>
<section anchor="RAA" title="The Registered Assigning Authority (RAA)">
<t>
An RAA is a business that manages a registry of HDAs.
</t>
<t>
The RAA is a 14 bit field (16,384 RAAs) assigned sequentially by a
numbers management organization, perhaps ICANN's IANA service. An
RAA must provide a set of services to allocate HDAs to
organizations. It must have a public policy on what is necessary to
obtain an HDA. The RAA need not maintain any HIP related services.
It must maintain a DNS zone for discovering HID RVS servers.
</t>
<t>
This DNS zone may be a reverse PTR for its RAA. Assume that the
RAA is 100. The PTR record is constructed at a 2 bit grouping:
</t>
<figure>
<artwork>
0.1.2.1.0.0.0.hhit.arpa IN PTR raa.bar.com.
</artwork>
</figure>
</section>
<section anchor="HDA"
title="The Hierarchical HIT Domain Authority (HDA)">
<t>
An HDA may be an ISP or any third party that takes on the business
to provide RVS and other needed services for HIP enabled devices.
</t>
<t>
The HDA is an 18 bit field (262,144 HDAs per RAA) assigned
sequentially by an RAA. An HDA should maintain a set of RVS
servers that its client HIP-enabled customers use. How this is
done and scales to the potentially millions of customers is outside
the scope of this document. This service should be discoverable
through the DNS zone maintained by the HDA's RAA.
</t>
<t>
An RAA may assign a block of values to an individual organization.
This is completely up to the individual RAA's published policy for
delegation.
</t>
</section>
<section anchor="HIDDNS" title="Example of the HID DNS">
<t>
HID related services should be discoverable via DNS. For example
the RVS for a HID could be found via the following. Assume that
the RAA is 100 and the HDA is 50. The PTR record is constructed at
a 2 bit grouping:
</t>
<figure>
<artwork>
2.0.3.0.0.0.0.0.0.1.3.1.0.0.0.0.hhit.arpa IN PTR rvs.foo.com.
</artwork>
</figure>
<t>
The RAA is running its zone, 1.3.1.0.0.0.0.hhit.arpa under the
hhit.arpa zone.
</t>
</section>
<section anchor="HCGA" title="Changes to ORCHIDv2 to support Hierarchical HITs">
<t>
ORCHIDv2 <xref target="RFC7343"></xref> has a number of inputs
including a context, some header bits, the hash algorithm, and the
public key. The output is a 96 bit value. Hierarchical HIT makes
the following changes. The HID is added as part of the header bits
and the output is a 64 bit value, derived the same way as the 96
bit hash.
</t>
<t>
<figure>
<artwork>
Input := HID | HOST_ID
OGA ID := 4-bit Orchid Generation Algorithm identifier
The HIT Suite ID = 0x40
Hash Input := Context ID | Input
Same Context ID as HIPv2
Prefix := HIPv2 Prefix
HID := Hierarchy ID
Hash := Hash_function( Hash Input )
Encode_64 := Same as Encode_96, but only 64 bits
ORCHID := Prefix | OGA ID | HID | Encode_64( Hash )
</artwork>
</figure>
</t>
<t>
Hierarchical HIT uses the same context as all other HIPv2 HIT
Suites as they are clearly separated by the distinct HIT Suite ID.
</t>
</section>
<section anchor="Collision" title="Collision risks with Hierarchical HITs">
<t>
The 64 bit hash size does have an increased risk of collisions over
the 96 bit hash size used for the other HIT Suites. There is a
0.01% probability of a collision in a population of 66 million.
The probability goes up to 1% for a population of 663 million. See
<xref target="Coll_Prob"/> for the collision probability formula.
</t>
<t>
However, this risk of collision is within a single HDA. Further,
all HDAs are expected to provide a registration process for reverse
lookup validation. This registration process would reject a
collision, forcing the client to generate a new HI and thus
hierarchical HIT and reapplying to the registration process.
</t>
</section>
</section>
</section>
<section anchor="hippars" title="HIP Parameters">
<t>
The HIP parameters carry information that is necessary for
establishing and maintaining a HIP association. For example,
the device's public keys as well as the signaling for negotiating
ciphers and payload handling are encapsulated in HIP
parameters. Additional information, meaningful for end hosts
or middleboxes, may also be included in HIP parameters. The
specification of the HIP parameters and their mapping to HIP
packets and packet types is flexible to allow HIP extensions to
define new parameters and new protocol behavior.
</t>
<section anchor="hit_suite_list" title="HIT_SUITE_LIST">
<t>
The HIT_SUITE_LIST parameter contains a list of the supported
HIT suite IDs of the Responder. Based on the HIT_SUITE_LIST,
the Initiator can determine which source HIT Suite IDs are
supported by the Responder. The HIT_SUITE_LIST parameter is
defined in Section 5.2.10 of <xref target="RFC7401" />.
</t>
<t>
The following HIT Suite IDs are defined for Hierarchical HITs,
and the relationship between the four-bit ID value used in the
OGA ID field and the eight-bit encoding within the
HIT_SUITE_LIST ID field is clarified:
</t>
<figure>
<artwork>
HIT Suite Four-bit ID Eight-bit encoding
ECDSA/hier/SHA-256 4 0x40
</artwork>
</figure>
<t>
Note that the Hierarchical HIP HIT Suite ID allows the devices
to use the hierarchical RVS discovery and authentication
services to validate the peer and discover available services.
The Responder SHOULD respond with a HIP hierarchical HIT suite
ID when the HIT of the Initiator is a HIP hierarchical HIT.
</t>
</section>
<section anchor="CLIENT_INFO" title="CLIENT_INFO">
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Client Information /
/ /
/ +-------------------------------+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [TBD-IANA]
Length length in octets, excluding Type, Length, and
Padding
Client The information required by the HDA in the format
Information required by the HDA.
</artwork>
</figure>
<t>
This parameter contains client information to include in the HIT
registration. The specific content and format is set by the HDA.
</t>
</section>
</section>
<section title="HHIT Registry services to support hierarchical HITs">
<t>
Hierarchical HIT registration SHOULD be performed using the HIP
Registration Extension <xref target="RFC8003"> </xref>. The client
either uses an X.509 certificate <xref target="RFC8002"> </xref>,
or use a PSK, as defined in Appendix A of HIP-DEX <xref
target="I-D.ietf-hip-dex"> </xref>, to validate the registration.
</t>
<t>
The Registration should include additional client information. This
information may be contained within the X.509 certificate and/or is
carried in the CLIENT_INFO parameter, see <xref
target="CLIENT_INFO" />. The Registrar can include its requirements
in the R1 packet, and the client provide its information in the I2
packet. This parameter may be encrypted within the ENCRYPTED
parameter. If the CLIENT_INFO contains Personal Identifying
Information (PII), then it MUST be placed into the ENCRYPTED
parameter.
</t>
<t>
The content and internal format of the CLIENT_INFO parameter is set by
the HDA's policy and is outside the scope of this document. Examples
of client information can by phone number, IMEI, and ICCID.
</t>
<section title="Hierarchical HIT Registration using X.509 Certificates">
<t>
This requires the HIP client to possess a client certificate
trusted by the HDA/Registrar. Registration will either succeed or
fail.
</t>
</section>
<section title="Hierarchical HIT Registration using a PSK">
<t>
This requires the HIP client and the HDA/Registrar to share a PSK.
The PSK may already exist prior to starting the registration and
just be used within the registration. A PSK out-of-band exchange
may be triggered by performing the registration without any
authentication.
</t>
<t>
If no client authentication is included in the I2 packet, the
registration fails with "No Authentication provided". If the I2
packet included the proper HDA required client information, the HDA
can use it to set up a side channel for an out-of-band delivery of
a PSK. And example of this would be to send an SMS message with
the PSK. Once the client possesses the PSK, it can rerun the
registration at which point the HI and HIT duplicate checks are
performed.
</t>
</section>
<section anchor="RegType" title="Hierarchical HIT Registration Type">
<t>
The Registration Type used in the REG_REQUEST is:
</t>
<?rfc needLines="4" ?>
<figure>
<artwork align="left">
Number Registration Type
------ -----------------
2 HIT Registration
</artwork>
</figure>
</section>
<section anchor="RegFail" title="Hierarchical HIT Registration Failure Type">
<t>
The Registration may fail. In fact, with PSK, this may be the
response to expect an SMS message with the PSK to use in a second
registration request. Failure Types used in the REG_FAIL are:
</t>
<?rfc needLines="4" ?>
<figure>
<artwork align="left">
Failure Type Reason
------------ -----------------------
[TBD-IANA] Hierarchical HIT Already Registered
[TBD-IANA] HI Already Registered
[TBD-IANA] Previously Registered HI with different device information
[TBD-IANA] No Authentication provided
[TBD-IANA] Invalid Authentication
[TBD-IANA] Invalid Authentication, new PSK sent via SMS
</artwork>
</figure>
</section>
<section title="Registration failure behavior">
<t>
If the failure type is "Hierarchical HIT Already
Registered", the client's HI is hashing to an existing HIT and must
generate a new HI and hierarchical HIT and reregister. If the
failure is "HI Already Registered", the client should assume it is
registered. If the failure is "Previously Registered HI with
different device information", either the client managed to
generate a duplicate HI, probably indicating a weak key generation
algorithm, or the client was previously registered on a different
device. Resolving this conflict will be left to the HDA's policy.
</t>
<section title="Example of a simple HDA policy">
<t>
A simple HDA policy would be to require the device to generate a
new HI and thus HHIT and try registration again. The HDA policy
may also provide a URL for "Previous Registration Resolution".
This contact is primarily to assist a device that was registered,
but had some local failure resulting in a new registration attempt.
</t>
</section>
</section>
</section>
<section title="Using hierarchical HITs">
<t>
All HIP clients with hierarchical HITs maintain an RVS connection
with their HDA's RVS server(s). How the HDA scales this service up
to a potential population in the millions is out of scope of this
document. Lifetime management of these connections is also out of
scope.
</t>
<t>
One approach an HDA can use to address the scaling challenge is to
add an internal level of hierarchy to assign a set number of
devices per RVS server.
</t>
<t>
Peering agreements between HDAs would allow for geographically
close RVS to a device. This may reduce the latency for use of a
device's current RVS. This is a subject of another document.
</t>
<section title="Contacting a HIP client">
<t>
A service Initiator uses some service to discover the HIT of the
service Responder. The Initiator uses the hierarchical information
in the HIT to find the Responder's RVS. A trusted RVS discover
method could use the DNS PTR to RVS as shown in <xref
target="HIDDNS"/>. An I1 is sent to that RVS which forwards it to
the Responder.
</t>
<t>
The potential Responder uses the HIT in the I1 to query the
Initiator's RVS about the Initiator. The nature of information,
and method of communication are determined by the Initiator's HDA
and the Responder's (and or HDA's) relationship with it. Based on
the Responder's local policy, this information will be used to
determine if the contact is to be accepted. If accepted, the
Responder may proceed sending an R1 to the Initiator. It may
alternatively initiate some non-HIP process.
</t>
<t>
It should be noted that this R1 may contain a REG_INFO list for the
Initiator to validate that the Responder does offer the desired
service.
</t>
</section>
<section title="Defense against fraudulent HITs">
<t>
Both the Initiator and Responder MAY validate a peer host as a
defense against a second pre-image attack on the HHIT. This may
occur via a <xref target="RFC8002">CERT</xref> in R1 or I2. It may
be through a back end process associated with the R1 or I2
validation to look up the HHIT and retrieve the registered HI.
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
IANA will need to make the following changes to the "Host
Identity Protocol (HIP) Parameters" registries:
</t>
<t>
<list style="hanging">
<t hangText="HIT Suite ID:">
This document defines the new HIT Suite "Hierarchy with
ECDSA/SHA256" (see <xref target="hit_suite_list" />).
</t>
<t hangText="CLIENT_INFO:">
This document defines the new CLIENT_INFO parameter (see
<xref target="CLIENT_INFO" />). The parameter value will be
assigned by IANA.
</t>
<t hangText="Reg Type:">
This document defines the new Registration Type for the
REG_REQUEST parameter "HIT Registration" (see <xref
target="RegType" />).
</t>
<t hangText="Reg Fail:">
This document defines the new Failure Types for the REG_FAIL
parameter (see <xref target="RegFail" />).
</t>
</list>
</t>
</section>
<section title="RAA Management Organization Considerations">
<t>
Introducing the RAA management organization may be the largest
hurdle for hierarchical HITs. Thus it would be best if this were
adopted by an organization already in the business of allocating
numbers within either the Internet or the Mobile, cellular,
infrastructure.
</t>
<t>
One consideration would be to reserve the first N RAA values to map
to the existing DNS TLDs. For example, these TLDs can be organized
in an ascending order and numbered accordingly. Thus the 2
character TLDs will be a lower number than the 3 character TLDs.
After that, it could be a first come, first numbered assignment
process.
</t>
</section>
<section title="Security Considerations">
<t>
There are potential risks with the hierarchical HIT, the Registry
service, and the discovery of potential peer hosts using its
hierarchical HIT.
</t>
<t>
A 64 bit hash space presents a real risk of second pre-image
attacks. The HHIT Registry services effectively block attempts to
"take over" a HHIT. It does not stop a rogue attempting to
impersonate a known HHIT. This attack can be mitigated by the
Responder using DNS to find the HI for the HHIT or the RVS for the
HHIT that then provides the registered HI.
</t>
<t>
The two risks with hierarchical HITs are the use of an invalid HID
and forced HIT collisions. The use of the "hhit.arpa." DNS zone is
a strong protection against invalid HIDs. Querying an HDA's RVS
for a HIT under the HDA protects against talking to unregistered
clients. The Registry service has direct protection against forced
or accidental HIT hash collisions.
</t>
<t>
By using the HIP Registration Extension, the Registry service is
protected from direct attacks. This service does rely on either
the integrity of a PKI service or an out-of-band PSK delivery
process. Thus the risk to the Registry service is highly related
to the trust in these authentication setup services. Further, the
duplicate HI resolution process may require human interaction with
related social engineering risks.
</t>
<t>
Finally the peer host discovery process relies on trusting the
finding the proper HDA for the host and its forwarding the I1 to
the proper Responder. A rogue RVS, impersonating the RVS for the
HIT, could redirect the I1 to a client that has forced a collision
with the HIT and the Initiator would be none the wiser. The only
defense against this is if the Initiator has some other source for
the Responder HI and validate the HI in the R1.
</t>
</section>
<section title="Acknowledgments">
<t>
Sue Hares of Huawei contributed to the clarity in this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.7343.xml"?>
<?rfc include="reference.RFC.7401.xml"?>
<?rfc include="reference.RFC.8002.xml"?>
<?rfc include="reference.RFC.8003.xml"?>
<?rfc include="reference.RFC.8004.xml"?>
<?rfc include="reference.I-D.irtf-hiprg-dht.xml"?>
<?rfc include="reference.I-D.ietf-hip-dex.xml"?>
</references>
<section anchor="Coll_Prob" title="Calculating Collision Probabilities">
<t>
The accepted formula for calculating the probability of a collision
is:
</t>
<figure>
<artwork>
p = 1 - e^{-k^2/(2n)}
P Collision Probability
n Total possible population
k Actual population
</artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:26:56 |