Host Identity Protocol
draft-ietf-hip-base-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the Yes position for Sam Hartman |
2008-04-21
|
10 | (System) | This was part of a ballot set with: draft-ietf-hip-esp, draft-ietf-hip-mm, draft-ietf-hip-registration, draft-ietf-hip-rvs |
2007-12-12
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2007-12-12
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2007-12-12
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2007-12-07
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2007-12-05
|
10 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2007-12-05
|
10 | Amy Vezza | IESG state changed to Approved-announcement sent |
2007-12-05
|
10 | Amy Vezza | IESG has approved the document |
2007-12-05
|
10 | Amy Vezza | Closed "Approve" ballot |
2007-12-05
|
10 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2007-12-05
|
10 | (System) | IANA Action state changed to In Progress |
2007-12-03
|
10 | Sam Hartman | [Ballot Position Update] Position for Sam Hartman has been changed to Yes from Discuss by Sam Hartman |
2007-12-03
|
10 | Mark Townsley | [Note]: 'After Sam''s discuss is cleared, I need one more position recorded from Dan, Jon or Cullen to have the 2/3 necessary to approve these … [Note]: 'After Sam''s discuss is cleared, I need one more position recorded from Dan, Jon or Cullen to have the 2/3 necessary to approve these specs.' added by Mark Townsley |
2007-12-03
|
10 | Mark Townsley | Note field has been cleared by Mark Townsley |
2007-10-30
|
10 | (System) | New version available: draft-ietf-hip-base-10.txt |
2007-10-02
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-10-02
|
09 | (System) | New version available: draft-ietf-hip-base-09.txt |
2007-09-26
|
10 | Mark Townsley | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Mark Townsley |
2007-09-26
|
10 | Mark Townsley | [Note]: 'Awaiting -09, and then Mark to writeup IESG note' added by Mark Townsley |
2007-09-26
|
10 | Mark Townsley | Email thread with basis for IESG note -------- Original Message -------- Subject: Re: your DISCUSS on the HIP spec Date: Tue, 25 Sep 2007 22:27:05 … Email thread with basis for IESG note -------- Original Message -------- Subject: Re: your DISCUSS on the HIP spec Date: Tue, 25 Sep 2007 22:27:05 +0300 From: Gonzalo Camarillo To: Mark Townsley CC: Sam Hartman , Petri Jokela , "Henderson, Thomas R" , hip-chairs@tools.ietf.org, Jari Arkko , Pekka Nikander References: <77F357662F8BFA4CA7074B0410171B6D0404975A@XCH-NW-5V1.nw.nos.boeing.com> Mark, could you please take the text below, including Sam's suggestions, fix the grammar (also per Sam's suggestion), and produce the IESG note we need? Thanks, Gonzalo Sam Hartman wrote: >>>>>> "Petri" == Petri Jokela writes: > > >> -----Original Message----- From: Sam Hartman > >> [mailto:hartmans-ietf@mit.edu] Sent: 5. syyskuuta 2007 22:48 > >> To: Henderson, Thomas R Cc: hip-chairs@tools.ietf.org; Jari > >> Arkko; Mark Townsley; Pekka Nikander; Petri Jokela (JO/LMF) > >> Subject: Re: your DISCUSS on the HIP spec > >> > >> Hi. > >> > >> I look forward to the IESG note; I'd like to see hip get > >> published. > > Petri> Hi, > > Petri> here is an initial proposal for an IESG note. This is now > Petri> divided into base and esp draft sections; maybe they should > Petri> be combined and included in all the documents? I don't know > Petri> the usual procedure. > > We can do it either way. > > Petri> /Petri > > > > Petri> draft-ietf-hip-base > > > Petri> These issues describe the IESG concerns in this > Petri> document. It is expected that this list will be taken into > Petri> account when future versions of HIP are designed. > s/taken into account/addressed > > Petri> This document doesn't currently define support for > Petri> parameterized (randomized) hashing in signatures, support > Petri> for negotiation of a key derivation function, or support > Petri> for combined encryption modes. > > Petri> HIP defines the usage of RSA mandatory in signing and > Petri> encrypting data. Current recommendations propose usage of > Petri> e.g. RSA OAEP/PSS for these operations. Changing the > Petri> algorithms for more recent ones needs to be considered. > s/operations/operations in new protocols/ > > Petri> The current specification is currently using HMAC for > Petri> message authentication. This is considered to be acceptable > Petri> for experimental RFC, but future versions have to define a > Petri> more generic way allowing also other MAC algorithms to be > Petri> used. > > Petri> SHA-1 is not any longer the preferred hashing > Petri> algorithm. This is noted also by authors but it is used for > Petri> this experimental version of HIP. Future versions must > Petri> consider other, more secure, hashing algorithms. > > Petri> In incoming traffic handling it is specified that the > Petri> incoming packet's IP address is ignored. In simple cases > How about but when there are security policies based on incoming interface > or IP address rules > > Petri> this can be done, but when there are e.g. different > Petri> security policies on different interfaces, the situation > Petri> changes. The handling of data needs to be enhanced to cover > Petri> different types of network and security configurations. > > Add and to meet local security policies. > > > > Petri> draft-ietf-hip-esp > > Petri> These issues describe the IESG concerns in this > Petri> document. It is expected that this list will be taken into > Petri> account when future versions of HIP are designed. > see above > > Petri> In case of complex SPDs and co-existence of HIP and > Petri> e.g. IKE, there may be unspecified conditions. For example |
2007-09-26
|
10 | Mark Townsley | Email about items left for version -09 -------- Original Message -------- Subject: RE: your DISCUSS on the HIP spec Date: Wed, 26 Sep 2007 13:59:06 … Email about items left for version -09 -------- Original Message -------- Subject: RE: your DISCUSS on the HIP spec Date: Wed, 26 Sep 2007 13:59:06 +0200 From: Petri Jokela To: Gonzalo Camarillo , Mark Townsley , Jari Arkko CC: Sam Hartman , Henderson, Thomas R , , Pekka Nikander References: <77F357662F8BFA4CA7074B0410171B6D0404975A@XCH-NW-5V1.nw.nos.boeing.com> <46F96109.1050606@ericsson.com> Hi, In addition to the IESG note, there are few fixes that are needed in the base draft: few typos in parameters, small mistake in state diagram and few pieces of text that were agreed to be included during discussions. One thing that is still missing is the analysis on the Opportunistic mode. Jari was willing to help with the text so I hope he can provide something for me to be added in the draft. Thus, there is a need to submit one more version of the draft (-09) where all these are fixed. In practise, I have everything ready, just the opportunistic mode analysis is missing. /petri |
2007-06-12
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-06-12
|
08 | (System) | New version available: draft-ietf-hip-base-08.txt |
2007-04-24
|
10 | Sam Hartman | [Ballot discuss] [revised to clarify issue with 6.2] Hi. I've evaluated this document set and held it to a higher level of quality than I … [Ballot discuss] [revised to clarify issue with 6.2] Hi. I've evaluated this document set and held it to a higher level of quality than I would normally hold an experimental publication to. I'm assuming there is some reasonable chance that this will be the basis of important internet architecture. I'd rather identify issues now than when a successor to this version of HIP goes to proposed. As such, many of my issues may be handled by documenting (in an IESG note?) as things that must be fixed before going to proposed. HIP is missing several important features I'd expect a new cryptographic protocol designed starting today to have: support for parameterized (randomized) hashing in signatures; support for negotiation of a key derivation function; support for combined encryption modes. By support I mean it should be possible to add these in the future, more than that I'd expect them to be used now. Support for randomized hashing seems most difficult. I think these will become more important in the future and HIP should be modified now or should expect to be modified before it could become a standard. If HIP were a completely new protocol today I'd expect it to use RSA OAEP/PSS; this is probably forgivable. Another significant problem is that HIP is too tightly bound to HMAC. There are several MACs these days that are strong and not based on hashes. I don't understand why HIP needs to use an HMAC rather than a MAC. It's fine if you choose to use sha family hmacs today. The security area is recommending when people choose one hash today that it be stronger than sha-1. If this were not experimental you would need to use something stronger; as is, I strongly recommend you use sha-256 for a hash. It's not such a big deal inside a HMAC. HIP's handling of lost state seems insufficient to guarantee interoperability. Section 6.16 allows a HIP node to drop state at any time. However there is no mandatory to implement mechanism to recover other than waiting for a potentially very long timeout. Implementations MAY send ICMP messages; implementations may respond to these messages. But there is not actually a mechanism that people have to make available to solve this. Opportunistic mode is described sufficiently to implement but is not analyzed from a security standpoint. I think that you either need to do the things you say are coming in another document, remove opportunistic mode or do at least enough analysis to show that it is not less secure than the Internet today. Section 6.2 of the base spec needs to require that the HIT of the incoming packet be checked to confirm that it is the expected HIT. The base spec says that the IP address a packet arrives/is sent on should be ignored. The problem with this approach is that different interfaces have different security properties. I may well be willing to send data without confidentiality protection over a interface internal to a corporation but not over an external interface. This interaction would need to be carefully explored and reasonable controls added before HIP would be appropriate as a standard. Thinking about HIP interacts with mandatory access control in the SPD is also going to be challenging. I discuss one case of this below. Section 6.3 needs to describe what key material to use. It's implied later, but whenever you describe a keyed cryptographic operation you need to say what keys to use. Similarly, the description of what data is MACed and signed is not sufficient to meet the requirements of id-nits. Please show a diagram showing the header and data especially for the hmac_2 parameter. The procedure as described is too specific to existing hip parameters. The rules would break if you added some new signature or mac related parameters and would be ambiguous if you added new parameters that were not covered by the signature/mac. You should say something general like the signature/mac covers everything before itself and nothing after. (Obviously hip_signature_2 is more complicated) Base document Section 6..6: >Furthermore, upon timeout, the > implementation MUST refrain from sending the same I1 packet to > multiple addresses. What does this mean? Section 6.9: > 11. The implementation SHOULD also verify that the Initiator's HIT > in the I2 corresponds to the Host Identity sent in the I2. Why is this a SHOULD not a MUST? In the ESP document , how does HIP interact with the SPD? Suppose I have an SPD entry saying that traffic to 18/8 needs to be protected. Suppose that I contact a machine via HIP whose HIT happens to resolve to something in 18/8. Do I expect double encapsulation? The ESP document does not make it clear what ipsec mode is being used. It sounds like beet is desired, but beet is not a normative reference. How is the mode indicated and what is the mandatory to implement mode? In a discussion with secdir, Pekka N said that one of the motivations behind the unsigned echo and echo response is for middleboxes. I don't think this is well defined enough to be interoperable as only one of these parameters can exist in a packet. What happens if a middle box wants to add one of these and cannot do so because it already exists? I found no issues in the registration document and did not get a chance to review the mobility document. |
2007-04-19
|
10 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation - Defer by Amy Vezza |
2007-04-19
|
10 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2007-04-19
|
10 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2007-04-19
|
10 | David Ward | [Ballot Position Update] Position for David Ward has been changed to Recuse from No Objection by David Ward |
2007-04-19
|
10 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2007-04-19
|
10 | Magnus Westerlund | [Ballot comment] draft-ietf-hip-mm-05, Section 1: Finally, making underlying IP mobility transparent to the transport layer has implications on the proper … [Ballot comment] draft-ietf-hip-mm-05, Section 1: Finally, making underlying IP mobility transparent to the transport layer has implications on the proper response of transport congestion control, path MTU selection, and QoS. Transport-layer mobility triggers, and the proper transport response to a HIP mobility or multihoming address change, are outside the scope of this document. This is a important issue with mobility. I expect that there are some real considerations and hopefully solutions on this if and when HIP goes from experimental to standards track. But I do understand that it is likely to requrie also work on the transport side. |
2007-04-19
|
10 | Magnus Westerlund | [Ballot comment] draft-ietf-hip-mm-05, Section 1: Finally, making underlying IP mobility transparent to the transport layer has implications on the proper … [Ballot comment] draft-ietf-hip-mm-05, Section 1: Finally, making underlying IP mobility transparent to the transport layer has implications on the proper response of transport congestion control, path MTU selection, and QoS. Transport-layer mobility triggers, and the proper transport response to a HIP mobility or multihoming address change, are outside the scope of this document. This is a potential important issue with mobility. I expect that there are some real consideration on this if and when HIP goes from experimental to standards track. |
2007-04-19
|
10 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2007-04-19
|
10 | Russ Housley | [Ballot comment] It is possible to run vanilla IPsec and HIP on the same node and get the intended security services applied to the … [Ballot comment] It is possible to run vanilla IPsec and HIP on the same node and get the intended security services applied to the intended traffic if one is careful about configuration. The security services are present, and it appears to be possible to use a HIP-unaware IPsec to do the HIP ESP processing. One should worry about whether there is a possibility of a HIT conflicting with an actual IPv6 address as the technique advocated for a HIP-unaware IPsec implementation apparently has HITs masquerade as IPv6 addresses for IPsec processing. Since HIP and IPsec share a common SPI space, and traffic on any HIP SPI completely bypasses IPsec policy. (Think about Steve Kent's usual rant about IPsec being more than just a means to apply cryptographic security mechanisms to traffic.) The assurances that IPsec provides are easily broken with HIP, since inbound HIP traffic bypasses the IPsec SPD and gets handed directly to HIP, which logically has its own SPD. It is not clear to me exactly how to avoid this situation, or what to add to the document to warn about this security consideration. A long discussion may be needed. Since the document is intended for Experimental RFC, this may be an acceptable situation, but this must be resolved for this document to transition to the standards track. |
2007-04-18
|
10 | Sam Hartman | [Ballot comment] A lot of effort is spent supporting middleboxes that want to verify HIP packets: signatures are required after key material is available and … [Ballot comment] A lot of effort is spent supporting middleboxes that want to verify HIP packets: signatures are required after key material is available and especially on update packets. As an option this seems like a reasonable design choice. However as a requirement this seems poorly considered as it significantly increases the computational complexity of HIP. NATs get along today without verifying state. I think there are many cases where state verification will not be required for HIP. I'd like to thank the HIP community for an excellent set of documents for spending a lot of time working with the security directorate to get their comments resolved. I'd also like to thank the many security directorate members who provided reviews. |
2007-04-18
|
10 | Sam Hartman | [Ballot comment] A lot of effort is spent supporting middleboxes that want to verify HIP packets: signatures are required after key material is available and … [Ballot comment] A lot of effort is spent supporting middleboxes that want to verify HIP packets: signatures are required after key material is available and especially on update packets. As an option this seems like a reasonable design choice. However as a requirement this seems poorly considered as it significantly increases the computational complexity of HIP. NATs get along today without verifying state. I think there are many cases where state verification will not be required for HIP. |
2007-04-18
|
10 | Sam Hartman | [Ballot discuss] Hi. I've evaluated this document set and held it to a higher level of quality than I would normally hold an experimental publication … [Ballot discuss] Hi. I've evaluated this document set and held it to a higher level of quality than I would normally hold an experimental publication to. I'm assuming there is some reasonable chance that this will be the basis of important internet architecture. I'd rather identify issues now than when a successor to this version of HIP goes to proposed. As such, many of my issues may be handled by documenting (in an IESG note?) as things that must be fixed before going to proposed. HIP is missing several important features I'd expect a new cryptographic protocol designed starting today to have: support for parameterized (randomized) hashing in signatures; support for negotiation of a key derivation function; support for combined encryption modes. By support I mean it should be possible to add these in the future, more than that I'd expect them to be used now. Support for randomized hashing seems most difficult. I think these will become more important in the future and HIP should be modified now or should expect to be modified before it could become a standard. If HIP were a completely new protocol today I'd expect it to use RSA OAEP/PSS; this is probably forgivable. Another significant problem is that HIP is too tightly bound to HMAC. There are several MACs these days that are strong and not based on hashes. I don't understand why HIP needs to use an HMAC rather than a MAC. It's fine if you choose to use sha family hmacs today. The security area is recommending when people choose one hash today that it be stronger than sha-1. If this were not experimental you would need to use something stronger; as is, I strongly recommend you use sha-256 for a hash. It's not such a big deal inside a HMAC. HIP's handling of lost state seems insufficient to guarantee interoperability. Section 6.16 allows a HIP node to drop state at any time. However there is no mandatory to implement mechanism to recover other than waiting for a potentially very long timeout. Implementations MAY send ICMP messages; implementations may respond to these messages. But there is not actually a mechanism that people have to make available to solve this. Opportunistic mode is described sufficiently to implement but is not analyzed from a security standpoint. I think that you either need to do the things you say are coming in another document, remove opportunistic mode or do at least enough analysis to show that it is not less secure than the Internet today. Section 6.2 of the base spec says that the IP address a packet arrives/is sent on should be ignored. The problem with this approach is that different interfaces have different security properties. I may well be willing to send data without confidentiality protection over a interface internal to a corporation but not over an external interface. This interaction would need to be carefully explored and reasonable controls added before HIP would be appropriate as a standard. Thinking about HIP interacts with mandatory access control in the SPD is also going to be challenging. I discuss one case of this below. Section 6.3 needs to describe what key material to use. It's implied later, but whenever you describe a keyed cryptographic operation you need to say what keys to use. Similarly, the description of what data is MACed and signed is not sufficient to meet the requirements of id-nits. Please show a diagram showing the header and data especially for the hmac_2 parameter. The procedure as described is too specific to existing hip parameters. The rules would break if you added some new signature or mac related parameters and would be ambiguous if you added new parameters that were not covered by the signature/mac. You should say something general like the signature/mac covers everything before itself and nothing after. (Obviously hip_signature_2 is more complicated) Base document Section 6..6: >Furthermore, upon timeout, the > implementation MUST refrain from sending the same I1 packet to > multiple addresses. What does this mean? Section 6.9: > 11. The implementation SHOULD also verify that the Initiator's HIT > in the I2 corresponds to the Host Identity sent in the I2. Why is this a SHOULD not a MUST? In the ESP document , how does HIP interact with the SPD? Suppose I have an SPD entry saying that traffic to 18/8 needs to be protected. Suppose that I contact a machine via HIP whose HIT happens to resolve to something in 18/8. Do I expect double encapsulation? The ESP document does not make it clear what ipsec mode is being used. It sounds like beet is desired, but beet is not a normative reference. How is the mode indicated and what is the mandatory to implement mode? In a discussion with secdir, Pekka N said that one of the motivations behind the unsigned echo and echo response is for middleboxes. I don't think this is well defined enough to be interoperable as only one of these parameters can exist in a packet. What happens if a middle box wants to add one of these and cannot do so because it already exists? I found no issues in the registration document and did not get a chance to review the mobility document. |
2007-04-18
|
10 | Sam Hartman | [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman |
2007-04-18
|
10 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2007-04-18
|
10 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2007-04-18
|
10 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2007-04-17
|
10 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2007-04-16
|
10 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from No Objection by Tim Polk |
2007-04-06
|
10 | (System) | Removed from agenda for telechat - 2007-04-05 |
2007-04-02
|
10 | Sam Hartman | State Changes to IESG Evaluation - Defer from IESG Evaluation by Sam Hartman |
2007-04-02
|
10 | Jari Arkko | [Ballot Position Update] New position, Recuse, has been recorded by Jari Arkko |
2007-03-26
|
10 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2007-03-23
|
10 | Lars Eggert | [Ballot Position Update] New position, Recuse, has been recorded by Lars Eggert |
2007-03-15
|
10 | Mark Townsley | State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Mark Townsley |
2007-03-15
|
10 | Mark Townsley | Placed on agenda for telechat - 2007-04-05 by Mark Townsley |
2007-02-01
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-02-01
|
07 | (System) | New version available: draft-ietf-hip-base-07.txt |
2007-01-30
|
10 | Mark Townsley | -------- Original Message -------- Subject: Re: I-D ACTION:draft-ietf-hip-base-03.txt Date: Thu, 23 Jun 2005 20:00:45 -0400 From: Bruce Lilly Reply-To: ietf@ietf.org Organization: Bruce Lilly To: ietf@ietf.org … -------- Original Message -------- Subject: Re: I-D ACTION:draft-ietf-hip-base-03.txt Date: Thu, 23 Jun 2005 20:00:45 -0400 From: Bruce Lilly Reply-To: ietf@ietf.org Organization: Bruce Lilly To: ietf@ietf.org CC: petri.jokela@nomadiclab.com, rgm@icsalabs.com, thomas.r.henderson@boeing.com References: On Thu June 23 2005 18:50, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Host Identity Protocol Working Group of the IETF. > > Title : Host Identity Protocol > Author(s) : R. Moskowitz, et al. > Filename : draft-ietf-hip-base-03.txt > Pages : 96 > Date : 2005-6-23 > > This memo specifies the details of the Host Identity Protocol (HIP). > HIP provides a rapid exchange of Host Identities (public keys) > between hosts and uses a Sigma-compliant [REF] Diffie-Hellman key > exchange to establish shared secrets between such endpoints. The > protocol is designed to be resistant to Denial-of-Service (DoS) and > Man-in-the-middle (MitM) attacks, and when used together with another > suitable security protocol, such as Encapsulated Security Payload > (ESP) [24], it provides encryption and/or authentication protection > for upper layer protocols such as TCP and UDP, while enabling > continuity of communications across network layer address changes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-base-03.txt Brief comments: 1. The Abstract isn't supposed to contain references. 2. It is helpful to indicate a suggested forum for discussion (the Abstract is a good place) 3. Numeric references are deprecated http://www.rfc-editor.org/pipermail/rfc-interest/2005-January/000235.html 4. The introduction refers to an architecture document, reference #25: [25] Moskowitz, R., "Host Identity Protocol Architecture", draft-moskowitz-hip-arch-03 (work in progress), May 2003. Given the date, I strongly suspected expiration; I checked the I-D database: https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=4950 which shows a -06 version as the latest, also expired, and therefore no link to retrieve the document. Dead End. 5. Appendices (the draft's contain reference citations) should appear before the Normative/Informative references. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf |
2007-01-16
|
10 | Mark Townsley | [Note]: 'One remaining issue with ORCHID document that is normatively referenced from here. Requested authors to remove as many dependencies as possible (no duplicate information … [Note]: 'One remaining issue with ORCHID document that is normatively referenced from here. Requested authors to remove as many dependencies as possible (no duplicate information in multiple documents) and move forward (letting the normative reference alone be a holdup, and no longer needing to sync between the two documents). Waiting for new docs, and then should be ready to go on telechat.' added by Mark Townsley |
2007-01-15
|
10 | Mark Townsley | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Mark Townsley |
2007-01-15
|
10 | Mark Townsley | [Note]: 'Awaiting new document with (1) Resolution of HIT issue (as documented in attached email from chair), (2) GEN-ART review comments (mostly editorial), and (3) … [Note]: 'Awaiting new document with (1) Resolution of HIT issue (as documented in attached email from chair), (2) GEN-ART review comments (mostly editorial), and (3) outcome of secdir review. Pinged authors/chairs/sec-ads 1/15/2007' added by Mark Townsley |
2007-01-15
|
10 | Mark Townsley | Status date has been changed to 2007-02-01 from |
2006-11-19
|
10 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2006-11-08
|
10 | (System) | Request for Last Call review by SECDIR is assigned to Tero Kivinen |
2006-11-08
|
10 | (System) | Request for Last Call review by SECDIR is assigned to Tero Kivinen |
2006-11-08
|
10 | (System) | Requested Last Call review by SECDIR |
2006-11-05
|
10 | Amy Vezza | Last call sent |
2006-11-05
|
10 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-11-05
|
10 | Amy Vezza | Last Call was requested by Amy Vezza |
2006-11-05
|
10 | Amy Vezza | State Changes to Last Call Requested from IESG Evaluation::Revised ID Needed by Amy Vezza |
2006-10-30
|
10 | Mark Townsley | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Mark Townsley |
2006-10-30
|
10 | Mark Townsley | State Changes to IESG Evaluation from Waiting for AD Go-Ahead::Revised ID Needed by Mark Townsley |
2006-10-30
|
10 | Mark Townsley | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Mark Townsley |
2006-10-30
|
10 | Mark Townsley | -------- Original Message -------- Subject: Re: Your new charter was approved Date: Sat, 28 Oct 2006 12:45:25 +0300 From: Gonzalo Camarillo To: Mark Townsley CC: … -------- Original Message -------- Subject: Re: Your new charter was approved Date: Sat, 28 Oct 2006 12:45:25 +0300 From: Gonzalo Camarillo To: Mark Townsley CC: hip-chairs@tools.ietf.org References: <4540F284.8030607@cisco.com> Hi Mark, there are ongoing discussions on the prefix to be used for HITs (Host Identity Tags), which act as host identifiers. Ted had some concerns and we may need a new IETF LC. Those discussions affect the base HIP spec. Then, we have sent you all the remaining documents, which are ready for IETF LC. Regarding the new milestones, we have initial documents for all of them. If you need further info, let us know. Cheers, Gonzalo |
2006-10-30
|
10 | Mark Townsley | [Note]: 'Awaiting new document with (1) Resolution of HIT issue (as documented in attached email from chair), (2) GEN-ART review comments (mostly editorial), and (3) … [Note]: 'Awaiting new document with (1) Resolution of HIT issue (as documented in attached email from chair), (2) GEN-ART review comments (mostly editorial), and (3) outcome of secdir review.' added by Mark Townsley |
2006-10-30
|
10 | Mark Townsley | Removed from agenda for telechat - 2006-11-16 by Mark Townsley |
2006-10-30
|
10 | Mark Townsley | Placed on agenda for telechat - 2006-11-16 by Mark Townsley |
2006-10-30
|
10 | Mark Townsley | Note field has been cleared by Mark Townsley |
2006-09-26
|
10 | Mark Townsley | [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley |
2006-09-26
|
10 | Mark Townsley | Ballot has been issued by Mark Townsley |
2006-09-26
|
10 | Mark Townsley | Created "Approve" ballot |
2006-09-26
|
10 | Mark Townsley | [Note]: 'Inquirying with Security ADs about need for sec review. Inquiring about LC comments as well.' added by Mark Townsley |
2006-09-15
|
10 | Yoshiko Fong | IANA Last Call Comments: Upon approval of this document IANA understands that three IANA Actions are required. First, IANA will assign a protocol number for … IANA Last Call Comments: Upon approval of this document IANA understands that three IANA Actions are required. First, IANA will assign a protocol number for HIP in the following registry: http://www.iana.org/assignments/protocol-numbers The document specifies the protocol number 253 which is currently reserved for experimental use. Second, IANA will assign a new 128-bit value in the CGA Message Type Name Space which is located at: http://www.iana.org/assignments/cga-message-types The new value will be: 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA Third, IANA will create a new HIP Parameters Name Space with the following seven Name Spaces within it: - Packet Type - HIP Version - Parameter Type - Group ID - Suite ID - DI-Type - Notify Message Type Each of these new Name Spaces will be instantiated with the values and new value assignment rules documented in the IANA Considerations section. IANA will use the instructions on pages 86 through 90 to create the new HIP Parameters Name Space. IANA understands these three actions to be the only actions required for this document. |
2006-09-14
|
10 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2006-08-31
|
10 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-08-31
|
10 | Mark Townsley | State Changes to Last Call Requested from AD Evaluation by Mark Townsley |
2006-08-31
|
10 | Mark Townsley | Last Call was requested by Mark Townsley |
2006-08-31
|
10 | (System) | Ballot writeup text was added |
2006-08-31
|
10 | (System) | Last call text was added |
2006-08-31
|
10 | (System) | Ballot approval text was added |
2006-08-21
|
10 | Mark Townsley | State Changes to AD Evaluation from Publication Requested by Mark Townsley |
2006-08-21
|
10 | Mark Townsley | [Note]: 'Inquirying with Security ADs about need for sec review.' added by Mark Townsley |
2006-07-03
|
10 | Dinara Suleymanova | PROTO Write-up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this … PROTO Write-up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Gonzalo Camarillo, who is the shepherd for this document and co-chairs the HIP WG, has reviewed this document and believes it is ready. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed thoroughly. The reviews performed included a Belovin-Rescorla security analysis. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No, the shepherd does not have any concerns. (1.d) Does the Document Shepherd have any specific concerns or issues 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 those issues have been discussed in the WG and the WG has indicated that it still wishes to advance the document, detail those concerns here. No, the shepherd does not have any concerns. (1.e) 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 is behind this document. (1.f) 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 will be entered into the ID Tracker.) There have been discussions on the length of the IPv6 prefix to be allocated for this experiment. The document normatively references the draft entitled "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", which at this point defines a /28 prefix. It seems that now, all the parties involved in the discussion are happy with this length. (1.g) Has the Document Shepherd verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. The document has two missing references: RFC2536 and RFC3110. This detail can be resolved along with other IETF last call comments once its IETF last call ends. (1.h) Has the document split its references into normative and informative? 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 strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references have been separated and there are normative references to Internet Drafts. Among these, the reference that could potentially delay the publication of this document could be the ORCHID draft (See 1.f). The HIP WG will request the publication of the draft entitled "Using ESP transport format with HIP" at the same time as this document. They should be processed together by the IESG. (1.i) 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 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 name space for mutual peer authentication. The protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in-the- middle (MitM) attacks, and when used together with another suitable security protocol, such as Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper layer protocols, suchs as TCP and UDP. Discussion related to this document is going on at the IETF HIP Working Group mailing list. 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? Consensus was strong on 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? There are several known implementations of this specification. Thanks, Gonzalo HIP co-chair |
2006-07-03
|
10 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2006-06-16
|
06 | (System) | New version available: draft-ietf-hip-base-06.txt |
2006-03-05
|
05 | (System) | New version available: draft-ietf-hip-base-05.txt |
2005-10-26
|
04 | (System) | New version available: draft-ietf-hip-base-04.txt |
2005-06-23
|
03 | (System) | New version available: draft-ietf-hip-base-03.txt |
2005-02-22
|
02 | (System) | New version available: draft-ietf-hip-base-02.txt |
2004-10-27
|
01 | (System) | New version available: draft-ietf-hip-base-01.txt |
2004-06-11
|
00 | (System) | New version available: draft-ietf-hip-base-00.txt |