Host Identity Protocol Version 2 (HIPv2)
draft-ietf-hip-rfc5201-bis-20
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-03-18
|
20 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-01-26
|
20 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-01-16
|
20 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2015-01-12
|
20 | (System) | RFC Editor state changed to REF from AUTH |
2014-12-22
|
20 | (System) | RFC Editor state changed to AUTH from EDIT |
2014-12-11
|
20 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2014-12-11
|
20 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2014-12-07
|
20 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-12-05
|
20 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2014-12-04
|
20 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-12-02
|
20 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2014-11-28
|
20 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2014-11-26
|
20 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-11-25
|
20 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-11-19
|
20 | (System) | RFC Editor state changed to EDIT |
2014-11-19
|
20 | (System) | IANA Action state changed to In Progress from No IC |
2014-11-19
|
20 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2014-11-19
|
20 | Cindy Morgan | IESG has approved the document |
2014-11-19
|
20 | Cindy Morgan | Ballot approval text was generated |
2014-10-30
|
20 | Naveen Khan | New revision available |
2014-09-26
|
19 | (System) | IANA Action state changed to No IC from In Progress |
2014-09-25
|
19 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::AD Followup from Approved-announcement to be sent |
2014-09-25
|
19 | Ted Lemon | IESG state changed to Approved-announcement to be sent::AD Followup from RFC Ed Queue |
2014-09-24
|
19 | (System) | IANA Action state changed to In Progress |
2014-09-24
|
19 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-09-24
|
19 | (System) | RFC Editor state changed to EDIT |
2014-09-24
|
19 | (System) | Announcement was received by RFC Editor |
2014-09-24
|
19 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2014-09-24
|
19 | Cindy Morgan | IESG has approved the document |
2014-09-24
|
19 | Cindy Morgan | Closed "Approve" ballot |
2014-09-24
|
19 | Cindy Morgan | Ballot approval text was generated |
2014-09-24
|
19 | Cindy Morgan | Ballot writeup was changed |
2014-09-24
|
19 | Ted Lemon | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2014-09-24
|
19 | Ted Lemon | [Ballot Position Update] Position for Ted Lemon has been changed to Yes from Discuss |
2014-09-22
|
19 | Thomas Henderson | New version available: draft-ietf-hip-rfc5201-bis-19.txt |
2014-09-22
|
18 | Thomas Henderson | New version available: draft-ietf-hip-rfc5201-bis-18.txt |
2014-09-15
|
17 | Brian Haberman | [Ballot comment] Thanks for addressing my DISCUSS points. |
2014-09-15
|
17 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss |
2014-09-15
|
17 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from No Objection |
2014-09-15
|
17 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss |
2014-09-05
|
17 | Thomas Henderson | New version available: draft-ietf-hip-rfc5201-bis-17.txt |
2014-09-04
|
16 | Stephen Farrell | [Ballot comment] The original DISCUSS and COMMENT points are below. I think only this one remains to be discussed: (3) Continuing to support the 1536 … [Ballot comment] The original DISCUSS and COMMENT points are below. I think only this one remains to be discussed: (3) Continuing to support the 1536 MODP DHE group but not supporting the 2048 equivalent seems a bit odd, as does not having a code point for the 4096 but group. Similarly, making the 1536 bit group the MTI (in 5.2.7) is odd as is the assertion that "web surfing" can use a lower security level. And we discussed it! Seems like adding the 2048 bit group would be good. I'm fine that the WG decide what they want there. (In other words ignore text below here.) --- original discuss below This review is based on the diff from 5201 [1] [1] https://tools.ietf.org/rfcdiff?url1=rfc5201&url2=draft-ietf-hip-rfc5201-bis-14.txt Work started on this in 2009 it appears and the backwards incompatible changes made to the BEX are roughly what I'd expect to have seen for good work done around that time. However, some things have changed since, that I don't see reflected in the changes made to the BEX, so I'd like to chat about those for a bit, in case they're still malleable. If it is really the case that the boat has sailed for such changes, then that's life, but I wonder has it? (I really don't know for HIP.) I think the features in the changes to the BEX that one would consider noteworthy were that work done today are: (1) Mandating some form of variability of, and confidentiality for, the (non-routable?) HIT to enhance privacy or at least mitigate trival passive tracking of activity across time and different connections. (Or maybe the "anonymous HI" mechanism achieves this, I wasn't sure? If it does, then why have any other?) (2) There is no support for newer elliptic curves or representations like 25519. (4) (5.2.8) Did the WG discuss deprecating the NULL encryption option? (Haven't you finished testing yet:-) Also - there are no counter modes, is that wise? Finally, HIPv1's encryption codepoint 1 was for a 3DES option, but here you have 1 == NULL, yet you deprecate codepoint 3, which is confusing. Why is that? (5) Requiring HMAC-SHA-1 in 6.4.1 seems a bit odd. If HMAC-SHA-256 is supported, then why not just use that? Is there are real benefit in the sha1 variant? -- old comment below - abstract: SIGMA-compliant is a bit of a mouthful for an abstract - how many readers do we really expect to get that? - 1.1: Saying the HI is the identity of the host seems a little overstated to me, but I guess that's accepted as a description for HIP, so not objecting, but it'd seem more natural to me to say that a HI is an identifier that a host can use. (Presumably load-balancing and mobility scenarios could mean that a private key could be on more than one host or one "host" might have >1 private key.) - section 3: 3110 doesn't seem like a great reference for RSA. Isn't there better? |
2014-09-04
|
16 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2014-08-23
|
16 | Stephen Farrell | [Ballot discuss] The original DISCUSS and COMMENT points are below. I think only this one remains to be discussed: (3) Continuing to support the 1536 … [Ballot discuss] The original DISCUSS and COMMENT points are below. I think only this one remains to be discussed: (3) Continuing to support the 1536 MODP DHE group but not supporting the 2048 equivalent seems a bit odd, as does not having a code point for the 4096 but group. Similarly, making the 1536 bit group the MTI (in 5.2.7) is odd as is the assertion that "web surfing" can use a lower security level. (In other words ignore text below here.) |
2014-08-23
|
16 | Stephen Farrell | [Ballot comment] --- original discuss below This review is based on the diff from 5201 [1] [1] https://tools.ietf.org/rfcdiff?url1=rfc5201&url2=draft-ietf-hip-rfc5201-bis-14.txt Work started on this in 2009 … [Ballot comment] --- original discuss below This review is based on the diff from 5201 [1] [1] https://tools.ietf.org/rfcdiff?url1=rfc5201&url2=draft-ietf-hip-rfc5201-bis-14.txt Work started on this in 2009 it appears and the backwards incompatible changes made to the BEX are roughly what I'd expect to have seen for good work done around that time. However, some things have changed since, that I don't see reflected in the changes made to the BEX, so I'd like to chat about those for a bit, in case they're still malleable. If it is really the case that the boat has sailed for such changes, then that's life, but I wonder has it? (I really don't know for HIP.) I think the features in the changes to the BEX that one would consider noteworthy were that work done today are: (1) Mandating some form of variability of, and confidentiality for, the (non-routable?) HIT to enhance privacy or at least mitigate trival passive tracking of activity across time and different connections. (Or maybe the "anonymous HI" mechanism achieves this, I wasn't sure? If it does, then why have any other?) (2) There is no support for newer elliptic curves or representations like 25519. (4) (5.2.8) Did the WG discuss deprecating the NULL encryption option? (Haven't you finished testing yet:-) Also - there are no counter modes, is that wise? Finally, HIPv1's encryption codepoint 1 was for a 3DES option, but here you have 1 == NULL, yet you deprecate codepoint 3, which is confusing. Why is that? (5) Requiring HMAC-SHA-1 in 6.4.1 seems a bit odd. If HMAC-SHA-256 is supported, then why not just use that? Is there are real benefit in the sha1 variant? -- old comment below - abstract: SIGMA-compliant is a bit of a mouthful for an abstract - how many readers do we really expect to get that? - 1.1: Saying the HI is the identity of the host seems a little overstated to me, but I guess that's accepted as a description for HIP, so not objecting, but it'd seem more natural to me to say that a HI is an identifier that a host can use. (Presumably load-balancing and mobility scenarios could mean that a private key could be on more than one host or one "host" might have >1 private key.) - section 3: 3110 doesn't seem like a great reference for RSA. Isn't there better? |
2014-08-23
|
16 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2014-08-23
|
16 | Stephen Farrell | [Ballot discuss] Sent a mail Aug 23rd. No response seen except to the NULL issue dealt with in 5205bis, -16 doesn't address. --- original discuss … [Ballot discuss] Sent a mail Aug 23rd. No response seen except to the NULL issue dealt with in 5205bis, -16 doesn't address. --- original discuss below This review is based on the diff from 5201 [1] [1] https://tools.ietf.org/rfcdiff?url1=rfc5201&url2=draft-ietf-hip-rfc5201-bis-14.txt Work started on this in 2009 it appears and the backwards incompatible changes made to the BEX are roughly what I'd expect to have seen for good work done around that time. However, some things have changed since, that I don't see reflected in the changes made to the BEX, so I'd like to chat about those for a bit, in case they're still malleable. If it is really the case that the boat has sailed for such changes, then that's life, but I wonder has it? (I really don't know for HIP.) I think the features in the changes to the BEX that one would consider noteworthy were that work done today are: (1) Mandating some form of variability of, and confidentiality for, the (non-routable?) HIT to enhance privacy or at least mitigate trival passive tracking of activity across time and different connections. (Or maybe the "anonymous HI" mechanism achieves this, I wasn't sure? If it does, then why have any other?) (2) There is no support for newer elliptic curves or representations like 25519. (3) Continuing to support the 1536 MODP DHE group but not supporting the 2048 equivalent seems a bit odd, as does not having a code point for the 4096 but group. Similarly, making the 1536 bit group the MTI (in 5.2.7) is odd as is the assertion that "web surfing" can use a lower security level. (4) (5.2.8) Did the WG discuss deprecating the NULL encryption option? (Haven't you finished testing yet:-) Also - there are no counter modes, is that wise? Finally, HIPv1's encryption codepoint 1 was for a 3DES option, but here you have 1 == NULL, yet you deprecate codepoint 3, which is confusing. Why is that? (5) Requiring HMAC-SHA-1 in 6.4.1 seems a bit odd. If HMAC-SHA-256 is supported, then why not just use that? Is there are real benefit in the sha1 variant? |
2014-08-23
|
16 | Stephen Farrell | Ballot discuss text updated for Stephen Farrell |
2014-08-12
|
16 | Barry Leiba | [Ballot comment] Thanks for posting -16. There's only one minor thing that's still missed -- you can change it or not, as you see best. … [Ballot comment] Thanks for posting -16. There's only one minor thing that's still missed -- you can change it or not, as you see best. Thanks very much for the work on this document. In the IANA Considerations, similar to what was done for R1_COUNTER, I suggest this: OLD A new value (579) for a new Parameter Type HIP_CIPHER should be added, with reference to this specification. This Parameter Type functionally replaces the HIP_TRANSFORM Parameter Type (value 577) which can be left in the table with existing reference to [RFC5201]. NEW A new value (579) for a new Parameter Type HIP_CIPHER should be added, with reference to this specification. This Parameter Type functionally replaces the HIP_TRANSFORM Parameter Type (value 577) which can be left in the table with existing reference to [RFC5201]. For clarity, we recommend that the name for the value 577 be changed from "HIP_TRANSFORM" to "HIP_TRANSFORM (v1 only)". END |
2014-08-12
|
16 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2014-08-11
|
16 | Thomas Henderson | New version available: draft-ietf-hip-rfc5201-bis-16.txt |
2014-07-28
|
15 | Barry Leiba | [Ballot discuss] Thanks for posting -15, which resolves most of my comments about the IANA Considerations. I'm updating this with the things that remain -- … [Ballot discuss] Thanks for posting -15, which resolves most of my comments about the IANA Considerations. I'm updating this with the things that remain -- most are now non-blocking comments, below. 1. In the table at the end of Section 5.2, the reserved range that follows the experimental one seems to have a typo in it: it says "41952", and should say "49152". There's also a discrepancy between the "61440 - 64443" range and the following "62464 - 63487" range. 2. IANA has reserved protocol number 139 for the Host Identity Protocol and included it in the "IPv6 Extension Header Types" registry [RFC7045]. No new action regarding this value is required by this specification. There are actually two registries with the 139 value: "IPv6 Extension Header Types" http://www.iana.org/assignments/ipv6-parameters#extension-header "Assigned Internet Protocol Numbers" http://www.iana.org/assignments/protocol-numbers#protocol-numbers-1 In both of those registries, HIP is assigned the value 139, with a reference document of [RFC5201]. Both entries should have the reference document changed to this RFC. |
2014-07-28
|
15 | Barry Leiba | Ballot discuss text updated for Barry Leiba |
2014-07-28
|
15 | Barry Leiba | [Ballot discuss] Thanks for posting -15, which resolves most of my comments about the IANA Considerations. I'm updating this with the things that remain -- … [Ballot discuss] Thanks for posting -15, which resolves most of my comments about the IANA Considerations. I'm updating this with the things that remain -- most are now non-blocking comments, below. 1. In the table at the end of Section 5.2, the reserved range that follows the experimental one seems to have a typo in it: it says "41952", and should say "49152". There's also a discrepancy between the "61440 - 64443" range and the following "62464 - 63487" range. 2. IANA has reserved protocol number 139 for the Host Identity Protocol and included it in the "IPv6 Extension Header Types" registry [RFC7045]. No new action regarding this value is required by this specification. Do you really still want that reference to point to 5201, and not to this? Why? Isn't this the definitive reference for HIP once it's published? (The way you're handling the HIP Version reference seems correct though.) |
2014-07-28
|
15 | Barry Leiba | [Ballot comment] HIT Suite ID This specification creates a new registry for "HIT Suite ID". This is different … [Ballot comment] HIT Suite ID This specification creates a new registry for "HIT Suite ID". This is different than the existing registry for "Suite ID" which can be left unmodified for version 1 of the protocol ([RFC5201]). Should the v1 registry be closed to new registrations? HIT Suite IDs must be allocated carefully to avoid namespace exhaustion. Moreover, deprecated IDs should be reused after an appropriate time span. I think it would be useful to add something like this, just to make sure everything is clear to all readers, including IANA, and to help make sure that the right thing happens in the future: ADD Requests to register reused values should include a note that the value is being reused after a deprecation period, to ensure appropriate IETF review and approval. END A new value (129) for R1_COUNTER should be introduced, with a reference to this specification, and the existing value (128) for R1_COUNTER left in place with a reference to [RFC5201]. This documents the change in value that has occurred in version 2 of this protocol. A question: Would it be sensible, for this and for HIP_TRANSFORM, to add a notation to the old entry? Something like this: OLD | 128 | R1_COUNTER | 12 | [RFC5201] | ... | 577 | HIP_TRANSFORM | variable | [RFC5201] | NEW | 128 | R1_COUNTER (v1 only) | 12 | [RFC5201] | ... | 577 | HIP_TRANSFORM (v1 only) | variable | [RFC5201] | END That way, no one has to infer it from the fact that 5201 is still the reference for it. The name of the HMAC Parameter Type (value 61505) should be changed to HIP_MAC. The name of the HMAC_2 Parameter Type (value 61569) should be changed to HIP_MAC_2. This should say whether the reference is changing or staying as 5201. It looks like it should change, but if it's staying, the same comment applies to this as to HIP_TRANSFORM. The Type codes 32768 through 49151 are reserved for experimentation. Types SHOULD be selected in a random fashion from this range, thereby reducing the probability of collisions. A method employing genuine randomness (such as flipping a coin) SHOULD be used. I think this should be worded slightly differently to be clear that it's not an instruction to IANA, but to implementors. Changing to active voice should do that nicely: NEW The Type codes 32768 through 49151 are reserved for experimentation. Implementors SHOULD select types in a random fashion from this range, thereby reducing the probability of collisions. A method employing genuine randomness (such as flipping a coin) SHOULD be used. END |
2014-07-28
|
15 | Barry Leiba | Ballot comment and discuss text updated for Barry Leiba |
2014-07-28
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-07-28
|
15 | Thomas Henderson | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2014-07-28
|
15 | Thomas Henderson | New version available: draft-ietf-hip-rfc5201-bis-15.txt |
2014-07-16
|
14 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2014-07-10
|
14 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2014-07-10
|
14 | Pete Resnick | [Ballot comment] 4.4.1: Maximum Segment Lifetime (MSL): Maximum time that a TCP segment is expected to spend in the network. TCP … [Ballot comment] 4.4.1: Maximum Segment Lifetime (MSL): Maximum time that a TCP segment is expected to spend in the network. TCP segment? First mention of use of TCP in this document. |
2014-07-10
|
14 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2014-07-09
|
14 | Alissa Cooper | [Ballot comment] Looking forward to seeing the discuss resolutions. |
2014-07-09
|
14 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2014-07-09
|
14 | Barry Leiba | [Ballot discuss] I need to add a DISCUSS to Ted's on IANA registry issues. 1. It seems to me that this document needs to change … [Ballot discuss] I need to add a DISCUSS to Ted's on IANA registry issues. 1. It seems to me that this document needs to change all the registration entries that cite 5201, making them point to this document instead. 2. This document doesn't create the registries that it says it creates, and it shouldn't say that it does. But this document changes the registration policies of some of the registries, so it needs to make those changes clear. Perhaps (1) and (2) are already in the plan, in response to IANA's questions. 3. The last paragraph describing the Parameter Type registry says that "all other values" (it would be better to list them: 1024 through 32767 and 49152 through 61439) are assigned through "Fist Come First Served, with Specification Required." I realize the policy specification is unchanged from 5201, but it's not a valid policy combination. What is it intended to mean? FCFS and Specification Required are contradictory policies. Perhaps what you want is FCFS, with a documentation reference recorded in the registry. You can then say a few words about what registrants should make sure the reference document contains, but realize that it will not be validated by anyone for completeness or sensibility. 4. 5201 specified that the experimentation range ended at 49141; this changes it to 49151. I just want to make sure that was intentional, and not a typo. Will you confirm that? 5. In the table at the end of Section 5.2, the reserved range that follows the experimental one seems to have a typo in it: it says "41952", and should say "49152". There's also a discrepancy between the "61440 - 64443" range and the following "62464 - 63487" range. I have no idea which one has the typo there. 6. The comment in (3) about FCFS also applies to the Notify Message Type registry. Also, in the ranges given, the value 16384 doesn't fall in any range. |
2014-07-09
|
14 | Barry Leiba | [Ballot comment] -- Section 4.1.8 -- Therefore, the Responder SHOULD should select its HIT from the same HIT Suite as the Initiator's HIT … [Ballot comment] -- Section 4.1.8 -- Therefore, the Responder SHOULD should select its HIT from the same HIT Suite as the Initiator's HIT "SHOULD should" typo. |
2014-07-09
|
14 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2014-07-09
|
14 | Richard Barnes | [Ballot comment] I agree with Stephen's DISCUSS. The cryptographic algorithm choices here seem incrementally better than RFC 5201, but not very forward-looking. |
2014-07-09
|
14 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2014-07-08
|
14 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2014-06-26
|
14 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Donald Eastlake. |
2014-06-26
|
14 | Cindy Morgan | Telechat date has been changed to 2014-07-10 from 2014-06-26 |
2014-06-26
|
14 | Ted Lemon | [Ballot discuss] This has outstanding IANA questions that need to be addressed, please. |
2014-06-26
|
14 | Ted Lemon | [Ballot Position Update] Position for Ted Lemon has been changed to Discuss from Yes |
2014-06-26
|
14 | Stephen Farrell | [Ballot discuss] This review is based on the diff from 5201 [1] [1] https://tools.ietf.org/rfcdiff?url1=rfc5201&url2=draft-ietf-hip-rfc5201-bis-14.txt Work started on this in 2009 it appears and the … [Ballot discuss] This review is based on the diff from 5201 [1] [1] https://tools.ietf.org/rfcdiff?url1=rfc5201&url2=draft-ietf-hip-rfc5201-bis-14.txt Work started on this in 2009 it appears and the backwards incompatible changes made to the BEX are roughly what I'd expect to have seen for good work done around that time. However, some things have changed since, that I don't see reflected in the changes made to the BEX, so I'd like to chat about those for a bit, in case they're still malleable. If it is really the case that the boat has sailed for such changes, then that's life, but I wonder has it? (I really don't know for HIP.) I think the features in the changes to the BEX that one would consider noteworthy were that work done today are: (1) Mandating some form of variability of, and confidentiality for, the (non-routable?) HIT to enhance privacy or at least mitigate trival passive tracking of activity across time and different connections. (Or maybe the "anonymous HI" mechanism achieves this, I wasn't sure? If it does, then why have any other?) (2) There is no support for newer elliptic curves or representations like 25519. (3) Continuing to support the 1536 MODP DHE group but not supporting the 2048 equivalent seems a bit odd, as does not having a code point for the 4096 but group. Similarly, making the 1536 bit group the MTI (in 5.2.7) is odd as is the assertion that "web surfing" can use a lower security level. (4) (5.2.8) Did the WG discuss deprecating the NULL encryption option? (Haven't you finished testing yet:-) Also - there are no counter modes, is that wise? Finally, HIPv1's encryption codepoint 1 was for a 3DES option, but here you have 1 == NULL, yet you deprecate codepoint 3, which is confusing. Why is that? (5) Requiring HMAC-SHA-1 in 6.4.1 seems a bit odd. If HMAC-SHA-256 is supported, then why not just use that? Is there are real benefit in the sha1 variant? |
2014-06-26
|
14 | Stephen Farrell | [Ballot comment] - abstract: SIGMA-compliant is a bit of a mouthful for an abstract - how many readers do we really expect to get that? … [Ballot comment] - abstract: SIGMA-compliant is a bit of a mouthful for an abstract - how many readers do we really expect to get that? - 1.1: Saying the HI is the identity of the host seems a little overstated to me, but I guess that's accepted as a description for HIP, so not objecting, but it'd seem more natural to me to say that a HI is an identifier that a host can use. (Presumably load-balancing and mobility scenarios could mean that a private key could be on more than one host or one "host" might have >1 private key.) - section 3: 3110 doesn't seem like a great reference for RSA. Isn't there better? |
2014-06-26
|
14 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2014-06-26
|
14 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2014-06-26
|
14 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2014-06-25
|
14 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-06-25
|
14 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2014-06-24
|
14 | Martin Stiemerling | [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling |
2014-06-24
|
14 | Jari Arkko | [Ballot discuss] The Gen-ART review from Tom Taylor raised a couple of issues that in my mind require at least clarification. The authors have acknowledged … [Ballot discuss] The Gen-ART review from Tom Taylor raised a couple of issues that in my mind require at least clarification. The authors have acknowledged the review, but I think we still need to see you answer if changes are necessary. Otherwise I am very happy with this document, and will be happy to recommend "Yes" for it once the above is clear. |
2014-06-24
|
14 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko |
2014-06-23
|
14 | Brian Haberman | [Ballot discuss] I have no objection to the publication of this document, but I do have two small points to discuss in section 5.2.3. 1. … [Ballot discuss] I have no objection to the publication of this document, but I do have two small points to discuss in section 5.2.3. 1. The R1_COUNTER parameter was labeled as optional in RFC 5201, but made mandatory in this revision. However, the text says it SHOULD be included in R1. If it is not included in R1 (violates the SHOULD), where will it be included given it is mandatory? 2. The Type value of R1_COUNTER was 128 in 5201 and is now 129. Is that correct? |
2014-06-23
|
14 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2014-06-23
|
14 | Ted Lemon | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2014-06-11
|
14 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2014-06-08
|
14 | Ted Lemon | Ballot has been issued |
2014-06-08
|
14 | Ted Lemon | [Ballot Position Update] New position, Yes, has been recorded for Ted Lemon |
2014-06-08
|
14 | Ted Lemon | Created "Approve" ballot |
2014-06-08
|
14 | Ted Lemon | Ballot writeup was changed |
2014-06-08
|
14 | Ted Lemon | Placed on agenda for telechat - 2014-06-26 |
2014-06-06
|
14 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2014-06-06
|
14 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-hip-rfc5201-bis-14. Authors SHOULD review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-hip-rfc5201-bis-14. Authors SHOULD review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA has questions about some of the IANA Actions requested in the IANA Considerations section of this document. IANA understands that, upon approval of this document, there are eight actions which IANA must complete. First, in the CGA Extension Type Tags subregistry of the Cryptographically Generated Addresses (CGA) Message Type Name Space registry located at: http://www.iana.org/assignments/cga-message-types/ a new value is to be registered as follows: CGA Type Tag: F0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA Reference: [ RFC-to-be ] Second, in the HIP Version subregistry of the Host Identity Protocol (HIP) Parameters registry located at: http://www.iana.org/assignments/hip-parameters/ a new version is to be registered as follows: Value: 2 Reference: [ RFC-to-be ] IANA Question -> The current document creates a series of new namespaces. Are these new namespaces to be standalone registries or are they to be subregistries of the existing Host Identity Protocol (HIP) Parameters registry located at: http://www.iana.org/assignments/hip-parameters/ ?? Third, in a location [ TBD, see question above ] a new registry is to be created called the "HIP Packet Type." The HIP packet type is a 7-bit value. The new registry is maintained via IETF Review or IESG Approval as defined by RFC 5226. There are initial values in the new registry as follows. +------------------+------------------------------------------------+ | Packet type | Packet name | +------------------+------------------------------------------------+ | 1 | I1 - the HIP Initiator Packet | | | | | 2 | R1 - the HIP Responder Packet | | | | | 3 | I2 - the Second HIP Initiator Packet | | | | | 4 | R2 - the Second HIP Responder Packet | | | | | 16 | UPDATE - the HIP Update Packet | | | | | 17 | NOTIFY - the HIP Notify Packet | | | | | 18 | CLOSE - the HIP Association Closing Packet | | | | | 19 | CLOSE_ACK - the HIP Closing Acknowledgment | | | Packet | +------------------+------------------------------------------------+ For each of the packet type values above, IANA will use a reference of [ RFC-to-be ]. Fourth, in a location [ TBD, see question above ] a new registry is to be created called the "HIT Suite." The HIP packet type is a 4-bit value. The new registry is maintained via IETF Review or IESG Approval as defined by RFC 5226. IANA Question -> The IANA Considerations section states that "This document defines two HIT Suites (see Appendix E)." However, Appendix E seems to provide three HIT Suites. Which is correct? There are initial registrations in this new registry as follows: +-------+----------+--------------+------------+--------------------+ | Index | Hash | HMAC | Signature | Description | | | function | | algorithm | | | | | | family | | +-------+----------+--------------+------------+--------------------+ | 0 | | | | Reserved | | 1 | SHA-256 | HMAC-SHA-256 | RSA, DSA | RSA or DSA HI | | | | | | hashed with | | | | | | SHA-256, truncated | | | | | | to 96 bits | | 2 | SHA-384 | HMAC-SHA-384 | ECDSA | ECDSA HI hashed | | | | | | with SHA-384, | | | | | | truncated to 96 | | | | | | bits | | 3 | SHA-1 | HMAC-SHA-1 | ECDSA_LOW | ECDSA_LOW HI | | | | | | hashed with SHA-1, | | | | | | truncated to 96 | | | | | | bits | +-------+----------+--------------+------------+--------------------+ For each of the HIT Suite values above, IANA will use a reference of [ RFC-to-be ]. Fifth, in a location [ TBD, see question above ] a new registry is to be created called the "Parameter Type." The Parameter type is a 16-bit value. The Type codes 0 through 1023 and 61440 through 65535 are reserved for future base protocol extensions, and are assigned through IETF Review or IESG Approval as defined by RFC 5226. The Type codes 32768 through 49151 are reserved for experimentation. Types SHOULD be selected in a random fashion from this range, thereby reducing the probability of collisions. A method employing genuine randomness (such as flipping a coin) SHOULD be used. All other Type codes are assigned through First Come First Served, with Specification Required as defined by RFC 5226. There are initial values in this new registry as follows: +------------------------+-------+-----------+----------------------+ | TLV | Type | Length | Data | +------------------------+-------+-----------+----------------------+ | R1_COUNTER | 129 | 12 | Puzzle generation | | | | | counter | | | | | | | PUZZLE | 257 | 12 | K and Random #I | | | | | | | SOLUTION | 321 | 20 | K, Random #I and | | | | | puzzle solution J | | | | | | | SEQ | 385 | 4 | UPDATE packet ID | | | | | number | | | | | | | ACK | 449 | variable | UPDATE packet ID | | | | | number | | | | | | | DH_GROUP_LIST | 511 | variable | Ordered list of DH | | | | | Group IDs supported | | | | | by a host | | | | | | | DIFFIE_HELLMAN | 513 | variable | public key | | | | | | | HIP_CIPHER | 579 | variable | List of HIP | | | | | encryption | | | | | algorithms | | | | | | | ENCRYPTED | 641 | variable | Encrypted part of a | | | | | HIP packet | | | | | | | HOST_ID | 705 | variable | Host Identity with | | | | | Fully-Qualified | | | | | Domain FQDN (Name) | | | | | or Network Access | | | | | Identifier (NAI) | | | | | | | HIT_SUITE_LIST | 715 | variable | Ordered list of the | | | | | HIT suites supported | | | | | by the Responder | | | | | | | CERT | 768 | variable | HI Certificate; used | | | | | to transfer | | | | | certificates. | | | | | Specified in a | | | | | separate docment. | | | | | | | NOTIFICATION | 832 | variable | Informational data | | | | | | | ECHO_REQUEST_SIGNED | 897 | variable | Opaque data to be | | | | | echoed back; signed | | | | | | | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | | | | | back by request; | | | | | signed | | | | | | | TRANSPORT_FORMAT_LIST | 2049 | Ordered | variable | | | | list of | | | | | preferred | | | | | HIP | | | | | transport | | | | | type | | | | | numbers | | | | | | | | HIP_MAC | 61505 | variable | HMAC-based message | | | | | authentication code, | | | | | with key material | | | | | from KEYMAT | | | | | | | HIP_MAC_2 | 61569 | variable | HMAC based message | | | | | authentication code, | | | | | with key material | | | | | from KEYMAT. Unlike | | | | | HIP_MAC, the HOST_ID | | | | | parameter is | | | | | included in | | | | | HIP_MAC_2 | | | | | calculation. | | | | | | | HIP_SIGNATURE_2 | 61633 | variable | Signature used in R1 | | | | | packet | | | | | | | HIP_SIGNATURE | 61697 | variable | Signature of the | | | | | packet | | | | | | | ECHO_REQUEST_UNSIGNED | 63661 | variable | Opaque data to be | | | | | echoed back; after | | | | | signature | | | | | | | ECHO_RESPONSE_UNSIGNED | 63425 | variable | Opaque data echoed | | | | | back by request; | | | | | after signature | +------------------------+-------+-----------+----------------------+ IANA Question -> Parameter Type 768 indicates that the reference for this parameter should be another document. What is that document? All other parameter types will be given a reference of [ RFC-to-be ]. Sixth, in a location [ TBD, see question above ] a new registry is to be created called the "Group ID." The Group ID is a 8-bit value. The new registry is maintained via IETF Review or IESG Approval as defined by RFC 5226. Thre are initial registrations in this new registry as follows: Value Group KDF Reference --------+----------------------------------+----------------+------------- 0 Reserved [ RFC-to-be ] 1 DEPRECATED [ RFC-to-be ] 2 DEPRECATED [ RFC-to-be ] 3 1536-bit MODP group [RFC3526] HKDF [RFC5869] [ RFC-to-be ] 4 3072-bit MODP group [RFC3526] HKDF [RFC5869] [ RFC-to-be ] 5 DEPRECATED [ RFC-to-be ] 6 DEPRECATED [ RFC-to-be ] 7 NIST P-256 [RFC5903] HKDF [RFC5869] [ RFC-to-be ] 8 NIST P-384 [RFC5903] HKDF [RFC5869] [ RFC-to-be ] 9 NIST P-521 [RFC5903] HKDF [RFC5869] [ RFC-to-be ] 10 SECP160R1 [SECG] HKDF [RFC5869] [ RFC-to-be ] Seventh, in a location [ TBD, see question above ] a new registry is to be created called the "HIP Cipher ID." The Cipher ID is a 16-bit value. The new registry is maintained via IETF Review or IESG Approval as defined by RFC 5226. There are initial registrations in the HIP Cipher ID registry as follows: Value Suite ID Reference -------+------------------+--------------- 0 RESERVED [ RFC-to-be ] 1 NULL-ENCRYPT [RFC2410] 2 AES-128-CBC [RFC3602] 3 DEPRECATED [ RFC-to-be ] 4 AES-256-CBC [RFC3602] Seventh, in a location [ TBD, see question above ] a new registry is to be created called the "DI-type." The DI-type is a 4-bit value. The new registry is maintained via IETF Review or IESG Approval as defined by RFC 5226. There are initial registrations in the DI-type registry as follows: Value Type Reference ------+---------------+-------------- 0 non included [ RFC-to-be ] 1 FQDN [ RFC-to-be ] 2 NAI [ RFC-to-be ] Eighth, in a location [ TBD, see question above ] a new registry is to be created called the "Notify Message Type." The DI-type is a 16-bit value. Registration rules are as follows: 51-8191 are error types reserved to be allocated by IANA 8192-16383 are error types for experimentation 16385-40959 are status types to be allocated by IANA 40960-65535 are status types for experimentation New values in ranges 51-8191 and 16385-40959 are assigned through First Come First Served, with Specification Required. IANA Question -> what are the registration rules for values 0-50? IANA Question -> what are the registration rules for values 40960-65535? IANA understands that there are initial values for the Notify Message Type registry as follows: Value Notify Message Type Reference -------+--------------------------------------+---------------- 1 UNSUPPORTED_CRITICAL_PARAMETER_TYPE [ RFC-to-be ] 7 INVALID_SYNTAX [ RFC-to-be ] 14 NO_DH_PROPOSAL_CHOSEN [ RFC-to-be ] 15 INVALID_DH_CHOSEN [ RFC-to-be ] 16 NO_HIP_PROPOSAL_CHOSEN [ RFC-to-be ] 17 INVALID_HIP_CIPHER_CHOSEN [ RFC-to-be ] 20 UNSUPPORTED_HIT_SUITE [ RFC-to-be ] 24 AUTHENTICATION_FAILED [ RFC-to-be ] 26 CHECKSUM_FAILED [ RFC-to-be ] 28 HIP_MAC_FAILED [ RFC-to-be ] 32 ENCRYPTION_FAILED [ RFC-to-be ] 40 INVALID_HIT [ RFC-to-be ] 42 BLOCKED_BY_POLICY [ RFC-to-be ] 44 RESPONDER_BUSY_PLEASE_RETRY [ RFC-to-be ] 16384 I2_ACKNOWLEDGEMENT [ RFC-to-be ] IANA understands that these eight actions are the only actions required to be completed by IANA upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2014-06-02
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Niclas Comstedt |
2014-06-02
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Niclas Comstedt |
2014-05-30
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2014-05-30
|
14 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2014-05-28
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Tom Taylor |
2014-05-28
|
14 | Jean Mahoney | Request for Last Call review by GENART is assigned to Tom Taylor |
2014-05-28
|
14 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-05-28
|
14 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Host Identity Protocol Version 2 … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Host Identity Protocol Version 2 (HIPv2)) to Proposed Standard The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Host Identity Protocol Version 2 (HIPv2)' as Proposed Standard 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 2014-06-11. 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 document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a SIGMA- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1541/ |
2014-05-28
|
14 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-05-28
|
14 | Ted Lemon | Last call was requested |
2014-05-28
|
14 | Ted Lemon | Last call announcement was generated |
2014-05-28
|
14 | Ted Lemon | Ballot approval text was generated |
2014-05-28
|
14 | Ted Lemon | Ballot writeup was generated |
2014-05-28
|
14 | Ted Lemon | IESG state changed to Last Call Requested from Publication Requested |
2014-03-20
|
14 | Gonzalo Camarillo | PROTO Writeup for draft-ietf-hip-rfc5201-bis (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … PROTO Writeup for draft-ietf-hip-rfc5201-bis (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? Proposed Standard, as indicated in the header. The HIP WG is currently chartered to revise a few Experimental RFCs into Proposed Standards. This is one of those RFCs. The HIP WG learned a few lessons experimenting with those Experimental RFCs. RFC 6538 documents those learnings. (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: This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a SIGMA- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. Working Group Summary: There is full 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 standards-track specs. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Gonzalo Camarillo is the document shepherd. Ted Lemon is the responsible AD. (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 has reviewed version 12 of the document and believes it is ready for publication request. (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 special reviews are needed. (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. None. (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. Yes, an IPR disclosure was filed against this draft in 2011. The WG decided to mandate a co-factor of 1 in an attempt to avoid the first patent referenced in the IPR disclosure. (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. Note that this is the revision of an existing RFC (i.e., a bis document). (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 warnings given by the ID nits tool are not relevant as they do not represent actual issues. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No further 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? There are two normative references to Internet drafts. Those two drafts are being progressed at the same time as this one. (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, the publication of this RFC will obsolete RFC 5201. RFC 4843 is listed in the document header and is discussed in the Abstract, although not in the Introduction. If having the Introduction discuss RFC 4843 as well was considered necessary, copying the last paragraph of the Abstract and pasting it into the Introduction could be trivially done. (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 IANA Considerations Section is consisten with the body of the document. (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 registries follow the Expert Review policy. (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 formal language review is needed. |
2014-03-20
|
14 | Gonzalo Camarillo | State Change Notice email list changed to hip-chairs@tools.ietf.org, draft-ietf-hip-rfc5201-bis@tools.ietf.org |
2014-03-20
|
14 | Gonzalo Camarillo | Responsible AD changed to Ted Lemon |
2014-03-20
|
14 | Gonzalo Camarillo | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2014-03-20
|
14 | Gonzalo Camarillo | IESG state changed to Publication Requested |
2014-03-20
|
14 | Gonzalo Camarillo | IESG process started in state Publication Requested |
2014-03-20
|
14 | Gonzalo Camarillo | Changed document writeup |
2014-03-20
|
14 | Gonzalo Camarillo | Document shepherd changed to Gonzalo Camarillo |
2014-03-20
|
14 | Gonzalo Camarillo | Intended Status changed to Proposed Standard from None |
2014-03-20
|
14 | Gonzalo Camarillo | Changed consensus to Yes from Unknown |
2013-10-06
|
14 | Tom Henderson | New version available: draft-ietf-hip-rfc5201-bis-14.txt |
2013-09-05
|
13 | Tom Henderson | New version available: draft-ietf-hip-rfc5201-bis-13.txt |
2013-06-30
|
12 | Tom Henderson | New version available: draft-ietf-hip-rfc5201-bis-12.txt |
2013-02-25
|
11 | Tom Henderson | New version available: draft-ietf-hip-rfc5201-bis-11.txt |
2012-11-25
|
10 | Tom Henderson | New version available: draft-ietf-hip-rfc5201-bis-10.txt |
2012-07-16
|
09 | Robert Moskowitz | New version available: draft-ietf-hip-rfc5201-bis-09.txt |
2012-03-12
|
08 | Tom Henderson | New version available: draft-ietf-hip-rfc5201-bis-08.txt |
2011-10-31
|
07 | (System) | New version available: draft-ietf-hip-rfc5201-bis-07.txt |
2011-07-09
|
06 | (System) | New version available: draft-ietf-hip-rfc5201-bis-06.txt |
2011-04-17
|
(System) | Posted related IPR disclosure: Certicom Corp.'s Statement about IPR related to draft-ietf-hip-rfc5201-bis | |
2011-03-14
|
05 | (System) | New version available: draft-ietf-hip-rfc5201-bis-05.txt |
2011-01-20
|
04 | (System) | New version available: draft-ietf-hip-rfc5201-bis-04.txt |
2010-10-23
|
03 | (System) | New version available: draft-ietf-hip-rfc5201-bis-03.txt |
2010-09-03
|
02 | (System) | New version available: draft-ietf-hip-rfc5201-bis-02.txt |
2010-09-01
|
01 | (System) | New version available: draft-ietf-hip-rfc5201-bis-01.txt |
2010-08-23
|
00 | (System) | New version available: draft-ietf-hip-rfc5201-bis-00.txt |