From heer@informatik.rwth-aachen.de Thu Feb 3 05:52:21 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F030A3A6971 for ; Thu, 3 Feb 2011 05:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx1f6oS2oCxk for ; Thu, 3 Feb 2011 05:52:18 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 08FDE3A696A for ; Thu, 3 Feb 2011 05:52:17 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LG100J49O0RZXK0@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Thu, 03 Feb 2011 14:55:39 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,418,1291590000"; d="scan'208";a="92039331" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 03 Feb 2011 14:55:39 +0100 Received: from umic-i4-137-226-45-197.nn.rwth-aachen.de ([unknown] [137.226.45.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LG100JYIO0R3060@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 03 Feb 2011 14:55:39 +0100 (CET) From: Tobias Heer In-reply-to: Date: Thu, 03 Feb 2011 14:55:39 +0100 Message-id: References: To: hipsec@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [Hipsec] rfc5201-bis-04 review X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 13:52:21 -0000 Hello Ari, thanks a lot for the review. I'll comment below. Am 27.01.2011 um 18:13 schrieb Ari Keranen: > Hi, > > I reviewed part of the -04 draft (version dated Jan 27th), and here's some comments, questions, and suggestions. > > > Since we are specifying the version 2 of the protocol, should we say that in the title and abstract? > I think we should. I guess we would have to add "Version 2" to the title at least. Other comments? > > 1. Introduction > > As a result, all cryptographic protocols need to be agile. > That is, it should be a part of the protocol to switch from one > cryptographic primitive to another, and reasonable effort should be > done to support a reasonable set of mainstream algorithms. > > s/to switch/to be able to switch/ Ok. > > Instead of "reasonable effort should be done [...]" one could say something like: "[...] it is important to support a reasonable set of mainstream algorithms to cater for different use cases and allow moving away from algorithms that are later discovered to be vulnerable". > Sounds good. Thanks for the suggestion. > > 1.1. A New Namespace and Identifiers > > The HI is a > public key and directly represents the Identity. > > s/Identity/identity of a host/ > Done. > > Since there are > different public key algorithms that can be used with different key > lengths, the HI is unsuitable for use as a packet identifier > > s/HI is unsuitable/HI, as such, is unsuitable/ > Done. > > Consequently, a hash of the HI, the Host > Identity Tag (HIT), is the operational representation. > > s/is/is used as/ > > Done. > 1.2. The HIP Base Exchange (BEX) > > It > should be noted, however, that both the Initiator's and the > Responder's HITs are transported as such (in cleartext) in the > packets, allowing an eavesdropper with a priori knowledge about the > parties to identify them by their HITs. Hence, encrypting the HI of > any party does not provide privacy against such attacker. > > This text goes fairly deep into a specific attack and could better fit to the Security Considerations section than in the introduction. > > I think it needs to be there to understand the reasons and implications of using HIP before mechanisms like the ENCRYPTED parameter are introduced. I would prefer it to be there rather than in the SC section. > Data packets start to flow after the 4th packet. The 3rd and 4th HIP > packets may carry a data payload in the future. However, the details > of this may be defined later. > > s/may be defined later/are not defined for the time being/ > May be defined foe HIP Version 2 later? So far the data packets are defined for HIPv1. > > Thus, HIP is not a > complete replacement for IKE. > > This begs for a question "why would I use HIP instead of IKE". Perhaps a section (to appendix?) on HIP's relationship to IKE (and a reference to that section here) would be helpful. > It probably would be. I'll see what I can do. Maybe Bob is the best person to write a few lines about it, > > 2.3. Definitions > > All the definitions repeat the "defined word" in the beginning; that's a bit redundant. That is, instead of: > > HIP Base Exchange (BEX) The HIP Base Exchange is the handshake for > establishing a new HIP association. > > One could say: > > HIP Base Exchange (BEX): the handshake for > establishing a new HIP association > Done. > > Could also add "Initiator", "Responder", "HIP association" and "signed" to the definitions. > Good idea. I added those terms. Check if you like it in the next revision, please. > > 3. Host Identity (HI) and its Structure > > HIP implementations MUST support the Rivest Shamir Adelman (RSA) > [RFC3110] public key algorithm, and SHOULD support the Digital > Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve > Digital Signature Algorithm (ECDSA) defined in Section 5.2.8. > > Must support [...] for generating the Host Identity, as defined in [...] Done. > > > Other > algorithms MAY be supported. > > s/Other/Additional/ > > Ack. > 3.1. Host Identity Tag (HIT) > > This section repeats quite a bit the material in the previous section. Maybe some of the text related to HITs in the previous section could be removed and discussed only here. > > > This document extends [RFC5201] with measures to support crypto > agility. > > s/extends [RFC5201]/extends the original, experimental HIP specification [RFC5201]/ or "HIP v1" or something. > Good idea. Done. > > 3.2. Generating a HIT from an HI > > The HIT MUST be generated according to the ORCHID generation method > described in [I-D.ietf-hip-rfc4843-bis] using a context ID value of > 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA > > Should one say something about the byte order of the value? > Is there a byte order problem here at all? These are all single-byte values concatenated to a multi-byte string. Byte order is a problem for multi-byte values. We don't have these here. Am I missing something here? > > 4.1. Creating a HIP Association > > By definition, the system initiating a HIP exchange is the Initiator, > and the peer is the Responder. This distinction is forgotten once > the base exchange completes, and either party can become the > Initiator in future communications. > > Would one call a host making a HIP transaction (say, UPDATE) during an active HIP association an Initiator? The text seems to imply that, but at least I would not have used that term in that case. > it would be the initiator of the transaction but not the Initiator (note the capital I). > Also, there are cases where one may need to remember the distinction after the BEX (e.g., with NAT traversal the Initiator becomes the active ICE agent; and I vaguely remember discussing some time ago some other use case too..), so I would say, e.g., that the "distinction is typically forgotten [...]". > Point taken. I changed it to "typically..." > > The R2 packet acknowledges the receipt of the I2 packet and completes > the base exchange. The packet is signed by the Responder. > > s/The packet/The R2 packet/ Okay. > > > The base exchange is illustrated below > > The figure should be numbered (,center-aligned), and referenced with the number. Bit surprisingly, none of the figures in the draft are numbered. I'll see how to get this done. There are only two real figures anyway - this should be a quick fix. > > > 4.1.1. HIP Puzzle Mechanism > > The puzzle mechanism has been explicitly designed to give space for > various implementation options. First, it allows a Responder > implementation to completely delay session-specific state creation > until a valid I2 packet is received. In such a case, a correctly > formatted I2 packet can be rejected immediately once the Responder > has checked its validity by computing only one hash function. > > Why is a correctly formatted I2 rejected? Because of incorrect solution? > Yes... the correct packet format is not the main point here: In such a case, a correctly formatted I2 packet without valid puzzle solution can be rejected immediately once the Responder has checked the solution by computing only one hash function. > > Second, the design also allows a Responder implementation to keep > state about received I1 packets, and match the received I2 packets > against the state, thereby allowing the implementation to avoid the > computational cost of the hash function. > > It's not clear what this means (how one avoids the cost by matching). > I think it misses the point of proving that the Initiator or attacker has churned cycles. Optimizing away the singular hash function application does not seem worth the effort anyway. I would rephrase or remove the text completely. We could write something like: The puzzle allows a Responder implementation to completely delay session-specific state creation until a valid I2 packet is received. An I2 packet without valid puzzle solution can be rejected immediately once the Responder has checked the solution by computing only one hash function before state is created and CPU-intensive public-key signature verification and Diffie-Hellman key generation are performed. By varying the difficulty of the puzzle, the Responder can frustrate CPU or memory targeted DoS attacks. Any opinion? > > 4.1.2. Puzzle Exchange > > [...] the Receiver can verify that it has itself sent the I to the > > s/Receiver/Responder/ > > Done. > NOTE: The protocol developers explicitly considered whether a memory > bound function should be used for the puzzle instead of a CPU-bound > function. The decision was not to use memory-bound functions. > > A few words of rationale for not using memory-bound functions would be nice. > The rationale was that the first document deferred the decision and no good points _for_ memory-bound puzzles were presented. I think writing that down here will not help much. > > 4.1.3. Authenticated Diffie-Hellman Protocol with DH Group Negotiation > > However, since it is precomputed and therefore does not cover > association-specific information in the I1 packet [...] > > s/it is/the signature is/ or /the R1 is/ ? Done. "the R1", > > > The Initiator continues the BEX only > if the Group ID of the public DH value of the Responder intersects > the preferences of both Initiator and Responder. > > s/intersects the preferences of/is the most preferred of the IDs supported by/ > > Done. > Otherwise, the > communication is subject of a downgrade attack and the Initiator MUST > either restart the key exchange with a new I1 packet or abort the key > exchange. > > s/key exchange/base exchange/g > Done. > > The signature of the I2 > message covers all signed parameters of the packet without exceptions > as in the R1. > > Saying "all signed parameters are signed" sounds a bit redundant. And what would be an exception to this rule? > I'd change it into: The signature of the I2 message covers all parameters of the signed parameter ranges (see [ref]) in the packet without exceptions as in the R1. The exceptions are named when the SIGNATURE_2 and HIP_MAC2 are discussed. Discussing the specific exceptions here would distract the reader, I think. > > 4.1.4. HIP Replay Protection > > The scope of the > counter MAY be system-wide but SHOULD be applied per Host Identity, > if there is more than one local host identity. > > What "applied per Host Identity" means is not clear. Could be "every HI must have its own counter" or "every HI must use the same counter and increase it at every usage". > The first one. I'll change it to: The scope of the counter MAY be system-wide but there SHOULD be a separate counter for each Host Identity, if there is more than one local host identity. > > Implementations MUST accept puzzles from the current > generation and MAY accept puzzles from earlier generations. > > Could give some recommendation on how many earlier generations SHOULD be accepted (otherwise one may conclude that any earlier is always OK). > Any earlier may be okay.... however this really depends on the choice of the duration for which the R1 counter is current and the probability or possibility of misuse (including the choice of I and the opaque data field in the puzzle). Giving some exact value is difficulty without knowing the implementation details here. > > When > sending multiple I1 packets, an Initiator SHOULD wait for a small > amount of time (a reasonable time may be 2 * expected RTT) after the > first R1 reception to allow possibly multiple R1s to arrive > > s/multiple I1 packets/multiple I1 packets to the same host/ > Done. Thanks. > > 4.1.5. Refusing a HIP Exchange > > A HIP-aware host may choose not to accept a HIP exchange. If the > host's policy is to only be an Initiator, it should begin its own HIP > exchange. A host MAY choose to have such a policy since only the > privacy of the Initiator's HI is protected in the exchange. It > should be noted that such behavior can introduce the risk of a race > condition if each host's policy is to only be an Initiator, at which > point the HIP exchange will fail. > > s/HIP Exchange/HIP Base Exchange/g (title and text) -- unless this applies to some other exchanges too? Same with Section 4.1.6. > Done for the whole document. > Also, should there be some mechanism to detect and prevent the race situation continuing forever? > At this point, the hosts have incompatible policies and cannot communicate. The text concludes that the HIP base exchange will fail in that case. Do you think this needs further elaboration in the text? > > 4.1.7. HIP Downgrade Protection > > In a downgrade attack, an attacker manipulates the packets of an > Initiator and/or a Responder to unnoticeably influence the result of > the cryptographic negotiations in the BEX to its favor. > > s/an attacker manipulates/an attacker attempts to unnoticeably manipulate/ > (and remove the 2nd unnoticeably) > Done. Thanks for providing the alternative text. > > In contrast to the first version of HIP [RFC5201], this version > begins the negotiation of the DH Groups already in the first BEX > packet, the I1. > > s/this version/the version 2 of HIP defined in this document/ > Done. > > If the choice of the DH Group in the > R1 packet does not equal to the best match of the two lists (the > highest priority of the Responder that is present in the Initiator's > DH list), > > s/highest priority/highest priority DH ID/ > Done. > > 4.1.8. HIP Opportunistic Mode > > Since the Responder's HIT Suite is not determined by the > destination HIT of the I1 packet, the Responder can freely select a > HIT of any HIT Suite. > > s/is not determined/in the opportunistic mode is not determined/ > Done. > > the Initiator MAY restart the > BEX with an I1 packet with a source HIT that is contained in the list > of the Responder's HIT Suites in the R1 packet. > > s/is contained in/is compatible with one of the Suite IDs in/ > Done. > 4.4.3. HIP State Processes > > | Receive I2, process | If successful, send R2 and go to R2-SENT | > > What does "process" mean here? (same in the other tables) Should that be "receive and process"? And what is the difference compared to triggers without "process" (e.g., with receiving I1s and in Table 6)? We could remove the process and say "If processing is successful, send R2 and go to R2-SENT"... That might make it clearer. Agreed? > > > | Receive ANYOTHER | Drop and stay at UNASSOCIATED | > > "ANYOTHER" is not defined. Could just say "Receive something else" or define ANYOTHER somewhere (say, change 4.4.1 into "State Machine Terminology" and have ANYOTHER there). > > Good idea. I'll make the change. > Table 3 (I1-SENT) > > | Receive I1 | If the local HIT is smaller than the peer | > | | HIT, drop I1 and stay at I1-SENT | > > s/Receive I1/Receive I1 from the peer/ > Or maybe could explain before the table that "Receive X" means here receiving from a peer one is setting up a HIP SA with -- or does it? I think "Receive I1 from Responder" would be best. Because from the perspective of the Initiator (who is in state I1-sent) the Responder sends an I1. > > Could also add a reference to the Section 6.5 on how to compare HITs > Done. > > Table 5: R2-SENT - Waiting to finish HIP > and > Table 6: ESTABLISHED - HIP association established > > What to do if some other HIP message arrives? Probably with message types not specified in this document that's extension-specific, but could mention it somewhere here. Also, Table 5 doesn't have CLOSE_ACK. I changed the sentence in the introduction of the state machine from: New states may be introduced by mechanisms in other specifications (such as mobility and multihoming). to New states and state transitions may be introduced by mechanisms in other specifications (such as mobility and multihoming). I guess that covers additional procedures for extensions quite well. > Table 5: R2-SENT - Waiting to finish HI it should contain "CLOSE_ACK -> Drop and stay at R2-SENT" because no CLOSE, and therefore, no echo request was sent. Validating the echo will fail anyway. > > > Table 7: CLOSING - HIP association has not been used for UAL minutes/CLOSING - HIP association has not been used for UAL minutes > > | Timeout, increment | If timeout sum is less than UAL+MSL | > | timeout sum, reset | minutes, retransmit CLOSE and stay at | > | timer | CLOSING | > > This trigger's definition is not particularly clear. > This is because it intermingles the action (increment timeout sum, reset timer) into the trigger. I'll separate these: | Timeout | Increment timeout sum and reset timer. If | | | timeout sum is less than UAL+MSL minutes, | | | retransmit CLOSE and stay at CLOSING | | | | | | If timeout sum is greater than UAL+MSL | | | minutes, go to UNASSOCIATED | +---------------------+---------------------------------------------+ > > 4.5.1. TCP and UDP Pseudo-Header Computation for User Data > > When computing TCP and UDP checksums on user data packets that flow > through sockets bound to HITs, the IPv6 pseudo-header format > [RFC2460] MUST be used, even if the actual addresses on the packet > are IPv4 addresses. > > s/on the packet/on the IP header of the packet/ > > > 4.5.2. Sending Data on HIP Packets > > A future version of this document may define how to include user data > in various HIP packets. However, currently the HIP header is a > terminal header, and not followed by any other headers. > > Do we plan to do this in a future version of *this* document or would that be better left for some other document? > I think other is more accurate given the developments regarding the sending of user data in overlays, etc. > > 4.6. Certificate Distribution > > This document does not define how to use certificates or how to > transfer them between hosts. These functions are expected to be > defined in a future specification. > > Informational reference to the CERT draft could be appropriate. > Good point. > > I'll send additional nits off-list. > Thanks. > > Cheers, > Ari > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From ari.keranen@nomadiclab.com Thu Feb 3 09:44:43 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2742F3A69D9 for ; Thu, 3 Feb 2011 09:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9fPkkLnALIp for ; Thu, 3 Feb 2011 09:44:41 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 1AD573A6A32 for ; Thu, 3 Feb 2011 09:44:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 064004E6DC for ; Thu, 3 Feb 2011 19:48:01 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yek2dWjrNs1 for ; Thu, 3 Feb 2011 19:47:59 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 05C5D4E6BC for ; Thu, 3 Feb 2011 19:47:59 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Ari Keranen In-Reply-To: Date: Thu, 3 Feb 2011 19:47:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8B48650A-E9CA-4C74-90FA-4BE3860DB3A7@nomadiclab.com> References: To: HIP X-Mailer: Apple Mail (2.1082) Subject: Re: [Hipsec] rfc5201-bis-04 review X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:44:43 -0000 Hi, Here's comments, suggestions, and questions of the rest of the = rfc5201-bis-04 document.=20 BTW, don't be scared of the amount of comments; I just tried to do a = thorough review and weed out all the remaining errors, ambiguities, and = style issues -- even the smaller ones. 5.1. Payload Format | Next Header | Header Length |0| Packet Type | VER. | RES.|1| s/ VER. /Version/ (if fits there, so no need to abbreviate?) document does not describe processing for Next Header values other than decimal 59, IPPROTO_NONE, the IPv6 'no next header' value. Future documents MAY do so.=20 s/do so/define behavior for also other values/ The Header Length field contains the length of the HIP Header and HIP parameters in 8-byte units, excluding the first 8 bytes.=20 s/the length/the combined length/ The HIP Version is four bits. The current version is 2.=20 s/Version is/Version field is/ s/current version/version defined in this document/ For example, in the case that the forthcoming SHIM6 protocol happens to be compatible with this specification Since SHIM6 is already an RFC, this text could be updated. 5.1.2. HIP Controls The HIP Controls section conveys information about the structure of s/section/field/ The following fields have been defined: s/fields/sub-fields/ This control is set in packets R1 and/or I2. The peer receiving an anonymous HI may choose to refuse it. How about using anonymous HIs with other packets? Say, NOTIFYs or = UPDATEs? 5.1.3. HIP Fragmentation Support In IPv4 networks, HIP packets may encounter low MTUs along their routed path. Since HIP does not provide a mechanism to use multiple IP datagrams for a single HIP packet HIP over HIP does provide mechanism for this, so I'd change: s/HIP does not/basic HIP, as defined in this document, does not/ (or = something) HIP-aware NAT devices MUST perform any IPv4 reassembly/fragmentation. Despite the warning in the next paragraph, this would potentially make = all HIP-aware IPv4 NAT devices vulnerable for fragment-attacks. Could = change the MUST into SHOULD? Also, could clarify that = reassembly/fragmentation is a MUST/SHOULD for HIP packets, not for any = random packet. it is strongly recommended that the separate document specifying the certificate usage in the HIP Base Exchange defines the usage of "Hash and URL" formats rather than including certificates in exchanges.=20 This already exists in the CERT draft, so this text could be = removed/re-worded. The reference to fragmentation DoS attack is still = useful though. 5.2. HIP Parameters The HIP Parameters are used to carry the public key associated with the sender's HIT, together with related security and other information. Considering the amount of different things carried in HIP Parameters = today, this section could start with a more generic description of the = use of the parameters ("and other information" sounds a bit = understatement). Can't come up with the right words for now, but would = be good to have something that would explain that Parameters are used to = carry the security stuff, but are also one of the main ways for = extending HIP. | R1_COUNTER | 128 | 12 | System Boot Counter | The data description does not seem to match other descriptions of = R1_COUNTER. | HIP_CIPHER | 579 | variable | HIP encryption | | | | | algorithm | s/HIP encryption algorithm/List of HIP encryption algorithms/ | ENCRYPTED | 641 | variable | Encrypted part of I2 | | | | | packet | ENCRYPTED could be also in other packets than just I2, right? | CERT | 768 | variable | HI Certificate; used | Also this text regarding certificates should be updated. | ECHO_RESPONSE_SIGNED | 961 | variable | Opaque data echoed | | | | | back; under signature | s/echoed back/echoed back by request/ Also "covered by signature", or "signed" could be better than "under = signature" (also in ECHO_REQ_SIGNED). | 2048 - 4095 | Parameters related to HIP transport types | s/transport types/transport formats/ (to be consistent with the later text) 5.2.1. TLV Format The type-field value also describes the order of these fields in the packet, except for type values from 2048 to 4095 which are reserved for new transport forms. This is a bit strange exception. I wonder if it would make sense to make = this consistent with the other ordered lists, i.e., have one parameter = that lists the supported transport formats and then, depending on which = format was chosen, the corresponding parameter(s) from this range are = used (and others ignored).=20 Also: s/order of these fields/order of these parameters/ s/transport forms/transport formats/ If the parameter can exist multiple times in the packet, the type value may be the same in consecutive parameters.=20 This could rather be formatted as a normative requirement (and then it = would be also implicit for the responder). Something like: If the parameter can exist multiple times in the packet, the parameters with the same type MUST be consecutive in the packet. 5.2.2. Defining New Parameters Implementations operating in a mode adhering to this specification MUST disable the sending of new critical parameters. This sounds a bit strange. Should that be "MUST allow disabling"? 5.2.3. R1_COUNTER The sender is supposed to increment this counter periodically. s/is supposed to increment/increments/ or "SHOULD increment" 5.2.6. DIFFIE_HELLMAN The 160-bit ECP group can be used when lower security is enough (e.g., web surfing) and when the equipment is not powerful enough (e.g., some PDAs). Should mention which Group ID the 160-bit ECP is (I'd assume 10, but = it's not explicit). Also, some general recommendation on the order of proposed group IDs = would be helpful so that implementations don't end up (unnecessarily) = proposing the weakest groups by default. 5.2.7. HIP_CIPHER Cipher ID defines the cipher algorithm to be used for encrypting parts of the HIP packet Is HIP_CIPHER used anywhere else except in the ENCRYPTED parameter? If = not, the explanation above could say that explicitly. That is, for = example, s/parts of the HIP packet/the contents of the ENCRYPTED parameter/ NULL-ENCRYPTION is included for testing purposes. NULL-ENCRYPTION SHOULD NOT be configurable via the UI. There may be no UI for the implementation, so could say "by the user" = instead of "via the UI". 5.2.8. HOST_ID DI-type type of the following Domain Identifier field Domain Identifier the identifier of the sender The actual content of these fields is not clear from the text. Could at = least move the DI-types table closer to the figure. Also, "DI Length" = could simply say "length (in octets) of the Domain Identifier field"; = the FQDN and NAI part just confuses here. If there is no Domain Identifier, i.e., the DI-type field is zero, the DI Length field is set to zero as well. Should there be some normative text on when to have the domain = identifier? 5.2.10. DH_GROUP_LIST The information in the DH_GROUP_LIST allows the Responder to select the DH group preferred by itself and the Initiator. s/and the Initiator/and supported by the Initiator/ 5.2.13. HIP_SIGNATURE The signature algorithms are defined in Section 5.2.8. The algorithm identifier field side for HOST_ID (Section 5.2.8) is 16 = bits whereas here it is 8 bits. Something wrong here?=20 Could also reference to exact table with the algorithms since section = 5.2.8 has 4 different tables. Sections 5.2.15 and 5.2.16 (SEQ and ACK)=20 Figures, and their Length descriptions are not consistent although, = AFAIK, the format of the parameters is identical. 5.2.16. ACK The Length field identifies the number of peer Update IDs that are present in the parameter. This is a bit misleading. Could say something like "number of peer = Update IDs can be inferred from the length by dividing it by 4" 5.2.17. ENCRYPTED Encrypted The data is encrypted using an encryption algorithm data as defined in the HIP_CIPHER parameter. s/an encryption algorithm as defined in/the encryption algorithm defined = by/ 5.2.18. NOTIFICATION Padding any Padding, if necessary, to make the parameter a multiple of 8 bytes. This is the first parameter to explicitly define padding after the = figure (not consistent). Also, base text says that padding MUST be zero, = but here it says "anything will do". Would suggest removing this = altogether. Notification information can be error messages specifying why an SA First occurrence of SA. Expand, and maybe add a reference too. Overall, this section is fairly inconsistent with the use of different = ways to refer to "Notify Message Type", some suggestions for change: The table below lists the Notification messages and their corresponding values. s/Notification messages/Notify Message Types/ Types in the range 0-16383 are intended for reporting errors and in s/Types/Notify Message Types/ An implementation that receives a NOTIFY packet with a NOTIFICATION error parameter in response to a request packet s/NOTIFICATION error parameter/(something)/ Notify payloads with status types MUST be ignored if not recognized. s/Notify payloads with status types/Notification Data in NOTIFICATION = parameters with status Notify Message Types/ NOTIFICATION PARAMETER - ERROR TYPES Value s/NOTIFICATION PARAMETER - ERROR TYPES/Notify Message Types - Errors/ (or why not in all-caps, if that looks better) NOTIFY MESSAGES - STATUS TYPES Value s/NOTIFY MESSAGES - STATUS TYPES/Notify Message Types - Status/ UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1 Sent if the parameter type has the "critical" bit set and the parameter type is not recognized. Notification Data contains the two-octet parameter type. What if there are multiple unsupported critical parameter types? Should = send multiple NOTIFICATIONs of this Message Type or would it be better = to concatenate the types? INVALID_SYNTAX 7 Indicates that the HIP message received was invalid because some type, length, or value was out of range or because the request was rejected for policy reasons.=20 Rejecting message with "invalid syntax" code due to policy reasons = sounds strange. Isn't the type "BLOCKED_BY_POLICY" for that purpose? = Could change that policy text to: "[...] or the message was otherwise = malformed". 5.2.19. ECHO_REQUEST_SIGNED A HIP packet can contain only one ECHO_REQUEST_SIGNED or ECHO_REQUEST_UNSIGNED parameter. =20 s/can/MUST/ ? 5.2.20. ECHO_REQUEST_UNSIGNED HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. It is possible that middleboxes add ECHO_REQUEST_UNSIGNED parameters in HIP packets passing by.=20 This seems to contradict with the previous section (see above). The sender has to create the Opaque field so that it can later identify and remove the corresponding ECHO_RESPONSE_UNSIGNED parameter. Does this apply also to middleboxes, i.e., is "sender" the sender of the = packet or sender of the parameter? 5.3.1. I1 - the HIP Initiator Packet IP ( HIP ( DH_GROUP_LIST ) ) This is not strictly consistent with the notation definition "X(y) = indicates that y is a parameter of X" (HIP stuff is not really a = parameter of IP packet). I'm not entirely sure how to fix this though = (or if it even needs to be fixed). The Initiator receives the Responder's HIT either from a DNS lookup of the Responder's FQDN,=20 Add here a reference to 5205-bis. 5.3.2. R1 - the HIP Responder Packet The Initiator's HIT MUST match the one received in the I1 packet.=20 ...if the R1 is sent due to I1.=20 Re-using Diffie-Hellman public keys opens up the potential security risk of more than one Initiator ending up with the same keying s/public keys/public values/ ? (same in next paragraph) If a future version of this protocol is considered, we strongly recommend that these issues be studied again. Has anyone looked into this? The signature is calculated over the whole HIP envelope "HIP envelope" is not defined anywhere (but used many times after this = occurrence too). Perhaps add it to the definitions part. 5.3.3. I2 - the Second HIP Initiator Packet The HITs used MUST match the ones used previously. This is ambiguous. Should that be "used in R1" or are there also other = possibilities? The HIP_CIPHER contains the single encryption transform selected by the Initiator, that it uses to encrypt the ENCRYPTED parameter. s/the ENCRYPTED parameter/ENCRYPTED parameters/ (The ENCRYPTED parameter is optional here, but may be sent later, = right?) 5.3.5. UPDATE - the HIP Update Packet An UPDATE that does not contain a SEQ parameter is simply an acknowledgment of a previous UPDATE and itself MUST NOT be acknowledged by a separate ACK. What about UPDATE without ACK nor SEQ? Unreliable UPDATE or a protocol = error? 5.3.7. CLOSE - the HIP Association Closing Packet The receiver peer MUST validate the ECHO_RESPONSE_SIGNED and validate both the HIP_MAC and the signature if it has state for a HIP association, The ECHO_RESPONSE_SIGNED is only in the CLOSE_ACK. I assume this is not = just a typo, since there's not much to validate in the request, right? = Also, could be more explicit about who the state is with. 5.3.8. CLOSE_ACK - the HIP Closing Acknowledgment Packet The receiver peer MUST validate both the HMAC and the signature. ...and the contents of the ECHO_RESPONSE? 5.4.1. Invalid Version pointing to the VER./RES. byte in the HIP header. If you change the "VER." field (as suggested in the beginning of this = mail), remember to change it also here. 6.1. Processing Outgoing Application Data The exact format and method for transferring the data from the source s/the data/the user data/ (this does not apply to HIP packets) 6.4.1. HMAC Calculation 6. Set Checksum and Header Length field in the HIP header to original values. This could be just an implementation issue, but unless the signatures = and MACs are also restored, the length and checksum are invalid after = this step. Is this step even needed? 6.5. HIP KEYMAT Generation HIP-gl encryption key for HOST_g's outgoing HIP packets HIP-gl integrity (HMAC) key for HOST_g's outgoing HIP packets It's a bit confusing to use the same "key name" twice (same for -lg). I = assume "outgoing HIP packets" means the ENCRYPTED parameter? If so, = could say it explicitly. HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP packets Why HOST_l's key is not used if either Initiator or Responder may end up = being the HOST_l? 6.7. Processing Incoming I1 Packets 2. If the Responder is in ESTABLISHED state, the Responder MAY respond to this with an R1 packet, prepare to drop existing SAs, Should prepare to drop only the SAs one has with the I1's sender? Other than that, selecting the HIT is a local policy matter. Shouldn't the Responder use the same as HIT the Initiator used for it? = This would otherwise break section 6.8 step 3. 6.8. Processing Incoming R1 Packets 7. The system MUST check that the DH Group ID in the DH parameter s/DH parameter/DIFFIE_HELLMAN parameter/=20 (twice in this step) 6.9. Processing Incoming I2 Packets Hellman key, decrypting the Initiator's Host Identity, verifying the s/decrypting/possibly decrypting/ (if it's not within ENCRYPTED parameter; also in step 11) 7. If the system's state machine is in any other state than R2- SENT, the system SHOULD check that the echoed R1 generation counter in the I2 packet is within the acceptable range. ...if the counter is included 6.10. Processing of Incoming R2 Packets If an R2 packet is received in state I2-SENT, it SHOULD be processed. When would it be appropriate to *not* process the R2 in I2-SENT state? = This looks like a MUST to me. 2. The system MUST verify that the HITs in use correspond to the HITs that were received in the R1 packet. "..that caused the transition to the I1-SENT state"=20 i.e., not just any R1 6.14. Processing CLOSE Packets The HIP association is not discarded before the host moves from the UNASSOCIATED state. s/from/to/? 6.15. Processing CLOSE_ACK Packets A host can map CLOSE messages to CLOSE_ACK messages by using the included ECHO_RESPONSE_SIGNED in response to the sent ECHO_REQUEST_SIGNED in the CLOSE_ACK. s/using/matching/ And the end of the sentence seems to be incorrect anyway (REQ is not in = ACK). Could rephrase the whole sentence. The CLOSE_ACK contains the HIP_MAC and the SIGNATURE for s/and the SIGNATURE/and SIGNATURE parameters/ 7. HIP Policies Initiators may use a different HI for different Responders to provide basic privacy. Such implementations SHOULD keep state for mapping Initiator's HIT to Responder's HIT. This access control list (ACL) SHOULD also include preferred transform and local lifetimes. This sounds a bit ambiguous. Why is the mapping needed? What are the = lifetimes? Why store the preferred transform? The value of K used in the HIP R1 packet can also vary by policy. K should never be greater than 20, but for trusted partners it could be as low as 0. s/should never/SHOULD NOT/ Also, why 20? Some rough number on "how much is 20" could be helpful. = How about, say, 10 years from now, is 20 that big still then or should = we comment something on adjusting the maximum value in the future? Or = will it be HIP v3 by then? :) 10. IANA Considerations This document also creates a set of new namespaces. These are described below. Do we create new namespaces for v2 or should we re-use the existing = ones? HIP Version At least this namespace we shouldn't redefine (but e.g., HIP Suite we = should). Group ID New values either from the reserved or unassigned space are assigned through IETF Consensus. What are these spaces? Is "0" the "reserved space"? Same with CIPHER_ID. Notify Message Type values 1-10 are used for informing about errors in packet structures, values 11-20 for informing about problems in parameters [...] This text could be more helpful in the NOTIFICATION section. That's all for now. More nits coming off-lists. Cheers, Ari= From ari.keranen@nomadiclab.com Fri Feb 4 05:37:59 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 165813A68F6 for ; Fri, 4 Feb 2011 05:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IbjeHxPr5fJ for ; Fri, 4 Feb 2011 05:37:57 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id D58643A6911 for ; Fri, 4 Feb 2011 05:37:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 6969A4E6D7; Fri, 4 Feb 2011 15:41:20 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miQqyzE+MQ7U; Fri, 4 Feb 2011 15:41:19 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 01CBE4E6BC; Fri, 4 Feb 2011 15:41:19 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ari Keranen In-Reply-To: Date: Fri, 4 Feb 2011 15:41:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <715A0CB5-5AAC-453F-B631-7BEFBF4DB81C@nomadiclab.com> References: To: Tobias Heer X-Mailer: Apple Mail (2.1082) Cc: hipsec@ietf.org Subject: Re: [Hipsec] rfc5201-bis-04 review X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 13:37:59 -0000 Hi Tobi, Responses inline. On Feb 3, 2011, at 3:55 PM, Tobias Heer wrote: > Am 27.01.2011 um 18:13 schrieb Ari Keranen: >>=20 >> Since we are specifying the version 2 of the protocol, should we say = that in the title and abstract? >>=20 >=20 > I think we should. I guess we would have to add "Version 2" to the = title at least. Other comments? I would probably do like they did for IKEv2: = http://tools.ietf.org/html/rfc5996 >> 1.2. The HIP Base Exchange (BEX) >>=20 >> It >> should be noted, however, that both the Initiator's and the >> Responder's HITs are transported as such (in cleartext) in the >> packets, allowing an eavesdropper with a priori knowledge about the >> parties to identify them by their HITs. Hence, encrypting the HI of >> any party does not provide privacy against such attacker. >>=20 >> This text goes fairly deep into a specific attack and could better = fit to the Security Considerations section than in the introduction. >>=20 >>=20 > I think it needs to be there to understand the reasons and = implications of using HIP before mechanisms like the ENCRYPTED parameter = are introduced. I would prefer it to be there rather than in the SC = section. OK, makes sense. >> Data packets start to flow after the 4th packet. The 3rd and 4th HIP >> packets may carry a data payload in the future. However, the details >> of this may be defined later. >>=20 >> s/may be defined later/are not defined for the time being/ >>=20 > May be defined foe HIP Version 2 later? So far the data packets are = defined for HIPv1. But not for I2/R2, as discussed in the text above, right? >> 3.2. Generating a HIT from an HI >>=20 >> The HIT MUST be generated according to the ORCHID generation method >> described in [I-D.ietf-hip-rfc4843-bis] using a context ID value of >> 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA >>=20 >> Should one say something about the byte order of the value? >>=20 > Is there a byte order problem here at all? These are all single-byte = values concatenated to a multi-byte string. Byte order is a problem for = multi-byte values. We don't have these here. Am I missing something = here? OK, if it's just a set of single-byte values, that should work. >> 4.1. Creating a HIP Association >>=20 >> By definition, the system initiating a HIP exchange is the Initiator, >> and the peer is the Responder. This distinction is forgotten once >> the base exchange completes, and either party can become the >> Initiator in future communications. >>=20 >> Would one call a host making a HIP transaction (say, UPDATE) during = an active HIP association an Initiator? The text seems to imply that, = but at least I would not have used that term in that case.=20 >>=20 > it would be the initiator of the transaction but not the Initiator = (note the capital I).=20 OK, so the text above should change s/the Initiator in/an initiator in/ = ? Or would it be more clear to say "[...]either party can initiate future = communications"? >> The base exchange is illustrated below >>=20 >> The figure should be numbered (,center-aligned), and referenced with = the number. Bit surprisingly, none of the figures in the draft are = numbered. >=20 > I'll see how to get this done. There are only two real figures anyway = - this should be a quick fix.=20 I tend to label also all "message format figures" Figures because it = makes it easier to reference to them in the text. That said, 5201 seems = to have survived without that convention, so maybe it's OK. >> 4.1.1. HIP Puzzle Mechanism >>=20 >> The puzzle mechanism has been explicitly designed to give space for >> various implementation options. First, it allows a Responder >> implementation to completely delay session-specific state creation >> until a valid I2 packet is received. In such a case, a correctly >> formatted I2 packet can be rejected immediately once the Responder >> has checked its validity by computing only one hash function. >>=20 >> Why is a correctly formatted I2 rejected? Because of incorrect = solution? >>=20 > Yes... the correct packet format is not the main point here: >=20 > In such a case, a correctly formatted I2 packet > without valid puzzle solution can be rejected immediately > once the Responder has checked the solution by computing > only one hash function.=20 OK, looks better. Just: s/valid puzzle/a valid puzzle/ >>=20 >> Second, the design also allows a Responder implementation to keep >> state about received I1 packets, and match the received I2 packets >> against the state, thereby allowing the implementation to avoid the >> computational cost of the hash function.=20 >>=20 >> It's not clear what this means (how one avoids the cost by matching). >>=20 > I think it misses the point of proving that the Initiator or attacker = has churned cycles. > Optimizing away the singular hash function application does not seem = worth the effort anyway. >=20 > I would rephrase or remove the text completely. >=20 >=20 > We could write something like: >=20 > The puzzle allows a Responder implementation to completely > delay session-specific state creation until a valid I2 > packet is received. An I2 packet without valid puzzle > solution can be rejected immediately once the Responder > has checked the solution by computing only one hash > function before state is created and CPU-intensive > public-key signature verification and Diffie-Hellman key > generation are performed. By varying the difficulty of the > puzzle, the Responder can frustrate CPU or memory targeted > DoS attacks. >=20 > Any opinion? Looks good to me. I would use something else than "frustrate" though; = but can't come up with any better text right now. >=20 >> NOTE: The protocol developers explicitly considered whether a memory >> bound function should be used for the puzzle instead of a CPU-bound >> function. The decision was not to use memory-bound functions. >>=20 >> A few words of rationale for not using memory-bound functions would = be nice. >>=20 > The rationale was that the first document deferred the decision and no = good points _for_ memory-bound puzzles were presented. > I think writing that down here will not help much. >=20 I think even that would be actually helpful. Something like " [...] = CPU-bound function, but so far no {compelling arguments | proper uses = cases | something else} for using memory-bound functions have been = presented."=20 Although, I guess memory bound functions would be useful in *some* use = cases, so perhaps we could leave that as an option for extension? That = is, instead of PUZZLE parameter, there could be PUZZLE_MEM parameter = that has different kind of puzzle? >>=20 >> The signature of the I2 >> message covers all signed parameters of the packet without exceptions >> as in the R1. >>=20 >> Saying "all signed parameters are signed" sounds a bit redundant. And = what would be an exception to this rule? >>=20 > I'd change it into: >=20 > The > signature of the I2 message covers all parameters of the > signed parameter ranges (see [ref]) in > the packet without exceptions as in the R1. >=20 > The exceptions are named when the SIGNATURE_2 and HIP_MAC2 are = discussed. Discussing the specific exceptions here would distract the = reader, I think. OK, now I get the point of exceptions. The proposed text looks good to = me. Just add commas around "without exceptions". >>=20 >> 4.1.4. HIP Replay Protection >>=20 >> The scope of the >> counter MAY be system-wide but SHOULD be applied per Host Identity, >> if there is more than one local host identity. >>=20 >> What "applied per Host Identity" means is not clear. Could be "every = HI must have its own counter" or "every HI must use the same counter and = increase it at every usage". >>=20 >=20 > The first one. I'll change it to: >=20 > The scope of the counter MAY be system-wide but there SHOULD > be a separate counter for each Host Identity, if > there is more than one local host identity.=20 Thanks, this is much clearer. >=20 >>=20 >> Implementations MUST accept puzzles from the current >> generation and MAY accept puzzles from earlier generations. >>=20 >> Could give some recommendation on how many earlier generations SHOULD = be accepted (otherwise one may conclude that any earlier is always OK). >>=20 > Any earlier may be okay.... however this really depends on the choice = of the duration for which the R1 counter is current and the probability = or possibility of misuse (including the choice of I and the opaque data = field in the puzzle). >=20 > Giving some exact value is difficulty without knowing the = implementation details here. OK, if any earlier can be used, this doesn't sound like a big problem. >=20 >>=20 >> 4.1.5. Refusing a HIP Exchange >>=20 >> A HIP-aware host may choose not to accept a HIP exchange. If the >> host's policy is to only be an Initiator, it should begin its own HIP >> exchange. A host MAY choose to have such a policy since only the >> privacy of the Initiator's HI is protected in the exchange. It >> should be noted that such behavior can introduce the risk of a race >> condition if each host's policy is to only be an Initiator, at which >> point the HIP exchange will fail. >>=20 >=20 [...] >=20 >> Also, should there be some mechanism to detect and prevent the race = situation continuing forever? >>=20 > At this point, the hosts have incompatible policies and cannot = communicate. The text concludes that the HIP base exchange will fail in = that case. Do you think this needs further elaboration in the text? I think so. I'm not concerned of the fact that they can't communicate, = but that they will end up trying to Initiate the BeX, and eventually = I1-DoS:ing each other, indefinitely. >=20 >> 4.4.3. HIP State Processes >>=20 >> | Receive I2, process | If successful, send R2 and go to R2-SENT | >>=20 >> What does "process" mean here? (same in the other tables) Should that = be "receive and process"? And what is the difference compared to = triggers without "process" (e.g., with receiving I1s and in Table 6)? >=20 > We could remove the process and say "If processing is successful, send = R2 and go to R2-SENT"... That might make it clearer. Agreed? Agreed. >=20 >> Table 3 (I1-SENT) >>=20 >> | Receive I1 | If the local HIT is smaller than the peer | >> | | HIT, drop I1 and stay at I1-SENT | >>=20 >> s/Receive I1/Receive I1 from the peer/ >> Or maybe could explain before the table that "Receive X" means here = receiving from a peer one is setting up a HIP SA with -- or does it? > I think "Receive I1 from Responder" would be best. Because from the = perspective of the Initiator (who is in state I1-sent) the Responder = sends an I1. Agreed (but just say "the Responder" to make it clear it's not just any = host), >=20 >>=20 >> Table 5: R2-SENT - Waiting to finish HIP >> and >> Table 6: ESTABLISHED - HIP association established >>=20 >> What to do if some other HIP message arrives? Probably with message = types not specified in this document that's extension-specific, but = could mention it somewhere here. Also, Table 5 doesn't have CLOSE_ACK. > I changed the sentence in the introduction of the state machine from: >=20 > New states may be introduced by mechanisms in other > specifications (such as mobility and multihoming). >=20 > to >=20 > New states and state transitions may be introduced by mechanisms in = other > specifications (such as mobility and multihoming). >=20 > I guess that covers additional procedures for extensions quite well. OK, but what I actually meant was that there's no ANYOTHER here like in = the other tables.=20 >> Table 5: R2-SENT - Waiting to finish HI > it should contain "CLOSE_ACK -> Drop and stay at R2-SENT" because no = CLOSE, and therefore, no echo request was sent. Validating the echo will = fail anyway. Sounds good. >> Table 7: CLOSING - HIP association has not been used for UAL = minutes/CLOSING - HIP association has not been used for UAL minutes >>=20 >> | Timeout, increment | If timeout sum is less than UAL+MSL | >> | timeout sum, reset | minutes, retransmit CLOSE and stay at | >> | timer | CLOSING | >>=20 >> This trigger's definition is not particularly clear. >>=20 > This is because it intermingles the action (increment timeout sum, = reset timer) into the trigger. I'll separate these: >=20 > | Timeout | Increment timeout sum and reset timer. If = | > | | timeout sum is less than UAL+MSL minutes, = | > | | retransmit CLOSE and stay at CLOSING = | > | | = | > | | If timeout sum is greater than UAL+MSL = | > | | minutes, go to UNASSOCIATED = | > = +---------------------+---------------------------------------------+ Much better. >>=20 >>=20 >> 4.5.2. Sending Data on HIP Packets >>=20 >> A future version of this document may define how to include user data >> in various HIP packets. However, currently the HIP header is a >> terminal header, and not followed by any other headers. >>=20 >> Do we plan to do this in a future version of *this* document or would = that be better left for some other document? >>=20 > I think other is more accurate given the developments regarding the = sending of user data in overlays, etc. Sounds reasonable; could change the text accordingly. Cheers, Ari= From rgm@htt-consult.com Sun Feb 6 05:48:28 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567203A68C6; Sun, 6 Feb 2011 05:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iET5L2yA9lKv; Sun, 6 Feb 2011 05:48:27 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 3A38F3A6778; Sun, 6 Feb 2011 05:48:27 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 45FB662A76; Sun, 6 Feb 2011 13:47:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-iAZ0YcchoZ; Sun, 6 Feb 2011 08:47:36 -0500 (EST) Received: from nc2400.htt-consult.com (ip212-238-40-185.hotspotsvankpn.com [212.238.40.185]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id CA71D62A45; Sun, 6 Feb 2011 08:47:34 -0500 (EST) Message-ID: <4D4EA667.2050102@htt-consult.com> Date: Sun, 06 Feb 2011 14:47:19 +0100 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Internet-Drafts@ietf.org References: <20100820164502.005F03A6937@core3.amsl.com> In-Reply-To: <20100820164502.005F03A6937@core3.amsl.com> Content-Type: multipart/alternative; boundary="------------090508040302060109080404" Cc: hipsec@ietf.org Subject: Re: [Hipsec] I-D ACTION:draft-ietf-hip-rfc5203-bis-00.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 13:48:28 -0000 This is a multi-part message in MIME format. --------------090508040302060109080404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This draft is NOT available. I get a 404 page not found. On 08/20/2010 06:45 PM, 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 (HIP) Registration Extension > > Author(s) : J. Laganier, T. Koponen, L. Eggert > Filename : draft-ietf-hip-rfc5203-bis-00.txt > Pages : 12 > Date : > > This document specifies a registration mechanism for the Host > Identity Protocol (HIP) that allows hosts to register with services, > such as HIP rendezvous servers or middleboxes. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5203-bis-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec --------------090508040302060109080404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This draft is NOT available.

I get a 404 page not found.

On 08/20/2010 06:45 PM, 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 (HIP) Registration Extension

	Author(s)	: J. Laganier, T. Koponen, L. Eggert
	Filename	: draft-ietf-hip-rfc5203-bis-00.txt
	Pages		: 12
	Date		: 
	
This document specifies a registration mechanism for the Host
   Identity Protocol (HIP) that allows hosts to register with services,
   such as HIP rendezvous servers or middleboxes.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5203-bis-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec
--------------090508040302060109080404-- From julien.ietf@gmail.com Sun Feb 6 10:20:59 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 061BE3A69AF; Sun, 6 Feb 2011 10:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvVjbySpMUrx; Sun, 6 Feb 2011 10:20:57 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 667643A6949; Sun, 6 Feb 2011 10:20:57 -0800 (PST) Received: by fxm9 with SMTP id 9so4423943fxm.31 for ; Sun, 06 Feb 2011 10:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LNcUC9edIktuRVHSSPQLcjSsz4bUl2ttRt5vm4li28E=; b=EH5Viz0QKNp2k4S9DOvgTYjxYrCrdkryz/JQWJc/wfRVO434c4fOUotRXxH2hl3l5V MTZwlpsiZBljaoKJkaLyKyu75XPrO4UBJJ0scNRG1ffv2jfmZzARB2RxUp0Wq/m76Xrh 39F/Htw+Xhocpq4Bbb0Myo5ljm0PpbBsn7Qtc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sEDunOD3WK0SzCXOii05M/pF+zy/mF2HMmXusO72HSvWiDfK6ycntqeIgoJhBgJHkL vVnL69V0BKJ/m0hcQ4uuFKu2WXLH2XuejIJnck/CvWSvCSNodtenGq3qnDjOwvs6+VZi 4SegSp4XlML4YuFRsugtTXikhsKP7CBYQhwRY= MIME-Version: 1.0 Received: by 10.103.220.10 with SMTP id x10mr9932570muq.93.1297016458335; Sun, 06 Feb 2011 10:20:58 -0800 (PST) Received: by 10.103.221.9 with HTTP; Sun, 6 Feb 2011 10:20:58 -0800 (PST) In-Reply-To: <4D4EA667.2050102@htt-consult.com> References: <20100820164502.005F03A6937@core3.amsl.com> <4D4EA667.2050102@htt-consult.com> Date: Sun, 6 Feb 2011 10:20:58 -0800 Message-ID: From: Julien Laganier To: Robert Moskowitz Content-Type: text/plain; charset=ISO-8859-1 Cc: hipsec@ietf.org, Internet-Drafts@ietf.org Subject: Re: [Hipsec] I-D ACTION:draft-ietf-hip-rfc5203-bis-00.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 18:20:59 -0000 I find it on the tools webpage though: http://tools.ietf.org/html/draft-ietf-hip-rfc5203-bis-00 On Sun, Feb 6, 2011 at 5:47 AM, Robert Moskowitz wrote: > This draft is NOT available. > > I get a 404 page not found. > > On 08/20/2010 06:45 PM, 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 (HIP) Registration Extension > > Author(s) : J. Laganier, T. Koponen, L. Eggert > Filename : draft-ietf-hip-rfc5203-bis-00.txt > Pages : 12 > Date : > > This document specifies a registration mechanism for the Host > Identity Protocol (HIP) that allows hosts to register with services, > such as HIP rendezvous servers or middleboxes. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5203-bis-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > From rgm@htt-consult.com Sun Feb 6 11:55:31 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A153A697E for ; Sun, 6 Feb 2011 11:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL+uORs0hpxF for ; Sun, 6 Feb 2011 11:55:30 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id EF56D3A68FA for ; Sun, 6 Feb 2011 11:55:29 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id DA11362A83; Sun, 6 Feb 2011 19:55:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGXtHWpA7ooU; Sun, 6 Feb 2011 14:54:38 -0500 (EST) Received: from nc2400.htt-consult.com (ip212-238-40-185.hotspotsvankpn.com [212.238.40.185]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 70D3D62A76; Sun, 6 Feb 2011 14:54:37 -0500 (EST) Message-ID: <4D4EFC77.3050006@htt-consult.com> Date: Sun, 06 Feb 2011 20:54:31 +0100 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Julien Laganier References: <20100820164502.005F03A6937@core3.amsl.com> <4D4EA667.2050102@htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] I-D ACTION:draft-ietf-hip-rfc5203-bis-00.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 19:55:31 -0000 On 02/06/2011 07:20 PM, Julien Laganier wrote: > I find it on the tools webpage though: > > http://tools.ietf.org/html/draft-ietf-hip-rfc5203-bis-00 Thanks. I have a copy now... > On Sun, Feb 6, 2011 at 5:47 AM, Robert Moskowitz wrote: >> This draft is NOT available. >> >> I get a 404 page not found. >> >> On 08/20/2010 06:45 PM, 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 (HIP) Registration Extension >> >> Author(s) : J. Laganier, T. Koponen, L. Eggert >> Filename : draft-ietf-hip-rfc5203-bis-00.txt >> Pages : 12 >> Date : >> >> This document specifies a registration mechanism for the Host >> Identity Protocol (HIP) that allows hosts to register with services, >> such as HIP rendezvous servers or middleboxes. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5203-bis-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> >> From rgm@htt-consult.com Tue Feb 8 02:48:55 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11C123A7081 for ; Tue, 8 Feb 2011 02:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAFF3B+ISfPO for ; Tue, 8 Feb 2011 02:48:54 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 023283A70DA for ; Tue, 8 Feb 2011 02:48:53 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 6D40E62A75 for ; Tue, 8 Feb 2011 10:48:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIBKpFPAfMtb for ; Tue, 8 Feb 2011 05:48:21 -0500 (EST) Received: from nc2400.htt-consult.com (unknown [89.248.128.101]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 62DBA62A2E for ; Tue, 8 Feb 2011 05:48:21 -0500 (EST) Message-ID: <4D511F73.10001@htt-consult.com> Date: Tue, 08 Feb 2011 11:48:19 +0100 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Hipsec] Fundamental ECC now an RFC X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 10:48:55 -0000 http://www.rfc-editor.org/rfc/rfc6090.txt We will update 5201-bis accordingly. Meanwhile I would like to get some code size estimations for ECDSA and ECDH using RFC 6090. I have been asked this by sensor developers. From heer@informatik.rwth-aachen.de Fri Feb 11 03:23:52 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22AE3A694F for ; Fri, 11 Feb 2011 03:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-EpzqJidx6c for ; Fri, 11 Feb 2011 03:23:50 -0800 (PST) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 6C8723A6947 for ; Fri, 11 Feb 2011 03:23:50 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LGG00GBWAC32WB0@mta-1.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Fri, 11 Feb 2011 12:24:03 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,454,1291590000"; d="scan'208";a="93663346" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 11 Feb 2011 12:24:04 +0100 Received: from umic-i4-137-226-45-197.nn.rwth-aachen.de ([unknown] [137.226.45.197]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LGG008Q0AC3C570@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Fri, 11 Feb 2011 12:24:03 +0100 (CET) From: Tobias Heer In-reply-to: Date: Fri, 11 Feb 2011 12:24:03 +0100 Message-id: <6C39D444-8FDE-40E9-927A-F570224EFC23@cs.rwth-aachen.de> References: To: Jeffrey M Ahrenholz X-Mailer: Apple Mail (2.1082) Cc: hipsec@ietf.org Subject: Re: [Hipsec] more comments on draft-ietf-hip-rfc5201-bis-04 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 11:23:52 -0000 Hi Jeff, thanks for the comments. See my responses in line. Am 24.01.2011 um 22:31 schrieb Ahrenholz, Jeffrey M: > Here are some additional comments on the 5201-bis draft. > > Section 5.4.2 says: > "However, an implementation MUST NOT send an ICMP message if the checksum fails; instead, it MUST silently drop the packet." If we MUST silently drop a packet, why do we have NOTIFY type 26, "CHECKSUM_FAILED"? (Debugging?) Hmmm good question. This was already that way in RFC5201-bis. I think we have three options here: a) go for "SHOULD silently drop". Implementors could use the notify if they have a good reason to do so. b) remove the NOTIFY type 26 c) state that is for debugging purposes only and sending notifies for malformed checksums MUST be turned off by default. I don't have a strong preference on either of the solutions. Any comments from the group? > > Section 6.11 item 4: this says the association is considered broken if an > UPDATE is not ACKed, but one circumstance where the association is NOT broken > would be when a host is informing its peer of its current address list > (without changing the current preferred locators used.) In that case, the > association may continue happily without going to CLOSING. > Well, the payload channel might be still functional in that case. However, the missing ACK on the control channel is certainly a sign that something is wrong with the HIP association. I think if the problem persists (sender of the update keeps retransmitting the update with the seq and receiver does not acknowledge it) it indicates that the HIP channel is broken. Trying to re-establish the connection (by first closing it and then doing another BEX (because user data is still coming) might be the best choice here. Am I missing something here? > Below are more minor editorial nits... > > -Jeff > > > 5.2.4, 5.2.5 - suggest changing "n bytes" in parameter diagram to "n bits" > the descriptions that follow (for random #I, solution #J) discuss n-bit > integers, and RHASH_len is stated as a bit length > All parameter descriptions are given in bytes. I think going to bits in that single case would confuse people, don't you think? On the other hand, security-related discussions (as for hash functions, etc.) mostly refer to bits in literature. So I wouldn't want to change that here either. We could try to untangle a bit by not reusing the quantity n as bit and bytes, though. We could just refer to RHASH_len/8 bytes for I and J: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K, 1 byte | Lifetime | Opaque, 2 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random #I, RHASH_len/8 bytes | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | K, 1 byte | Reserved | Opaque, 2 bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random #I, n bytes | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Puzzle solution #J, RHASH_len/8 bytes | / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > in 5.3.2 > To support the "i" used in the diagram, may want to add > a note about multiple ECHO_REQUEST_UNSIGNEDs as described in 5.2.20 with text such as: > "The R1 packet may contain zero or more ECHO_REQUEST_UNSIGNED parameters as > described in Section 5.2.20." > Thanks, Done. > Then in 5.3.3 may change s/parameter/parameter(s)/ to support the > "i" diagram notation. Done. > > in 5.3.7 and 9 > s/an HIP_MAC/a HIP_MAC/ > (for consistency with "a HIP..." elsewhere in the document) Done. > > 5.3.8, suggest changing: > "The receiver peer MUST validate both the HMAC and the signature." > to: > "The receiver MUST verify the echo response and validate both the HIP_MAC and the signature." > (because 5.3.7 says you MUST include the ECHO_REQUEST_SIGNED) Good catch! Done. > > Section 6.4.1 s/SAH-1/SHA-1/ > Oops. Done. > Section 6.7 s/the Responder a HIT with/the Responder selects a HIT with/ > Done. > Section 6.8 item 6 s/a Initiator/an Initiator/ > Fixed it. > Section 5.3.2 and 6.8 item 7 s/SHOULD not/SHOULD NOT/ > Done. I checked for other SHOULD not as well. There were a few. > Section 6.9 item 12 s/packet I2/I2 packet/ Done. > Section 6.9 item 13 s/verify the HMAC/verify the HIP_MAC/ for consistency? > (elsewhere, "verify the HIP_MAC" is used) Good catch. Done. > > Section 6.11 s/steps below ./steps below./ > Done. > Section 6.11 item 2: support multiple ACKs? > replace: > "The UPDATE packet MAY also include an ACK of the peer's Update > ID found in a received UPDATE SEQ parameter, if any." > with: > "The UPDATE packet MAY also include zero or more ACKs of the peer's Update > ID(s) from previously received UPDATE SEQ parameter(s)." > Done. Thanks for providing alternative text. > Section 7 > suggest defining the first occurrence of ACL: > "This access control list (ACL) SHOULD also include..." > Done. > s/representing which hosts/representing for which hosts/ Done. > s/for such ACL also/for such ACLs, and also/ ? Done. > > Appendix C.2 suggest re-wording slightly: > "The IPv4 checksum value for the example I1 packet equals the IPv6 checksum > value (since the checksum components due to the IPv4 and IPv6 pseudo-header are the same)." > Done. Again, thanks for the alternative text. > Appendix D > s/Today should be used only when/Today these groups should only be used when/ Kudos for the review! Tobias From jeffrey.m.ahrenholz@boeing.com Fri Feb 11 07:25:45 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EE363A69CC for ; Fri, 11 Feb 2011 07:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDh2VidCuVu2 for ; Fri, 11 Feb 2011 07:25:44 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 1D6823A69B2 for ; Fri, 11 Feb 2011 07:25:44 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1BFPrxE014281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Feb 2011 09:25:53 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1BFPqAS000618; Fri, 11 Feb 2011 09:25:52 -0600 (CST) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1BFPqVq000586 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 11 Feb 2011 09:25:52 -0600 (CST) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Fri, 11 Feb 2011 07:25:52 -0800 From: "Ahrenholz, Jeffrey M" To: Tobias Heer Date: Fri, 11 Feb 2011 07:25:51 -0800 Thread-Topic: [Hipsec] more comments on draft-ietf-hip-rfc5201-bis-04 Thread-Index: AcvJ3jJJMWUi0LS5QxWyBioAmWXkygAH7YgQ Message-ID: References: <6C39D444-8FDE-40E9-927A-F570224EFC23@cs.rwth-aachen.de> In-Reply-To: <6C39D444-8FDE-40E9-927A-F570224EFC23@cs.rwth-aachen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] more comments on draft-ietf-hip-rfc5201-bis-04 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 15:25:45 -0000 > checksum fails; instead, it MUST silently drop the packet." If we MUST > silently drop a packet, why do we have NOTIFY type 26, > "CHECKSUM_FAILED"? (Debugging?) >=20 > Hmmm good question. This was already that way in RFC5201-bis. I think > we have three options here: >=20 > a) go for "SHOULD silently drop". > Implementors could use the notify if they have a good reason to do so. >=20 > b) remove the NOTIFY type 26 >=20 > c) state that is for debugging purposes only and sending notifies for > malformed checksums MUST be turned off by default. >=20 > I don't have a strong preference on either of the solutions. Any > comments from the group? (c) seems like a good solution > > Section 6.11 item 4: this says the association is considered broken > if an > > UPDATE is not ACKed, but one circumstance where the association is > NOT broken > > would be when a host is informing its peer of its current address > list > > (without changing the current preferred locators used.) In that case, > the > > association may continue happily without going to CLOSING. > > >=20 > Well, the payload channel might be still functional in that case. > However, the missing ACK on the control channel is certainly a sign > that something is wrong with the HIP association. > I think if the problem persists (sender of the update keeps > retransmitting the update with the seq and receiver does not > acknowledge it) it indicates that the HIP channel is broken. > Trying to re-establish the connection (by first closing it and then > doing another BEX (because user data is still coming) might be the best > choice here. > Am I missing something here? I guess I was thinking the SEQ/ACK mechanism was not always required. But y= es, if every UPDATE requires a SEQ and ACKs have gone missing, this is prob= ably the best thing to do (close the association). > All parameter descriptions are given in bytes. I think going to bits in > that single case would confuse people, don't you think? On the other > hand, security-related discussions (as for hash functions, etc.) mostly > refer to bits in literature. So I wouldn't want to change that here > either. > We could try to untangle a bit by not reusing the quantity n as bit and > bytes, though. We could just refer to RHASH_len/8 bytes for I and J: OK, yes. My comment was how "n" referred to both bits and bytes here; using= RHASH_len/8 does untangle that a bit. -Jeff From heer@informatik.rwth-aachen.de Sat Feb 12 08:47:29 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 961883A69EF for ; Sat, 12 Feb 2011 08:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H70-P8uEukKM for ; Sat, 12 Feb 2011 08:47:28 -0800 (PST) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 20ACB3A69C9 for ; Sat, 12 Feb 2011 08:47:27 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LGI000SPJZKZJ40@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Sat, 12 Feb 2011 17:47:44 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.60,462,1291590000"; d="scan'208";a="93881295" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Sat, 12 Feb 2011 17:47:45 +0100 Received: from [192.168.3.3] ([unknown] [91.179.155.99]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LGI00H43JZKJU00@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Sat, 12 Feb 2011 17:47:44 +0100 (CET) From: Tobias Heer Date: Sat, 12 Feb 2011 17:47:42 +0100 Message-id: <3B655520-4A45-4B06-8616-76B39E66976B@cs.rwth-aachen.de> To: hipsec@ietf.org X-Mailer: Apple Mail (2.1082) Cc: Jan Melen , =?iso-8859-1?Q?Ari_Ker=E4nen?= Subject: [Hipsec] HIP transforms X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 16:47:29 -0000 Hi everyone, this came up in Miika's and Ari's review of 5201-bis. The cited text comes from rfc5201 - This also affects rfc5202. > 5.2.1. TLV Format > > The type-field value also describes the order of these > fields in the packet, except for type values from 2048 to 4095 which > are reserved for new transport forms. > ... Parameters using type values from 2048 up to 4095 are transport formats. Currently, one transport format is defined: the ESP transport format [I-D.ietf-hip-rfc5202-bis]. The order of these parameters does not follow the order of their type value, but they are put in the packet in order of preference. The first of the transport formats it the most preferred, and so on. ... > Ari: This is a bit strange exception. I wonder if it would make sense to make this consistent with the other ordered lists, i.e., have one parameter that lists the supported transport formats and then, depending on which format was chosen, the corresponding parameter(s) from this range are used (and others ignored). As Ari correctly stated, we have other negotiations in BEX and these use different preference lists encoded as list parameters (e.g., DH list, HIT suite list). Even the ESP transform parameter (rfc5202, type 4095) has such list. The question is: is the exception for the transport formats really good/necessary/justified or should we consider an alternative? I personally think lifting this exception will make implementations simpler and less error prone. Especially the checking of the parameter sequence would be easier. I see two options here: A) Give all transforms the same type number and an additional sub-type number. The order of the parameters in the HIP packet would indicate the preference then. From a handling-point-of-view this option is very similar to as it is now but there would be just one transform type with subtypes. Example HIP packet excerpt: (2096 is an arbitrary type number for the new transport form parameter) +------+ +------+--------+ +------+--------+ |Header| | 2096 | 1| ESP | | 2096 | 2| XYZ | ... +------+ +---------------+ +------+--------+ This would mean ESP is preferred, XYZ is not preferred but supported. B) Give all transforms different type numbers, keep the ordering and express preference in a list. From a specification-point-of-view this is similar to what we have now. 5202 could stay mostly as it is now. Example HIP packet excerpt: (ESP has type number 4095 but for the clarity of the example I use 2095) +------+ +----+--------------+ +----+---+ +----+---+ |Header| |2050|List: ESP, XYZ| |2095|XYZ| |4095|ESP| ... +------+ +----+--------------+ +----+---+ +----+---+ ^ | List------------+ Again, this would mean ESP is preferred, XYZ is not preferred but supported. I prefer option B because it is more similar to other negotiations in BEX. Any opinions? Tobias -- Dipl.-Inform. Tobias Heer, Ph.D. Student Chair of Communication and Distributed Systems - comsys RWTH Aachen University, Germany tel: +49 241 80 207 76 web: http://www.comsys.rwth-aachen.de/team/tobias-heer/ blog: http://dtobi.wordpress.com/ card: http://card.ly/dtobi From mkomu@cs.hut.fi Sun Feb 13 21:43:40 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F44E3A6C65 for ; Sun, 13 Feb 2011 21:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+JGdhLdKol4 for ; Sun, 13 Feb 2011 21:43:39 -0800 (PST) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 3A7603A6C64 for ; Sun, 13 Feb 2011 21:43:39 -0800 (PST) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1PorE7-0000M9-SG for hipsec@ietf.org; Mon, 14 Feb 2011 07:43:59 +0200 Message-ID: <4D58C109.2060002@cs.hut.fi> Date: Mon, 14 Feb 2011 07:43:37 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hipsec@ietf.org References: <3B655520-4A45-4B06-8616-76B39E66976B@cs.rwth-aachen.de> In-Reply-To: <3B655520-4A45-4B06-8616-76B39E66976B@cs.rwth-aachen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] HIP transforms X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 05:43:40 -0000 Hi, On 12/02/11 18:47, Tobias Heer wrote: > Hi everyone, > > this came up in Miika's and Ari's review of 5201-bis. The cited text comes from > rfc5201 - This also affects rfc5202. > > >> 5.2.1. TLV Format >> >> The type-field value also describes the order of these >> fields in the packet, except for type values from 2048 to 4095 which >> are reserved for new transport forms. >> > ... > Parameters using type values from 2048 up to 4095 are transport > formats. Currently, one transport format is defined: the ESP > transport format [I-D.ietf-hip-rfc5202-bis]. The order of these > parameters does not follow the order of their type value, but they > are put in the packet in order of preference. The first of the > transport formats it the most preferred, and so on. > ... > > > >> Ari: This is a bit strange exception. I wonder if it would make sense to make this consistent with the other ordered lists, i.e., have one parameter that lists the supported transport formats and then, depending on which format was chosen, the corresponding parameter(s) from this range are used (and others ignored). > > As Ari correctly stated, we have other negotiations in BEX and these use > different preference lists encoded as list parameters (e.g., DH list, HIT suite > list). Even the ESP transform parameter (rfc5202, type 4095) has such list. > > The question is: is the exception for the transport formats really > good/necessary/justified or should we consider an alternative? > > I personally think lifting this exception will make implementations simpler and > less error prone. Especially the checking of the parameter sequence would be > easier. > > I see two options here: > > > A) Give all transforms the same type number and an additional sub-type number. > The order of the parameters in the HIP packet would indicate the preference > then. From a handling-point-of-view this option is very similar to as it is now > but there would be just one transform type with subtypes. > > Example HIP packet excerpt: > (2096 is an arbitrary type number for the new transport form parameter) > +------+ +------+--------+ +------+--------+ > |Header| | 2096 | 1| ESP | | 2096 | 2| XYZ | ... > +------+ +---------------+ +------+--------+ > This would mean ESP is preferred, XYZ is not preferred but supported. > > > > B) Give all transforms different type numbers, keep the ordering and express > preference in a list. From a specification-point-of-view this is similar to what we have now. > 5202 could stay mostly as it is now. > > Example HIP packet excerpt: > (ESP has type number 4095 but for the clarity of the example I use 2095) > +------+ +----+--------------+ +----+---+ +----+---+ > |Header| |2050|List: ESP, XYZ| |2095|XYZ| |4095|ESP| ... > +------+ +----+--------------+ +----+---+ +----+---+ > ^ > | > List------------+ > > Again, this would mean ESP is preferred, XYZ is not preferred but supported. > > I prefer option B because it is more similar to other negotiations in BEX. > > Any opinions? what about: C) The order of these parameters follows the order of their type value and they are put in the packet in order of preference. Then the type value for ESP should be (2048 + 4095) / 2 =~ 3071 (further types should be allocated similarly). If not C), then my vote goes to B). From ari.keranen@nomadiclab.com Mon Feb 14 08:44:01 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18C93A69EB for ; Mon, 14 Feb 2011 08:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhIa+pAF7AvB for ; Mon, 14 Feb 2011 08:44:01 -0800 (PST) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 784DA3A699E for ; Mon, 14 Feb 2011 08:44:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id E09274E6D7; Mon, 14 Feb 2011 18:44:21 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzLs-NjKLpJo; Mon, 14 Feb 2011 18:44:21 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 5FBE74E6CF; Mon, 14 Feb 2011 18:44:21 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ari Keranen In-Reply-To: <3B655520-4A45-4B06-8616-76B39E66976B@cs.rwth-aachen.de> Date: Mon, 14 Feb 2011 18:44:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <904F15AA-9DD3-4CD3-BA56-375470DA5CB0@nomadiclab.com> References: <3B655520-4A45-4B06-8616-76B39E66976B@cs.rwth-aachen.de> To: Tobias Heer X-Mailer: Apple Mail (2.1082) Cc: HIP Subject: Re: [Hipsec] HIP transforms X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 16:44:01 -0000 Hi, On Feb 12, 2011, at 6:47 PM, Tobias Heer wrote: [...] > I see two options here: >=20 >=20 > A) Give all transforms the same type number and an additional sub-type = number. > The order of the parameters in the HIP packet would indicate the = preference > then. =46rom a handling-point-of-view this option is very similar to = as it is now > but there would be just one transform type with subtypes. >=20 > Example HIP packet excerpt: > (2096 is an arbitrary type number for the new transport form = parameter) > +------+ +------+--------+ +------+--------+=20 > |Header| | 2096 | 1| ESP | | 2096 | 2| XYZ | ...=20 > +------+ +---------------+ +------+--------+ > This would mean ESP is preferred, XYZ is not preferred but supported. >=20 >=20 >=20 > B) Give all transforms different type numbers, keep the ordering and = express > preference in a list. =46rom a specification-point-of-view this is = similar to what we have now. > 5202 could stay mostly as it is now. >=20 > Example HIP packet excerpt: > (ESP has type number 4095 but for the clarity of the example I use = 2095) > +------+ +----+--------------+ +----+---+ +----+---+=20 > |Header| |2050|List: ESP, XYZ| |2095|XYZ| |4095|ESP| ...=20 > +------+ +----+--------------+ +----+---+ +----+---+ > ^ > | > List------------+ >=20 > Again, this would mean ESP is preferred, XYZ is not preferred but = supported. >=20 > I prefer option B because it is more similar to other negotiations in = BEX. >=20 > Any opinions? I'd go for B. Cheers, Ari= From iesg-secretary@ietf.org Tue Feb 15 06:52:33 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAA653A6E9A; Tue, 15 Feb 2011 06:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdbSRYW9uCzK; Tue, 15 Feb 2011 06:52:33 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA51D3A6D10; Tue, 15 Feb 2011 06:52:32 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110215145232.1028.82339.idtracker@localhost> Date: Tue, 15 Feb 2011 06:52:32 -0800 X-Mailman-Approved-At: Wed, 16 Feb 2011 23:01:54 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] Last Call: (Host Identity Protocol Certificates) to Experimental RFC X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 14:52:33 -0000 The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Host Identity Protocol Certificates' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-01. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-hip-cert/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-hip-cert/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Tue Feb 15 07:40:00 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC1D23A6D10; Tue, 15 Feb 2011 07:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoR2SVIneF8M; Tue, 15 Feb 2011 07:40:00 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BE2F3A6AF1; Tue, 15 Feb 2011 07:40:00 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110215154000.15051.58132.idtracker@localhost> Date: Tue, 15 Feb 2011 07:40:00 -0800 X-Mailman-Approved-At: Wed, 16 Feb 2011 23:01:54 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] Last Call: (Host Identity Protocol Signaling Message Transport Modes) to Experimental RFC X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 15:40:00 -0000 The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Host Identity Protocol Signaling Message Transport Modes' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-01. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-hip-over-hip/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-hip-over-hip/ No IPR declarations have been submitted directly on this I-D. From rgm@htt-consult.com Mon Feb 21 05:37:13 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F57B3A6FFB for ; Mon, 21 Feb 2011 05:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tQdnwqmacBr for ; Mon, 21 Feb 2011 05:37:12 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id A45FB3A6FA3 for ; Mon, 21 Feb 2011 05:37:12 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 1265462AD3; Mon, 21 Feb 2011 13:37:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcuvEoPPeDct; Mon, 21 Feb 2011 08:37:13 -0500 (EST) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 3BFD762A79; Mon, 21 Feb 2011 08:37:13 -0500 (EST) Message-ID: <4D626A88.6060806@htt-consult.com> Date: Mon, 21 Feb 2011 08:37:12 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] comments on draft-ietf-hip-rfc4423-bis-01 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 13:37:13 -0000 On 01/21/2011 10:53 AM, Ahrenholz, Jeffrey M wrote: > Here are some comments after reviewing the HIP Architecture -bis draft... > > Should RFC 5201 be referenced? Added > - the base exchange is discussed > - the table of terms in Section 2.2 could refer to > RFC 5201 under definition of base exchange Not sure what you would want here. Can you offer up some text? > - ESP (5202), Rendezvous (5204), and DNS (5205) are listed as normative > references, but 5201 is not referenced > > Section 5.1 talks about moving Host Identities from one physical computer to > another without breaking transport associations. Really? You would need a secure channel (hint, hint) to move the Security Association, including all private key needed that are not technically part of the SA. But, yes, there are people looking into this for cloud computing. > Section 6.1 mentions "HIP readdress packets"; earlier versions of the > spec actually had readdress packets, but now it would be more precise to say > "HIP UPDATE packets" Done > Section 6.2 says "To close this attack, HIP includes..." > Could this better be phrased as "To close this attack vector" or > "To prevent this type of attack"? Done > Section 6.2 last paragraph discusses skipping the address check; > CBA can also be used to reduce handover latency here? CBA? > Section 8.1 "HIP and TCP checksums" should be titled > "HIP and Upper-layer checksums"? Yes. > This was briefly discussed on this list before [1]. > Section 9 Multicast says: > "There was little if any concrete thoughts about how HIP might affect > IP-layer or application-layer multicast." > This sentence made sense in conjunction with the RFC 4423 abstract: > "The memo describes the thinking of the authors as of Fall 2003." > ...but without such text that sentence on multicast doesn't really > stand on its own. What would you suggest? > Section 11.1 question 5 missing question mark at the end Fixed. Thanks! From mkomu@cs.hut.fi Mon Feb 21 07:27:37 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BF23A6DD8 for ; Mon, 21 Feb 2011 07:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN7exZXvryEv for ; Mon, 21 Feb 2011 07:27:31 -0800 (PST) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id A1E443A6D03 for ; Mon, 21 Feb 2011 07:27:31 -0800 (PST) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1PrXgK-0005fK-3h for hipsec@ietf.org; Mon, 21 Feb 2011 17:28:12 +0200 Message-ID: <4D62845E.1020603@cs.hut.fi> Date: Mon, 21 Feb 2011 17:27:26 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hip WG References: <4D626A88.6060806@htt-consult.com> In-Reply-To: <4D626A88.6060806@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] comments on draft-ietf-hip-rfc4423-bis-01 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 15:27:37 -0000 Hi, On 21/02/11 15:37, Robert Moskowitz wrote: >> - ESP (5202), Rendezvous (5204), and DNS (5205) are listed as normative >> references, but 5201 is not referenced >> >> Section 5.1 talks about moving Host Identities from one physical >> computer to >> another without breaking transport associations. Really? > > You would need a secure channel (hint, hint) to move the Security > Association, including all private key needed that are not technically > part of the SA. But, yes, there are people looking into this for cloud > computing. actually I would agree with Jeff here. I think the experiment report would be a better fit for such research work. I would include also reference to the earlier work: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.5588&rep=rep1&type=pdf From jeffrey.m.ahrenholz@boeing.com Mon Feb 21 07:48:32 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C2F3A7131 for ; Mon, 21 Feb 2011 07:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4qsK8JvJEGa for ; Mon, 21 Feb 2011 07:48:31 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 180213A6EEC for ; Mon, 21 Feb 2011 07:48:31 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1LFmtKV013514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Feb 2011 09:49:00 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1LFmtcg018713; Mon, 21 Feb 2011 09:48:55 -0600 (CST) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1LFmsjN018692 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 21 Feb 2011 09:48:55 -0600 (CST) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Mon, 21 Feb 2011 07:48:54 -0800 From: "Ahrenholz, Jeffrey M" To: Miika Komu , hip WG Date: Mon, 21 Feb 2011 07:48:57 -0800 Thread-Topic: [Hipsec] comments on draft-ietf-hip-rfc4423-bis-01 Thread-Index: AcvR2/wBkUNVlKorQzu7ol66NZxUnwAAqGtA Message-ID: References: <4D626A88.6060806@htt-consult.com> <4D62845E.1020603@cs.hut.fi> In-Reply-To: <4D62845E.1020603@cs.hut.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] comments on draft-ietf-hip-rfc4423-bis-01 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 15:48:32 -0000 > > You would need a secure channel (hint, hint) to move the Security > > Association, including all private key needed that are not > technically > > part of the SA. But, yes, there are people looking into this for > cloud > > computing. >=20 > actually I would agree with Jeff here. I think the experiment report > would be a better fit for such research work. I would include also > reference to the earlier work: >=20 > http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.79.5588&rep=3D= re > p1&type=3Dpdf I just wanted to make sure that statement on HI mobility didn't appear out = of thin air :) -Jeff From jeffrey.m.ahrenholz@boeing.com Mon Feb 21 07:48:59 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058D03A711F for ; Mon, 21 Feb 2011 07:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kePAEMdafgwX for ; Mon, 21 Feb 2011 07:48:58 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 2485D3A7108 for ; Mon, 21 Feb 2011 07:48:58 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1LFnTRt025617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Feb 2011 07:49:34 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1LFnTop019804; Mon, 21 Feb 2011 09:49:29 -0600 (CST) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1LFmTKL018151 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 21 Feb 2011 09:49:28 -0600 (CST) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Mon, 21 Feb 2011 07:49:11 -0800 From: "Ahrenholz, Jeffrey M" To: Robert Moskowitz Date: Mon, 21 Feb 2011 07:49:15 -0800 Thread-Topic: [Hipsec] comments on draft-ietf-hip-rfc4423-bis-01 Thread-Index: AcvRzIEPzDYluTuPRe++eHLyQjIHeAADqMzA Message-ID: References: <4D626A88.6060806@htt-consult.com> In-Reply-To: <4D626A88.6060806@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] comments on draft-ietf-hip-rfc4423-bis-01 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 15:48:59 -0000 > > - the table of terms in Section 2.2 could refer to > > RFC 5201 under definition of base exchange >=20 > Not sure what you would want here. Can you offer up some text? The first occurrence of "HIP base exchange" and the table refer to Section = 7. If Section 7 refers to RFC 5201 that is probably enough, and/or in the t= able in 2.2 you could have a "see [RFC5201]". As long as 5201 is referenced= somewhere that seems fine. > > Section 6.2 last paragraph discusses skipping the address check; > > CBA can also be used to reduce handover latency here? >=20 > CBA? credit-based authentication Maybe this lost its steam? Was it ever implemented? http://tools.ietf.org/html/draft-vogt-hip-credit-based-authorization-00 I wouldn't reference CBA if there is no WG interest... > > "There was little if any concrete thoughts about how HIP might affect > > IP-layer or application-layer multicast." > > This sentence made sense in conjunction with the RFC 4423 abstract: > > "The memo describes the thinking of the authors as of Fall 2003." > > ...but without such text that sentence on multicast doesn't really > > stand on its own. >=20 > What would you suggest? maybe: "There has not been much work in describing how HIP might affect IP-layer or application-layer multicast." or: "Few concrete thoughts exist about how HIP might affect IP-layer or application-layer multicast." ? Just trying to reduce the dependency on: "[As of Fall 2003] there was littl= e if any..." -Jeff From mkomu@cs.hut.fi Mon Feb 21 08:54:37 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 275FB3A6FE0 for ; Mon, 21 Feb 2011 08:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrulX8glIyuq for ; Mon, 21 Feb 2011 08:54:35 -0800 (PST) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id C11923A6DC6 for ; Mon, 21 Feb 2011 08:54:35 -0800 (PST) Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1PrZ2a-0006PN-La for hipsec@ietf.org; Mon, 21 Feb 2011 18:55:16 +0200 Message-ID: <4D6298C6.50705@cs.hut.fi> Date: Mon, 21 Feb 2011 18:54:30 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hipsec@ietf.org References: <4D626A88.6060806@htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Hipsec] comments on draft-ietf-hip-rfc4423-bis-01 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 16:54:37 -0000 Hi, On 21/02/11 17:49, Ahrenholz, Jeffrey M wrote: >>> Section 6.2 last paragraph discusses skipping the address check; >>> CBA can also be used to reduce handover latency here? >> >> CBA? > > credit-based authentication > > Maybe this lost its steam? Was it ever implemented? > http://tools.ietf.org/html/draft-vogt-hip-credit-based-authorization-00 > > I wouldn't reference CBA if there is no WG interest... it's part of RFC5206. >>> "There was little if any concrete thoughts about how HIP might affect >>> IP-layer or application-layer multicast." >>> This sentence made sense in conjunction with the RFC 4423 abstract: >>> "The memo describes the thinking of the authors as of Fall 2003." >>> ...but without such text that sentence on multicast doesn't really >>> stand on its own. >> >> What would you suggest? > > maybe: > "There has not been much work in describing how HIP might affect > IP-layer or application-layer multicast." > or: > "Few concrete thoughts exist about how HIP might affect > IP-layer or application-layer multicast." > ? > > Just trying to reduce the dependency on: "[As of Fall 2003] there was little if any..." these guys have been researching on HIP-based multicast: http://www.computer.org/portal/web/csdl/doi/10.1109/ICNS.2007.66 From rgm@htt-consult.com Mon Feb 21 09:03:57 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D993A6FE3 for ; Mon, 21 Feb 2011 09:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9RrkYgboU0c for ; Mon, 21 Feb 2011 09:03:56 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 524503A7131 for ; Mon, 21 Feb 2011 09:03:56 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 5B1F762AB6; Mon, 21 Feb 2011 17:04:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X7Pth0ourAN; Mon, 21 Feb 2011 12:03:57 -0500 (EST) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id BB1C462ABB; Mon, 21 Feb 2011 12:03:57 -0500 (EST) Message-ID: <4D629AFD.50107@htt-consult.com> Date: Mon, 21 Feb 2011 12:03:57 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Miika Komu References: <4D626A88.6060806@htt-consult.com> <4D6298C6.50705@cs.hut.fi> In-Reply-To: <4D6298C6.50705@cs.hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] comments on draft-ietf-hip-rfc4423-bis-01 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 17:03:58 -0000 On 02/21/2011 11:54 AM, Miika Komu wrote: > Hi, > > On 21/02/11 17:49, Ahrenholz, Jeffrey M wrote: > >>>> Section 6.2 last paragraph discusses skipping the address check; >>>> CBA can also be used to reduce handover latency here? >>> >>> CBA? >> >> credit-based authentication >> >> Maybe this lost its steam? Was it ever implemented? >> http://tools.ietf.org/html/draft-vogt-hip-credit-based-authorization-00 >> >> I wouldn't reference CBA if there is no WG interest... > > it's part of RFC5206. So any help on wording and adding 5206-bis as a reference? > >>>> "There was little if any concrete thoughts about how HIP might affect >>>> IP-layer or application-layer multicast." >>>> This sentence made sense in conjunction with the RFC 4423 abstract: >>>> "The memo describes the thinking of the authors as of Fall 2003." >>>> ...but without such text that sentence on multicast doesn't really >>>> stand on its own. >>> >>> What would you suggest? >> >> maybe: >> "There has not been much work in describing how HIP might affect >> IP-layer or application-layer multicast." >> or: >> "Few concrete thoughts exist about how HIP might affect >> IP-layer or application-layer multicast." >> ? >> >> Just trying to reduce the dependency on: "[As of Fall 2003] there was >> little if any..." > > these guys have been researching on HIP-based multicast: > > http://www.computer.org/portal/web/csdl/doi/10.1109/ICNS.2007.66 I will look at this, but if you already have, wording help is appreciated. From jeffrey.m.ahrenholz@boeing.com Mon Feb 21 09:11:19 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6C13A6CC5 for ; Mon, 21 Feb 2011 09:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT2QKzTLVqfl for ; Mon, 21 Feb 2011 09:11:18 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 8656C3A6FE3 for ; Mon, 21 Feb 2011 09:11:18 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1LHBekb015364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Feb 2011 09:11:47 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1LHBdoD025351; Mon, 21 Feb 2011 11:11:39 -0600 (CST) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1LHBd8H025333 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 21 Feb 2011 11:11:39 -0600 (CST) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Mon, 21 Feb 2011 09:11:39 -0800 From: "Ahrenholz, Jeffrey M" To: Miika Komu , "hipsec@ietf.org" Date: Mon, 21 Feb 2011 09:11:43 -0800 Thread-Topic: [Hipsec] comments on draft-ietf-hip-rfc4423-bis-01 Thread-Index: AcvR6CGrA3LCTZfASjeUFgwH0BnnDwAAUwsQ Message-ID: References: <4D626A88.6060806@htt-consult.com> <4D6298C6.50705@cs.hut.fi> In-Reply-To: <4D6298C6.50705@cs.hut.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] comments on draft-ietf-hip-rfc4423-bis-01 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 17:11:20 -0000 > >>> Section 6.2 last paragraph discusses skipping the address check; > >>> CBA can also be used to reduce handover latency here? > >> > >> CBA? > > > > credit-based authentication > > > > Maybe this lost its steam? Was it ever implemented? > > http://tools.ietf.org/html/draft-vogt-hip-credit-based-authorization- > 00 > > > > I wouldn't reference CBA if there is no WG interest... >=20 > it's part of RFC5206. Aha, that's where CBA went. So, the last paragraph in 6.2 could be revised = with something like: "A credit-based authorization approach [RFC5206] can be used between hosts = for sending data prior to completing the address tests. Otherwise, if HIP i= s used between two hosts that fully trust each other, the hosts may optiona= lly decide to skip the address tests. ..." -Jeff From gonzalo.camarillo@ericsson.com Thu Feb 24 00:32:17 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912563A6992 for ; Thu, 24 Feb 2011 00:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+hfzNgowFlt for ; Thu, 24 Feb 2011 00:32:16 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 65E3C3A6A2A for ; Thu, 24 Feb 2011 00:32:15 -0800 (PST) X-AuditID: c1b4fb39-b7b76ae00000276e-fa-4d6617bf5bd0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4E.4B.10094.FB7166D4; Thu, 24 Feb 2011 09:33:03 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Thu, 24 Feb 2011 09:33:03 +0100 Received: from [131.160.126.131] (rvi2-126-131.lmf.ericsson.se [131.160.126.131]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B0ADC25BC for ; Thu, 24 Feb 2011 10:33:02 +0200 (EET) Message-ID: <4D6617BE.1080803@ericsson.com> Date: Thu, 24 Feb 2011 10:33:02 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] Milestones X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 08:32:17 -0000 Hi, FYI: I have updated the dates of the milestones in our charter because we were running late. Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Thu Feb 24 03:10:24 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461143A6A83 for ; Thu, 24 Feb 2011 03:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WalmaOVHDaQ for ; Thu, 24 Feb 2011 03:10:23 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 46EC43A6A84 for ; Thu, 24 Feb 2011 03:10:23 -0800 (PST) X-AuditID: c1b4fb3d-b7c78ae000005844-c0-4d663ccff816 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4A.C8.22596.FCC366D4; Thu, 24 Feb 2011 12:11:11 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Thu, 24 Feb 2011 12:11:11 +0100 Received: from [131.160.126.131] (rvi2-126-131.lmf.ericsson.se [131.160.126.131]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1D63525C2 for ; Thu, 24 Feb 2011 13:11:11 +0200 (EET) Message-ID: <4D663CCE.5080704@ericsson.com> Date: Thu, 24 Feb 2011 13:11:10 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: HIP X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Hipsec] Agenda requests for Prague X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 11:10:24 -0000 Hi, I need to get your agenda requests in order to prepare our session in Prague. Please, send me an email with the topic you would like to present and how much time you think you will be needing for the presentation. Thanks, Gonzalo From Internet-Drafts@ietf.org Fri Feb 25 09:30:13 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFBCF3A693A; Fri, 25 Feb 2011 09:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFfqo5fBSieU; Fri, 25 Feb 2011 09:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0993A67B0; Fri, 25 Feb 2011 09:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110225173002.23278.9153.idtracker@localhost> Date: Fri, 25 Feb 2011 09:30:02 -0800 Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action:draft-ietf-hip-rfc4423-bis-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:30:13 -0000 --NextPart 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 Architecture Author(s) : R. Moskowitz Filename : draft-ietf-hip-rfc4423-bis-02.txt Pages : 27 Date : 2011-02-25 This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. It incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signalling channel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc4423-bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-hip-rfc4423-bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-25092459.I-D@ietf.org> --NextPart-- From rgm@htt-consult.com Fri Feb 25 09:33:57 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A423A67EB for ; Fri, 25 Feb 2011 09:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+xOfnGS4YK2 for ; Fri, 25 Feb 2011 09:33:56 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id E4B483A65A5 for ; Fri, 25 Feb 2011 09:33:55 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 7BABB62AB7; Fri, 25 Feb 2011 17:34:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zxEmj+Ah0WK; Fri, 25 Feb 2011 12:34:02 -0500 (EST) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id DE99762A95; Fri, 25 Feb 2011 12:34:01 -0500 (EST) Message-ID: <4D67E804.60709@htt-consult.com> Date: Fri, 25 Feb 2011 12:33:56 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Miika Komu References: <4D626A88.6060806@htt-consult.com> <4D62845E.1020603@cs.hut.fi> In-Reply-To: <4D62845E.1020603@cs.hut.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hip WG Subject: Re: [Hipsec] comments on draft-ietf-hip-rfc4423-bis-01 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:33:57 -0000 On 02/21/2011 10:27 AM, Miika Komu wrote: > Hi, > > On 21/02/11 15:37, Robert Moskowitz wrote: >>> - ESP (5202), Rendezvous (5204), and DNS (5205) are listed as normative >>> references, but 5201 is not referenced >>> >>> Section 5.1 talks about moving Host Identities from one physical >>> computer to >>> another without breaking transport associations. Really? >> >> You would need a secure channel (hint, hint) to move the Security >> Association, including all private key needed that are not technically >> part of the SA. But, yes, there are people looking into this for cloud >> computing. > > actually I would agree with Jeff here. I think the experiment report > would be a better fit for such research work. I would include also > reference to the earlier work: > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.79.5588&rep=rep1&type=pdf > Please help with the text change and the Informative reference. From rgm@htt-consult.com Fri Feb 25 09:34:04 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114413A6968 for ; Fri, 25 Feb 2011 09:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTbyfV7NA2BE for ; Fri, 25 Feb 2011 09:34:02 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 09E853A65A5 for ; Fri, 25 Feb 2011 09:34:02 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id C864462B8F; Fri, 25 Feb 2011 17:34:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHtMMdR6mP+3; Fri, 25 Feb 2011 12:34:09 -0500 (EST) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 78F1C62AAA; Fri, 25 Feb 2011 12:34:08 -0500 (EST) Message-ID: <4D67E810.8000109@htt-consult.com> Date: Fri, 25 Feb 2011 12:34:08 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Miika Komu References: <4D626A88.6060806@htt-consult.com> <4D6298C6.50705@cs.hut.fi> In-Reply-To: <4D6298C6.50705@cs.hut.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: Re: [Hipsec] comments on draft-ietf-hip-rfc4423-bis-01 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:34:04 -0000 On 02/21/2011 11:54 AM, Miika Komu wrote: > Hi, > > On 21/02/11 17:49, Ahrenholz, Jeffrey M wrote: > >>>> Section 6.2 last paragraph discusses skipping the address check; >>>> CBA can also be used to reduce handover latency here? >>> >>> CBA? >> >> credit-based authentication >> >> Maybe this lost its steam? Was it ever implemented? >> http://tools.ietf.org/html/draft-vogt-hip-credit-based-authorization-00 >> >> I wouldn't reference CBA if there is no WG interest... > > it's part of RFC5206. Which is NOT referenced in 4423 yet. Should it here and how? > >>>> "There was little if any concrete thoughts about how HIP might affect >>>> IP-layer or application-layer multicast." >>>> This sentence made sense in conjunction with the RFC 4423 abstract: >>>> "The memo describes the thinking of the authors as of Fall 2003." >>>> ...but without such text that sentence on multicast doesn't really >>>> stand on its own. >>> >>> What would you suggest? >> >> maybe: >> "There has not been much work in describing how HIP might affect >> IP-layer or application-layer multicast." >> or: >> "Few concrete thoughts exist about how HIP might affect >> IP-layer or application-layer multicast." >> ? >> >> Just trying to reduce the dependency on: "[As of Fall 2003] there was >> little if any..." > > these guys have been researching on HIP-based multicast: > > http://www.computer.org/portal/web/csdl/doi/10.1109/ICNS.2007.66 I could not figure this out enough to develop an informative reference. If you think I should, please help with the text in the section and the reference XML. From rgm@htt-consult.com Fri Feb 25 09:34:23 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43C133A69EF for ; Fri, 25 Feb 2011 09:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WftqIcVA+9KK for ; Fri, 25 Feb 2011 09:34:22 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 46B4B3A69F5 for ; Fri, 25 Feb 2011 09:34:22 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id ECD3062AAA; Fri, 25 Feb 2011 17:34:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqbOiMpiZcFW; Fri, 25 Feb 2011 12:34:33 -0500 (EST) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 192DD62A2F; Fri, 25 Feb 2011 12:34:11 -0500 (EST) Message-ID: <4D67E813.1040109@htt-consult.com> Date: Fri, 25 Feb 2011 12:34:11 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <4D626A88.6060806@htt-consult.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] comments on draft-ietf-hip-rfc4423-bis-01 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:34:23 -0000 On 02/21/2011 10:49 AM, Ahrenholz, Jeffrey M wrote: >>> - the table of terms in Section 2.2 could refer to >>> RFC 5201 under definition of base exchange >> Not sure what you would want here. Can you offer up some text? > The first occurrence of "HIP base exchange" and the table refer to Section 7. If Section 7 refers to RFC 5201 that is probably enough, and/or in the table in 2.2 you could have a "see [RFC5201]". As long as 5201 is referenced somewhere that seems fine. What for draft 02 and changes to sec 2.2 for this. >>> Section 6.2 last paragraph discusses skipping the address check; >>> CBA can also be used to reduce handover latency here? >> CBA? > credit-based authentication > > Maybe this lost its steam? Was it ever implemented? > http://tools.ietf.org/html/draft-vogt-hip-credit-based-authorization-00 > > I wouldn't reference CBA if there is no WG interest... I have not made any changes here. Review draft 02 when it is out and think about changes. >>> "There was little if any concrete thoughts about how HIP might affect >>> IP-layer or application-layer multicast." >>> This sentence made sense in conjunction with the RFC 4423 abstract: >>> "The memo describes the thinking of the authors as of Fall 2003." >>> ...but without such text that sentence on multicast doesn't really >>> stand on its own. >> What would you suggest? > maybe: > "There has not been much work in describing how HIP might affect > IP-layer or application-layer multicast." > or: > "Few concrete thoughts exist about how HIP might affect > IP-layer or application-layer multicast." > ? Change made, please review. > Just trying to reduce the dependency on: "[As of Fall 2003] there was little if any..." > > -Jeff > From rgm@htt-consult.com Fri Feb 25 09:41:04 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D0BC3A69E7 for ; Fri, 25 Feb 2011 09:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWbQ1I2v7bmE for ; Fri, 25 Feb 2011 09:41:03 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 482E63A693A for ; Fri, 25 Feb 2011 09:41:03 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id C6B8062A45; Fri, 25 Feb 2011 17:41:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pxGQFtcAlZA; Fri, 25 Feb 2011 12:41:04 -0500 (EST) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 1D20962AAA; Fri, 25 Feb 2011 12:41:04 -0500 (EST) Message-ID: <4D67E9AF.7030208@htt-consult.com> Date: Fri, 25 Feb 2011 12:41:03 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <4D626A88.6060806@htt-consult.com> <4D6298C6.50705@cs.hut.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hipsec@ietf.org" Subject: Re: [Hipsec] comments on draft-ietf-hip-rfc4423-bis-01 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:41:04 -0000 On 02/21/2011 12:11 PM, Ahrenholz, Jeffrey M wrote: >>>>> Section 6.2 last paragraph discusses skipping the address check; >>>>> CBA can also be used to reduce handover latency here? >>>> CBA? >>> credit-based authentication >>> >>> Maybe this lost its steam? Was it ever implemented? >>> http://tools.ietf.org/html/draft-vogt-hip-credit-based-authorization- >> 00 >>> I wouldn't reference CBA if there is no WG interest... >> it's part of RFC5206. > Aha, that's where CBA went. So, the last paragraph in 6.2 could be revised with something like: > > "A credit-based authorization approach [RFC5206] can be used between hosts for sending data prior to completing the address tests. Otherwise, if HIP is used between two hosts that fully trust each other, the hosts may optionally decide to skip the address tests. ..." Check out what I changed. From rgm@htt-consult.com Fri Feb 25 09:41:49 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C313A693A for ; Fri, 25 Feb 2011 09:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOhvyvMxoKp7 for ; Fri, 25 Feb 2011 09:41:48 -0800 (PST) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 4C6E63A679F for ; Fri, 25 Feb 2011 09:41:48 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id CB23A62AB7 for ; Fri, 25 Feb 2011 17:42:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at localhost Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUMb-ZyXwev1 for ; Fri, 25 Feb 2011 12:41:58 -0500 (EST) Received: from nc2400.htt-consult.com (nc2400.htt-consult.com [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 0B5A662A45 for ; Fri, 25 Feb 2011 12:41:58 -0500 (EST) Message-ID: <4D67E9E5.6000108@htt-consult.com> Date: Fri, 25 Feb 2011 12:41:57 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: hipsec@ietf.org References: <20110225173002.23278.9153.idtracker@localhost> In-Reply-To: <20110225173002.23278.9153.idtracker@localhost> Content-Type: multipart/alternative; boundary="------------010501000602090004010100" Subject: [Hipsec] Please review -- I-D Action:draft-ietf-hip-rfc4423-bis-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:41:49 -0000 This is a multi-part message in MIME format. --------------010501000602090004010100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I tried to make the recommended changes. Please review and comment. On 02/25/2011 12:30 PM, 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 Architecture > Author(s) : R. Moskowitz > Filename : draft-ietf-hip-rfc4423-bis-02.txt > Pages : 27 > Date : 2011-02-25 > > This memo describes a new namespace, the Host Identity namespace, and > a new protocol layer, the Host Identity Protocol, between the > internetworking and transport layers. Herein are presented the > basics of the current namespaces, their strengths and weaknesses, and > how a new namespace will add completeness to them. The roles of this > new namespace in the protocols are defined. > > This document obsoletes RFC 4423 and addresses the concerns raised by > the IESG, particularly that of crypto agility. It incorporates > lessons learned from the implementations of RFC 5201 and goes further > to explain how HIP works as a secure signalling channel. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc4423-bis-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec --------------010501000602090004010100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I tried to make the recommended changes.

Please review and comment.

On 02/25/2011 12:30 PM, 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 Architecture
	Author(s)       : R. Moskowitz
	Filename        : draft-ietf-hip-rfc4423-bis-02.txt
	Pages           : 27
	Date            : 2011-02-25

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

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc4423-bis-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec
--------------010501000602090004010100-- From jeffrey.m.ahrenholz@boeing.com Fri Feb 25 13:42:22 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC193A6A53 for ; Fri, 25 Feb 2011 13:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9haPV2gCY2bZ for ; Fri, 25 Feb 2011 13:42:21 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 437F43A6A44 for ; Fri, 25 Feb 2011 13:42:21 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p1PLh6uk008634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Feb 2011 13:43:10 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p1PLh5hA003105; Fri, 25 Feb 2011 13:43:06 -0800 (PST) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p1PLh5NL003079 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 25 Feb 2011 13:43:05 -0800 (PST) Received: from XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Fri, 25 Feb 2011 13:43:05 -0800 From: "Ahrenholz, Jeffrey M" To: Robert Moskowitz , "hipsec@ietf.org" Date: Fri, 25 Feb 2011 13:43:11 -0800 Thread-Topic: [Hipsec] Please review -- I-DAction:draft-ietf-hip-rfc4423-bis-02.txt Thread-Index: AcvVE28AZh60NQMTTQS2PHjqZARAYwAICYFA Message-ID: References: <20110225173002.23278.9153.idtracker@localhost> <4D67E9E5.6000108@htt-consult.com> In-Reply-To: <4D67E9E5.6000108@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Hipsec] Please review -- I-DAction:draft-ietf-hip-rfc4423-bis-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 21:42:22 -0000 > I tried to make the recommended changes. >=20 > Please review and comment. The new version looks good and addresses the comments that I posted earlier= . The 5201 and 5206/CBA references look good. Regarding the previous multic= ast work I guess we'll see if Miika has any suggested text. -Jeff From david.black@emc.com Fri Feb 25 11:08:25 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6303A69F5; Fri, 25 Feb 2011 11:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6sxKR+VLwPf; Fri, 25 Feb 2011 11:08:24 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 2A2203A67E2; Fri, 25 Feb 2011 11:08:23 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1PJ9DrM012442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Feb 2011 14:09:13 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 25 Feb 2011 14:09:08 -0500 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.221.56.102]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1PJ7XZV027722; Fri, 25 Feb 2011 14:07:33 -0500 Received: from mxhub29.corp.emc.com (128.221.47.158) by mxhub13.corp.emc.com (128.221.56.102) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 25 Feb 2011 14:07:32 -0500 Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub29.corp.emc.com ([128.221.47.158]) with mapi; Fri, 25 Feb 2011 14:07:32 -0500 From: To: , Date: Fri, 25 Feb 2011 14:07:31 -0500 Thread-Topic: OPS-DIE review of draft-ietf-hip-over-hip-05 Thread-Index: AcvVH0DX3VV8D/c5RHyKZzzIGzhxzA== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5B1C06C@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Sun, 27 Feb 2011 23:57:36 -0800 Cc: hipsec@ietf.org, david.black@emc.com, rdroms.ietf@gmail.com, gonzalo.camarillo@ericsson.com Subject: [Hipsec] OPS-DIE review of draft-ietf-hip-over-hip-05 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:08:25 -0000 I have performed an Operations Directorate review of draft-ietf-hip-over-hi= p-05 Operations directorate reviews are solicited primarily to help the area dir= ectors improve their efficiency, particularly when preparing for IESG telec= hats, and allowing them to focus on documents requiring their attention and= spend less time on the trouble-free ones. Improving the documents is impo= rtant, but clearly a secondary purpose. A third purpose is to broaden the = OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to r= aise issue with a document. The reviews may, however, convince individual I= ESG members to raise concern over a particular document requiring further d= iscussion. The reviews, particularly those conducted in last call and earli= er, may also help the document editors improve their documents. -------------- Summary: This draft is basically ready for publication, but has nits that s= hould be fixed before publication. HIP is in a related functional space to IPsec, and in both cases IETF proto= cols are not typical means for operation and management (e.g., the IPsec SP= D MIB is not widely used for configuring IPsec). This draft specifies mino= r extensions to HIP in that it defines two additional HIP transports, so it= 's not a reasonable vehicle for a general discussion of HIP operations and = management. As a result, this review focuses on operational characteristic= s of the extensions specified in the draft. This draft defines two new fully encrypted transports for HIP signaling mes= sages - ESP and ESP over TCP. The draft includes details on negotiation of= these modes as extensions to existing HIP signaling, providing support for= incremental deployment, a migration path and backwards compatibility. Whi= le it is probably best to start out with the intended transport (i.e., nego= tiate it in the HIP base exchange), means are also specified to negotiate a= transport change later. An error report is defined for use when a HIP nod= e policy requires use of one of these fully encrypted transports, but none = is offered in negotiation. Fallback to a non-encrypted transport is specif= ied and recommended (SHOULD) when the encrypted transport fails. I have one recommendation for change - this draft is somewhat inconsistent = about support for a HIP node policy that requires use of an encrypted trans= port for HIP signaling. Section 3.3 provides an essential building block, = the error signaling mechanism to indicate that an encrypted transport is re= quired and none was proposed. On the other hand, Section 5 is unclear with= respect to this class of policy in that it strongly recommends (SHOULD) fa= llback to a non-encrypted HIP connection but requires (MUST) that "messages= that are intended to be sent only encrypted" not be sent unencrypted. If = the "messages that are intended to be sent only encrypted" are all HIP mess= ages after the base exchange, these two requirements appear to be in confli= ct. I suggest adding a short explanation to Section 5 of what would be reasonab= le vs. unreasonable policy for "messages that are intended to be sent only = encrypted", and how to use the Section 3.3 error report when a failed encry= pted connection is recovered by attempting to fall back to an unencrypted c= onnection when HIP node policy requires encryption of all signaling after t= he base exchange. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From david.black@emc.com Fri Feb 25 11:17:02 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72D9F3A67E2; Fri, 25 Feb 2011 11:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bePTEtOZ-M6N; Fri, 25 Feb 2011 11:17:01 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 571D73A67D2; Fri, 25 Feb 2011 11:17:01 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1PJHptH027593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Feb 2011 14:17:51 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 25 Feb 2011 14:17:42 -0500 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1PJERs4027785; Fri, 25 Feb 2011 14:14:27 -0500 Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Fri, 25 Feb 2011 14:14:26 -0500 From: To: , , Date: Fri, 25 Feb 2011 14:14:26 -0500 Thread-Topic: OPS-DIR review of draft-ietf-hip-over-hip-05 Thread-Index: AcvVH0DX3VV8D/c5RHyKZzzIGzhxzAAAOkNA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5B1C076@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5B1C06C@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5B1C06C@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Sun, 27 Feb 2011 23:57:36 -0800 Cc: hipsec@ietf.org, rdroms.ietf@gmail.com, gonzalo.camarillo@ericsson.com Subject: Re: [Hipsec] OPS-DIR review of draft-ietf-hip-over-hip-05 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:17:02 -0000 Freudian slip - that should be OPS-DI*R* in the subject line ... Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, February 25, 2011 2:08 PM > To: ari.keranen@ericsson.com; 'ops-dir@ietf.org' > Cc: Black, David; David Ward; Gonzalo Camarillo; Ralph Droms; hipsec@ietf= .org > Subject: OPS-DIE review of draft-ietf-hip-over-hip-05 >=20 > I have performed an Operations Directorate review of draft-ietf-hip-over-= hip-05 >=20 > Operations directorate reviews are solicited primarily to help the area d= irectors improve their > efficiency, particularly when preparing for IESG telechats, and allowing = them to focus on documents > requiring their attention and spend less time on the trouble-free ones. = Improving the documents is > important, but clearly a secondary purpose. A third purpose is to broade= n the OpsDir reviewers' > exposure to work going on in other parts of the IETF. >=20 > Reviews from OpsDir members do not in and of themselves cause the IESG to= raise issue with a document. > The reviews may, however, convince individual IESG members to raise conce= rn over a particular document > requiring further discussion. The reviews, particularly those conducted i= n last call and earlier, may > also help the document editors improve their documents. >=20 > -------------- >=20 > Summary: This draft is basically ready for publication, but has nits that= should be fixed before > publication. >=20 > HIP is in a related functional space to IPsec, and in both cases IETF pro= tocols are not typical means > for operation and management (e.g., the IPsec SPD MIB is not widely used = for configuring IPsec). This > draft specifies minor extensions to HIP in that it defines two additional= HIP transports, so it's not > a reasonable vehicle for a general discussion of HIP operations and manag= ement. As a result, this > review focuses on operational characteristics of the extensions specified= in the draft. >=20 > This draft defines two new fully encrypted transports for HIP signaling m= essages - ESP and ESP over > TCP. The draft includes details on negotiation of these modes as extensi= ons to existing HIP > signaling, providing support for incremental deployment, a migration path= and backwards compatibility. > While it is probably best to start out with the intended transport (i.e.,= negotiate it in the HIP base > exchange), means are also specified to negotiate a transport change later= . An error report is defined > for use when a HIP node policy requires use of one of these fully encrypt= ed transports, but none is > offered in negotiation. Fallback to a non-encrypted transport is specifi= ed and recommended (SHOULD) > when the encrypted transport fails. >=20 > I have one recommendation for change - this draft is somewhat inconsisten= t about support for a HIP > node policy that requires use of an encrypted transport for HIP signaling= . Section 3.3 provides an > essential building block, the error signaling mechanism to indicate that = an encrypted transport is > required and none was proposed. On the other hand, Section 5 is unclear = with respect to this class of > policy in that it strongly recommends (SHOULD) fallback to a non-encrypte= d HIP connection but requires > (MUST) that "messages that are intended to be sent only encrypted" not be= sent unencrypted. If the > "messages that are intended to be sent only encrypted" are all HIP messag= es after the base exchange, > these two requirements appear to be in conflict. >=20 > I suggest adding a short explanation to Section 5 of what would be reason= able vs. unreasonable policy > for "messages that are intended to be sent only encrypted", and how to us= e the Section 3.3 error > report when a failed encrypted connection is recovered by attempting to f= all back to an unencrypted > connection when HIP node policy requires encryption of all signaling afte= r the base exchange. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From ari.keranen@ericsson.com Mon Feb 28 05:10:12 2011 Return-Path: X-Original-To: hipsec@core3.amsl.com Delivered-To: hipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585873A6BF6; Mon, 28 Feb 2011 05:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.053 X-Spam-Level: X-Spam-Status: No, score=-5.053 tagged_above=-999 required=5 tests=[AWL=-1.246, BAYES_00=-2.599, FRT_ESTABLISH2=2.492, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AKk9zZS4EC6; Mon, 28 Feb 2011 05:10:11 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 124863A6BF7; Mon, 28 Feb 2011 05:10:10 -0800 (PST) X-AuditID: c1b4fb39-b7c6dae0000023f2-b0-4d6b9eee6e3f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 59.AD.09202.EEE9B6D4; Mon, 28 Feb 2011 14:11:10 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Mon, 28 Feb 2011 14:11:10 +0100 Received: from EV000C295089FF.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8D85425C4; Mon, 28 Feb 2011 15:11:09 +0200 (EET) MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="us-ascii" From: =?iso-8859-1?Q?Ari_Ker=E4nen?= In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5B1C06C@MX14A.corp.emc.com> Date: Mon, 28 Feb 2011 15:11:09 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <70848F08-3FA5-4BD0-8CCA-6987C6444C17@ericsson.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5B1C06C@MX14A.corp.emc.com> To: david.black@emc.com X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Mon, 28 Feb 2011 05:16:28 -0800 Cc: hipsec@ietf.org, ops-dir@ietf.org, rdroms.ietf@gmail.com, gonzalo.camarillo@ericsson.com Subject: Re: [Hipsec] OPS-DIE review of draft-ietf-hip-over-hip-05 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 13:10:12 -0000 Hi David, Thanks for the review! On Feb 25, 2011, at 9:07 PM, = wrote: [...] > Summary: This draft is basically ready for publication, but has nits = that should be fixed before publication. [...] > I have one recommendation for change - this draft is somewhat = inconsistent about support for a HIP node policy that requires use of an = encrypted transport for HIP signaling. Section 3.3 provides an = essential building block, the error signaling mechanism to indicate that = an encrypted transport is required and none was proposed. On the other = hand, Section 5 is unclear with respect to this class of policy in that = it strongly recommends (SHOULD) fallback to a non-encrypted HIP = connection but requires (MUST) that "messages that are intended to be = sent only encrypted" not be sent unencrypted. If the "messages that are = intended to be sent only encrypted" are all HIP messages after the base = exchange, these two requirements appear to be in conflict. That's a valid point. A policy that would prevent sending the = re-establishing UPDATEs un-encrypted after a failed encrypted connection = would be unreasonable since then one could never re-establish such a = connection or even close it properly. This is already explicit for the = receiving end (MUST accept without encryption), but making it explicit = also for the sender makes sense. The first SHOULD refers to the fact that one may also do something else = than re-establish the connection (e.g., close it). > I suggest adding a short explanation to Section 5 of what would be = reasonable vs. unreasonable policy for "messages that are intended to be = sent only encrypted", and how to use the Section 3.3 error report when a = failed encrypted connection is recovered by attempting to fall back to = an unencrypted connection when HIP node policy requires encryption of = all signaling after the base exchange. If we explicitly prevent a policy that would not allow un-encrypted = connection re-establisihing UPDATEs, I think we have this fixed, and we = would not need to use error messages for informing about this. I would = change the text in section 5 into (added the last sentence and changed = the second-to-last one): [...] If encryption was previously used, hosts SHOULD send outside of the encrypted connection only HIP messages that are used to re-establish the encrypted connection. Especially, messages for which the policy is to send them only encrypted (e.g., DATA messages using an encrypted transport mode) MUST be sent only using the encrypted connection. Note that a policy MUST NOT prevent sending un-encrypted UPDATE messages used for re-establishing the encrypted connection, since that would prevent recovering from failed encrypted connections. Cheers, Ari=