Skip to main content

Host Identity Protocol Architecture
draft-ietf-hip-rfc4423-bis-20

Revision differences

Document history

Date Rev. By Action
2021-07-13
20 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-06-04
20 (System) RFC Editor state changed to AUTH48
2021-04-22
20 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-04-02
20 (System) RFC Editor state changed to EDIT from MISSREF
2019-07-08
20 Éric Vyncke Shepherding AD changed to Éric Vyncke
2019-03-25
20 (System) RFC Editor state changed to MISSREF
2019-03-25
20 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-03-25
20 (System) Announcement was received by RFC Editor
2019-03-25
20 (System) IANA Action state changed to No IANA Actions
2019-03-23
20 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2019-03-23
20 Amy Vezza IESG has approved the document
2019-03-23
20 Amy Vezza Closed "Approve" ballot
2019-03-23
20 Amy Vezza Ballot approval text was generated
2019-02-14
20 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-02-14
20 Miika Komu New version available: draft-ietf-hip-rfc4423-bis-20.txt
2019-02-14
20 (System) New version approved
2019-02-14
20 (System) Request for posting confirmation emailed to previous authors: Robert Moskowitz , Miika Komu
2019-02-14
20 Miika Komu Uploaded new revision
2018-05-10
19 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2018-05-10
19 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-05-10
19 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2018-05-10
19 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-05-10
19 Will LIU Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Will LIU. Sent review to list.
2018-05-09
19 Ben Campbell
[Ballot comment]
I have mostly just reviewed the diff from RFC4423. My comments are mostly editorial.

First, a minor rant that I don't expect …
[Ballot comment]
I have mostly just reviewed the diff from RFC4423. My comments are mostly editorial.

First, a minor rant that I don't expect to be addressed at this point in the process; I mainly say this to try to discourage it future bis drafts: There are quite a few changes from 4423 that are entirely stylistic, but do not materially change the content or improve readability. I wish people wouldn't do that, because it makes it harder to review material changes with the diff tools. (I will only point out such changes where I think the original was more correct.)

-General: There seems to have been a systematic attempt to remove hyphens from compound adjectives. There also seems to be a systematic attempt to change headings from title case to normal sentence case.  I suspect the RFC editor will change those all back.

Abstract: The abstract manages to completely avoid saying what this namespace is _for_. (Yes, I realize that is old text :-) )

§1, first paragraph: s/ "try and do"/"try to do"

§4.2: Please mention the HIT abbreviation in the text, not just the heading. (The text should make sense even without the headings.)

§5:
- third paragraph: Missing articles before "Left" and "right".
- 2nd to last paragraph: Missing article before "HIP layer" (multiple instances).
2018-05-09
19 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-05-09
19 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-05-09
19 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-05-09
19 Adam Roach
[Ballot comment]
Thanks for everyone's work on updating RFC 4423.

In general, I agree with Mirja's point that section 11 seems a bit disjoint …
[Ballot comment]
Thanks for everyone's work on updating RFC 4423.

In general, I agree with Mirja's point that section 11 seems a bit disjoint
from the rest of the document, and would be better served as an appendix. It's
also somewhat jarring to have a document whose abstract talks about a "new
namespace" and a "new protocol layer," which goes on to describe conclusions
from twelve years of deployment experience. I would recommend re-working all
uses of the word "new" (which, in most cases, can be achieved by either
removing the word "new" from sentences, or replacing it with "HIP").

The remainder of my comments are editorial nits.

---------------------------------------------------------------------------

§2.1:

>  +---------------+---------------------------------------------------+
>  | Term          | Explanation                                      |
>  +---------------+---------------------------------------------------+
>  | Public key    | The public key of an asymmetric cryptographic key |
>  |              | pair.  Used as a publicly known identifier for    |
>  |              | cryptographic identity authentication.  Public is |
>  |              | a a relative term here, ranging from "known to    |
>  |              | peers only" to "known to the world."              |

Nit: this text contains a doubled "a" ("...a a relative...").

---------------------------------------------------------------------------
§2.2:

Nit: The change in spacing in this table makes certain terms difficult to read
(e.g., "HIP base exchange HIP packet" appears to be a single term until the
table is closely examined.) Consider reverting to the spacing from RFC 4423.

---------------------------------------------------------------------------

§3.1:

>  o  The names should have a fixed length representation, for easy

Nit: "fixed-length" is a compound adjective, and should be hyphenated.
cf. https://www.google.com/search?q=compound+adjective

>    (e.g the TCB).

Nit: The conventional form would call for "(e.g., the TCB)"
cf. https://www.google.com/search?q="e.g."+punctuation+comma

> o The names should be long lived, but replaceable at any time. This

"long-lived"

> designed, it can deliver all of the above stated requirements.

"above-stated"

---------------------------------------------------------------------------

§4:

>  In theory, any name that can claim to be 'statistically globally
>  unique' may serve as a Host Identifier.  In the HIP architecture, the
>  public key of a private-public key pair has been chosen as the Host
>  Identifier because it can be self managed and it is computationally

"self-managed"

---------------------------------------------------------------------------

§6.5:

>  The control plane between two hosts is terminated using a secure two
>  message exchange as specified in base exchange specification

"two-message"

---------------------------------------------------------------------------

§7:

>  control plane, protected by asymmetric key cryptography.  Also, S-RTP
>  has been considered as the data encapsulation protocol [hip-srtp].

"SRTP" rather than "S-RTP".

---------------------------------------------------------------------------

§8:

>  Besides this "native" NAT traversal mode for HIP, other NAT traversal
>  mechanisms have been successfully utilized, such as Teredo
>  [varjonen-split].

Please cite RFC 4380 for "Teredo." e.g.:

  Besides this "native" NAT traversal mode for HIP, other NAT traversal
  mechanisms have been successfully utilized, such as Teredo [RFC4380],
  as described in [varjonen-split].



---------------------------------------------------------------------------

§8:

>  can map to a single IP address on a NAT, simplifying connections on
>  address poor NAT interfaces.  The NAT can gain much of its knowledge

"address-poor"

---------------------------------------------------------------------------

§11.1:

>    Considering such human errors, a site
>    employing location-independent identifiers as promoted by HIP may
>    experience less problems while renumbering their network.

"...experience fewer problems..."

>  o  HITs (or LSIs) can be used in IP-based access control lists as a
>    more secure replacement for IPv6 addresses.  Besides security, HIT
>    based access control has two other benefits.

"HIT-based"

>    environments.  For instance, the benefits of HIT based access

"HIT-based"

---------------------------------------------------------------------------

§11.2:

>  The key exchange introduces some extra latency (two round trips) in
>  the initial transport layer connection establishment between two

"transport-layer"

>  keys and Diffie-Hellman key derivation at the control plane, but this
>  occurs only during the key exchange, its maintenance (handoffs,
>  refreshing of key material) and tear down procedures of HIP

"tear-down"

---------------------------------------------------------------------------

§11.3.1:

>  Networks [henderson-vpls] to facilitate, e.g, supervisory control and

"e.g.,"

---------------------------------------------------------------------------

§11.4:

>        A HI is a cryptographic public key.  However, instead of using
>        the keys directly, most protocols use a fixed size hash of the
>        public key.

"fixed-size"

>        HIP provides both stable and temporary Host Identifiers.
>        Stable HIs are typically long lived, with a lifetime of years

"long-lived"

>        network services.  Additionally, the Host Identifiers, as
>        public keys, are used in the built in key agreement protocol,

"built-in"

>        HIP reduces dependency on IP addresses, making the so called

"so-called"

---------------------------------------------------------------------------

§12.1:

>  Other types of MitM attacks against HIP can be mounted using ICMP
>  messages that can be used to signal about problems.  As a overall

"...an overall..."

>  be aborted after some retries).  As a drawback, this leads to an
>  6-way base exchange which may seem bad at first.  However, since this

"...a 6-way..."
2018-05-09
19 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-05-09
19 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-05-09
19 Benjamin Kaduk
[Ballot comment]
I share Eric's concerns about the need for
second-preimage-resistance from the hash, and in particular with the
birthday bound, it's unclear that using …
[Ballot comment]
I share Eric's concerns about the need for
second-preimage-resistance from the hash, and in particular with the
birthday bound, it's unclear that using a 128-bit hash leaves a very
large margin for growth.

Some other section-by-section notes follow.

Section 1

  [...] HIP provides for limited forms of trust between systems,
  enhance mobility, multi-homing and dynamic IP renumbering, aid in
  protocol translation / transition, and reduce certain types of
  denial-of-service (DoS) attacks.

I think that something is weird here with singular vs. plural in the
list elements.


Section 4

I agree with the secdir reviewer's not about "SHOULD NOT [implement
non-cryptographic HIP]"


Section 5.1

  At the client side, a host may have multiple Host Identities, for
  instance, for privacy purposes.  Another reason can be that the
  person utilizing the host employs different identities for different
  administrative domains as an extra security measure.  If a HIP-aware
  middlebox, such as a HIP-based firewall, is on the path between the
  client and server, the user or the underlying system should carefully
  choose the correct identity to avoid the firewall to unnecessarily
  drop HIP-based connectivity [komu-diss].

In addition to the firewall case, choosing the correct identifier
can also impact the privacy considerations, as a given identifier
would be trackable by on-path entities.


Section 6.2

  When a node moves while communication is already on-going, address
  changes are rather straightforward.  The peer of the mobile node can
  just accept a HIP or an integrity protected ESP packet from any
  address and ignore the source address.  However, as discussed in
  Section 12.2 below, a mobile node must send a HIP UPDATE packet to
  inform the peer of the new address(es), and the peer must verify that
  the mobile node is reachable through these addresses.

Am I reading this right that from a technical perspective, the peer
can just accept stuff from wherever, but from a policy/protocol
perspective the UPDATE requirement is included?  The text could
probably be a bit more clear, potentially even without using RFC
2119
language.


Section 10

  There are a number of variables that influence the HIP exchange that
  each host must support.  All HIP implementations should support at
  least 2 HIs, one to publish in DNS or similar directory service and
  an unpublished one for anonymous usage.  Although unpublished HIs

I suggest a parenthetical that the unpublished one should expect to
be rotated frequently in order to disrupt linkability/trackability.

  will be rarely used as responder HIs, they are likely to be common
  for initiators.  Support for multiple HIs is recommended.  [...]

If multiple means "more than two", it's probably better to say that.
(If multiple means "more than one", this is just a weaker version of
"should support at least 2", above.)  And it's rather tempting to
make it a MUST, anyway.

  Many initiators would want to use a different HI for different
  responders.  The implementations should provide for a policy mapping
  of initiator HITs to responder HITs.  This policy should also include
  preferred transforms and local lifetimes.

"mapping of initiator to responder" is potentially confusing, in
that in practice the procedure will be "I want to talk to responder
A, so let me look up that I use HIT X to talk to responder A", which
is the opposite direction from this text.


Section 11.1

I'd consider replacing "is an attempt to" with "attempts to" -- for
example, IPv6 tries to do a lot of things in addition to killing
NAT!


Section 11.3.1

  [...]Second, a
  data plane component is needed.  Most HIP implementations utilize the
  so called BEET mode of ESP that has been available since Linux kernel
  2.6.27, but is included also as a userspace component in a few of the
  implementations.

Nit: "but ESP is included", I think.


Section 12.1

I don't understand the usage of "a-priori" in:
  The need to support multiple hashes for generating the HIT from the
  HI affords the MitM to mount a potentially powerful downgrade attack
  due to the a-priori need of the HIT in the HIP base exchange.


  In HIP, the Security Association for ESP is indexed by the SPI; the
  source address is always ignored, and the destination address may be
  ignored as well.  Therefore, HIP-enabled Encapsulated Security
  Payload (ESP) is IP address independent.  This might seem to make
  attacking easier, but ESP with replay protection is already as well
  protected as possible, and the removal of the IP address as a check
  should not increase the exposure of ESP to DoS attacks.

It seems like there's still some potential incrased exposure, as
validating the ESP crypto is presumably more expensive than
validating source/destination IP addresses.


Section 12.3

  [...] At middleboxes, HIP-aware
  firewalls [lindqvist-enterprise] can use HITs or public keys to
  control both ingress and egress access to networks or individual
  hosts, even in the presence of mobile devices because the HITs and
  public keys are topologically independent. [...]

Nit: I think that just "topology independent" is what's intended.
2018-05-09
19 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-05-09
19 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-05-09
19 Alvaro Retana [Ballot comment]
Thank you for addressing the rtg-dir review: https://mailarchive.ietf.org/arch/msg/rtg-dir/wNRwnOCELE2lvz4Gy_YKy-Bkz0A
2018-05-09
19 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-05-07
19 Mirja Kühlewind
[Ballot comment]
A few minor high-level comments/questions:

1) To me it feels that sec 11 doesn't really belong in this bis doc. Maybe that is …
[Ballot comment]
A few minor high-level comments/questions:

1) To me it feels that sec 11 doesn't really belong in this bis doc. Maybe that is rather an own report or can just go in the appendix?

2) Should this document maybe discuss connection migration as used by QUIC as an alternative (based on short term connection identifiers instead of course)? Background: to provide identities between two endpoints, I'd say that TLS is sufficient or even the more appropriate solution. However, this document does not talk very much about cases where the identify of other IP hosts (not endpoints) is important. Oft course it covers the mobility use case but that also seems less relevant with migration support in QUIC.
2018-05-07
19 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2018-05-07
19 Mirja Kühlewind
[Ballot comment]
A few minor high-level comments/questions:

1) To me it feels that sec 11 doesn't really below in this bis doc. Maybe that is …
[Ballot comment]
A few minor high-level comments/questions:

1) To me it feels that sec 11 doesn't really below in this bis doc. Maybe that is rather an own report or can just go in the appendix?

2) Should this document maybe discuss connection migration as used by QUIC as an alternative (based on short term connection identifiers instead of course)? Background: to provide identities between two endpoints, I'd say that TLS is sufficient or even the more appropriate solution. However, this document does not talk very much about cases where the identify of other IP hosts (not endpoints) is important. Oft course it covers the mobility use case but that also seems less relevant with migration support in QUIC.
2018-05-07
19 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-05-06
19 Eric Rescorla
[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3709


Maybe I'm missing something important, but I don't see in this
document how you go from …
[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3709


Maybe I'm missing something important, but I don't see in this
document how you go from a HI (or HIT) to the corresponding IP
locator. That seems pretty critical to making this work. Can you point
me in the right direction?



IMPORTANT
S 11.3.1.
>      avoiding manual configurations.  The three components are further
>      described in the HIP experiment report [RFC6538].

>      Based on the interviews, Levae et al suggest further directions to
>      facilitate HIP deployment.  Transitioning the HIP specifications to
>      the standards track may help, but other measures could be taken.  As

This confuses me, because we seem to be looking to advance some of the
HIP specs (e.g., hip-dex) at PS

COMMENTS
S 3.1.
>        were obtained.  For 64 bits, this number is roughly 4 billion.  A
>        hash size of 64 bits may be too small to avoid collisions in a
>        large population; for example, there is a 1% chance of collision
>        in a population of 640M.  For 100 bits (or more), we would not
>        expect a collision until approximately 2**50 (1 quadrillion)
>        hashes were generated.

It's not just a matter of collisions being hard, but also of being
difficult to produce an HI with a given name.


S 4.
>      'well known', some unpublished or 'anonymous'.  A system may self-
>      assert its own identity, or may use a third-party authenticator like
>      DNSSEC [RFC2535], PGP, or X.509 to 'notarize' the identity assertion
>      to another namespace.  It is expected that the Host Identifiers will
>      initially be authenticated with DNSSEC and that all implementations
>      will support DNSSEC as a minimal baseline.

This wasn't a very good assumption when 4423 was published, and it
seems even worse now, given the low rate of deployment of DNSSEC and
the fact that we know many middleboxes break DNSSEC.


S 4.3.
>      packet.  Consequently, a HIT should be unique in the whole IP
>      universe as long as it is being used.  In the extremely rare case of
>      a single HIT mapping to more than one Host Identity, the Host
>      Identifiers (public keys) will make the final difference.  If there
>      is more than one public key for a given node, the HIT acts as a hint
>      for the correct public key to use.

How do you handle second-preimage attacks on the hash?


S 5.1.
>      At the server side, utilizing DNS is a better alternative than a
>      shared Host Identity to implement load balancing.  A single FQDN
>      entry can be configured to refer to multiple Host Identities.  Each
>      of the FQDN entries can be associated with the related locators, or a
>      single shared locator in the case the servers are using the same HIP
>      rendezvous server Section 6.3 or HIP relay server Section 6.4.

This is becoming a less common practice. How do you handle anycast,
which is the modern practice?


S 7.

>      The encapsulation format for the data plane used for carrying the
>      application-layer traffic can be dynamically negotiated during the
>      key exchange.  For instance, HICCUPS extensions [RFC6078] define one
>      way to transport application-layer datagrams directly over the HIP
>      control plane, protected by asymmetric key cryptography.  Also, S-RTP

Nit: SRTP, no hyphen
2018-05-06
19 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2018-04-05
19 Joel Halpern Request for Telechat review by GENART Completed: Ready. Reviewer: Joel Halpern. Sent review to list.
2018-04-05
19 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2018-04-05
19 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2018-03-23
19 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2018-03-21
19 Terry Manderson IESG state changed to IESG Evaluation from Waiting for Writeup
2018-03-21
19 Terry Manderson Ballot has been issued
2018-03-21
19 Terry Manderson [Ballot Position Update] New position, Yes, has been recorded for Terry Manderson
2018-03-21
19 Terry Manderson Created "Approve" ballot
2018-03-21
19 Terry Manderson Ballot writeup was changed
2018-03-21
19 Terry Manderson Placed on agenda for telechat - 2018-05-10
2018-03-21
19 Terry Manderson Changed consensus to Yes from Unknown
2018-03-05
19 Min Ye Request for Telechat review by RTGDIR Completed: Has Issues. Reviewer: Dan Frost.
2018-02-27
19 Sean Turner Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Sean Turner. Sent review to list.
2018-02-27
19 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2018-02-27
19 Miika Komu New version available: draft-ietf-hip-rfc4423-bis-19.txt
2018-02-27
19 (System) New version approved
2018-02-27
19 (System) Request for posting confirmation emailed to previous authors: Robert Moskowitz , Miika Komu
2018-02-27
19 Miika Komu Uploaded new revision
2018-02-26
18 Min Ye Request for Telechat review by RTGDIR is assigned to Dan Frost
2018-02-26
18 Min Ye Request for Telechat review by RTGDIR is assigned to Dan Frost
2018-02-26
18 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-02-22
18 Terry Manderson Last call announcement was generated
2018-02-21
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Will LIU
2018-02-21
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Will LIU
2018-02-20
18 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2018-02-20
18 Amanda Baber
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-hip-rfc4423-bis-18, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-hip-rfc4423-bis-18, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
Lead IANA Services Specialist
2018-02-19
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to (None)
2018-02-19
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to (None)
2018-02-17
18 Joel Halpern Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Joel Halpern. Sent review to list.
2018-02-16
18 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sean Turner
2018-02-16
18 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sean Turner
2018-02-15
18 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2018-02-15
18 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2018-02-14
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2018-02-14
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2018-02-12
18 Min Ye Request for Telechat review by RTGDIR is assigned to Manav Bhatia
2018-02-12
18 Min Ye Request for Telechat review by RTGDIR is assigned to Manav Bhatia
2018-02-12
18 Alvaro Retana Requested Telechat review by RTGDIR
2018-02-12
18 Amy Vezza IANA Review state changed to IANA - Review Needed
2018-02-12
18 Amy Vezza
The following Last Call announcement was sent out (ends 2018-02-26):

From: The IESG
To: IETF-Announce
CC: hipsec@ietf.org, gonzalo.camarillo@ericsson.com, hip-chairs@ietf.org, Gonzalo Camarillo , …
The following Last Call announcement was sent out (ends 2018-02-26):

From: The IESG
To: IETF-Announce
CC: hipsec@ietf.org, gonzalo.camarillo@ericsson.com, hip-chairs@ietf.org, Gonzalo Camarillo , terry.manderson@icann.org, draft-ietf-hip-rfc4423-bis@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Host Identity Protocol Architecture) to Informational RFC


The IESG has received a request from the Host Identity Protocol WG (hip) to
consider the following document: - 'Host Identity Protocol Architecture'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-02-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This memo describes a new namespace, the Host Identity namespace, and
  a new protocol layer, the Host Identity Protocol, between the
  internetworking and transport layers.  Herein are presented the
  basics of the current namespaces, their strengths and weaknesses, and
  how a new namespace will add completeness to them.  The roles of this
  new namespace in the protocols are defined.

  This document obsoletes RFC 4423 and addresses the concerns raised by
  the IESG, particularly that of crypto agility.  It incorporates
  lessons learned from the implementations of RFC 5201 and goes further
  to explain how HIP works as a secure signaling channel.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/ballot/


No IPR declarations have been submitted directly on this I-D.




2018-02-12
18 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2018-02-12
18 Amy Vezza Last call announcement was changed
2018-02-11
18 Terry Manderson Last call was requested
2018-02-11
18 Terry Manderson Ballot approval text was generated
2018-02-11
18 Terry Manderson Ballot writeup was generated
2018-02-11
18 Terry Manderson IESG state changed to Last Call Requested from AD Evaluation
2018-02-11
18 Terry Manderson Last call announcement was generated
2018-02-11
18 Terry Manderson IESG state changed to AD Evaluation from Publication Requested
2018-02-08
18 Gonzalo Camarillo
PROTO Writeup of draft-ietf-hip-rfc4423-bis-18
[2018-02-08 Thu]

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? …
PROTO Writeup of draft-ietf-hip-rfc4423-bis-18
[2018-02-08 Thu]

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
    is this the proper type of RFC? Is this type of RFC indicated in
    the title page header?

    Informational, as indicated on the title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement
    Write-Up. Recent examples can be found in the "Action"
    announcements for approved documents. The approval announcement
    contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

    This memo describes a new namespace, the Host Identity namespace,
    and a new protocol layer, the Host Identity Protocol, between the
    internetworking and transport layers.  Herein are presented the
    basics of the current namespaces, their strengths and weaknesses,
    and how a new namespace will add completeness to them.  The roles
    of this new namespace in the protocols are defined.

    This document obsoletes RFC 4423 and addresses the concerns raised
    by the IESG, particularly that of crypto agility.  It incorporates
    lessons learned from the implementations of RFC 5201 and goes
    further to explain how HIP works as a secure signaling channel.

Working Group Summary:

Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

    There was WG consensus behind this document.

Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

    As discussed in RFC 6538, there are several implementations of the
    Experimental HIP specs. At least, HIP for Linux and OpenHIP will
    be updated to comply with the updated Standards-track
    specifications.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

    Gonzalo Camarillo is the document shepherd. Terry Manderson is the
    responsible area director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not
    ready for publication, please explain why the document is being
    forwarded to the IESG.

    The document shepherd reviewed revision 18 of this document, which
    was ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

    No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the
    review that took place.

    No.

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area Director
    and/or the IESG should be aware of? For example, perhaps he or she
    is uncomfortable with certain parts of the document, or has
    concerns whether there really is a need for it. In any event, if
    the WG has discussed those issues and has indicated that it still
    wishes to advance the document, detail those concerns here.

    No concerns.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.

    No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with
    it?

    The whole WG understands the document and agree with
    it. Nevertheless, the number of active participants in the HIP WG
    is limited at this point.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

    No.

(11) Identify any ID nits the Document Shepherd has found in this
    document. (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist). Boilerplate checks are not enough;
    this check needs to be thorough.

      The document contains no nits.   

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type
    reviews.

    No formal reviews are needed.

(13) Have all references within this document been identified as
    either normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready
    for advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their
    completion?

    No. The only two documents that are not RFCs yet are already in
    the publication requested state:

      [I-D.ietf-hip-dex]
      [I-D.ietf-hip-native-nat-traversal]

(15) Are there downward normative references references (see RFC
    3967
)? If so, list these downward references to support the Area
    Director in the Last Call procedure.

    No.

(16) Will publication of this document change the status of any
    existing RFCs? Are those RFCs listed on the title page header,
    listed in the abstract, and discussed in the introduction? If the
    RFCs are not listed in the Abstract and Introduction, explain
    why, and point to the part of the document where the relationship
    of this document to the other RFCs is discussed. If this
    information is not in the document, explain why the WG considers
    it unnecessary.

    Yes. This RFC-to-be will obsolete RFC 4423 when approved, as
    discussed in the Title Page, the Abstract, and the Introduction.

(17) Describe the Document Shepherd's review of the IANA
    considerations section, especially with regard to its consistency
    with the body of the document. Confirm that all protocol
    extensions that the document makes are associated with the
    appropriate reservations in IANA registries. Confirm that any
    referenced IANA registries have been clearly identified. Confirm
    that newly created IANA registries include a detailed
    specification of the initial contents for the registry, that
    allocations procedures for future registrations are defined, and
    a reasonable name for the new registry has been suggested (see
    RFC 5226).

    The (non op) IANA Considerations Section is complete and
    consistent.
 
(18) List any new IANA registries that require Expert Review for
    future allocations. Provide any public guidance that the IESG
    would find useful in selecting the IANA Experts for these new
    registries.

    No new experts are required.
 
(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

    No such checks were needed.
2018-02-08
18 Gonzalo Camarillo Responsible AD changed to Terry Manderson
2018-02-08
18 Gonzalo Camarillo IETF WG state changed to Submitted to IESG for Publication from WG Document
2018-02-08
18 Gonzalo Camarillo IESG state changed to Publication Requested
2018-02-08
18 Gonzalo Camarillo IESG process started in state Publication Requested
2018-02-08
18 Gonzalo Camarillo Changed document writeup
2018-02-07
18 Gonzalo Camarillo Notification list changed to Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
2018-02-07
18 Gonzalo Camarillo Document shepherd changed to Gonzalo Camarillo
2018-02-07
18 Gonzalo Camarillo Intended Status changed to Informational from None
2017-11-23
18 Miika Komu New version available: draft-ietf-hip-rfc4423-bis-18.txt
2017-11-23
18 (System) New version approved
2017-11-23
18 (System) Request for posting confirmation emailed to previous authors: Robert Moskowitz , Miika Komu
2017-11-23
18 Miika Komu Uploaded new revision
2017-08-07
17 Miika Komu New version available: draft-ietf-hip-rfc4423-bis-17.txt
2017-08-07
17 (System) New version approved
2017-08-07
17 (System) Request for posting confirmation emailed to previous authors: Robert Moskowitz , Miika Komu
2017-08-07
17 Miika Komu Uploaded new revision
2017-02-15
16 Miika Komu New version available: draft-ietf-hip-rfc4423-bis-16.txt
2017-02-15
16 (System) New version approved
2017-02-15
16 (System) Request for posting confirmation emailed to previous authors: "Robert Moskowitz" , "Miika Komu"
2017-02-15
16 Miika Komu Uploaded new revision
2016-11-14
15 Miika Komu New version available: draft-ietf-hip-rfc4423-bis-15.txt
2016-11-14
15 (System) New version approved
2016-11-14
15 (System) Request for posting confirmation emailed to previous authors: "Robert Moskowitz" , "Miika Komu"
2016-11-14
15 Miika Komu Uploaded new revision
2016-06-07
14 Miika Komu New version available: draft-ietf-hip-rfc4423-bis-14.txt
2015-12-14
13 Miika Komu New version available: draft-ietf-hip-rfc4423-bis-13.txt
2015-06-23
12 Miika Komu New version available: draft-ietf-hip-rfc4423-bis-12.txt
2015-04-13
11 Miika Komu New version available: draft-ietf-hip-rfc4423-bis-11.txt
2015-04-13
10 Miika Komu New version available: draft-ietf-hip-rfc4423-bis-10.txt
2014-10-20
09 Miika Komu New version available: draft-ietf-hip-rfc4423-bis-09.txt
2014-04-24
08 Miika Komu New version available: draft-ietf-hip-rfc4423-bis-08.txt
2013-12-18
07 Miika Komu New version available: draft-ietf-hip-rfc4423-bis-07.txt
2013-11-07
06 Miika Komu New version available: draft-ietf-hip-rfc4423-bis-06.txt
2012-09-28
05 Robert Moskowitz New version available: draft-ietf-hip-rfc4423-bis-05.txt
2012-07-13
04 Robert Moskowitz New version available: draft-ietf-hip-rfc4423-bis-04.txt
2011-09-01
03 (System) New version available: draft-ietf-hip-rfc4423-bis-03.txt
2011-08-29
03 (System) Document has expired
2011-02-25
02 (System) New version available: draft-ietf-hip-rfc4423-bis-02.txt
2010-08-24
01 (System) New version available: draft-ietf-hip-rfc4423-bis-01.txt
2010-08-20
00 (System) New version available: draft-ietf-hip-rfc4423-bis-00.txt