From hipsec-bounces@lists.ietf.org Sun Apr 02 12:57:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ5tF-00082E-4I; Sun, 02 Apr 2006 12:57:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ5tD-000829-Gl for hipsec@ietf.org; Sun, 02 Apr 2006 12:57:23 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQ5tC-0008O1-6S for hipsec@ietf.org; Sun, 02 Apr 2006 12:57:23 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3CA1D4F0001; Sun, 2 Apr 2006 18:57:21 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Apr 2006 18:57:20 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Apr 2006 18:57:20 +0200 Received: from [131.160.126.64] (rvi2-126-64.lmf.ericsson.se [131.160.126.64]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 75237236D; Sun, 2 Apr 2006 19:57:20 +0300 (EEST) Message-ID: <4430026F.6000204@ericsson.com> Date: Sun, 02 Apr 2006 19:57:19 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2006 16:57:20.0837 (UTC) FILETIME=[81AD0F50:01C65676] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: Pekka Nikander , Petri Jokela Subject: [Hipsec] [Fwd: Fwd: Belovin-Rescorla analysis - HIP] X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi, we have already gotten the B-R analysis on the main spec. Cheers, Gonzalo -------- Original Message -------- Subject: Fwd: Belovin-Rescorla analysis - HIP Date: Sat, 01 Apr 2006 17:06:02 -0500 From: Russ Housley To: hip-chairs@tools.ietf.org, townsley@cisco.com CC: hartmans-ietf@mit.edu Charlie Kaufman did the security review for HIP. Please take a look at his review, and let us know your thoughts. Russ >From: Charlie Kaufman >To: Russ Housley , "secdir@mit.edu" >CC: "hartmans-ietf@mit.edu" >Date: Thu, 23 Mar 2006 12:49:35 -0800 >Subject: RE: [secdir] [Fwd: Belovin-Rescorla analysis] - HIP > >I read draft-ietf-hip-base-05.txt, draft-ietf-hip-esp-02.txt, >draft-ietf-hip-arch-03.txt with a particular eye towards >shortcomings with crypto algorithm agility. The HIP design has >evolved considerably since I last read it. I can't in good >conscience tell you that this is a complete analysis - these >documents are primarily about security. HIP today looks a lot like IKEv2. > >Issues with crypto agility: > >While crypto algorithms are in some cases negotiated, there are >several places where use of SHA-1 is "wired in". In one very >important case, this would be very hard to fix. > >A central idea behind HIP is that a hash of a public key can be used >as a host identifier and that identifier can be used in place of an >IPv6 address in both internal data structures and in some cases on >the wire. Because IPv6 has a fixed address size of 128 bits, the >public key hash can be no larger than 128 bits. Because of address >allocation issues, the proposed actual size of the hash is 120 bits. > >The HIP base document makes a normative reference to >draft-laganier-ipv6-khi-01, and that document wires in both use of >SHA-1 and the extraction of a particular 120 bits of the SHA-1 hash. >Switching to use 120 bits of a SHA-256 hash would not be terribly >difficult, but it's not clear that would be any more secure. > >There are no real attacks on HIP based on finding collisions, but as >with many of these protocols there could be long theoretical >discussions about how finding collisions would be interesting. A >real attack would depend on the ability to find a second preimage. > >There are other places where SHA-1 is wired in with no mechanism for >negotiating anything else. None can be exploited given collision >attacks. They are: > >1) Key expansion: hash is not negotiated - SHA-1 wired in. > >2) Puzzles: SHA-1 is certainly "good enough" for puzzles, since any >weakness would have to find a first preimage more quickly than >computing a small number of hashes. > >3) HMAC and encryption algorithms are negotiated, but currently >SHA-1 and MD5 are the only registered options. In one place, the >size of the output of the HMAC is fixed at 160 bits. This is >probably a bug in the spec and easily fixed. > >4) When doing signatures, the HASH type is not negotiated but rather >is assumed to be determined by the signature algorithm (which is >also not negotiated). Each endnode decides the signature and hash >algorithms it is going to used and the other endnode can accept it >or not. The spec references RFCs 2536 and 3110 to match up signature >and hash algorithms. This is probably acceptable. > >There are other places where crypto-agility is not all that it might be: > >1) There is no negotiation of Diffie-Hellman groups. The responder >chooses. This means that if both ends support multiple groups and >there is some overlap, the negotiation could still fail if the >initiator does not support the responder's default group. As with >IKEv1, connections might succeed if initiated from one end but not >from the other. If an implementation compensates for this by trying >different groups upon retry, the protocol is subject to a downgrade >attack where a man-in-the-middle can get the two ends to use a group >weaker than one they would both prefer. This would be >straightforward (but not trivial) to fix. > >2) No key size is negotiated. Use of AES implies use of 128 bit >keys. This is not a serious problem - it just means that if support >of AES with bigger keys is desired, they must be treated as >different encryption algorithms. > >3) Fixing the "wired-in" uses of SHA-1 will require a new version >number in the protocol, but there is a version downgrade attack. The >current spec says that if the version number you get is not >supported, you reject it with an unsigned ICMP message. This means >two endnodes could likely be tricked by a man-in-the-middle to use >the older version of the protocol even if they both support the newer one. > >Other Security Concerns (beyond crypto-agility): > >Many packets are integrity protected with both an HMAC and a digital >signature. This is inefficient because it requires extra public key >operations. It is done for the benefit of middle-boxes that don't >know the HMAC keys but want to be able to verify the packet contents >for updating NAT and firewall configurations. As it stands, the >protocol is secure but slow. If the signatures were left out or >unverified, certain subtle vulnerabilities are introduced. > >There is mandatory support for ESP with HMAC-SHA1 and either Null or >AES128CBC encryption. This is mandatory not just in the >implementation but also in the configuration. (i.e., as written, the >spec says that one of those two suites must be offered in every negotiation). > >Assurance that two sessions will always use different session keys >is fragile. The keys are derived from the Diffie-Hellman keys and >puzzle challenges and responses, all of which can be reused. Perhaps >I missed it, but there should probably be more explicit guidance on >how to avoid this or explicit nonces should be added. > >Around line 1829, the base spec says "All HIP implementations MUST >employ a reassembly algorithm that is sufficiently resistant to DoS >attacks." This statement is too vague to be useful (and arguably >impossible). It should probably be changed to be implementer advice. > >Notifications are not acknowledged or protected from replay. Today, >notifications are only used for diagnostics, so a third party >filtering, duplicating, and reordering them probably can't do >substantial damage. It does seem suspicious though. > >When doing "opportunistic" HIP negotiation, when node A wants to >send to node B and doesn't know whether node B supports HIP, it has >three choices: 1) It can hold the first packet to B while it tries >to negotiate HIP, and if that fails send the first packet >unprotected; 2) It can forward the first packet unprotected and in >parallel try to negotiate HIP. If the negotiation succeeds, it can >start using the ESP tunnel; or 3) it can not try to negotiate HIP. >Each of these mechanisms has problems. The spec should offer some >guidance. It's possible this is provided in one of the other HIP documents. > >Non-security concerns: > >Use of Extended Sequence Numbers is not negotiated; either end can >mandate it. If all endpoints are required to support ESNs, it would >be simpler to just mandate their use all the time. If not, the >negotiation should allow one end to propose their use and the other >to accept it. > > --Charlie _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 03 11:52:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQRLS-0002aS-Vi; Mon, 03 Apr 2006 11:51:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQRLR-0002aN-1o for hipsec@ietf.org; Mon, 03 Apr 2006 11:51:57 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQRLP-00085d-7H for hipsec@ietf.org; Mon, 03 Apr 2006 11:51:57 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 33F103045; Mon, 3 Apr 2006 18:51:54 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20040914 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20040914 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 13B203044 for ; Mon, 3 Apr 2006 18:51:53 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k33FpqQ05327; Mon, 3 Apr 2006 18:51:52 +0300 (EEST) Date: Mon, 3 Apr 2006 18:51:52 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: dfc64cf6e4c6efdbf6b8f4c995df04df Cc: Subject: [Hipsec] some comments for mm-03 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Some comments for mm-03, part 1/2 (I'll send the rest later this evening). Should keep Thomas busy until then :) I haven't read the mm-03 draft for a long time (1-2 years) througly, so decided to do it now with fresh eyes. Below are my suggested changes, but before that, a short executive summary of the proposed changes: * Mainly consists of many readability/understandability enchancements and requests for clarifications. * Mainly, no new features. In fact, I suggest removing one feature/use-case (readdress with peer-initiated rekey) in favour of simplifying state machine, interaction with middle-boxes and interoperable implementations. Suggest removal of it from this draft and adding to a follow-up draft. * An initial proposal for a state machine for mobility and multihoming based on the current text in the draft, excluding the (readdress with peer-initiated rekey). The actual state machine is in separate email. * Some new text on closing of SAs in multihoming case. I feel that the current draft is too "loose", just for the sake of experimentation but IMHO it makes the implementation too complex in practice and also makes the situation bad for the interoperability of implementations. I believe that this can be accomplished by reducing the functionality: removing the "readdress with peer-initiated rekey" use case, sticking to three-way packet exchange and adding a reference state machine. Editorial comments: > Abstract > > This document defines mobility and multihoming extensions to the Host > Identity Protocol (HIP). Add after this: The document assumes that ESP is being used. (because the draft really assumes this) > Table of Contents: Section 3.2 assumes detailed knowledge (especially the three first sections) of sections 4 and 5. Suggest making a forward reference in the intro of the section 3.2 and some patience from the reader :) Suggest adding section 3.2.9 (and perhaps 5.7) on "Closing of Security Associations": The SAs are closed as defined as in in the general case. As such, closing of the SAs causes all of the SAs to be closed also in multihoming scenarios. A host MAY add an ESP_INFO parameter to a CLOSE message to signal that a specific SA is to be close. The CLOSE-ACK message should also include the same ESP_INFO parameter. In the ESP_INFO parameter, the old SPI corresponds to SA to be removed. The new SPI and keymat index are set to zero. > 1. Introduction and Scope Add somewhere: The document assumes that ESP is being used. > We also do not consider localized mobility management extensions; Please define "localized mobility management extensions" or give an example of such a protocol. > 2. Terminology and Conventions > > Locator... It may also include transport port numbers or IPv6 Flow > Labels as demultiplexing context, or it may simply be a network > address. Further extensions of this document may also include transport port numbers or IPv6 Flow Labels as demultiplexing context. This document only defines it simply as a network address. Suggest adding also the definition of "SA selector" that later pops up in the text suddenly. Perhaps it would be nice to have some definitions also for SA and SPI also for the inexperienced reader. > 3. Protocol Model Add an small intro? Here would be a good place to mention that the UPDATE processing details are in sections 4 and 5. > 3.1. Operating Environment > .. > This document specifies extensions to the HIP protocol to enable > end-host mobility and multihoming. This document specifies extensions to the HIP protocol to enable end-host mobility and basic multihoming. > In summary, these extensions to the HIP protocol can carry new > addressing information to the peer and can enable direct > authentication of the message via a signature or keyed hash message > authentication code (HMAC) based on its host identity. In summary, these extensions to the HIP base protocol enable carrying of new address related information to the peer in HIP messages. The messages are authenticated using public key signatures and keyed hash message authentication codes (HMAC). > Figure 2: Architecture for HIP mobility and multihoming * The MH abbreviation is not explained in the text, nor in the caption. * I am not still convinced that the figure is more illustrative than confusing but I have nothing better to offer, so I let it be. Perhaps you need to be sure to mention in the text that it is neither a picture of the networking stack to be used for packet en/decapsulation nor a software module organization. * You may want to say that MH box is separate from HIP for i.e. to be usable also for other protocols? > The SPI (or other context tag if ESP is not used with HIP), and not > necessarily the IP addresses, is used to associate an incoming packet > with the right HITs. The SPI is used to associate an incoming packet with the right HITs. > The HIP base exchange establishes the HITs in use between the hosts, > the SPIs to use for ESP, and the IP addresses (used in the HIP > signaling packets). The HIP base exchange establishes the HITs in use between the hosts, the SPIs to use for ESP, and the IP addresses (used both in the HIP signaling packets and ESP data packets). > Note that there can only be one such binding in the outbound > direction for any given packet, and the only selectors for the > binding at the HIP layer are the fields exposed by ESP (the SPI and > HITs). What binding? HIT-to-IP or HIT-to-SPI or IP-to-SPI? What selectors, and what are they supposed to select? > This document specifies the messaging and elements of procedure for > such a mobility event. This sentence can be safely removed. > Finally, consider the case when a host is multihomed (has more than > one globally routable address) and wants to make these multiple > addresses available for use by the upper layer protocols, for fault > tolerance. Finally, consider the case when a host is multihomed (has more than one globally routable address) and makes these multiple addresses available for use by the upper layer protocols, for example, for fault tolerance. > However, only one SPI and address can be used for any given packet, so > the job of the "MH" block depicted above is to dynamically manipulate > these bindings. However, only one SPI and address pair can be used for an ESP packet, so the job of the "MH" block depicted above is to dynamically manipulate these bindings. Comment: seems like the MH is really required for: * Selection of outgoing SAs if multiple present (for incoming it is not really necessary because we just use SPI present in the packet) * Perhaps for tracking the CBA credits and communicating them to HIP. Maybe you want to de-blur the meaning of the MH somewhere in section 3.1. See also my next comment. > This document does not specify the "MH" block, nor does it specify > detailed elements of procedure for how to handle various multihoming > (perhaps combined with mobility) scenarios. The document wants to specify a blurry concept of MH but really does not do it? Compare to my previous comment. > 3.1.1. Locator > > Or locators may merely be traditional network addresses. In Section > 4, a generalized HIP LOCATOR parameter is defined that can contain > one or more locators (addresses). It is also possible that locators are merely traditional network addresses. The actual format of the locators is defined in section 4. > 3.1.2. Mobility overview > > This UPDATE packet is acknowledged by the peer, and is > protected by retransmission. This UPDATE packet is acknowledged by the peer. To ensure that packets are not lost or corrupted, proper retransmission mechanisms are used. > However, the peers are not able to reply before they can reliably and > securely update the set of addresses that they associate with the > sending host. s/reply/comminicate/ > 3.1.3. Multihoming overview > > Although this document defines a mechanism for multihoming, basic mechanism > 3.2. Protocol Overview It might be good to explain the ESP_INFO old and new SPI fields because they are not introduced but still used the subsections. > Each of the scenarios below assumes that the HIP base exchange has > completed, and the hosts each have a single outbound SA to the peer > host. Associated with this outbound SA is a single destination > address of the peer host-- the source address used by the peer > during the base exchange. The scenarios below assume that the two hosts have completed a single HIP base exchange with each other. Both of the hosts have one incoming and one outgoing SA. Further, each SA contains the two IP addresses the hosts were using for the base exchange. > The main packets on which the LOCATOR parameters are expected to be > carried are UPDATE packets. The majority of packets on which the LOCATOR parameters are expected to be carried on are UPDATE packets. > 3.2.1. Mobility with single SA pair (no rekeying) Add some text between the figure and numbered bullets: The steps of the packet processing are as follows: In second bullet: s/hte/the/ > 3.2.1.2. Mobility with single SA pair (peer-initiated rekey) What was the use case for doing this? If there is no really strong use case, I suggest removing this section from the draft and perhaps adding it a follow-up draft. This way, the state machine has a simpler design (three packets) and is easier to implement. See my following email. > 3.2.2. Host multihoming > > Consider the case between two single-homed hosts, in which one of > the host notifies the peer of an additional address. Consider the case between hosts, one single-homed and the other multi-homed. The multihomed host notifies the peer of an additional address. > It is RECOMMENDED that the host set up a new SA pair for use on this > new address. s/host/multihomed host/ > A Locator Type of "1" is used to associate the new address with the > new SPI. The LOCATOR parameter also contains a second Type 1 > locator: that of the original address and SPI. The latter sentence does not really make sense: * The sentence above basically says that there is a locator parameter embedded inside another locator parameter. * If it was meant that there are actually two separate locators this does make sense because in the figure below shows only one and somewhere in the draft it was said that multiple locator parameters are out of scope. > To simplify parameter processing and avoid explicit protocol > extensions to remove locators, each LOCATOR parameter must list all > locators in use on a connection (a complete listing of inbound > locators and SPIs for the host). s/must/MUST/ > The multihomed host transitions to state REKEYING, waiting for a > ESP_INFO (new outbound SA) from the peer and an ACK of its own > UPDATE. REKEYING state does not exist anymore. > As in the mobility case, the peer host must perform an > address verification before putting the new address into active use. s/putting/changing/ > Figure 6 illustrates the basic packet exchange. Figure 6 illustrates this scenario. > Figure 6: Basic multihoming scenario Is the ECHO_RESPONSE 100 % sure way to map the last incoming UPDATE to certain SA? Why don't we just include the ESP_INFO? If this is the case, why don't we do also for the other use cases for generality's sake. > When processing inbound LOCATORs that establish new security > associations on an interface with multiple addresses, a host uses the > destination address of the UPDATE containing LOCATOR as the local > address to which the LOCATOR plus ESP_INFO is targeted. Hosts may > send UPDATEs with the same IP address in the LOCATOR to different > peer addresses-- this has the effect of creating multiple inbound SAs > implicitly affiliated with different peer source addresses. This text was just somehow too confusing. Suggest rewriting again with simplicity in mind, or removing (I am almost sure that this text is described also later on). > 3.2.4. Dual host multihoming > > In Figure 7, consider that host1 wants to add address addr1b. Please explain what addresses and SPIs are negotiated before this. > It would send an UPDATE with LOCATOR to host2 located at addr2a, and > a new set of SPIs would be added between hosts 1 and 2 (call them > SPI1b and SPI2b). Please make sure that this sentence makes sense after describing the initial scenario better. Also, SPI1b and SPI2b are not shown in the figure. > 3.2.6. Using LOCATORs across addressing realms > > In such a case, some type > of mechanism for interworking between the different realms must be > employed; such techniques are outside the scope of the present text. Maybe you could still mention few experimental techniques. The problem is as follows: * Host I has run base exchange with host R using IPv6 * IPv4 address is added to host I * Host I is supposed to send UPDATE to host R * LOCATOR = the new IPv4 address * IP header source address = the new IPv4 address * IP header dst address = So, the problem is that the host I has no knowledge of the R's IPv4 address. This can be handled in at least in two ways: a) Both the IPv4 and IPv6 address of R are known by host I before it initiates base exchange, e.g., they are configured manually or DNS. b) Host R communicates both its IPv4 and IPv6 address to host I in the R1 packet in LOCATOR (as defined in section 3.2.8). (The methods above were obtained from a discussion with Jan) > 3.2.8. Initiating the protocol in R1 or I2 3.2.8. Communicating LOCATORs in R1 or I2 > All new non-preferred locators must still undergo address > verification. as defined in section XX ...but only after the base exchange has completed. > Even if the I2 packet contains LOCATOR parameters, the Responder > MUST still send the R2 packet to the source address of the I2. I1 and I2 source address must be the same? > The new preferred locator SHOULD be identical to the I2 source > address. If the I2 packet contains LOCATOR parameters, all new > locators must undergo address verification as usual. Finally, the possibly following ESP traffic uses the negotiated preferred locators. Perhaps also the ESP traffic could be illustrated also in the figures. Also, a figure for the case where both hosts include additional locators would be nice. > 3.3.2. Credit-Based Authorization > > Credit-Based Authorization allows a host to securely use a new > locator even though the peer's reachability at the address embedded > in this locator has not yet been verified. s/this/the received/ > 1. A flooding attacker typically seeks to somehow multiply the > packets it generates itself for the purpose of its attack because > bandwidth is an ample resource for many attractive victims. s/itself// s/attractive// > 3. Consequently, the additional effort required to set up a > redirection-based flooding attack would pay off for the attacker > only if amplification could be obtained this way. 3. Consequently, the additional effort required to set up a redirection-based flooding attack (without CBA and return routability checks) would pay off for the attacker only if amplification could be obtained this way. > On this basis, rather than eliminating malicious packet redirection in > the first place, Credit-Based Authorization prevents any amplification > that can be reached through it. On this basis, rather than eliminating malicious packet redirection in the first place, Credit-Based Authorization prevents any packet amplifications. > Figure 10 illustrates Credit-Based Authorization: Host B measures > the bytes recently received from peer A and, when A readdresses, > sends packets to A's new, unverified address as long as the sum of > their sizes does not exceed the measured, received data volume. What is "their" referring to? > Figure 10. Can the "+ address change" in the lower left corner be removed? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 03 11:54:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQRNV-0005tl-E0; Mon, 03 Apr 2006 11:54:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQRNT-0005V3-Cz for hipsec@ietf.org; Mon, 03 Apr 2006 11:54:03 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQRNS-00088E-Tk for hipsec@ietf.org; Mon, 03 Apr 2006 11:54:03 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 72FD23045; Mon, 3 Apr 2006 18:54:02 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20040914 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20040914 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 9617D3044 for ; Mon, 3 Apr 2006 18:54:01 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k33Fs1805486; Mon, 3 Apr 2006 18:54:01 +0300 (EEST) Date: Mon, 3 Apr 2006 18:54:01 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Subject: [Hipsec] a state machine proposal for mm-03 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Simplified State Machine without Peer Initiated Rekeying ======================================================== Note1: since there are no other HIP header types for mobility and multihoming (other than UPDATE), the actual packet processing depends on the parameters in the HIP packet. Note2: the state machine is simpler to design if we leave out the peer initiated rekeying (section 3.2.1.2 in the draft). This way, we can assume that the UPDATE exchange consists of three packets and that each packet can be distinguished from each other by the precence of LOCATOR, ECHO_REQUEST or ECHO_RESPONSE. Note3: reusing the same state variables on both hosts. At the mobile host (the sender of LOCATOR) it is related to the data structures of the source IP. On the corresponding node (receiver of LOCATOR), it is related to the destination IP. Note4: need some fresh eyes to verify that this is actually sensible :) Send UPDATE with LOCATOR: - Triggered at the MN depending on changes in network attachments and according to local policies - Removed addresses are DEPRACATED (and not included in the LOCATOR) - All other addresses are UNVERIFIED (and included in the LOCATOR) - Set preferred LOCATOR depending on local policies - Send UPDATE with LOCATOR for the CN Receive HIP UPDATE: - Verify the HIP packet: HMAC, SIG, the presence, dependencies and validity of the parameters. - If the result is failure, goto DROP. - If success, proceed based on presence of LOCATOR, ECHO_REQUEST or ECHO_RESPONSE (only one of them can be contained in the packet) Received LOCATOR: - For each MN address in the received LOCATOR - State is DEPRACATED or UNKNOWN - Goto UNVERIFIED and send ECHO_REQUEST - State is UNVERIFIED - Resend ECHO_REQUEST and decrease retransmission timeout - Any other state, DROP Received ECHO REQUEST: - For each MN address in the corresponding LOCATOR - State is UNVERIFIED - Goto ACTIVE and send ECHO_RESPONSE - Any other state, DROP Received ECHO_RESPONSE: - Goto DEPRACATED for all old addresses not present in LOCATOR - For each MN address in the corresponding LOCATOR - State is UNVERIFIED - Otherwise goto ACTIVE - Change preferred LOCATOR when necessary - Any other state, DROP Receive ESP: - For the ESP address - State is UNVERIFIED - Verify ESP validity. Goto DROP if failed - Change preferred LOCATOR when necessary - Process ESP if there are credits left, and decrease credits. - Otherwise DROP - State is ACTIVE - Process ESP - Any other state, DROP Send ESP: - Increase credits UPDATE retransmission timeout for LOCATOR (at MN): - State is UNVERIFIED - Resend and decrease retransmission counter - Any other state - DROP and zero retransmission counter UPDATE retransmission timeout for ECHO_REQUEST (at CN): - State is UNVERIFIED - Resend and decrease retransmission counter - Any other state - DROP and zero retransmission counter UPDATE retransmission timeout for ECHO_RESPONSE (occurs at the MN when no ESP was received from the CN from a new address?): - State is ACTIVE - Resend and decrease retransmission counter - Any other state - DROP and zero retransmission counter Handling of CLOSE with ESP_INFO: - TBD -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 03 17:29:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWcB-0008Ay-5j; Mon, 03 Apr 2006 17:29:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWc9-0008At-Ox for hipsec@lists.ietf.org; Mon, 03 Apr 2006 17:29:33 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQWc8-0006XY-7J for hipsec@lists.ietf.org; Mon, 03 Apr 2006 17:29:33 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id A7DA82E95; Tue, 4 Apr 2006 00:29:31 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20040914 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20040914 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id D75052E95 for ; Tue, 4 Apr 2006 00:29:30 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k33LTUc26574; Tue, 4 Apr 2006 00:29:30 +0300 (EEST) Date: Tue, 4 Apr 2006 00:29:30 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@lists.ietf.org Subject: Re: [Hipsec] some comments for mm-03 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org > Some comments for mm-03, part 1/2 (I'll send the rest later this > evening). Here we go again.. decided to split the email on separate sections. Here is (the end of section three and) section 4. > 3.3.4. Interaction with Security Associations > > This document specifies a new HIP protocol parameter, the LOCATOR > parameter (see Section 4), that allows the hosts to exchange information > about their locator(s), and any changes in their locator(s). This document specifies a new HIP protocol parameter, the LOCATOR parameter (see Section 4), that allows the hosts to exchange information about changes their locator(s). > The relation between these entities for an association negotiated as > defined in the base specification [2] and ESP transform [5] is > illustrated in Figure 11. What entities? There is also something other fishy with this sentence. > The addresses addr1a and addr2a are the source addresses that each host > uses in the base HIP exchange. The addresses addr1a and addr2a are the source addresses that the hosts use in the base HIP exchange. > These are the "preferred" (and only) addresses conveyed to the peer for > each SA; even though packets sent to any of the hosts' interfaces can > arrive on an inbound SPI, when a host sends packets to the peer on an > outbound SPI, it knows of a single destination address associated with > that outbound SPI (for host1, it sends a packet on SPI2a to addr2a to > reach host2), unless other mechanisms exist to learn of new addresses. * Perhaps you just replace the SA with SPI because SA is not really illustrated in the figure. * This is an overly long sentence, suggest splitting into 2-3 sentences. * I think that "arrive on SPI", "send to peer SPI" and "send packet on SPI" could be said in a better way. > In this figure, a host can have multiple inbound SPIs (and, not shown, > multiple outbound SPIs) between itself and another host. s/between/associated with/ > These addresses bound to an SPI are not used as SA selectors. (I suggested writing the term "SA selector" to the terminology in the beginning) > The LOCATOR parameter allows for IP addresses and SPIs to be combined to > form generalized locators. I am not sure if "generalized" is the right term, but rather "locators for suitable for IPsec use" etc. In any case, this sentence can be removed from here as it is repeated elsewhere. > Figure 12 This figure reminds me that is it possible to have both SPI1 and SPI2 mapping to the same ADDR21? > The main purpose of having multiple SPIs is to group the addresses into > collections that are likely to experience fate sharing. The main purpose of having multiple SPIs with a peer is to group the addresses into collections that are likely to experience fate sharing. > For this reason, HIP provides a mechanism to affiliate destination > addresses with inbound SPIs, if there is a concern that anti-replay > windows might be violated otherwise. s/if/when/ s/otherwise// > Moreover, even if the destination addresses used for a particular SPI > are held constant, the use of different source interfaces may also cause > packets to fall outside of the ESP anti-replay window, since the path > traversed is often affected by the source address or interface used. s/if/when > A host has no way to influence the source interface on which a peer uses > to send its packets on a given SPI. A host has no way to influence the source interface on which a peer sends its packets using a given SPI. > Hosts SHOULD consistently use the same source interface and address when > sending to a particular destination IP address and SPI. s/Hosts/A host/ > If the LOCATOR parameter is sent in an UPDATE packet, then the > receiver will respond with an UPDATE acknowledgment. When the LOCATOR parameter is sent in an UPDATE packet, then the receiver responds with an UPDATE acknowledgment. > If the LOCATOR parameter is sent in a NOTIFY, I2, or R2 packet, then the > recipient may consider the LOCATOR as informational, and act only when > it needs to activate a new address. If the LOCATOR parameter is sent in a NOTIFY, I2, or R2 packet, the recipient MUST consider the LOCATOR as informational, and act only when it needs to activate a new address. What does "act" mean here? > The use of LOCATOR in a NOTIFY message may not be compatible with > middleboxes. > 4. LOCATOR parameter format Is there are specific reason why the reserved field cannot be just flags? > Length: Length in octets, excluding Type and Length fields, and > excluding padding. Minimum length (is a locator without any address allowed)? Maximum length? > Locator Length: Defines the length of the Locator field, in units of > 4-byte words (Locators up to a maximum of 4*255 bytes are supported). s/bytes/octets/ > Locator: The locator whose semantics and encoding are indicated by the > Locator Type field. All Locator sub-fields are integral multiples of > four bytes in length. It is slightly confusing that there is LOCATOR and Locator :) Perhaps this should be noted in the terminology. s/bytes/octets/ > The address is expected to become deprecated when the specified number > of seconds has passed since the reception of the message. Also, CLOSE can be used for premature expiration of addresses. > A deprecated address SHOULD NOT be used as an destination address if an > alternate (non-deprecated) is available and has sufficient scope. In the case of many alternatives, the host chooses according to local host policies. > 4.1. Traffic Type and Preferred Locator > > The "P" bit, when set, has scope over the corresponding Traffic Type > that precedes it. s/precedes it// > That is, if a "P" bit is set for Traffic Type "2", for example, that > means that the locator is preferred for data packets. That is, when a "P" bit is set for Traffic Type "2", for example, it means that the locator is preferred for data packets. > If there is a conflict (for example, if P bit is set for an address of > Type "0" and a different address of Type "2"), the more specific Traffic > Type rule applies. If there is a conflict (for example, if P bit is set for an address of Type "0" and a different address of Type "2"), the more specific Traffic Type rule applies (in this case it was "2"). This seems to complicate the processing rules. Unless there is a special reason for doing this, it migth be easier to forbid mixing type 0 locators with type 1 or 2 locators. > 4.2. Locator Type and Locator > 0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [7] (128 > bits long). Suggest adding: Currently, mostly for non-ESP based usage. > 1: The concatenation of an ESP SPI (first 32 bits) followed by an > IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional > 128 bits). Suggest adding: Recommend for ESP based usage. > 4.3. UPDATE packet with included LOCATOR Add to this section some text about the correspondence between ESP_INFO and Type 1 LOCATORS. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 03 19:05:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQY7K-0007rG-RB; Mon, 03 Apr 2006 19:05:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQY7J-0007rB-MQ for hipsec@lists.ietf.org; Mon, 03 Apr 2006 19:05:49 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQY7H-0002m2-2F for hipsec@lists.ietf.org; Mon, 03 Apr 2006 19:05:49 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 9E0B72F0B; Tue, 4 Apr 2006 02:05:46 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20040914 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20040914 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 954312F06 for ; Tue, 4 Apr 2006 02:05:45 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k33N5jI29923; Tue, 4 Apr 2006 02:05:45 +0300 (EEST) Date: Tue, 4 Apr 2006 02:05:44 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@lists.ietf.org Subject: Re: [Hipsec] some comments for mm-03 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Tue, 4 Apr 2006, Miika Komu wrote: > > Some comments for mm-03, part 1/2 (I'll send the rest later this > > evening). > > Here we go again.. decided to split the email on separate sections. Here > is (the end of section three and) section 4. And here are comments from section five. > 5. Processing rules (perhaps a tiny intro) > 5.1. Locator data structure and status > > Rapidly sending conflicting LOCATORs SHOULD be avoided. What conflicting means here? This section does not talk about selecting the source address for a locator to be sent. Suggest adding text on what to choose as the source address: the newly obtained locator or, in the case of multiple obtained locators, selection according to a local policy. > 3. Host multihoming (addition of an address). We only describe the > simple case of adding an additional address to a single-homed, > non-mobile host. s/single-homed/multi-homed/ ? > To do this, the multihomed host creates a new inbound SA and creates a > new ESP_INFO parameter with an "Old SPI" parameter of "0", a "New SPI" > parameter corresponding to the new SPI, and a "Keymat Index" as selected > by local policy. To do this, the multihomed host creates a new inbound SA and creates a new SPI. For the outgoing UPDATE message, it inserts an ESP_INFO parameter with an "Old SPI" field of "0", a "New SPI" field corresponding to the new SPI, and a "Keymat Index" as selected by local policy. > 5.3. Handling received LOCATORs > > A host SHOULD be prepared to receive a LOCATOR parameter in any HIP > packet, excluding I1. ...and CLOSE and notify? > The ESP_INFO parameter is included if there is a need to rekey or key a > new SPI s/if/when/ > The LOCATOR parameter contains a complete map of the locators that the > host wishes to make or keep active for the HIP association. Currently, only a single ESP_INFO and LOCATOR are allowed in a HIP message. > 1. The host checks if the New SPI listed in the ESP_INFO is a new > one. If it is a new one, it creates a new inbound SA with that > SPI that contains no addresses. If it is an existing one, it > prepares to change the address set on the existing SPI. If the SPI is invalid, the packet MUST be dropped. > 2. For each locator listed in the LOCATOR parameter, check that the > address therein is a legal unicast or anycast address. That is, > the address MUST NOT be a broadcast or multicast address. the > local host, since it may be allowed that the host runs HIP with > itself. Also, when receiving link local addresses, they should be used only when no public addresses are present. The link local addresses may create reachability problems after the host moves to another network. > 3. For each Type 1 address listed in the LOCATOR parameter, check if > the address is already bound to the SPI indicated. For each Type 1 address listed in the LOCATOR parameter, the host checks if the address is already bound to the SPI indicated. > Mark all addresses on the SPI that were NOT listed in the LOCATOR > parameter as DEPRECATED. Mark all addresses corresponding to the SPI that were NOT listed in the LOCATOR parameter as DEPRECATED. > As a result, the SPI now contains any addresses listed in the LOCATOR > parameter either as UNVERIFIED or ACTIVE, and any old addresses not > listed in the LOCATOR parameter as DEPRECATED. As a result, the addresses listed in the LOCATOR parameter have a either state of UNVERIFIED or ACTIVE, and any old addresses not listed in the LOCATOR parameter have a state of DEPRECATED. > 4. If the LOCATOR is paired with an ESP_INFO parameter, the ESP_INFO > parameter is processed as follows: 4. Here, it is assumed that the LOCATOR is paired with an ESP_INFO which is processed as follows: Should this be actually the first bullet instead of fourth? (suggest using a different numbering style, e.g. letters, for the following bullets) > 1. If the Old SPI indicates an existing SPI and the New SPI is a > different non-zero value, the existing SA is being rekeyed > and the host follows HIP ESP rekeying procedures. Note that > the Locators in the LOCATOR parameter will use this New SPI > instead of the Old SPI. Do you mean Type 0 Locators? Type 1 Locators have an additional SPI field. > 2. If... When... > 3. If the Old SPI indicates an existing SPI and the New SPI is > zero, the SPI is being deprecated and all locators uniquely > bound to the SPI are put into DEPRECATED state. s/If/When/ Is the LOCATOR still processed, and if yes, how? > 4. If the Old SPI equals the New SPI and both correspond to an > existing SPI, the ESP_INFO is gratuitous (provided for > middleboxes) and no rekeying is necessary. s/equals/equals to/ 5. Otherwise, drop? > 5. Mark all locators on each SPI that were NOT listed in the LOCATOR > parameter as DEPRECATED. s/on/for/ > Once the host has updated the SPI, if the LOCATOR parameter contains > a new preferred locator, the host SHOULD initiate a change of the > preferred locator. This requires that the host first verifies > reachability of the associated address, and only then changes the > preferred locator. See Section 5.6. Once the host has updated the SPI and the LOCATOR parameter contains a new preferred locator, the host SHOULD first verify the reachability of the preferred locator. Only after that the host uses it for ESP communication with the peer. See Section 5.6. > 5.4. Verifying address reachability I'd say explicitly the following somewhere in this chapter because it is really manifested in the text: All of the new addresses received in a locator MUST be verified separately. This means that for each UPDATE with LOCATOR with N new Locators, N UPDATE ECHO_REQUEST packets must be sent and accepted. The source address of ECHO_REQUEST is the preferred address of the local host. > For example, if the host is changing its SPI and is sending an ESP_INFO > to the peer, the new SPI value SHOULD be random and the value MAY be > copied into an ECHO_REQUEST sent in the rekeying UPDATE. s/if/when/ > If the host is not rekeying, it MAY still use the ECHO_REQUEST parameter > in an UPDATE message sent to the new address. However, when the host is not changing its SPI, the MAY still add the ECHO_REQUEST parameter in an UPDATE message sent to the new address. > Note that in the case of receiving a LOCATOR on an R1 and replying with > an I2, receiving the corresponding R2 is sufficient proof of > reachability for the Responder's preferred address. Note that in the case of receiving a new LOCATOR in an R1 and replying with an I2 to the new address in the LOCATOR, receiving the corresponding R2 from the new address is sufficient proof of reachability for the Responder's preferred address. > In some cases, it may be sufficient to use the arrival of data on a > newly advertised SA as implicit address reachability verification, > instead of waiting for the confirmation via a HIP packet (e.g., Figure > 14). In some cases, it MAY be sufficient to use the arrival of data on a newly advertised SA as implicit address reachability verification as depicted in Figure 14, instead of waiting for the confirmation via a HIP packet. > Marking the address ACTIVE as a part of receiving data on the SA is an > idempotent operation, and does not cause any harm. Incorrect. The state is not changed as described 5.5.1. > Figure 14 I think the names of "Mobile Host" and "Peer Host" could be swapped since it is the "Peer Host" that is sending the SPI. Maybe "Peer Host" can be changed to "Corresponding Node". > 5.5. Credit-Based Authorization Add an intro. "CBA can be used to minimize the side effects of handovers. It allows sending of data before address reachability test has been completed to avoid transport layer timing problems. However, CBA cannot be used for redirection amplification attacks." > 5.5.1. Handling Payload Packets > When the host has a packet to be sent to the peer, if the peers > preferred locator is listed as UNVERIFIED and no alternative locator > with status ACTIVE is available, the host checks whether it can send the > packet to the UNVERIFIED locator: The packet SHOULD be sent if the value > of the credit counter is higher than the size of the outbound packet. When the host has a packet to be sent to the peer, and when the peers preferred locator is listed as UNVERIFIED and no alternative locator with status ACTIVE is available, the host checks whether it can send the packet to the UNVERIFIED locator. The packet SHOULD be sent if the value of the credit counter is higher than the size of the outbound packet. > 5.5.2. Credit Aging Is not obvious to me what should be the initial credit size? > Credit aging may be implemented by multiplying credit counters with a > factor, CreditAgingFactor, less than one in fixed time intervals of > CreditAgingInterval length. s/one/once/ ? > 5.6. Changing the preferred locator 5.6. Changing the Preferred Locator This section could be moved before CBA, that is, between sections 5.4 and 5.5. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Apr 05 03:34:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR2Ws-0002ka-TT; Wed, 05 Apr 2006 03:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR2Ws-0002jo-0r for hipsec@lists.ietf.org; Wed, 05 Apr 2006 03:34:14 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR2Wo-0000hN-Gz for hipsec@lists.ietf.org; Wed, 05 Apr 2006 03:34:13 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 7F29E2FC8; Wed, 5 Apr 2006 10:34:04 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20040914 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20040914 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 2C8242FA5 for ; Wed, 5 Apr 2006 10:34:02 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k357Y1Z07864; Wed, 5 Apr 2006 10:34:01 +0300 (EEST) Date: Wed, 5 Apr 2006 10:34:01 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@lists.ietf.org Subject: Re: [Hipsec] some comments for mm-03 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org My last comments, from section six: > 6. Security Considerations > > If no precautionary measures are taken, an attacker could misuse this > feature to impersonate a victim's peer from any arbitrary location. s/this/the redirection/ > If an attacker somehow uses a bug in the implementation or weakness in > some protocol to redirect a HIP connection, the original owner can > always reclaim their connection (they can always prove ownership of the > private key associated with their public HI). How is this possible if the private key is compromised? > MitM attacks are always possible if the attacker is present during the > initial HIP base exchange and if the hosts do not authenticate each > other's identities, but once the base exchange has taken place even a > MitM cannot steal an opportunistic HIP connection because it is very > difficult for an attacker to create an UPDATE packet (or any HIP packet) > that will be accepted as a legitimate update. This does not make sense because it is too obvious? After opportunistic connection (leap of faith) the connection is no longer opportunistic. Maybe this text can be just removed. > 6.2. Denial of Service attacks > This threat is mitigated through reachability checks and credit-based > authorization. This threat is mitigated through reachability checks and credit-based authorization strategies. > As a result, the combination of a reachability check and credit-based > authorization makes a HIP redirection-based flooding attack as effective > and applicable as a normal, direct flooding attack in which the attacker > itself sends the flooding traffic to the victim. As a result, the combination of a reachability check and credit-based authorization degrades a HIP redirection-based flooding attack to the level of a direct flooding attack in which the attacker itself sends the flooding traffic to the victim. > First, when a reachability packet is received, this nonce packet MUST be > ignored if the HIT is not one that is currently active. First, when a reachability packet is received, the nonce in the packet MUST be ignored if the HIT is not one that is currently active. What does a currently active HIT mean? You probably mean address... > Second, if the attacker is a MitM asnd can capture this nonce packet > then it can respond to it, in which case it is possible for an attacker > to redirect the connection. How? > 6.2.2. Memory/Computational exhaustion DoS attacks Suggest adding some text that central servers may have to deal with multiple mobile clients that change their location rapidly. This may burn too many CPU cycles of the server, and in such a case, the server may want to e.g. increase its SA lifetimes or increase cookie difficulty to slow down acceptance of new connections. > 6.3. Mixed deployment environment s/user/host/ in this section? s/their/its/ in this section I did not get the purpose of this section. If you user A uses IPsec, user B does not get anything meaninful even though the IPsec data is redirected from A to B. > ..connection with and then attempts to use a IPv6 change of address > request to steal the HIP user's connection. ..connection with and then attempts to change its IPv6 address to steal the HIP user's connection. > 4. .. What is a session here? TCP session? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Apr 06 03:19:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FROlW-0006oa-CP; Thu, 06 Apr 2006 03:18:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FROlV-0006oV-0k for hipsec@ietf.org; Thu, 06 Apr 2006 03:18:49 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FROlT-0003GM-85 for hipsec@ietf.org; Thu, 06 Apr 2006 03:18:48 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3CB68212C4E; Thu, 6 Apr 2006 10:18:45 +0300 (EEST) Received: from [193.234.219.118] (n118.nomadiclab.com [193.234.219.118]) by n2.nomadiclab.com (Postfix) with ESMTP id 95EE8212C46; Thu, 6 Apr 2006 10:18:44 +0300 (EEST) Message-ID: <4434C0D3.40905@nomadiclab.com> Date: Thu, 06 Apr 2006 10:18:43 +0300 From: Petri Jokela User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Hipsec] [Fwd: Fwd: Belovin-Rescorla analysis - HIP] References: <4430026F.6000204@ericsson.com> In-Reply-To: <4430026F.6000204@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: Pekka Nikander , HIP , Petri Jokela , charliek@exchange.microsoft.com X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hello everyone, Thanks Charlie for the analysis! Comments, questions, and possible actions in-line. Those issues that do not cause any actions should be described in the draft (Security considerations). > Charlie Kaufman did the security review for HIP. Please take a look > at his review, and let us know your thoughts. > > Russ > >> From: Charlie Kaufman >> To: Russ Housley , "secdir@mit.edu" >> >> CC: "hartmans-ietf@mit.edu" >> Date: Thu, 23 Mar 2006 12:49:35 -0800 >> Subject: RE: [secdir] [Fwd: Belovin-Rescorla analysis] - HIP >> The HIP base document makes a normative reference to >> draft-laganier-ipv6-khi-01, and that document wires in both use of >> SHA-1 and the extraction of a particular 120 bits of the SHA-1 hash. >> Switching to use 120 bits of a SHA-256 hash would not be terribly >> difficult, but it's not clear that would be any more secure. The only way to solve this issue is to modify the ORCHID (KHI) draft. There is nothing we can do in the HIP base draft; we need those HITs defined somewhere. >> There are no real attacks on HIP based on finding collisions, but as >> with many of these protocols there could be long theoretical >> discussions about how finding collisions would be interesting. A real >> attack would depend on the ability to find a second preimage. >> >> There are other places where SHA-1 is wired in with no mechanism for >> negotiating anything else. None can be exploited given collision >> attacks. They are: >> >> 1) Key expansion: hash is not negotiated - SHA-1 wired in. This could be changed to contain a non-fixed algorithm, possibly in a similar way as in puzzle where the algorithm is defined to be the same that is used in Responder's HIT generation. >> 2) Puzzles: SHA-1 is certainly "good enough" for puzzles, since any >> weakness would have to find a first preimage more quickly than >> computing a small number of hashes. Ok. >> 3) HMAC and encryption algorithms are negotiated, but currently SHA-1 >> and MD5 are the only registered options. In one place, the size of the >> output of the HMAC is fixed at 160 bits. This is probably a bug in the >> spec and easily fixed. I assume that this comment refers to the HMAC and HMAC_2 parameters. The 160 limit comes from the HMAC RFC 2104 (reference missing from the draft) and the length for HMAC is 160 bits. The current specification could work also with other algorithms, but in the HMAC field only the low-order 160 bits of the HMAC calculation are included. This should be changed to a variable length field with the length depending on the used hash algorithm. >> 4) When doing signatures, the HASH type is not negotiated but rather >> is assumed to be determined by the signature algorithm (which is also >> not negotiated). Each endnode decides the signature and hash >> algorithms it is going to used and the other endnode can accept it or >> not. The spec references RFCs 2536 and 3110 to match up signature and >> hash algorithms. This is probably acceptable. So this seems to be ok. >> There are other places where crypto-agility is not all that it might be: >> >> 1) There is no negotiation of Diffie-Hellman groups. The responder >> chooses. This means that if both ends support multiple groups and >> there is some overlap, the negotiation could still fail if the >> initiator does not support the responder's default group. As with >> IKEv1, connections might succeed if initiated from one end but not >> from the other. If an implementation compensates for this by trying >> different groups upon retry, the protocol is subject to a downgrade >> attack where a man-in-the-middle can get the two ends to use a group >> weaker than one they would both prefer. This would be straightforward >> (but not trivial) to fix. This issue has been discussed earlier in the HIPSEC list (Dec. 2003). The conclusion (at that time) was to use two mandatory Groups and rest were defined as "SHOULD be implemented". Negotiation was discussed, but never adopted; R1 would have contained for example two different DHs. The current system is slightly weird: when the responder sends the (only) DH proposal, the initiator cannot have anything to say to that, except to accept or deny it. Especially when the initiator is a slow PDA, supporting only weak encryption, and the server offers something else the connection can never be established even the server might be willing to do that with lower security. But if it supports these PDAs, it must always send the weak group in the R1, and nobody can get better security when talking to the server. ( Was this confusing enough :-) Link to the old discussion: http://honor.trusecure.com/pipermail/hipsec/2003-December.txt.gz Should we allow the server to send max two D-H groups in one DIFFIE_HELLMAN TLV, or shall we be happy with the current system, where almost all connections can be set up? >> 2) No key size is negotiated. Use of AES implies use of 128 bit keys. >> This is not a serious problem - it just means that if support of AES >> with bigger keys is desired, they must be treated as different >> encryption algorithms. No actions(?) >> 3) Fixing the "wired-in" uses of SHA-1 will require a new version >> number in the protocol, but there is a version downgrade attack. The >> current spec says that if the version number you get is not supported, >> you reject it with an unsigned ICMP message. This means two endnodes >> could likely be tricked by a man-in-the-middle to use the older >> version of the protocol even if they both support the newer one. Shall we leave these as a headache for the HIP v2 designers? >> Other Security Concerns (beyond crypto-agility): >> >> Many packets are integrity protected with both an HMAC and a digital >> signature. This is inefficient because it requires extra public key >> operations. It is done for the benefit of middle-boxes that don't know >> the HMAC keys but want to be able to verify the packet contents for >> updating NAT and firewall configurations. As it stands, the protocol >> is secure but slow. If the signatures were left out or unverified, >> certain subtle vulnerabilities are introduced. Speeding up things and changing these issues would require a lot of work. (Maybe something for HIP v2 ?) >> There is mandatory support for ESP with HMAC-SHA1 and either Null or >> AES128CBC encryption. This is mandatory not just in the implementation >> but also in the configuration. (i.e., as written, the spec says that >> one of those two suites must be offered in every negotiation). The reason for this was that we would have something common between all nodes. >> Assurance that two sessions will always use different session keys is >> fragile. The keys are derived from the Diffie-Hellman keys and puzzle >> challenges and responses, all of which can be reused. Perhaps I missed >> it, but there should probably be more explicit guidance on how to >> avoid this or explicit nonces should be added. If we change some value in each of the R1s, we need to recalculate R1s when we send them out. This opens some DoS attack possibilities. It means also that we lose the advantage of pre-generating R1 messages. Currently there is a requirement that puzzles must be re-calculated every few minutes (one possible way to implement is described in Appendix A). The problem would exist only when two hosts negotiate the association, close it, and renegotiate it within the time when the set of pre-generated R1s is valid. >> Around line 1829, the base spec says "All HIP implementations MUST >> employ a reassembly algorithm that is sufficiently resistant to DoS >> attacks." This statement is too vague to be useful (and arguably >> impossible). It should probably be changed to be implementer advice. Ok. >> Notifications are not acknowledged or protected from replay. Today, >> notifications are only used for diagnostics, so a third party >> filtering, duplicating, and reordering them probably can't do >> substantial damage. It does seem suspicious though. At the minimum, we could add a warning that NOTIFY messages are not trustworthy. >> When doing "opportunistic" HIP negotiation, when node A wants to send >> to node B and doesn't know whether node B supports HIP, it has three >> choices: 1) It can hold the first packet to B while it tries to >> negotiate HIP, and if that fails send the first packet unprotected; 2) >> It can forward the first packet unprotected and in parallel try to >> negotiate HIP. If the negotiation succeeds, it can start using the ESP >> tunnel; or 3) it can not try to negotiate HIP. Each of these >> mechanisms has problems. The spec should offer some guidance. It's >> possible this is provided in one of the other HIP documents. Maybe a recommendation: 6.6. Initiating a HIP connection The host should try to establish an opportunistic mode HIP association sending at most I1_RETRIES_MAX I1 packets. If it does not receive any R1s, it can try to initiate the connection without HIP if local policy allows. >> Non-security concerns: >> >> Use of Extended Sequence Numbers is not negotiated; either end can >> mandate it. If all endpoints are required to support ESNs, it would be >> simpler to just mandate their use all the time. If not, the >> negotiation should allow one end to propose their use and the other to >> accept it. What do people think? Should we go for mandatory 64-bit sequence numbers directly, or is there some advantage of staying at 32? /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Apr 06 04:13:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRPcO-0004YC-Dt; Thu, 06 Apr 2006 04:13:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRPcN-0004Y7-T3 for hipsec@ietf.org; Thu, 06 Apr 2006 04:13:27 -0400 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRPcN-0005hu-5w for hipsec@ietf.org; Thu, 06 Apr 2006 04:13:27 -0400 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id UAA14730; Thu, 6 Apr 2006 20:13:19 +1200 In-Reply-To: <4434C0D3.40905@nomadiclab.com> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [Hipsec] [Fwd: Fwd: Belovin-Rescorla analysis - HIP] Date: Thu, 6 Apr 2006 20:13:54 +1200 To: Petri Jokela X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: Pekka Nikander , HIP , Petri Jokela , charliek@exchange.microsoft.com X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On 06/04/2006, at 7:18 PM, Petri Jokela wrote: > Hello everyone, > > Thanks Charlie for the analysis! > > Comments, questions, and possible actions in-line. Those issues > that do not cause any actions should be described in the draft > (Security considerations). I have a few further comments inline. > >> Charlie Kaufman did the security review for HIP. Please take a look >> at his review, and let us know your thoughts. >> Russ >>> From: Charlie Kaufman >>> To: Russ Housley , "secdir@mit.edu" >>> >>> CC: "hartmans-ietf@mit.edu" >>> Date: Thu, 23 Mar 2006 12:49:35 -0800 >>> Subject: RE: [secdir] [Fwd: Belovin-Rescorla analysis] - HIP > >>> There are other places where crypto-agility is not all that it >>> might be: >>> >>> 1) There is no negotiation of Diffie-Hellman groups. The >>> responder chooses. This means that if both ends support multiple >>> groups and there is some overlap, the negotiation could still >>> fail if the initiator does not support the responder's default >>> group. As with IKEv1, connections might succeed if initiated from >>> one end but not from the other. If an implementation compensates >>> for this by trying different groups upon retry, the protocol is >>> subject to a downgrade attack where a man-in-the-middle can get >>> the two ends to use a group weaker than one they would both >>> prefer. This would be straightforward (but not trivial) to fix. > > This issue has been discussed earlier in the HIPSEC list (Dec. 2003). > The conclusion (at that time) was to use two mandatory Groups and rest > were defined as "SHOULD be implemented". Negotiation was discussed, > but never adopted; R1 would have contained for example two > different DHs. We implemented this at one stage before the big packet format change... IIRC it worked fine. I think it should be resurrected. > >>> 2) No key size is negotiated. Use of AES implies use of 128 bit >>> keys. This is not a serious problem - it just means that if >>> support of AES with bigger keys is desired, they must be treated >>> as different encryption algorithms. > > No actions(?) Just define the code points for them. > >>> 3) Fixing the "wired-in" uses of SHA-1 will require a new version >>> number in the protocol, but there is a version downgrade attack. >>> The current spec says that if the version number you get is not >>> supported, you reject it with an unsigned ICMP message. This >>> means two endnodes could likely be tricked by a man-in-the-middle >>> to use the older version of the protocol even if they both >>> support the newer one. > > Shall we leave these as a headache for the HIP v2 designers? I think we should fix this one. > >>> Other Security Concerns (beyond crypto-agility): >>> >>> Many packets are integrity protected with both an HMAC and a >>> digital signature. This is inefficient because it requires extra >>> public key operations. It is done for the benefit of middle-boxes >>> that don't know the HMAC keys but want to be able to verify the >>> packet contents for updating NAT and firewall configurations. As >>> it stands, the protocol is secure but slow. If the signatures >>> were left out or unverified, certain subtle vulnerabilities are >>> introduced. > > Speeding up things and changing these issues would require a lot of > work. (Maybe something for HIP v2 ?) This is HIP v2 material, I think. > >>> There is mandatory support for ESP with HMAC-SHA1 and either Null >>> or AES128CBC encryption. This is mandatory not just in the >>> implementation but also in the configuration. (i.e., as written, >>> the spec says that one of those two suites must be offered in >>> every negotiation). > > The reason for this was that we would have something common between > all nodes. But Null should not be mandatory to offer. AES128CBC would do as a mandatory-to-offer. > >>> When doing "opportunistic" HIP negotiation, when node A wants to >>> send to node B and doesn't know whether node B supports HIP, it >>> has three choices: 1) It can hold the first packet to B while it >>> tries to negotiate HIP, and if that fails send the first packet >>> unprotected; 2) It can forward the first packet unprotected and >>> in parallel try to negotiate HIP. If the negotiation succeeds, it >>> can start using the ESP tunnel; or 3) it can not try to negotiate >>> HIP. Each of these mechanisms has problems. The spec should offer >>> some guidance. It's possible this is provided in one of the other >>> HIP documents. > > Maybe a recommendation: > > 6.6. Initiating a HIP connection > > The host should try to establish an opportunistic mode HIP > association sending at most I1_RETRIES_MAX I1 packets. If it does > not receive any R1s, it can try to initiate the connection without > HIP if local policy allows. And use option 1 in the meantime. 2 has many problems, because migrating a non-HIP connection to HIP is probably hard to implement. > >>> Non-security concerns: >>> >>> Use of Extended Sequence Numbers is not negotiated; either end >>> can mandate it. If all endpoints are required to support ESNs, it >>> would be simpler to just mandate their use all the time. If not, >>> the negotiation should allow one end to propose their use and the >>> other to accept it. > > What do people think? Should we go for mandatory 64-bit sequence > numbers > directly, or is there some advantage of staying at 32? Go straight to 64. Andrew _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 07 05:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUi-0000H0-KD; Fri, 07 Apr 2006 05:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUh-0000Fp-CF for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRnUg-0005xO-R9 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7A282212C64; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3601F212C5D; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) In-Reply-To: <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98E1DF9E-E0E1-4713-A379-566741D14BD2@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 7 Apr 2006 10:29:06 +0300 To: HIP X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: charliek@exchange.microsoft.com, Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis - HIP: wired-in SHA-1 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>>> 3) Fixing the "wired-in" uses of SHA-1 will require a new >>>> version number in the protocol, but there is a version downgrade >>>> attack. The current spec says that if the version number you get >>>> is not supported, you reject it with an unsigned ICMP message. >>>> This means two endnodes could likely be tricked by a man-in-the- >>>> middle to use the older version of the protocol even if they >>>> both support the newer one. >> >> Shall we leave these as a headache for the HIP v2 designers? > > I think we should fix this one. I agree. And I think we already decided to fix this by replacing all references to SHA-1 with a reference to the HIT hash algorithm. HIT hash algorithm, OTOH, is currently being defined by the KHI prefix. Changing the algorithm requires changing the prefix; that is clearly defined in the Security Considerations part of the KHI draft. The rationale here was that in non-opportunistic HIP the initiator can choose among the responder's HITs (if there are many), and thereby choose which hash algorithm to use, usually choosing the strongest one. A counter argument would be that opportunistic HIP might have problems. OTOH, in opportunistic HIP the responder could choose its HIT based on the Initiator's HIT if it recognises the prefix in the Initiator's HIT. If it doesn't, it could use still use SHA-1. That wouldn't most probably matter that much as opportunistic HIP is always vulnerable to man-in-the-middle attacks. Looking at -05, always referring to the HIT hash algorithm hasn't been implemented. Unfortunately I don't remember how we weighted the arguments and counter-arguments. Maybe this is just an issue that has slipped through in the editing process? My intention hFrom hipsec-bounces@lists.ietf.org Fri Apr 07 05:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUi-0000H0-KD; Fri, 07 Apr 2006 05:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUh-0000Fp-CF for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRnUg-0005xO-R9 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7A282212C64; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3601F212C5D; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) In-Reply-To: <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98E1DF9E-E0E1-4713-A379-566741D14BD2@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 7 Apr 2006 10:29:06 +0300 To: HIP X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: charliek@exchange.microsoft.com, Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis - HIP: wired-in SHA-1 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>>> 3) Fixing the "wired-in" uses of SHA-1 will require a new >>>> version number in the protocol, but there is a version downgrade >>>> attack. The current spec says that if the version number you get >>>> is not supported, you reject it with an unsigned ICMP message. >>>> This means two endnodes could likely be tricked by a man-in-the- >>>> middle to use the older version of the protocol even if they >>>> both support the newer one. >> >> Shall we leave these as a headache for the HIP v2 designers? > > I think we should fix this one. I agree. And I think we already decided to fix this by replacing all references to SHA-1 with a reference to the HIT hash algorithm. HIT hash algorithm, OTOH, is currently being defined by the KHI prefix. Changing the algorithm requires changing the prefix; that is clearly defined in the Security Considerations part of the KHI draft. The rationale here was that in non-opportunistic HIP the initiator can choose among the responder's HITs (if there are many), and thereby choose which hash algorithm to use, usually choosing the strongest one. A counter argument would be that opportunistic HIP might have problems. OTOH, in opportunistic HIP the responder could choose its HIT based on the Initiator's HIT if it recognises the prefix in the Initiator's HIT. If it doesn't, it could use still use SHA-1. That wouldn't most probably matter that much as opportunistic HIP is always vulnerable to man-in-the-middle attacks. Looking at -05, always referring to the HIT hash algorithm hasn't been implemented. Unfortunately I don't remember how we weighted the arguments and counter-arguments. Maybe this is just an issue that has slipped through in the editing process? My intention hFrom hipsec-bounces@lists.ietf.org Fri Apr 07 05:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUi-0000H0-KD; Fri, 07 Apr 2006 05:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUh-0000Fp-CF for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRnUg-0005xO-R9 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7A282212C64; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3601F212C5D; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) In-Reply-To: <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98E1DF9E-E0E1-4713-A379-566741D14BD2@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 7 Apr 2006 10:29:06 +0300 To: HIP X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: charliek@exchange.microsoft.com, Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis - HIP: wired-in SHA-1 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>>> 3) Fixing the "wired-in" uses of SHA-1 will require a new >>>> version number in the protocol, but there is a version downgrade >>>> attack. The current spec says that if the version number you get >>>> is not supported, you reject it with an unsigned ICMP message. >>>> This means two endnodes could likely be tricked by a man-in-the- >>>> middle to use the older version of the protocol even if they >>>> both support the newer one. >> >> Shall we leave these as a headache for the HIP v2 designers? > > I think we should fix this one. I agree. And I think we already decided to fix this by replacing all references to SHA-1 with a reference to the HIT hash algorithm. HIT hash algorithm, OTOH, is currently being defined by the KHI prefix. Changing the algorithm requires changing the prefix; that is clearly defined in the Security Considerations part of the KHI draft. The rationale here was that in non-opportunistic HIP the initiator can choose among the responder's HITs (if there are many), and thereby choose which hash algorithm to use, usually choosing the strongest one. A counter argument would be that opportunistic HIP might have problems. OTOH, in opportunistic HIP the responder could choose its HIT based on the Initiator's HIT if it recognises the prefix in the Initiator's HIT. If it doesn't, it could use still use SHA-1. That wouldn't most probably matter that much as opportunistic HIP is always vulnerable to man-in-the-middle attacks. Looking at -05, always referring to the HIT hash algorithm hasn't been implemented. Unfortunately I don't remember how we weighted the arguments and counter-arguments. Maybe this is just an issue that has slipped through in the editing process? My intention here was, IIRC, to refer to the HIT hash algorithm everywhere, but maybe in the puzzle. The puzzle could still remain using PHASH, which would be, for now, SHA-1. OTOH, for consistency's sake we should edit the document to refer to PHASH everywhere, and mention SHA-1 only in the definition of PHASH. (Most of that has apparently been done but at least Para #1 in 4.1.2 and Para #2 in 6.3 still refer to SHA-1.) One more point is what to use for keymat generation. My choice would be HIT hash algorithm, not SHA-1. As a detail here, looking at 6.9 Point #7 we may have an inconsistency. There we refer to the HIT hash algorithm in verifying the puzzle, not PHASH. So, I become puzzled of what we really decided. [Side note: KHI draft title has been changed; Petri please update Para #2 in Section 3.1] --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 07 05:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUi-0000G4-7m; Fri, 07 Apr 2006 05:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUh-0000Fe-A8 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRnUg-0005xP-R7 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DCC06212C5D; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 54FC5212C63; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) In-Reply-To: <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 7 Apr 2006 10:39:29 +0300 To: HIP X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: charliek@exchange.microsoft.com, Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis - HIP: Opportunistic HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>>> When doing "opportunistic" HIP negotiation, when node A wants to >>>> send to node B and doesn't know whether node B supports HIP, it >>>> has three choices: 1) It can hold the first packet to B while it >>>> tries to negotiate HIP, and if that fails send the first packet >>>> unprotected; 2) It can forward the first packet unprotected and >>>> in parallel try to negotiate HIP. If the negotiation succeeds, >>>> it can start using the ESP tunnel; or 3) it can not try to >>>> negotiate HIP. Each of these mechanisms has problems. The spec >>>> should offer some guidance. It's possible this is provided in >>>> one of the other HIP documents. >> >> Maybe a recommendation: >> >> 6.6. Initiating a HIP connection >> >> The host should try to establish an opportunistic moere was, IIRC, to refer to the HIT hash algorithm everywhere, but maybe in the puzzle. The puzzle could still remain using PHASH, which would be, for now, SHA-1. OTOH, for consistency's sake we should edit the document to refer to PHASH everywhere, and mention SHA-1 only in the definition of PHASH. (Most of that has apparently been done but at least Para #1 in 4.1.2 and Para #2 in 6.3 still refer to SHA-1.) One more point is what to use for keymat generation. My choice would be HIT hash algorithm, not SHA-1. As a detail here, looking at 6.9 Point #7 we may have an inconsistency. There we refer to the HIT hash algorithm in verifying the puzzle, not PHASH. So, I become puzzled of what we really decided. [Side note: KHI draft title has been changed; Petri please update Para #2 in Section 3.1] --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 07 05:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUi-0000G4-7m; Fri, 07 Apr 2006 05:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUh-0000Fe-A8 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRnUg-0005xP-R7 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DCC06212C5D; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 54FC5212C63; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) In-Reply-To: <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 7 Apr 2006 10:39:29 +0300 To: HIP X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: charliek@exchange.microsoft.com, Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis - HIP: Opportunistic HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>>> When doing "opportunistic" HIP negotiation, when node A wants to >>>> send to node B and doesn't know whether node B supports HIP, it >>>> has three choices: 1) It can hold the first packet to B while it >>>> tries to negotiate HIP, and if that fails send the first packet >>>> unprotected; 2) It can forward the first packet unprotected and >>>> in parallel try to negotiate HIP. If the negotiation succeeds, >>>> it can start using the ESP tunnel; or 3) it can not try to >>>> negotiate HIP. Each of these mechanisms has problems. The spec >>>> should offer some guidance. It's possible this is provided in >>>> one of the other HIP documents. >> >> Maybe a recommendation: >> >> 6.6. Initiating a HIP connection >> >> The host should try to establish an opportunistic moere was, IIRC, to refer to the HIT hash algorithm everywhere, but maybe in the puzzle. The puzzle could still remain using PHASH, which would be, for now, SHA-1. OTOH, for consistency's sake we should edit the document to refer to PHASH everywhere, and mention SHA-1 only in the definition of PHASH. (Most of that has apparently been done but at least Para #1 in 4.1.2 and Para #2 in 6.3 still refer to SHA-1.) One more point is what to use for keymat generation. My choice would be HIT hash algorithm, not SHA-1. As a detail here, looking at 6.9 Point #7 we may have an inconsistency. There we refer to the HIT hash algorithm in verifying the puzzle, not PHASH. So, I become puzzled of what we really decided. [Side note: KHI draft title has been changed; Petri please update Para #2 in Section 3.1] --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 07 05:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUi-0000G4-7m; Fri, 07 Apr 2006 05:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUh-0000Fe-A8 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRnUg-0005xP-R7 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DCC06212C5D; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 54FC5212C63; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) In-Reply-To: <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 7 Apr 2006 10:39:29 +0300 To: HIP X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: charliek@exchange.microsoft.com, Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis - HIP: Opportunistic HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>>> When doing "opportunistic" HIP negotiation, when node A wants to >>>> send to node B and doesn't know whether node B supports HIP, it >>>> has three choices: 1) It can hold the first packet to B while it >>>> tries to negotiate HIP, and if that fails send the first packet >>>> unprotected; 2) It can forward the first packet unprotected and >>>> in parallel try to negotiate HIP. If the negotiation succeeds, >>>> it can start using the ESP tunnel; or 3) it can not try to >>>> negotiate HIP. Each of these mechanisms has problems. The spec >>>> should offer some guidance. It's possible this is provided in >>>> one of the other HIP documents. >> >> Maybe a recommendation: >> >> 6.6. Initiating a HIP connection >> >> The host should try to establish an opportunistic mode HIP >> association sending at most I1_RETRIES_MAX I1 packets. If it does >> not receive any R1s, it can try to initiate the connection >> without HIP if local policy allows. > > And use option 1 in the meantime. 2 has many problems, because > migrating a non-HIP connection to HIP is probably hard to implement. I would be tempted to make it explicit that this document does not define how to do opportunistic HIP but simply provides hooks for it, a full definition being expected to be available in some future document. Opinions? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 07 05:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUi-0000Fx-1x; Fri, 07 Apr 2006 05:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUh-0000Fd-A3 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRnUg-0005xQ-R9 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0EC23212C66; Fri, 7 Apr 2006 12:43:06 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B8BF4212C46; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) In-Reply-To: <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 7 Apr 2006 10:39:48 +0300 To: HIP X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: charliek@exchange.microsoft.com, Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>>> There is mandatory support for ESP with HMAC-SHA1 and either >>>> Null or AES128CBC encryption. This is mandatory not just in the >>>> implementation but also in the configuration. (i.e., as written, >>>> the spec says that one of those two suites must be offered in >>>> every negotiation). >> >> The reason for this was that we would have something common >> between all nodes. > > But Null should not be mandatory to offer. AES128CBC would do as a > mandatory-to-offer. I don't understand this comment. Maybe the text is unclear (Section 5.2.7 I think), but AFAICS it just requires that the responder includes _at_least_ either HMAC-SHA1-NULL or HMAC-SHA1-AES128CBC. Nothing prevents it from including both and perhaps others. If you implement HMAC-SHA1-AES128CBC, it is trivial to implement HMAC- SHA1-NULL. What is wrong with this? To me this approach seems to be fine with me; not all connections require encryption. --Pekka _______________________________________________ Hipsec mailing list Hipsec@listsde HIP >> association sending at most I1_RETRIES_MAX I1 packets. If it does >> not receive any R1s, it can try to initiate the connection >> without HIP if local policy allows. > > And use option 1 in the meantime. 2 has many problems, because > migrating a non-HIP connection to HIP is probably hard to implement. I would be tempted to make it explicit that this document does not define how to do opportunistic HIP but simply provides hooks for it, a full definition being expected to be available in some future document. Opinions? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 07 05:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUi-0000Fx-1x; Fri, 07 Apr 2006 05:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUh-0000Fd-A3 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRnUg-0005xQ-R9 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0EC23212C66; Fri, 7 Apr 2006 12:43:06 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B8BF4212C46; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) In-Reply-To: <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 7 Apr 2006 10:39:48 +0300 To: HIP X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: charliek@exchange.microsoft.com, Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>>> There is mandatory support for ESP with HMAC-SHA1 and either >>>> Null or AES128CBC encryption. This is mandatory not just in the >>>> implementation but also in the configuration. (i.e., as written, >>>> the spec says that one of those two suites must be offered in >>>> every negotiation). >> >> The reason for this was that we would have something common >> between all nodes. > > But Null should not be mandatory to offer. AES128CBC would do as a > mandatory-to-offer. I don't understand this comment. Maybe the text is unclear (Section 5.2.7 I think), but AFAICS it just requires that the responder includes _at_least_ either HMAC-SHA1-NULL or HMAC-SHA1-AES128CBC. Nothing prevents it from including both and perhaps others. If you implement HMAC-SHA1-AES128CBC, it is trivial to implement HMAC- SHA1-NULL. What is wrong with this? To me this approach seems to be fine with me; not all connections require encryption. --Pekka _______________________________________________ Hipsec mailing list Hipsec@listsde HIP >> association sending at most I1_RETRIES_MAX I1 packets. If it does >> not receive any R1s, it can try to initiate the connection >> without HIP if local policy allows. > > And use option 1 in the meantime. 2 has many problems, because > migrating a non-HIP connection to HIP is probably hard to implement. I would be tempted to make it explicit that this document does not define how to do opportunistic HIP but simply provides hooks for it, a full definition being expected to be available in some future document. Opinions? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 07 05:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUi-0000Fx-1x; Fri, 07 Apr 2006 05:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUh-0000Fd-A3 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRnUg-0005xQ-R9 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0EC23212C66; Fri, 7 Apr 2006 12:43:06 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B8BF4212C46; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) In-Reply-To: <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 7 Apr 2006 10:39:48 +0300 To: HIP X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: charliek@exchange.microsoft.com, Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>>> There is mandatory support for ESP with HMAC-SHA1 and either >>>> Null or AES128CBC encryption. This is mandatory not just in the >>>> implementation but also in the configuration. (i.e., as written, >>>> the spec says that one of those two suites must be offered in >>>> every negotiation). >> >> The reason for this was that we would have something common >> between all nodes. > > But Null should not be mandatory to offer. AES128CBC would do as a > mandatory-to-offer. I don't understand this comment. Maybe the text is unclear (Section 5.2.7 I think), but AFAICS it just requires that the responder includes _at_least_ either HMAC-SHA1-NULL or HMAC-SHA1-AES128CBC. Nothing prevents it from including both and perhaps others. If you implement HMAC-SHA1-AES128CBC, it is trivial to implement HMAC- SHA1-NULL. What is wrong with this? To me this approach seems to be fine with me; not all connections require encryption. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec .ietf.org https://www1.ietf.org/mailman/listinfo/hipsec .ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 07 05:43:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUk-0000Im-Ro; Fri, 07 Apr 2006 05:43:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUi-0000G2-69 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:08 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRnUg-0005xR-T9 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:08 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 37D54212C63; Fri, 7 Apr 2006 12:43:06 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E34E9212C65; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) In-Reply-To: <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 7 Apr 2006 10:41:25 +0300 To: HIP X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: charliek@exchange.microsoft.com, Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis - HIP: Sequence numbers X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>>> Non-security concerns: >>>> >>>> Use of Extended Sequence Numbers is not negotiated; either end >>>> can mandate it. If all endpoints are required to support ESNs, >>>> it would be simpler to just mandate their use all the time. If >>>> not, the negotiation should allow one end to propose their use >>>> and the other to accept it. >> >> What do people think? Should we go for mandatory 64-bit sequence >> numbers >> directly, or is there some advantage of staying at 32? > > Go straight to 64. I agree with Andrew. Let's just go to 64. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 07 05:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUi-0000Gg-DM; Fri, 07 Apr 2006 05:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnUh-0000Fn-Bv for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRnUg-0005xN-R6 for hipsec@ietf.org; Fri, 07 Apr 2006 05:43:07 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4BDA0212C5F; Fri, 7 Apr 2006 12:43:05 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id EBB22212C46; Fri, 7 Apr 2006 12:43:04 +0300 (EEST) In-Reply-To: <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 7 Apr 2006 10:11:59 +0300 To: HIP X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: charliek@exchange.microsoft.com, Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis - HIP: D-H group negotiation X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org [Creating separate threads for separate issues.] >>>> There are other places where crypto-agility is not all that it >>>> might be: >>>> >>>> 1) There is no negotiation of Diffie-Hellman groups. The >>>> responder chooses. This means that if both ends support multiple >>>> groups and there is some overlap, the negotiation could still >>>> fail if the initiator does not support the responder's default >>>> group. As with IKEv1, connections might succeed if initiated >>>> from one end but not from the other. If an implementation >>>> compensates for this by trying different groups upon retry, the >>>> protocol is subject to a downgrade attack where a man-in-the- >>>> middle can get the two ends to use a group weaker than one they >>>> would both prefer. This would be straightforward (but not >>>> trivial) to fix. >> >> This issue has been discussed earlier in the HIPSEC list (Dec. 2003). >> The conclusion (at that time) was to use two mandatory Groups and >> rest >> were defined as "SHOULD be implemented". Negotiation was discussed, >> but never adopted; R1 would have contained for example two >> different DHs. > > We implemented this at one stage before the big packet format > change... IIRC it worked fine. I think it should be resurrected. IIRC, one of the reasons why we left this (and other similar negotiations) out was simplicity. Back at that time, we (or at least I :-) wanted to keep the protocol simple to implement and understand. What comes to downgrade attacks, IIRC the argumentation was that a man-in-the-middle that is sufficiently strong to launch such a downgrade attack can also launch a full DoS, which was considered worse. OTOH, there may be scenarios where downgrade might be considered worse than DoS. So, IMHO, if someone (Andrew?) cares to write text, we could consider including it. Would simply including multiple D-H payloads in R1 do? In that case the Initiator could choose instead of the Responder? That would require more work from the Responder (keeping pools of multiple types D-H keys instead of just one pool), but AFAICS would be fairly simple at the Initiator end. Or am I missing something? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 07 05:48:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRna4-0003Bd-Vv; Fri, 07 Apr 2006 05:48:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRna4-0003BY-B7 for hipsec@ietf.org; Fri, 07 Apr 2006 05:48:40 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRna3-00060d-UO for hipsec@ietf.org; Fri, 07 Apr 2006 05:48:40 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 28F01212C4E; Fri, 7 Apr 2006 12:48:39 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D7E12212C46; Fri, 7 Apr 2006 12:48:38 +0300 (EEST) In-Reply-To: <4434C0D3.40905@nomadiclab.com> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <97F374FF-960A-4D53-A1A7-F43583624D71@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 7 Apr 2006 12:48:37 +0300 To: Petri Jokela X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: charliek@exchange.microsoft.com, HIP , Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis - HIP: SHA-1 or SHA-256 as the baseline X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>> The HIP base document makes a normative reference to draft- >>> laganier-ipv6-khi-01, and that document wires in both use of >>> SHA-1 and the extraction of a particular 120 bits of the SHA-1 >>> hash. Switching to use 120 bits of a SHA-256 hash would not be >>> terribly difficult, but it's not clear that would be any more >>> secure. > > The only way to solve this issue is to modify the ORCHID (KHI) > draft. There is nothing we can do in the HIP base draft; we need > those HITs defined somewhere. I am open to both options. If people feel that now is the right time to move from SHA-1 to SHA-256, I'm sure we can update the ORCHID/KHI draft. IF we decide to make PHASH independent of the HIT hash algorithm, then the base draft needs to be updated accordingly. In any case, we need to figure out for the base draft from where the hash algorithms for various cases come. Right now the draft is not in good enough shape. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 07 05:56:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnhJ-0007l8-SF; Fri, 07 Apr 2006 05:56:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnhI-0007l3-6u for hipsec@ietf.org; Fri, 07 Apr 2006 05:56:08 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRnhH-00067F-PJ for hipsec@ietf.org; Fri, 07 Apr 2006 05:56:08 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B2262212C4E; Fri, 7 Apr 2006 12:56:06 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 40004212C46; Fri, 7 Apr 2006 12:56:06 +0300 (EEST) In-Reply-To: <4434C0D3.40905@nomadiclab.com> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <96D8C6FB-8445-44FD-861E-0D636F700CA6@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 7 Apr 2006 12:56:04 +0300 To: Petri Jokela X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: charliek@exchange.microsoft.com, HIP , Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis - HIP: Key derivation vs. D-H reuse X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>> Assurance that two sessions will always use different session >>> keys is fragile. The keys are derived from the Diffie-Hellman >>> keys and puzzle challenges and responses, all of which can be >>> reused. Perhaps I missed it, but there should probably be more >>> explicit guidance on how to avoid this or explicit nonces should >>> be added. > > If we change some value in each of the R1s, we need to recalculate > R1s when we send them out. This opens some DoS attack > possibilities. It means also that we lose the advantage of pre- > generating R1 messages. > > Currently there is a requirement that puzzles must be re-calculated > every few minutes (one possible way to implement is described in > Appendix A). The problem would exist only when two hosts negotiate the > association, close it, and renegotiate it within the time when the > set of pre-generated R1s is valid. IIRC, the original intent was that a given D-H key half is used only once. That is, it may be offered multiple times at different points of time, but once an Initiator accepts it, it is NOT used in any other HIP session. In implementation terms, one would have a pool of R1s, with different D-H values, and send them selectively. Under normal traffic there should be no problems. You just send one D-H key half in one R1, you get the I2 and you deprecate the R1. Problems start to appear under I1 flooding, where you cannot afford keeping re-generating D-H key halves but must reuse them. So, I agree with Charlie that there should be better guidance on how to re-use pre-generated R1s in order to avoid fragile session keys. Given the current design, I'm afraid we cannot avoid them completely; i.e., there will be some I1 flooding scenarios under which some D-H keys may be fragile. That should be documented in the Security Considerations section. Anyone willing to write text? [I think this is the last issue that I wanted to raise separately.] --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 07 05:57:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnid-0008Ci-5k; Fri, 07 Apr 2006 05:57:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRnib-0008Cd-El for hipsec@ietf.org; Fri, 07 Apr 2006 05:57:29 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRnib-0006Bn-5g for hipsec@ietf.org; Fri, 07 Apr 2006 05:57:29 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7D655212C4E; Fri, 7 Apr 2006 12:57:28 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0E799212C46; Fri, 7 Apr 2006 12:57:28 +0300 (EEST) In-Reply-To: <4434C0D3.40905@nomadiclab.com> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Fri, 7 Apr 2006 12:57:26 +0300 To: Petri Jokela X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: charliek@exchange.microsoft.com, HIP , Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis - HIP: Key expansion X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>> There are no real attacks on HIP based on finding collisions, but >>> as with many of these protocols there could be long theoretical >>> discussions about how finding collisions would be interesting. A >>> real attack would depend on the ability to find a second preimage. >>> >>> There are other places where SHA-1 is wired in with no mechanism >>> for negotiating anything else. None can be exploited given >>> collision attacks. They are: >>> >>> 1) Key expansion: hash is not negotiated - SHA-1 wired in. > > This could be changed to contain a non-fixed algorithm, possibly in a > similar way as in puzzle where the algorithm is defined to be the same > that is used in Responder's HIT generation. I mentioned this already in the other thread. I think your suggestion Petri of using the Responder's HIT hash algorithm is a good one. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 07 12:51:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRuBV-0002zx-MV; Fri, 07 Apr 2006 12:51:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRuBU-0002zs-SU for hipsec@ietf.org; Fri, 07 Apr 2006 12:51:44 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRuBT-0003bv-Vo for hipsec@ietf.org; Fri, 07 Apr 2006 12:51:44 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA26780; Fri, 7 Apr 2006 09:51:34 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k37GpXN15868; Fri, 7 Apr 2006 11:51:33 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 09:51:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] some comments for mm-03 Date: Fri, 7 Apr 2006 09:51:29 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] some comments for mm-03 Thread-Index: AcZXNp9zVFlWgAyoQAqsLCJ8SQG/OwCVan9w From: "Henderson, Thomas R" To: "Miika Komu" , X-OriginalArrivalTime: 07 Apr 2006 16:51:29.0485 (UTC) FILETIME=[8451BFD0:01C65A63] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1fb4c76a9d88e8fb8b791f63f8d1b07f Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Miika, thank you for this detailed review. I will answer them in-line, and eventually put out a new -04 preview corresponding to these changes. > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Monday, April 03, 2006 8:52 AM > To: hipsec@ietf.org > Subject: [Hipsec] some comments for mm-03 >=20 > Some comments for mm-03, part 1/2 (I'll send the rest later=20 > this evening). > Should keep Thomas busy until then :) >=20 > I haven't read the mm-03 draft for a long time (1-2 years) througly, > so decided to do it now with fresh eyes. Below are my suggested > changes, but before that, a short executive summary of the > proposed changes: >=20 > * Mainly consists of many readability/understandability=20 > enchancements and > requests for clarifications. > * Mainly, no new features. In fact, I suggest removing one > feature/use-case (readdress with peer-initiated rekey) in favour of > simplifying state machine, interaction with middle-boxes and > interoperable implementations. > Suggest removal of it from this draft and adding to a follow-up > draft. > * An initial proposal for a state machine for mobility and multihoming > based on the current text in the draft, excluding the=20 > (readdress with > peer-initiated rekey). The actual state machine is in=20 > separate email. > * Some new text on closing of SAs in multihoming case. >=20 > I feel that the current draft is too "loose", just for the sake of > experimentation but IMHO it makes the implementation too complex in > practice and also makes the situation bad for the interoperability of > implementations. I believe that this can be accomplished by reducing > the functionality: removing the "readdress with peer-initiated > rekey" use case, sticking to three-way packet exchange and adding a > reference state machine. >=20 >=20 > Editorial comments: >=20 > > Abstract > > > > This document defines mobility and multihoming extensions=20 > to the Host > > Identity Protocol (HIP). >=20 > Add after this: The document assumes that ESP is > being used. >=20 > (because the draft really assumes this) I would suggest not including this in the abstract. It may be that much of this is reusable for other transport formats. It is stated in the Introduction: While HIP can potentially be used with transports other than the ESP transport format, this document largely assumes the use of ESP and leaves other transport for further study. and also in Section 3.2: These scenarios assume that HIP is being used with the ESP transform [5], although other scenarios may be defined in the future. =20 >=20 > > Table of Contents: >=20 > Section 3.2 assumes detailed knowledge (especially the three first > sections) of sections 4 and 5. Suggest making a forward reference in > the intro of the section 3.2 and some patience from the reader :) OK >=20 > Suggest adding section 3.2.9 (and perhaps 5.7) on "Closing of Security > Associations": >=20 > The SAs are closed as defined as in in the general > case. As such, closing of the SAs causes all of the SAs to be closed > also in multihoming scenarios. A host MAY add an ESP_INFO parameter to > a CLOSE message to signal that a specific SA is to be close. The > CLOSE-ACK message should also include the same ESP_INFO parameter. In > the ESP_INFO parameter, the old SPI corresponds to SA to be > removed. The new SPI and keymat index are set to zero. I do not necessarily agree with this, and would like to hear other opinions. CLOSE should close all security associations; if a specific SA is to be closed while others remain open, it should be possible to do so through the UPDATE protocol.=20 >=20 > > 1. Introduction and Scope >=20 > Add somewhere: The document assumes that ESP is > being used. This is already in the Introduction (see above). >=20 > > We also do not consider localized mobility management extensions; >=20 > Please define "localized mobility management extensions" or give an > example of such a protocol. An example might be the protocols defined in netlmm or mipshop groups. I will clarify by adding "localized mobility management extensions (i.e., mobility management techniques that do not involve directly signaling the correspondent node)" >=20 > > 2. Terminology and Conventions > > > > Locator... It may also include transport port numbers or IPv6 Flow > > Labels as demultiplexing context, or it may simply be a network > > address. >=20 > Further extensions of this document may also include transport port > numbers or IPv6 Flow Labels as demultiplexing context. This document > only defines it simply as a network address. >=20 > Suggest adding also the definition of "SA selector" that later pops up > in the text suddenly. Perhaps it would be nice to have some > definitions also for SA and SPI also for the inexperienced reader. >=20 > > 3. Protocol Model >=20 > Add an small intro? Here would be a good place to mention that the > UPDATE processing details are in sections 4 and 5. OK >=20 > > 3.1. Operating Environment > > .. > > This document specifies extensions to the HIP protocol to enable > > end-host mobility and multihoming. >=20 > This document specifies extensions to the HIP protocol to enable > end-host mobility and basic multihoming. OK >=20 > > In summary, these extensions to the HIP protocol can carry new > > addressing information to the peer and can enable direct > > authentication of the message via a signature or keyed hash message > > authentication code (HMAC) based on its host identity. >=20 > In summary, these extensions to the HIP base protocol enable carrying > of new address related information to the peer in HIP messages. The > messages are authenticated using public key signatures and keyed hash > message authentication codes (HMAC). OK >=20 > > Figure 2: Architecture for HIP mobility and multihoming >=20 > * The MH abbreviation is not explained in the text, nor in=20 > the caption. added to caption. It is defined later in the text. > * I am not still convinced that the figure is more illustrative than > confusing but I have nothing better to offer, so I let it=20 > be. Perhaps > you need to be sure to mention in the text that it is=20 > neither a picture > of the networking stack to be used for packet=20 > en/decapsulation nor a > software module organization. I think it is what it says it is-- a layered architectural description. > * You may want to say that MH box is separate from HIP for i.e. to be > usable also for other protocols? Added. >=20 > > The SPI (or other context tag if ESP is not used with HIP), and not > > necessarily the IP addresses, is used to associate an=20 > incoming packet > > with the right HITs. >=20 > The SPI is used to associate an incoming packet with the right HITs. OK >=20 > > The HIP base exchange establishes the HITs in use between the hosts, > > the SPIs to use for ESP, and the IP addresses (used in the HIP > > signaling packets). >=20 > The HIP base exchange establishes the HITs in use between the hosts, > the SPIs to use for ESP, and the IP addresses (used both in the HIP > signaling packets and ESP data packets). OK >=20 > > Note that there can only be one such binding in the outbound > > direction for any given packet, and the only selectors for the > > binding at the HIP layer are the fields exposed by ESP (the SPI and > > HITs). >=20 > What binding? HIT-to-IP or HIT-to-SPI or IP-to-SPI? What selectors, > and what are they supposed to select? s/such binding/such set of bindings/ The selectors are those fields that are used to select the next field that needs to be assigned (in this case, the SPI and HITs are the fields available to select the IP addresses) >=20 > > This document specifies the messaging and elements of procedure for > > such a mobility event. >=20 > This sentence can be safely removed. OK >=20 > > Finally, consider the case when a host is multihomed (has more than > > one globally routable address) and wants to make these multiple > > addresses available for use by the upper layer protocols, for fault > > tolerance. >=20 > Finally, consider the case when a host is multihomed (has more than > one globally routable address) and makes these multiple addresses > available for use by the upper layer protocols, for example, for fault > tolerance. >=20 OK > > However, only one SPI and address can be used for any given=20 > packet, so > > the job of the "MH" block depicted above is to dynamically=20 > manipulate > > these bindings. >=20 > However, only one SPI and address pair can be used for an ESP=20 > packet, so > the job of the "MH" block depicted above is to dynamically manipulate > these bindings. OK >=20 > Comment: seems like the MH is really required for: >=20 > * Selection of outgoing SAs if multiple present (for incoming=20 > it is not > really necessary because we just use SPI present in the packet) > * Perhaps for tracking the CBA credits and communicating them to HIP. also possibly transport triggers to signal path change events. >=20 > Maybe you want to de-blur the meaning of the MH somewhere in section > 3.1. See also my next comment. >=20 > > This document does not specify the "MH" block, nor does it specify > > detailed elements of procedure for how to handle various multihoming > > (perhaps combined with mobility) scenarios. >=20 > The document wants to specify a blurry concept of MH but really does > not do it? Compare to my previous comment. Well, I think that it just indicates that some kind of functional block is needed there, without trying to specify it. IMO, this will be harder to specify than mobility, and will have some commonality with what shim6 is trying to define. >=20 > > 3.1.1. Locator > > > > Or locators may merely be traditional network addresses. In Section > > 4, a generalized HIP LOCATOR parameter is defined that can contain > > one or more locators (addresses). >=20 > It is also possible that locators are merely traditional network > addresses. The actual format of the locators is defined in section 4. OK >=20 > > 3.1.2. Mobility overview > > > > This UPDATE packet is acknowledged by the peer, and is > > protected by retransmission. >=20 > This UPDATE packet is acknowledged by the peer. To ensure that packets > are not lost or corrupted, proper retransmission mechanisms are used. >=20 > > However, the peers are not able to reply before they can=20 > reliably and > > securely update the set of addresses that they associate with the > > sending host. >=20 > s/reply/comminicate/ s/reply/send packets to these new addresses/ >=20 > > 3.1.3. Multihoming overview > > > > Although this document defines a mechanism for multihoming, >=20 > basic mechanism OK >=20 > > 3.2. Protocol Overview >=20 > It might be good to explain the ESP_INFO old and new SPI fields > because they are not introduced but still used the subsections. Added a little text for this. >=20 > > Each of the scenarios below assumes that the HIP base exchange has > > completed, and the hosts each have a single outbound SA to the peer > > host. Associated with this outbound SA is a single destination > > address of the peer host-- the source address used by the peer > > during the base exchange. >=20 > The scenarios below assume that the two hosts have completed a single > HIP base exchange with each other. Both of the hosts have one incoming > and one outgoing SA. Further, each SA contains the two IP addresses > the hosts were using for the base exchange. >=20 OK (I slightly modified). >=20 > > The main packets on which the LOCATOR parameters are expected to be > > carried are UPDATE packets. >=20 > The majority of packets on which the LOCATOR parameters are expected > to be carried on are UPDATE packets. OK >=20 > > 3.2.1. Mobility with single SA pair (no rekeying) >=20 > Add some text between the figure and numbered bullets: >=20 > The steps of the packet processing are as follows: OK >=20 > In second bullet: s/hte/the/ OK >=20 > > 3.2.1.2. Mobility with single SA pair (peer-initiated rekey) >=20 > What was the use case for doing this? If there is no really strong use > case, I suggest removing this section from the draft and perhaps > adding it a follow-up draft. This way, the state machine has a simpler > design (three packets) and is easier to implement. See my following > email. I am fine with this (will respond to your other mail), as long as we cleanly deal with the possibility of collision of UPDATEs. =20 >=20 > > 3.2.2. Host multihoming > > > > Consider the case between two single-homed hosts, in which one of > > the host notifies the peer of an additional address. >=20 > Consider the case between hosts, one single-homed and the other > multi-homed. The multihomed host notifies the peer of an additional > address. >=20 OK > > It is RECOMMENDED that the host set up a new SA pair for use on this > > new address. >=20 > s/host/multihomed host/ OK >=20 > > A Locator Type of "1" is used to associate the new address with the > > new SPI. The LOCATOR parameter also contains a second Type 1 > > locator: that of the original address and SPI. >=20 > The latter sentence does not really make sense: >=20 > * The sentence above basically says that there is a locator=20 > parameter > embedded inside another locator parameter. >=20 > * If it was meant that there are actually two separate locators this > does > make sense because in the figure below shows only one and=20 > somewhere > in the draft it was said that multiple locator parameters=20 > are out of > scope. I think you are confusing LOCATOR (parameter type) with locator (address within the parameter). I think the sentence is correct and necessary. >=20 > > To simplify parameter processing and avoid explicit protocol > > extensions to remove locators, each LOCATOR parameter must list all > > locators in use on a connection (a complete listing of inbound > > locators and SPIs for the host). >=20 > s/must/MUST/ OK >=20 > > The multihomed host transitions to state REKEYING, waiting for a > > ESP_INFO (new outbound SA) from the peer and an ACK of its own > > UPDATE. >=20 > REKEYING state does not exist anymore. Right-- deleted this. >=20 > > As in the mobility case, the peer host must perform an > > address verification before putting the new address into active use. >=20 > s/putting/changing/ s/putting the new address into active use/actively using the new address/ >=20 > > Figure 6 illustrates the basic packet exchange. >=20 > Figure 6 illustrates this scenario. OK >=20 > > Figure 6: Basic multihoming scenario >=20 > Is the ECHO_RESPONSE 100 % sure way to map the last incoming UPDATE to > certain SA? Why don't we just include the ESP_INFO? If this is the > case, why don't we do also for the other use cases for generality's > sake. I had always thought that the HIP daemon would use the SEQs and ACKs to map these packets. I do not have a problem with including ESP_INFO, either as a MUST or a MAY, to help implementors (although it would have to be treated as a protocol error if it didn't match the original ESP_INFO). What do other implementors think? >=20 > > When processing inbound LOCATORs that establish new security > > associations on an interface with multiple addresses, a=20 > host uses the > > destination address of the UPDATE containing LOCATOR as the local > > address to which the LOCATOR plus ESP_INFO is targeted. Hosts may > > send UPDATEs with the same IP address in the LOCATOR to different > > peer addresses-- this has the effect of creating multiple=20 > inbound SAs > > implicitly affiliated with different peer source addresses. >=20 > This text was just somehow too confusing. Suggest rewriting again with > simplicity in mind, or removing (I am almost sure that this text is > described also later on). I think that the point is important-- tried to clarify it. >=20 > > 3.2.4. Dual host multihoming > > > > In Figure 7, consider that host1 wants to add address addr1b. >=20 > Please explain what addresses and SPIs are negotiated before this. >=20 OK > > It would send an UPDATE with LOCATOR to host2 located at addr2a, and > > a new set of SPIs would be added between hosts 1 and 2 (call them > > SPI1b and SPI2b). >=20 > Please make sure that this sentence makes sense after describing the > initial scenario better. Also, SPI1b and SPI2b are not shown in the > figure. Clarified. >=20 > > 3.2.6. Using LOCATORs across addressing realms > > > > In such a case, some type > > of mechanism for interworking between the different realms must be > > employed; such techniques are outside the scope of the present text. >=20 > Maybe you could still mention few experimental techniques. The problem > is as follows: >=20 > * Host I has run base exchange with host R using IPv6 > * IPv4 address is added to host I > * Host I is supposed to send UPDATE to host R > * LOCATOR =3D the new IPv4 address > * IP header source address =3D the new IPv4 address > * IP header dst address =3D >=20 > So, the problem is that the host I has no knowledge of the R's IPv4 > address. This can be handled in at least in two ways: >=20 > a) Both the IPv4 and IPv6 address of R are known by host I before it > initiates base exchange, e.g., they are configured manually or > DNS. >=20 > b) Host R communicates both its IPv4 and IPv6 address to host I in the > R1 packet in LOCATOR (as defined in section 3.2.8). >=20 > (The methods above were obtained from a discussion with Jan) OK, added some discussion along these lines. >=20 > > 3.2.8. Initiating the protocol in R1 or I2 >=20 > 3.2.8. Communicating LOCATORs in R1 or I2 >=20 > > All new non-preferred locators must still undergo address > > verification. >=20 > as defined in section XX ...but only after the base exchange has > completed. >=20 OK > > Even if the I2 packet contains LOCATOR parameters, the Responder > > MUST still send the R2 packet to the source address of the I2. >=20 > I1 and I2 source address must be the same? What does it matter? I1 state is not kept by responder. >=20 > > The new preferred locator SHOULD be identical to the I2 source > > address. If the I2 packet contains LOCATOR parameters, all new > > locators must undergo address verification as usual. >=20 > Finally, the possibly following ESP traffic uses the negotiated > preferred locators. > OK =20 > Perhaps also the ESP traffic could be illustrated also in the > figures. Also, a figure for the case where both hosts include > additional locators would be nice. I am electing to skip these optional mods. >=20 > > 3.3.2. Credit-Based Authorization > > > > Credit-Based Authorization allows a host to securely use a new > > locator even though the peer's reachability at the address embedded > > in this locator has not yet been verified. >=20 > s/this/the received/ s/this/the >=20 > > 1. A flooding attacker typically seeks to somehow multiply the > > packets it generates itself for the purpose of its=20 > attack because > > bandwidth is an ample resource for many attractive victims. >=20 > s/itself// > s/attractive// >=20 > > 3. Consequently, the additional effort required to set up a > > redirection-based flooding attack would pay off for the attacker > > only if amplification could be obtained this way. >=20 > 3. Consequently, the additional effort required to set up a > redirection-based flooding attack (without CBA and return=20 > routability > checks) would pay off for the attacker only if=20 > amplification could be > obtained this way. OK >=20 > > On this basis, rather than eliminating malicious packet=20 > redirection in > > the first place, Credit-Based Authorization prevents any=20 > amplification > > that can be reached through it. >=20 > On this basis, rather than eliminating malicious packet redirection in > the first place, Credit-Based Authorization prevents any packet > amplifications. >=20 > > Figure 10 illustrates Credit-Based Authorization: Host B measures > > the bytes recently received from peer A and, when A readdresses, > > sends packets to A's new, unverified address as long as the sum of > > their sizes does not exceed the measured, received data volume. >=20 > What is "their" referring to? s/their/the packet/ >=20 > > Figure 10. >=20 > Can the "+ address change" in the lower left corner be removed? >=20 I will check with Christian about this figure, as your question has raised also a question in my mind whether it is correct. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 07 15:07:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRwIe-0005s3-3k; Fri, 07 Apr 2006 15:07:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRwId-0005ry-3z for hipsec@ietf.org; Fri, 07 Apr 2006 15:07:15 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRwIb-0001ym-Pe for hipsec@ietf.org; Fri, 07 Apr 2006 15:07:15 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id D74A22EF8; Fri, 7 Apr 2006 22:07:12 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 79B052EBD; Fri, 7 Apr 2006 22:07:12 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k37J7Bv12711; Fri, 7 Apr 2006 22:07:12 +0300 (EEST) Date: Fri, 7 Apr 2006 22:07:11 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Nikander Subject: Re: [Hipsec] Belovin-Rescorla analysis - HIP: Opportunistic HIP In-Reply-To: Message-ID: References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> <130467ED-00F5-4C30-A10A-6CFD6D5C1B17@indranet.co.nz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: charliek@exchange.microsoft.com, HIP , Petri Jokela X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Fri, 7 Apr 2006, Pekka Nikander wrote: > >>>> When doing "opportunistic" HIP negotiation, when node A wants to > >>>> send to node B and doesn't know whether node B supports HIP, it > >>>> has three choices: 1) It can hold the first packet to B while it > >>>> tries to negotiate HIP, and if that fails send the first packet > >>>> unprotected; 2) It can forward the first packet unprotected and > >>>> in parallel try to negotiate HIP. If the negotiation succeeds, > >>>> it can start using the ESP tunnel; or 3) it can not try to > >>>> negotiate HIP. Each of these mechanisms has problems. The spec > >>>> should offer some guidance. It's possible this is provided in > >>>> one of the other HIP documents. > >> > >> Maybe a recommendation: > >> > >> 6.6. Initiating a HIP connection > >> > >> The host should try to establish an opportunistic mode HIP > >> association sending at most I1_RETRIES_MAX I1 packets. If it does > >> not receive any R1s, it can try to initiate the connection > >> without HIP if local policy allows. > > > > And use option 1 in the meantime. 2 has many problems, because > > migrating a non-HIP connection to HIP is probably hard to implement. > > I would be tempted to make it explicit that this document does not > define how to do opportunistic HIP but simply provides hooks for it, > a full definition being expected to be available in some future > document. > > Opinions? Agree. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Apr 08 07:58:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSC5O-0005Ku-Er; Sat, 08 Apr 2006 07:58:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSC5N-0005Kp-4l for hipsec@ietf.org; Sat, 08 Apr 2006 07:58:37 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSC5L-00014f-Ke for hipsec@ietf.org; Sat, 08 Apr 2006 07:58:37 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id D601D2E5D; Sat, 8 Apr 2006 14:58:34 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 41E1F2E59; Sat, 8 Apr 2006 14:58:34 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k38BwW520979; Sat, 8 Apr 2006 14:58:32 +0300 (EEST) Date: Sat, 8 Apr 2006 14:58:32 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Hipsec] some comments for mm-03 In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Fri, 7 Apr 2006, Henderson, Thomas R wrote: > > Editorial comments: > > > > > Abstract > > > > > > This document defines mobility and multihoming extensions > > to the Host > > > Identity Protocol (HIP). > > > > Add after this: The document assumes that ESP is > > being used. > > > > (because the draft really assumes this) > > I would suggest not including this in the abstract. It may be that much > of this is reusable for other transport formats. It is stated in the > Introduction: > > While HIP can potentially be used with transports other than > the ESP transport format, > this document largely assumes the use of ESP and leaves other > transport for further study. > > and also in Section 3.2: > These scenarios assume that HIP is > being used with the ESP transform [5], although other scenarios may > be defined in the future. Fine. > > The SAs are closed as defined as in in the general > > case. As such, closing of the SAs causes all of the SAs to be closed > > also in multihoming scenarios. A host MAY add an ESP_INFO parameter to > > a CLOSE message to signal that a specific SA is to be close. The > > CLOSE-ACK message should also include the same ESP_INFO parameter. In > > the ESP_INFO parameter, the old SPI corresponds to SA to be > > removed. The new SPI and keymat index are set to zero. > > I do not necessarily agree with this, and would like to hear other > opinions. CLOSE should close all security associations; if a specific > SA is to be closed while others remain open, it should be possible to do > so through the UPDATE protocol. So, there seems to be some redundancy with CLOSE and UPDATE. In fact, I'd say that the CLOSE could be replaced with UPDATE as it implements only a subset of UPDATE. Petri, Pekka, others - comments? > > > 3.2.1.2. Mobility with single SA pair (peer-initiated rekey) > > > > What was the use case for doing this? If there is no really strong use > > case, I suggest removing this section from the draft and perhaps > > adding it a follow-up draft. This way, the state machine has a simpler > > design (three packets) and is easier to implement. See my following > > email. > > I am fine with this (will respond to your other mail), as long as we > cleanly deal with the possibility of collision of UPDATEs. Waiting for the follow-up email, no hurry. > > > A Locator Type of "1" is used to associate the new address with the > > > new SPI. The LOCATOR parameter also contains a second Type 1 > > > locator: that of the original address and SPI. > > > > The latter sentence does not really make sense: > > > > * The sentence above basically says that there is a locator > > parameter > > embedded inside another locator parameter. > > > > * If it was meant that there are actually two separate locators this > > does > > make sense because in the figure below shows only one and > > somewhere > > in the draft it was said that multiple locator parameters > > are out of > > scope. > > I think you are confusing LOCATOR (parameter type) with locator (address > within the parameter). I think the sentence is correct and necessary. You are correct. This should be clarified at least in the terminology section. Another way, perhaps a more clear way, to do this is to rename LOCATOR to LOCATOR_{SET|GROUP|BAG|ETC}. > > > Figure 6: Basic multihoming scenario > > > > Is the ECHO_RESPONSE 100 % sure way to map the last incoming UPDATE to > > certain SA? Why don't we just include the ESP_INFO? If this is the > > case, why don't we do also for the other use cases for generality's > > sake. > > I had always thought that the HIP daemon would use the SEQs and ACKs to > map these packets. I do not have a problem with including ESP_INFO, > either as a MUST or a MAY, to help implementors (although it would have > to be treated as a protocol error if it didn't match the original > ESP_INFO). What do other implementors think? Now rethinking this again, base draft says "The Update ID has scope within a single HIP association, and not across multiple associations or multiple hosts.". As a result, the update ID should be enough information to map the incoming packet to a SA. However, requiring the use of ESP_INFO in all UPDATE packets would be at least systematical and implementor friendlier. Less indexing required in the implementation. Maybe it is also better for middleboxes. > > > Even if the I2 packet contains LOCATOR parameters, the Responder > > > MUST still send the R2 packet to the source address of the I2. > > > > I1 and I2 source address must be the same? > > What does it matter? I1 state is not kept by responder. Cookies might get burned if the indexing is affected by the IP addresses :) -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Apr 09 23:37:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSnDo-0002o4-60; Sun, 09 Apr 2006 23:37:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSnDn-0002nw-0g for hipsec@ietf.org; Sun, 09 Apr 2006 23:37:47 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSnDl-0003SW-Hu for hipsec@ietf.org; Sun, 09 Apr 2006 23:37:46 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 22FB0212C5D; Mon, 10 Apr 2006 06:37:43 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 604D2212C4E; Mon, 10 Apr 2006 06:37:42 +0300 (EEST) In-Reply-To: References: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D039943-1FBB-4997-97F4-FCEFE72B53EF@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] some comments for mm-03: CLOSE vs. UPDATE Date: Mon, 10 Apr 2006 06:37:41 +0300 To: Miika Komu X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org [Answering bit-by-bit as most probably I won't have time to go over all related messages at this point of time.] >>> The SAs are closed as defined as in in the general >>> case. As such, closing of the SAs causes all of the SAs to be closed >>> also in multihoming scenarios. A host MAY add an ESP_INFO >>> parameter to >>> a CLOSE message to signal that a specific SA is to be close. The >>> CLOSE-ACK message should also include the same ESP_INFO >>> parameter. In >>> the ESP_INFO parameter, the old SPI corresponds to SA to be >>> removed. The new SPI and keymat index are set to zero. >> >> I do not necessarily agree with this, and would like to hear other >> opinions. CLOSE should close all security associations; if a >> specific >> SA is to be closed while others remain open, it should be possible >> to do >> so through the UPDATE protocol. > > So, there seems to be some redundancy with CLOSE and UPDATE. In > fact, I'd > say that the CLOSE could be replaced with UPDATE as it implements > only a > subset of UPDATE. Petri, Pekka, others - comments? IIRC, CLOSE was added fairly late in order to allow the _HIP_ association to be cleanly torn down. I think Erik Nordmark suggested adding it. I don't think it is a good idea to use CLOSE for closing SAs, or for any other purpose than closing the who HIP SA. If I understand correctly the text above, you Miika are suggesting to use CLOSE to close only specific ESP SAs but not the HIP association. That sounds like a pretty bad idea to me, confusing the semantics of CLOSE. But perhaps I don't understand what you are suggesting, Miika? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Apr 09 23:51:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSnR2-0000fZ-V9; Sun, 09 Apr 2006 23:51:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSnR1-0000fU-M5 for hipsec@ietf.org; Sun, 09 Apr 2006 23:51:27 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSnR1-0003n1-85 for hipsec@ietf.org; Sun, 09 Apr 2006 23:51:27 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8C589212C5D; Mon, 10 Apr 2006 06:51:26 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BFEE6212C4E; Mon, 10 Apr 2006 06:51:24 +0300 (EEST) In-Reply-To: References: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2D12A2F5-80F5-42D9-AA54-289B62F3EC3D@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] some comments for mm-03: including ESP-INFO in all (relevant) UPDATES Date: Mon, 10 Apr 2006 06:51:25 +0300 To: Miika Komu X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>>> Figure 6: Basic multihoming scenario >>> >>> Is the ECHO_RESPONSE 100 % sure way to map the last incoming >>> UPDATE to certain SA? Why don't we just include the ESP_INFO? If >>> this is the case, why don't we do also for the other use cases >>> for generality's sake. >> >> I had always thought that the HIP daemon would use the SEQs and >> ACKs to map these packets. I do not have a problem with including >> ESP_INFO, either as a MUST or a MAY, to help implementors >> (although it would have to be treated as a protocol error if it >> didn't match the original ESP_INFO). What do other implementors >> think? > Now rethinking this again, base draft says "The Update ID has scope > within a single HIP association, and not across multiple > associations or multiple hosts.". As a result, the update ID should > be enough information to map the incoming packet to a SA. > > However, requiring the use of ESP_INFO in all UPDATE packets would > be at least systematical and implementor friendlier. Less indexing > required in the implementation. Maybe it is also better for > middleboxes. I could imagine privacy reasons why you may not want to add ESP_INFO in those UPDATE packets that you use to verify address reachability. Not particularly strong privacy reasons, but still. Hence, IMHO including ESP_INFO in those packets should be at most SHOULD, and probably MAY, if people want it. On the other hand, I don't understand this issue from the implementers' point of view, and would be very interested in hearing counter arguments. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 00:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSnxK-00063I-CP; Mon, 10 Apr 2006 00:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSnxJ-00063D-Db for hipsec@ietf.org; Mon, 10 Apr 2006 00:24:49 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSnxI-0005od-UR for hipsec@ietf.org; Mon, 10 Apr 2006 00:24:49 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DCD0B212C63; Mon, 10 Apr 2006 07:24:47 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4F1A3212C5F; Mon, 10 Apr 2006 07:24:45 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9AEF0EF5-18B0-4D1D-8722-37DB49721A94@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] a state machine proposal for mm-03 Date: Mon, 10 Apr 2006 07:24:45 +0300 To: Miika Komu X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org > Note2: the state machine is simpler to design if we leave out the > peer initiated rekeying (section 3.2.1.2 in the draft). This way, > we can assume that the UPDATE exchange consists of three packets > and that each packet can be distinguished from each other by the > precence of LOCATOR, ECHO_REQUEST or ECHO_RESPONSE. Unfortunately I don't have time to really consider this in detail, but my earlier understanding was that, at least in principle, you could make the mobility and re-keying state machines completely separate. Anyway, from the overall architectural design point of view the idea was to use UPDATEs as a semi-reliable retransmission and acknowledgement sub-layer, on the top of which you can implement any state machine. The UPDATE-layer would signal the state machine above about any eventual events where packets don't get acknowledged even after multiple retries. Furthermore, the idea was that you could have multiple parallel state machines running at the same time. Their messages (payloads) would just be transmitted and acknowledged at once at the UPDATE layer, without needing any co-ordination between the above state machines. Now, I agree that there might be problems if you want to synchronise these state machines, e.g., for privacy reasons. However, fortunately or not, in the particular case of privacy you need to do also other tricks (such as having a changing HIT-blinding algorithm) that basically make the whole update mechanism half-unnecessary for the strong privacy case. Some minor comments below, made without _proper_ understanding of the whole picture: > Send UPDATE with LOCATOR: > - Triggered at the MN depending on changes in network attachments > and according to local policies > - Removed addresses are DEPRACATED (and not included in the > LOCATOR) > - All other addresses are UNVERIFIED (and included in the LOCATOR) Why these need to be UNVERIFIED. Maybe some of those have been verified earlier? > - Set preferred LOCATOR depending on local policies > - Send UPDATE with LOCATOR for the CN > > Receive HIP UPDATE: > - Verify the HIP packet: HMAC, SIG, the presence, dependencies and > validity of the parameters. > - If the result is failure, goto DROP. > - If success, proceed based on presence of LOCATOR, ECHO_REQUEST or > ECHO_RESPONSE (only one of them can be contained in the packet) I don't agree that only one of them can be included; see above. You seem to be making unnecessary limitations. > Received LOCATOR: > - For each MN address in the received LOCATOR > - State is DEPRACATED or UNKNOWN Why? See above. > - Goto UNVERIFIED and send ECHO_REQUEST > - State is UNVERIFIED > - Resend ECHO_REQUEST and decrease retransmission timeout > - Any other state, DROP > > Received ECHO REQUEST: > - For each MN address in the corresponding LOCATOR > - State is UNVERIFIED > - Goto ACTIVE and send ECHO_RESPONSE > - Any other state, DROP I don't understand the logic here. IMHO you should always answer with ECHO_RESPONSE when you get an ECHO_REQUEST on any of your addresses, independent of what you are doing with your peer's address verification. Completely separate this out. > Received ECHO_RESPONSE: > - Goto DEPRACATED for all old addresses not present in LOCATOR Hmm. Sounds like a sensible place of doing that. But there may be dragons around, beware. > - For each MN address in the corresponding LOCATOR > - State is UNVERIFIED > - Otherwise goto ACTIVE But you can't do that for other than the address that you just verified? Are you saying that one ECHO pair is enough to make all addresses verified? Definitely NOT! > - Change preferred LOCATOR when necessary > - Any other state, DROP > > Receive ESP: > - For the ESP address > - State is UNVERIFIED > - Verify ESP validity. Goto DROP if failed > - Change preferred LOCATOR when necessary Did we specify this? May make sense sometimes, but again, beware.... ESP doesn't protect IP source... > - Process ESP if there are credits left, and decrease credits. > - Otherwise DROP > - State is ACTIVE > - Process ESP > - Any other state, DROP > --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 00:35:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSo7R-0001Nm-6I; Mon, 10 Apr 2006 00:35:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSo7Q-0001Nh-7L for hipsec@lists.ietf.org; Mon, 10 Apr 2006 00:35:16 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSo7O-0006EK-Q2 for hipsec@lists.ietf.org; Mon, 10 Apr 2006 00:35:16 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2170F212C63; Mon, 10 Apr 2006 07:35:14 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CAE66212C5F; Mon, 10 Apr 2006 07:35:13 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] some comments for mm-03: Section 6 Date: Mon, 10 Apr 2006 07:33:56 +0300 To: Miika Komu X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: hipsec@lists.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >> If an attacker somehow uses a bug in the implementation or >> weakness in >> some protocol to redirect a HIP connection, the original owner can >> always reclaim their connection (they can always prove ownership >> of the >> private key associated with their public HI). > > How is this possible if the private key is compromised? If the private key is compromised, there is nothing you can do. The only think you can do is to revoke the public key; something the (so far) have deliberately left out of scope. >> MitM attacks are always possible if the attacker is present during >> the >> initial HIP base exchange and if the hosts do not authenticate each >> other's identities, but once the base exchange has taken place even a >> MitM cannot steal an opportunistic HIP connection because it is very >> difficult for an attacker to create an UPDATE packet (or any HIP >> packet) >> that will be accepted as a legitimate update. > > This does not make sense because it is too obvious? After > opportunistic > connection (leap of faith) the connection is no longer opportunistic. > Maybe this text can be just removed. It may be obvious to you and me, but not to everyone. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 00:39:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSoBJ-0001bN-Is; Mon, 10 Apr 2006 00:39:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSoBH-0001bI-U3 for hipsec@ietf.org; Mon, 10 Apr 2006 00:39:15 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSoBH-0006HP-JV for hipsec@ietf.org; Mon, 10 Apr 2006 00:39:15 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7E80E212C5D; Mon, 10 Apr 2006 07:39:13 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CA427212C4E; Mon, 10 Apr 2006 07:39:12 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Mon, 10 Apr 2006 07:39:12 +0300 To: Charlie Kaufman X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: HIP , Petri Jokela Subject: [Hipsec] Re: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Charlie, The crux of this issue seems to be that (IIRC) we'd like to mandate/ recommend that the default configuration is one of the following: 1. Offer HMAC-SHA1-AES128CBC as the last resort cipher suite, _or_ 2. Offer HMAC-SHA1-NULL as the last resort cipher suite That is, by default, one of the above MUST be offered. Now, is there something that you see problematic with such a requirement? Maybe that the text is not clear enough in saying that the they are just the mandatory defaults, defined in order to ensure interoperability? If not, then I think we just need to clarify the text. --Pekka On Apr 8, 2006, at 9:49, Charlie Kaufman wrote: > I apologize that my mailer can't auto-generate the >> indentations > and at the moment I lack the patience to do it myself. > > I agree with Pekka that it's important that there could be a legal > implementation that did not offer encryption, so if you're going to > go down this path some Null scheme has to be mandatory to implement. > > But I still object to picking those algorithms as mandatory to > offer. While it guarantees interoperability between any two > compliant implementations (which is good), it comes at a cost of > disallowing *configurations* that only want to support some > stronger hash or that don't want to accept NULL encryption. I don't > know whether an RFC can say anything about the mandatory *default* > configuration, but I believe that's what you're really trying to > get at. > > --Charlie > > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Friday, April 07, 2006 12:40 AM > To: HIP > Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman > Subject: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a > mandatory algorithm > >>>>> There is mandatory support for ESP with HMAC-SHA1 and either >>>>> Null or AES128CBC encryption. This is mandatory not just in the >>>>> implementation but also in the configuration. (i.e., as written, >>>>> the spec says that one of those two suites must be offered in >>>>> every negotiation). >>> >>> The reason for this was that we would have something common >>> between all nodes. >> >> But Null should not be mandatory to offer. AES128CBC would do as a >> mandatory-to-offer. > > I don't understand this comment. Maybe the text is unclear (Section > 5.2.7 I think), but AFAICS it just requires that the responder > includes _at_least_ either HMAC-SHA1-NULL or HMAC-SHA1-AES128CBC. > Nothing prevents it from including both and perhaps others. > > If you implement HMAC-SHA1-AES128CBC, it is trivial to implement HMAC- > SHA1-NULL. > > What is wrong with this? To me this approach seems to be fine with > me; not all connections require encryption. > > --Pekka > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 02:16:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSph6-0001Ex-O8; Mon, 10 Apr 2006 02:16:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSph4-00017W-8T for hipsec@ietf.org; Mon, 10 Apr 2006 02:16:10 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSpVr-0000in-SU for hipsec@ietf.org; Mon, 10 Apr 2006 02:04:38 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E9FB3212C5D; Mon, 10 Apr 2006 09:04:33 +0300 (EEST) Received: from n50.nomadiclab.com (n50.nomadiclab.com [193.234.219.50]) by n2.nomadiclab.com (Postfix) with ESMTP id 9E12C212C4E; Mon, 10 Apr 2006 09:04:33 +0300 (EEST) From: Jan Mikael Melen To: hipsec@lists.ietf.org Subject: Re: [Hipsec] some comments for mm-03: CLOSE vs. UPDATE Date: Mon, 10 Apr 2006 09:05:09 +0300 User-Agent: KMail/1.8.2 References: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> <7D039943-1FBB-4997-97F4-FCEFE72B53EF@nomadiclab.com> In-Reply-To: <7D039943-1FBB-4997-97F4-FCEFE72B53EF@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604100905.10994.Jan.Melen@nomadiclab.com> X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi, I just want to say that I agree with Pekka that using the CLOSE message for closing something else than the whole HIP association is a bad idea. IMHO the semantics of CLOSE and UPDATE are different. UPDATE means that you are updating something and still want to continue using the previously created HIP association. CLOSE means that you want to end the communication, you don't want to send anymore anything using the existing HIP association. Regards, Jan On Monday 10 April 2006 06:37, Pekka Nikander wrote: > [Answering bit-by-bit as most probably I won't have time to go > over all related messages at this point of time.] > > >>> The SAs are closed as defined as in in the general > >>> case. As such, closing of the SAs causes all of the SAs to be closed > >>> also in multihoming scenarios. A host MAY add an ESP_INFO > >>> parameter to > >>> a CLOSE message to signal that a specific SA is to be close. The > >>> CLOSE-ACK message should also include the same ESP_INFO > >>> parameter. In > >>> the ESP_INFO parameter, the old SPI corresponds to SA to be > >>> removed. The new SPI and keymat index are set to zero. > >> > >> I do not necessarily agree with this, and would like to hear other > >> opinions. CLOSE should close all security associations; if a > >> specific > >> SA is to be closed while others remain open, it should be possible > >> to do > >> so through the UPDATE protocol. > > > > So, there seems to be some redundancy with CLOSE and UPDATE. In > > fact, I'd > > say that the CLOSE could be replaced with UPDATE as it implements > > only a > > subset of UPDATE. Petri, Pekka, others - comments? > > IIRC, CLOSE was added fairly late in order to allow the _HIP_ > association to be cleanly torn down. I think Erik Nordmark suggested > adding it. > > I don't think it is a good idea to use CLOSE for closing SAs, or for > any other purpose than closing the who HIP SA. If I understand > correctly the text above, you Miika are suggesting to use CLOSE to > close only specific ESP SAs but not the HIP association. That sounds > like a pretty bad idea to me, confusing the semantics of CLOSE. But > perhaps I don't understand what you are suggesting, Miika? _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 02:16:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSphA-0001Gj-PJ; Mon, 10 Apr 2006 02:16:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSph4-00015Z-8E for hipsec@lists.ietf.org; Mon, 10 Apr 2006 02:16:10 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSpVr-0000io-SU for hipsec@lists.ietf.org; Mon, 10 Apr 2006 02:04:38 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E9FB3212C5D; Mon, 10 Apr 2006 09:04:33 +0300 (EEST) Received: from n50.nomadiclab.com (n50.nomadiclab.com [193.234.219.50]) by n2.nomadiclab.com (Postfix) with ESMTP id 9E12C212C4E; Mon, 10 Apr 2006 09:04:33 +0300 (EEST) From: Jan Mikael Melen To: hipsec@lists.ietf.org Subject: Re: [Hipsec] some comments for mm-03: CLOSE vs. UPDATE Date: Mon, 10 Apr 2006 09:05:09 +0300 User-Agent: KMail/1.8.2 References: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> <7D039943-1FBB-4997-97F4-FCEFE72B53EF@nomadiclab.com> In-Reply-To: <7D039943-1FBB-4997-97F4-FCEFE72B53EF@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604100905.10994.Jan.Melen@nomadiclab.com> X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi, I just want to say that I agree with Pekka that using the CLOSE message for closing something else than the whole HIP association is a bad idea. IMHO the semantics of CLOSE and UPDATE are different. UPDATE means that you are updating something and still want to continue using the previously created HIP association. CLOSE means that you want to end the communication, you don't want to send anymore anything using the existing HIP association. Regards, Jan On Monday 10 April 2006 06:37, Pekka Nikander wrote: > [Answering bit-by-bit as most probably I won't have time to go > over all related messages at this point of time.] > > >>> The SAs are closed as defined as in in the general > >>> case. As such, closing of the SAs causes all of the SAs to be closed > >>> also in multihoming scenarios. A host MAY add an ESP_INFO > >>> parameter to > >>> a CLOSE message to signal that a specific SA is to be close. The > >>> CLOSE-ACK message should also include the same ESP_INFO > >>> parameter. In > >>> the ESP_INFO parameter, the old SPI corresponds to SA to be > >>> removed. The new SPI and keymat index are set to zero. > >> > >> I do not necessarily agree with this, and would like to hear other > >> opinions. CLOSE should close all security associations; if a > >> specific > >> SA is to be closed while others remain open, it should be possible > >> to do > >> so through the UPDATE protocol. > > > > So, there seems to be some redundancy with CLOSE and UPDATE. In > > fact, I'd > > say that the CLOSE could be replaced with UPDATE as it implements > > only a > > subset of UPDATE. Petri, Pekka, others - comments? > > IIRC, CLOSE was added fairly late in order to allow the _HIP_ > association to be cleanly torn down. I think Erik Nordmark suggested > adding it. > > I don't think it is a good idea to use CLOSE for closing SAs, or for > any other purpose than closing the who HIP SA. If I understand > correctly the text above, you Miika are suggesting to use CLOSE to > close only specific ESP SAs but not the HIP association. That sounds > like a pretty bad idea to me, confusing the semantics of CLOSE. But > perhaps I don't understand what you are suggesting, Miika? _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 05:16:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsVu-0003u2-7x; Mon, 10 Apr 2006 05:16:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsVt-0003to-6x for hipsec@lists.ietf.org; Mon, 10 Apr 2006 05:16:49 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSsVp-00088I-Rl for hipsec@lists.ietf.org; Mon, 10 Apr 2006 05:16:49 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id D972C2D72; Mon, 10 Apr 2006 12:16:44 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5EC1E2D72; Mon, 10 Apr 2006 12:16:44 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k3A9Gif27248; Mon, 10 Apr 2006 12:16:44 +0300 (EEST) Date: Mon, 10 Apr 2006 12:16:43 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Jan Mikael Melen Subject: Re: [Hipsec] some comments for mm-03: CLOSE vs. UPDATE In-Reply-To: <200604100905.10994.Jan.Melen@nomadiclab.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> <7D039943-1FBB-4997-97F4-FCEFE72B53EF@nomadiclab.com> <200604100905.10994.Jan.Melen@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: hipsec@ietf.org, hipsec@lists.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 10 Apr 2006, Jan Mikael Melen wrote: Agree. Thomas, may be you can add a similar text to the mm draft? > I just want to say that I agree with Pekka that using the CLOSE message for > closing something else than the whole HIP association is a bad idea. IMHO the > semantics of CLOSE and UPDATE are different. UPDATE means that you are > updating something and still want to continue using the previously created > HIP association. CLOSE means that you want to end the communication, you > don't want to send anymore anything using the existing HIP association. > > Regards, > Jan > > On Monday 10 April 2006 06:37, Pekka Nikander wrote: > > [Answering bit-by-bit as most probably I won't have time to go > > over all related messages at this point of time.] > > > > >>> The SAs are closed as defined as in in the general > > >>> case. As such, closing of the SAs causes all of the SAs to be closed > > >>> also in multihoming scenarios. A host MAY add an ESP_INFO > > >>> parameter to > > >>> a CLOSE message to signal that a specific SA is to be close. The > > >>> CLOSE-ACK message should also include the same ESP_INFO > > >>> parameter. In > > >>> the ESP_INFO parameter, the old SPI corresponds to SA to be > > >>> removed. The new SPI and keymat index are set to zero. > > >> > > >> I do not necessarily agree with this, and would like to hear other > > >> opinions. CLOSE should close all security associations; if a > > From hipsec-bounces@lists.ietf.org Mon Apr 10 05:16:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsVu-0003u2-7x; Mon, 10 Apr 2006 05:16:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsVt-0003to-6x for hipsec@lists.ietf.org; Mon, 10 Apr 2006 05:16:49 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSsVp-00088I-Rl for hipsec@lists.ietf.org; Mon, 10 Apr 2006 05:16:49 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id D972C2D72; Mon, 10 Apr 2006 12:16:44 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5EC1E2D72; Mon, 10 Apr 2006 12:16:44 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k3A9Gif27248; Mon, 10 Apr 2006 12:16:44 +0300 (EEST) Date: Mon, 10 Apr 2006 12:16:43 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Jan Mikael Melen Subject: Re: [Hipsec] some comments for mm-03: CLOSE vs. UPDATE In-Reply-To: <200604100905.10994.Jan.Melen@nomadiclab.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> <7D039943-1FBB-4997-97F4-FCEFE72B53EF@nomadiclab.com> <200604100905.10994.Jan.Melen@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: hipsec@ietf.org, hipsec@lists.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 10 Apr 2006, Jan Mikael Melen wrote: Agree. Thomas, may be you can add a similar text to the mm draft? > I just want to say that I agree with Pekka that using the CLOSE message for > closing something else than the whole HIP association is a bad idea. IMHO the > semantics of CLOSE and UPDATE are different. UPDATE means that you are > updating something and still want to continue using the previously created > HIP association. CLOSE means that you want to end the communication, you > don't want to send anymore anything using the existing HIP association. > > Regards, > Jan > > On Monday 10 April 2006 06:37, Pekka Nikander wrote: > > [Answering bit-by-bit as most probably I won't have time to go > > over all related messages at this point of time.] > > > > >>> The SAs are closed as defined as in in the general > > >>> case. As such, closing of the SAs causes all of the SAs to be closed > > >>> also in multihoming scenarios. A host MAY add an ESP_INFO > > >>> parameter to > > >>> a CLOSE message to signal that a specific SA is to be close. The > > >>> CLOSE-ACK message should also include the same ESP_INFO > > >>> parameter. In > > >>> the ESP_INFO parameter, the old SPI corresponds to SA to be > > >>> removed. The new SPI and keymat index are set to zero. > > >> > > >> I do not necessarily agree with this, and would like to hear other > > >> opinions. CLOSE should close all security associations; if a > > >> specific > > >> SA is to be closed while others remain open, it should be possible > > >> to do > > >> so through the UPDATE protocol. > > > > > > So, there seems to be some redundancy with CLOSE and UPDATE. In > > > fact, I'd > > > say that the CLOSE could be replaced with UPDATE as it implements > > > only a > > > subset of UPDATE. Petri, Pekka, others - comments? > > > > IIRC, CLOSE was added fairly late in order to allow the _HIP_ > > association to be cleanly torn down. I think Erik Nordmark suggested > > adding it. > > > > I don't think it is a good idea to use CLOSE for closing SAs, or for > > any other purpose than closing the who HIP SA. If I understand > > correctly the text above, you Miika are suggesting to use CLOSE to > > close only specific ESP SAs but not the HIP association. That sounds > > like a pretty bad idea to me, confusing the semantics of CLOSE. But > > perhaps I don't understand what you are suggesting, Miika? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 05:16:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsVu-0003tx-3D; Mon, 10 Apr 2006 05:16:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsVt-0003tn-6s for hipsec@ietf.org; Mon, 10 Apr 2006 05:16:49 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSsVp-00088J-Rl for hipsec@ietf.org; Mon, 10 Apr 2006 05:16:49 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id D972C2D72; Mon, 10 Apr 2006 12:16:44 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5EC1E2D72; Mon, 10 Apr 2006 12:16:44 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k3A9Gif27248; Mon, 10 Apr 2006 12:16:44 +0300 (EEST) Date: Mon, 10 Apr 2006 12:16:43 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Jan Mikael Melen Subject: Re: [Hipsec] some comments for mm-03: CLOSE vs. UPDATE In-Reply-To: <200604100905.10994.Jan.Melen@nomadiclab.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> <7D039943-1FBB-4997-97F4-FCEFE72B53EF@nomadiclab.com> <200604100905.10994.Jan.Melen@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: hipsec@ietf.org, hipsec@lists.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 10 Apr 2006, Jan Mikael Melen wrote: Agree. Thomas, may be you can add a similar text to the mm draft? > I just want to say that I agree with Pekka that using the CLOSE message for > closing something else than the whole HIP association is a bad idea. IMHO the > semantics of CLOSE and UPDATE >> specific > > >> SA is to be closed while others remain open, it should be possible > > >> to do > > >> so through the UPDATE protocol. > > > > > > So, there seems to be some redundancy with CLOSE and UPDATE. In > > > fact, I'd > > > say that the CLOSE could be replaced with UPDATE as it implements > > > only a > > > subset of UPDATE. Petri, Pekka, others - comments? > > > > IIRC, CLOSE was added fairly late in order to allow the _HIP_ > > association to be cleanly torn down. I think Erik Nordmark suggested > > adding it. > > > > I don't think it is a good idea to use CLOSE for closing SAs, or for > > any other purpose than closing the who HIP SA. If I understand > > correctly the text above, you Miika are suggesting to use CLOSE to > > close only specific ESP SAs but not the HIP association. That sounds > > like a pretty bad idea to me, confusing the semantics of CLOSE. But > > perhaps I don't understand what you are suggesting, Miika? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 05:16:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsVu-0003tx-3D; Mon, 10 Apr 2006 05:16:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsVt-0003tn-6s for hipsec@ietf.org; Mon, 10 Apr 2006 05:16:49 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSsVp-00088J-Rl for hipsec@ietf.org; Mon, 10 Apr 2006 05:16:49 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id D972C2D72; Mon, 10 Apr 2006 12:16:44 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5EC1E2D72; Mon, 10 Apr 2006 12:16:44 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k3A9Gif27248; Mon, 10 Apr 2006 12:16:44 +0300 (EEST) Date: Mon, 10 Apr 2006 12:16:43 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Jan Mikael Melen Subject: Re: [Hipsec] some comments for mm-03: CLOSE vs. UPDATE In-Reply-To: <200604100905.10994.Jan.Melen@nomadiclab.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> <7D039943-1FBB-4997-97F4-FCEFE72B53EF@nomadiclab.com> <200604100905.10994.Jan.Melen@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: hipsec@ietf.org, hipsec@lists.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 10 Apr 2006, Jan Mikael Melen wrote: Agree. Thomas, may be you can add a similar text to the mm draft? > I just want to say that I agree with Pekka that using the CLOSE message for > closing something else than the whole HIP association is a bad idea. IMHO the > semantics of CLOSE and UPDATE are different. UPDATE means that you are > updating something and still want to continue using the previously created > HIP association. CLOSE means that you want to end the communication, you > don't want to send anymore anything using the existing HIP association. > > Regards, > Jan > > On Monday 10 April 2006 06:37, Pekka Nikander wrote: > > [Answering bit-by-bit as most probably I won't have time to go > > over all related messages at this point of time.] > > > > >>> The SAs are closed as defined as in in the general > > >>> case. As such, closing of the SAs causes all of the SAs to be closed > > >>> also in multihoming scenarios. A host MAY add an ESP_INFO > > >>> parameter to > > >>> a CLOSE message to signal that a specific SA is to be close. The > > >>> CLOSE-ACK message should also include the same ESP_INFO > > >>> parameter. In > > >>> the ESP_INFO parameter, the old SPI corresponds to SA to be > > >>> removed. The new SPI and keymat index are set to zero. > > >> > > >> I do not necessarily agree with this, and would like to hear other > > >> opinions. CLOSE should close all security associations; if a > > >> specific > > >> SA is to be closed while others remain open, it should be possible > > >> to do > > >> so through the UPDATE protocol. > > > > > > So, there seems to be some redundancy with CLOSE and UPDATE. In > > > fact, I'd > > > say that the CLOSE could be replaced with UPDATE as it implements > > > only a > > > subset of UPDATE. Petri, Pekka, others - comments? > > > > IIRC, CLOSE was added fairly late in order to allow the _HIP_ > > association to be cleanly torn down. I think Erik Nordmark suggested > > adding it. > > > > I don't think it is a good idea to use CLOSE for closing SAs, or for > > any other purpose than closing the who HIP SA. If I understand > > correctly the text above, you Miika are suggesting to use CLOSE to > > close only specific ESP SAs but not the HIP association. That sounds > > like a pretty bad idea to me, confusing the semantics of CLOSE. But > > perhaps I don't understand what you are suggesting, Miika? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec are different. UPDATE means that you are > updating something and still want to continue using the previously created > HIP association. CLOSE means that you want to end the communication, you > don't want to send anymore anything using the existing HIP association. > > Regards, > Jan > > On Monday 10 April 2006 06:37, Pekka Nikander wrote: > > [Answering bit-by-bit as most probably I won't have time to go > > over all related messages at this point of time.] > > > > >>> The SAs are closed as defined as in in the general > > >>> case. As such, closing of the SAs causes all of the SAs to be closed > > >>> also in multihoming scenarios. A host MAY add an ESP_INFO > > >>> parameter to > > >>> a CLOSE message to signal that a specific SA is to be close. The > > >>> CLOSE-ACK message should also include the same ESP_INFO > > >>> parameter. In > > >>> the ESP_INFO parameter, the old SPI corresponds to SA to be > > >>> removed. The new SPI and keymat index are set to zero. > > >> > > >> I do not necessarily agree with this, and would like to hear other > > >> opinions. CLOSE should close all security associations; if a > > >> specific > > >> SA is to be closed while others remain open, it should be possible > > >> to do > > >> so through the UPDATE protocol. > > > > > > So, there seems to be some redundancy with CLOSE and UPDATE. In > > > fact, I'd > > > say that the CLOSE could be replaced with UPDATE as it implements > > > only a > > > subset of UPDATE. Petri, Pekka, others - comments? > > > > IIRC, CLOSE was added fairly late in order to allow the _HIP_ > > association to be cleanly torn down. I think Erik Nordmark suggested > > adding it. > > > > I don't think it is a good idea to use CLOSE for closing SAs, or for > > any other purpose than closing the who HIP SA. If I understand > > correctly the text above, you Miika are suggesting to use CLOSE to > > close only specific ESP SAs but not the HIP association. That sounds > > like a pretty bad idea to me, confusing the semantics of CLOSE. But > > perhaps I don't understand what you are suggesting, Miika? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 05:35:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsnh-0002qh-Ff; Mon, 10 Apr 2006 05:35:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsnf-0002qc-Rn for hipsec@ietf.org; Mon, 10 Apr 2006 05:35:11 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSsne-0000kz-Gj for hipsec@ietf.org; Mon, 10 Apr 2006 05:35:11 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 13B482E48; Mon, 10 Apr 2006 12:35:10 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 7E6802E1A; Mon, 10 Apr 2006 12:35:09 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k3A9Z8J28697; Mon, 10 Apr 2006 12:35:08 +0300 (EEST) Date: Mon, 10 Apr 2006 12:35:08 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Nikander Subject: Re: [Hipsec] some comments for mm-03: including ESP-INFO in all (relevant) UPDATES In-Reply-To: <2D12A2F5-80F5-42D9-AA54-289B62F3EC3D@nomadiclab.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> <2D12A2F5-80F5-42D9-AA54-289B62F3EC3D@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 10 Apr 2006, Pekka Nikander wrote: > >>>> Figure 6: Basic multihoming scenario > >>> > >>> Is the ECHO_RESPONSE 100 % sure way to map the last incoming > >>> UPDATE to certain SA? Why don't we just include the ESP_INFO? If > >>> this is the case, why don't we do also for the other use cases > >>> for generality's sake. > >> > >> I had always thought that the HIP daemon would use the SEQs and > >> ACKs to map these packets. I do not have a problem with including > >> ESP_INFO, either as a MUST or a MAY, to help implementors > >> (although it would have to be treated as a protocol error if it > >> didn't match the original ESP_INFO). What do other implementors > >> think? > > > Now rethinking this again, base draft says "The Update ID has scope > > within a single HIP association, and not across multiple > > associations or multiple hosts.". As a result, the update ID should > > be enough information to map the incoming packet to a SA. > > > > However, requiring the use of ESP_INFO in all UPDATE packets would > > be at least systematical and implementor friendlier. Less indexing > > required in the implementation. Maybe it is also better for > > middleboxes. > > I could imagine privacy reasons why you may not want to add ESP_INFO > in those UPDATE packets that you use to verify address reachability. > Not particularly strong privacy reasons, but still. What are the privacy reasons in this case? The SPIs are already exposed in the two first packets, so why not also in the third? > Hence, IMHO including ESP_INFO in those packets should be at most > SHOULD, and probably MAY, if people want it. I'd like it to be MUST (or SHOULD) just to reduce the (probability of) different combinations. Or as an alternative, leave it as it is now. > On the other hand, I don't understand this issue from the implementers' > point of view, and would be very interested in hearing counter > arguments. My point was to reduce the number of indexing mechanisms required in the implementations. When you receive an UPDATE packet containing an ECHO RESPONSE but without ESP_INFO, you need yet another index (the UPDATE ID) to map the packet to the corresponding SA. However, if we had the the ESP_INFO included, we'd find the SA just with the existing SPI search mechanisms that are already required for base exchange. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 05:39:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsrr-0003uq-Oi; Mon, 10 Apr 2006 05:39:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSsrq-0003ul-5q for hipsec@lists.ietf.org; Mon, 10 Apr 2006 05:39:30 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSsrp-0000pJ-ST for hipsec@lists.ietf.org; Mon, 10 Apr 2006 05:39:30 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 710782E7C; Mon, 10 Apr 2006 12:39:29 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 168972E21; Mon, 10 Apr 2006 12:39:29 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k3A9dSZ28994; Mon, 10 Apr 2006 12:39:28 +0300 (EEST) Date: Mon, 10 Apr 2006 12:39:28 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Nikander Subject: Re: [Hipsec] some comments for mm-03: Section 6 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: hipsec@lists.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 10 Apr 2006, Pekka Nikander wrote: > >> MitM attacks are always possible if the attacker is present during > >> the > >> initial HIP base exchange and if the hosts do not authenticate each > >> other's identities, but once the base exchange has taken place even a > >> MitM cannot steal an opportunistic HIP connection because it is very > >> difficult for an attacker to create an UPDATE packet (or any HIP > >> packet) > >> that will be accepted as a legitimate update. > > > > This does not make sense because it is too obvious? After > > opportunistic > > connection (leap of faith) the connection is no longer opportunistic. > > Maybe this text can be just removed. > > It may be obvious to you and me, but not to everyone. This was mostly a readibility comment. I suggest changing the text as follows: MitM attacks are always possible when the attacker is present during the initial HIP base exchange and the hosts do not authenticate each other's identities. However, once the opportunistic base exchange has taken place, even a MitM cannot steal the HIP connection anymore because it is very difficult for an attacker to create an UPDATE packet (or any HIP packet) that will be accepted as a legitimate update. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 05:49:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSt1U-0000Dj-Sk; Mon, 10 Apr 2006 05:49:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSt1T-0000De-O8 for hipsec@ietf.org; Mon, 10 Apr 2006 05:49:27 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSt1S-0000yC-Eh for hipsec@ietf.org; Mon, 10 Apr 2006 05:49:27 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DDDC6212C63; Mon, 10 Apr 2006 12:49:24 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 81CB2212C5F; Mon, 10 Apr 2006 12:49:24 +0300 (EEST) In-Reply-To: References: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> <2D12A2F5-80F5-42D9-AA54-289B62F3EC3D@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <93B5DE1A-E74F-4D57-9FED-4ABB5FB1E7CF@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] some comments for mm-03: including ESP-INFO in all (relevant) UPDATES Date: Mon, 10 Apr 2006 12:49:24 +0300 To: Miika Komu X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org > My point was to reduce the number of indexing mechanisms required > in the > implementations. When you receive an UPDATE packet containing an ECHO > RESPONSE but without ESP_INFO, you need yet another index (the > UPDATE ID) > to map the packet to the corresponding SA. However, if we had the the > ESP_INFO included, we'd find the SA just with the existing SPI search > mechanisms that are already required for base exchange. How come? Why don't you just include the necessary info in you ECHO_REQUEST? You can even include a direct memory pointer if you dare (but I wouldn't do that... :-) You are free to include any information you want there, aren't you? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 08:16:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSvJZ-0007vd-9O; Mon, 10 Apr 2006 08:16:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSvJY-0007vY-Hd for hipsec@ietf.org; Mon, 10 Apr 2006 08:16:16 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSvJW-0007Eu-79 for hipsec@ietf.org; Mon, 10 Apr 2006 08:16:16 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id A5F49304E; Mon, 10 Apr 2006 15:16:13 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 13FAE3026; Mon, 10 Apr 2006 15:16:13 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k3ACGBV09509; Mon, 10 Apr 2006 15:16:11 +0300 (EEST) Date: Mon, 10 Apr 2006 15:16:11 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Nikander Subject: Re: [Hipsec] some comments for mm-03: including ESP-INFO in all (relevant) UPDATES In-Reply-To: <93B5DE1A-E74F-4D57-9FED-4ABB5FB1E7CF@nomadiclab.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> <2D12A2F5-80F5-42D9-AA54-289B62F3EC3D@nomadiclab.com> <93B5DE1A-E74F-4D57-9FED-4ABB5FB1E7CF@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 10 Apr 2006, Pekka Nikander wrote: > > My point was to reduce the number of indexing mechanisms required in > > the implementations. When you receive an UPDATE packet containing an > > ECHO RESPONSE but without ESP_INFO, you need yet another index (the > > UPDATE ID) to map the packet to the corresponding SA. However, if we > > had the the ESP_INFO included, we'd find the SA just with the existing > > SPI search mechanisms that are already required for base exchange. > > How come? Why don't you just include the necessary info in you > ECHO_REQUEST? You can even include a direct memory pointer if you > dare (but I wouldn't do that... :-) You are free to include any > information you want there, aren't you? You are correct. The implementation can "hide" e.g. a SPI in the ECHO_REQUEST or even in SEQ/ACK update if this explicit handling is not wanted. So, it appears now to me that this idea can be forgotten. However, I'd like to see a hint for the silly implementor in section 5.4. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 09:50:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwmc-0002ND-BQ; Mon, 10 Apr 2006 09:50:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwma-0002N3-Q1 for hipsec@ietf.org; Mon, 10 Apr 2006 09:50:20 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSwmZ-0001wM-7Y for hipsec@ietf.org; Mon, 10 Apr 2006 09:50:20 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 6F74D3050; Mon, 10 Apr 2006 16:50:18 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id BE9FA2C66; Mon, 10 Apr 2006 16:50:17 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k3ADoHm15511; Mon, 10 Apr 2006 16:50:17 +0300 (EEST) Date: Mon, 10 Apr 2006 16:50:17 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Nikander Subject: Re: [Hipsec] a state machine proposal for mm-03 In-Reply-To: <9AEF0EF5-18B0-4D1D-8722-37DB49721A94@nomadiclab.com> Message-ID: References: <9AEF0EF5-18B0-4D1D-8722-37DB49721A94@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 10 Apr 2006, Pekka Nikander wrote: > > Note2: the state machine is simpler to design if we leave out the > > peer initiated rekeying (section 3.2.1.2 in the draft). This way, > > we can assume that the UPDATE exchange consists of three packets > > and that each packet can be distinguished from each other by the > > precence of LOCATOR, ECHO_REQUEST or ECHO_RESPONSE. > > Unfortunately I don't have time to really consider this in detail, > but my earlier understanding was that, at least in principle, you > could make the mobility and re-keying state machines completely > separate. > > Anyway, from the overall architectural design point of view the idea > was to use UPDATEs as a semi-reliable retransmission and > acknowledgement sub-layer, on the top of which you can implement any > state machine. The UPDATE-layer would signal the state machine above > about any eventual events where packets don't get acknowledged even > after multiple retries. Furthermore, the idea was that you could > have multiple parallel state machines running at the same time. > Their messages (payloads) would just be transmitted and acknowledged > at once at the UPDATE layer, without needing any co-ordination > between the above state machines. > > Now, I agree that there might be problems if you want to synchronise > these state machines, e.g., for privacy reasons. However, > fortunately or not, in the particular case of privacy you need to do > also other tricks (such as having a changing HIT-blinding algorithm) > that basically make the whole update mechanism half-unnecessary for > the strong privacy case. It is good to have a high level architectural design in the draft. My state machine proposal was an initial attempt to map the high level design to a more concrete proposal that will perhaps not fulfill all of the high level goals of the draft. However, it will be more easier to implement and make interoperable. I have observed in practice that the current draft, or at least the earlier versions, were quite difficult implement even though the draft has been improving all the time. As a result of the complexity of the draft, at least our mobility code is looking too complex now and needs some rewriting (and I think we are not the only one). Also, I think there has not been many successful interops for m&m either, even though I admit that having the ever-changing base exchange interops haven't made things any easier :) > Some minor comments below, made without _proper_ understanding of the > whole picture: > > > Send UPDATE with LOCATOR: > > - Triggered at the MN depending on changes in network attachments > > and according to local policies > > - Removed addresses are DEPRACATED (and not included in the > > LOCATOR) > > - All other addresses are UNVERIFIED (and included in the LOCATOR) > > Why these need to be UNVERIFIED. Maybe some of those have been > verified earlier? Compare to my notes in the beginning of the email: "Note3: reusing the same state variables on both hosts. At the mobile host (the sender of LOCATOR) it is related to the data structures of the source IP. On the corresponding node (receiver of LOCATOR), it is related to the destination IP." There could be a new state for this at the sender of LOCATOR to make this more clear if that is necessary? > > - Set preferred LOCATOR depending on local policies > > - Send UPDATE with LOCATOR for the CN > > > > Receive HIP UPDATE: > > - Verify the HIP packet: HMAC, SIG, the presence, dependencies and > > validity of the parameters. > > - If the result is failure, goto DROP. > > - If success, proceed based on presence of LOCATOR, ECHO_REQUEST or > > ECHO_RESPONSE (only one of them can be contained in the packet) > > I don't agree that only one of them can be included; see above. You > seem to be making unnecessary limitations. See my comment in the other email: * Mainly, no new features. In fact, I suggest removing one feature / use-case (readdress with peer-initiated rekey) in favour of simplifying state machine, interaction with middle-boxes and interoperable implementations. Suggest removal of it from this draft and adding to a follow-up draft. I am proposing the "artificial" restrictions on the draft to make it more concrete and to support interoperable implementations in the very near future. I think it is just too modular as it is now :) In addition, I think the explicit state machine for m&m could make a security analysis of the UPDATE easier in the future. If my opinion is going to be ruled out by rough concensus, I'd like to hear also other opinions. Anyway, I hope at least some of my comments are useful. > > - Goto UNVERIFIED and send ECHO_REQUEST > > - State is UNVERIFIED > > - Resend ECHO_REQUEST and decrease retransmission timeout > > - Any other state, DROP > > > > Received ECHO REQUEST: > > - For each MN address in the corresponding LOCATOR > > - State is UNVERIFIED > > - Goto ACTIVE and send ECHO_RESPONSE > > - Any other state, DROP > > I don't understand the logic here. IMHO you should always answer > with ECHO_RESPONSE when you get an ECHO_REQUEST on any of your > addresses, independent of what you are doing with your peer's address > verification. Completely separate this out. So the peer could doing some additional address verification? That is fine. > > - For each MN address in the corresponding LOCATOR > > - State is UNVERIFIED > > - Otherwise goto ACTIVE > > But you can't do that for other than the address that you just verified? > Are you saying that one ECHO pair is enough to make all addresses > verified? Definitely NOT! I think I might have confused something here. This would be the new rule: Received ECHO REQUEST: - Goto ACTIVE and send echo response > > Receive ESP: > > - For the ESP address > > - State is UNVERIFIED > > - Verify ESP validity. Goto DROP if failed > > - Change preferred LOCATOR when necessary > > Did we specify this? May make sense sometimes, but again, > beware.... ESP doesn't protect IP source... This was the CBA optimization. Maybe it should be mentioned explicitly. > > - Process ESP if there are credits left, and decrease credits. > > - Otherwise DROP > > - State is ACTIVE > > - Process ESP > > - Any other state, DROP > > > Thanks Pekka. Other comments? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 11:15:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSy7G-0005FR-G2; Mon, 10 Apr 2006 11:15:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSy7F-0005ET-82 for hipsec@ietf.org; Mon, 10 Apr 2006 11:15:45 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSy7E-00061z-Op for hipsec@ietf.org; Mon, 10 Apr 2006 11:15:45 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 28550212C63; Mon, 10 Apr 2006 18:15:43 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9A7C4212C5F; Mon, 10 Apr 2006 18:15:41 +0300 (EEST) In-Reply-To: References: <9AEF0EF5-18B0-4D1D-8722-37DB49721A94@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] a state machine proposal for mm-03 Date: Mon, 10 Apr 2006 18:15:40 +0300 To: Miika Komu X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Miika, I have a feeling that you are imposing the complexity on the design yourself. You seem to be making assumptions that seem unnecessary and complicating to me. For example, why do you attempt to have some kind of mirrored and identical state machines at both ends? I see no need for that. You also seem to try too hard or achieve a too strong consistency between the hosts. Try to think simple, and have address- based rather than host-based state machines. For example, a minimal implementation might do as follows: - When a host gets a new local address or deprecates an old one, it simply sends an update to its active peers (if it can) and lets the UPDATE layer to take care of ACKs and retransmission. If one peer does not get the info, let it be in that way, do not try any harder. If there is active communication with the peer, it will get the new address later on, or resort to using RVS. - When a host receives a new peer address, it simply enters it into its local database. Only if it needs to use it, e.g. due to that new address being the new preferred one or the old preferred one failing, initiate reachability check (with CBA). I'd rather keep those two "state machines" completely separate. It is a well known fact that when you combine multiple simple parallel state machines into a single one you get a complicated one; google e.g. for "state space explosion". Hence, in implementation terms, it is much better to implement several parallel state machines than a single big one. > "Note3: reusing the same state variables on both hosts. At the mobile > host (the sender of LOCATOR) it is related to the data structures of > the source IP. On the corresponding node (receiver of LOCATOR), it is > related to the destination IP." See above. That assumption is unnecessary and likely to complicate your design. > See my comment in the other email: > > * Mainly, no new features. In fact, I suggest removing one feature / > use-case (readdress with peer-initiated rekey) in favour of > simplifying state machine, interaction with middle-boxes and > interoperable implementations. Suggest removal of it from this > draft and > adding to a follow-up draft. See above. Decomposing your big state machine into several parallel ones is likely to simplify your design more than sufficiently. > I am proposing the "artificial" restrictions on the draft to make > it more > concrete and to support interoperable implementations in the very near > future. I think it is just too modular as it is now :) I think the reverse. In this case I think complete state-machine modularity is good; see the argumentation above. > In addition, I > think the explicit state machine for m&m could make a security > analysis of > the UPDATE easier in the future. I agree, but OTOH such a explicit complete state machine should be composed by an analysis tool that is able to automatically generate the compound state machine from the multiple parallel ones. > Received ECHO REQUEST: > - Goto ACTIVE and send echo response See above. There is no need to keep track what the other end thinks about the state of your addresses. That only complicates things. Furthermore, there is a strong theoretical result that says that it is _impossible_ to have complete synchrony between states in an asynchronous system. Google e.g. for "common knowledge" and "modal logic". > >>> Receive ESP: >>> - For the ESP address >>> - State is UNVERIFIED >>> - Verify ESP validity. Goto DROP if failed >>> - Change preferred LOCATOR when necessary >> >> Did we specify this? May make sense sometimes, but again, >> beware.... ESP doesn't protect IP source... > > This was the CBA optimization. Maybe it should be mentioned > explicitly. OK; I haven't been following the details of CBA. I thought it was being applied only for new preferred address candidates as _indicated_ by the peer (or necessitated by the previous peer address'es failure.) --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 11:50:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSyf5-0002ZR-5r; Mon, 10 Apr 2006 11:50:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSyf3-0002Vy-To for hipsec@ietf.org; Mon, 10 Apr 2006 11:50:41 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSydZ-0007C1-Uj for hipsec@ietf.org; Mon, 10 Apr 2006 11:49:10 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA15285; Mon, 10 Apr 2006 10:48:59 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k3AFmxN06137; Mon, 10 Apr 2006 10:48:59 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 08:48:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Belovin-Rescorla analysis - HIP: Opportunistic HIP Date: Mon, 10 Apr 2006 08:48:57 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2EFCA@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Belovin-Rescorla analysis - HIP: Opportunistic HIP Thread-Index: AcZaJ7IyxOlyspLtQQOrQk1ViK2PawCjiXaw From: "Henderson, Thomas R" To: "Pekka Nikander" , "HIP" X-OriginalArrivalTime: 10 Apr 2006 15:48:58.0054 (UTC) FILETIME=[47880E60:01C65CB6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: charliek@exchange.microsoft.com, Petri Jokela X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Friday, April 07, 2006 12:39 AM > To: HIP > Cc: charliek@exchange.microsoft.com; Petri Jokela > Subject: [Hipsec] Belovin-Rescorla analysis - HIP: Opportunistic HIP >=20 > >>>> When doing "opportunistic" HIP negotiation, when node A=20 > wants to =20 > >>>> send to node B and doesn't know whether node B supports HIP, it =20 > >>>> has three choices: 1) It can hold the first packet to B=20 > while it =20 > >>>> tries to negotiate HIP, and if that fails send the first packet =20 > >>>> unprotected; 2) It can forward the first packet unprotected and =20 > >>>> in parallel try to negotiate HIP. If the negotiation succeeds, =20 > >>>> it can start using the ESP tunnel; or 3) it can not try to =20 > >>>> negotiate HIP. Each of these mechanisms has problems. The spec =20 > >>>> should offer some guidance. It's possible this is provided in =20 > >>>> one of the other HIP documents. > >> > >> Maybe a recommendation: > >> > >> 6.6. Initiating a HIP connection > >> > >> The host should try to establish an opportunistic mode HIP =20 > >> association sending at most I1_RETRIES_MAX I1 packets. If it does =20 > >> not receive any R1s, it can try to initiate the connection =20 > >> without HIP if local policy allows. > > > > And use option 1 in the meantime. 2 has many problems, because =20 > > migrating a non-HIP connection to HIP is probably hard to implement. >=20 > I would be tempted to make it explicit that this document does not =20 > define how to do opportunistic HIP but simply provides hooks for it, =20 > a full definition being expected to be available in some future =20 > document. >=20 > Opinions? >=20 I agree to the above proposal to avoid defining it here, because even the option 1 described above has another possible outcome (block the packet). This topic is worthy of a separate draft, and some alignment with opportunistic IPsec design. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 13:27:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT0BB-0001wY-PX; Mon, 10 Apr 2006 13:27:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT0BA-0001wT-QK for hipsec@ietf.org; Mon, 10 Apr 2006 13:27:56 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT0BA-0002q1-FC for hipsec@ietf.org; Mon, 10 Apr 2006 13:27:56 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA25626; Mon, 10 Apr 2006 12:27:45 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k3AHRjT18526; Mon, 10 Apr 2006 10:27:45 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 10:27:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] some comments for mm-03: including ESP-INFO in all (relevant) UPDATES Date: Mon, 10 Apr 2006 10:27:39 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2EFD2@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <2D12A2F5-80F5-42D9-AA54-289B62F3EC3D@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] some comments for mm-03: including ESP-INFO in all (relevant) UPDATES Thread-Index: AcZcUg4WlTvQtF9lSw6uUnfyklpGhwAcEv0A From: "Henderson, Thomas R" To: "Pekka Nikander" , "Miika Komu" X-OriginalArrivalTime: 10 Apr 2006 17:27:39.0554 (UTC) FILETIME=[11054020:01C65CC4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Sunday, April 09, 2006 8:51 PM > To: Miika Komu > Cc: Henderson, Thomas R; hipsec@ietf.org > Subject: Re: [Hipsec] some comments for mm-03: including=20 > ESP-INFO in all (relevant) UPDATES >=20 > >>>> Figure 6: Basic multihoming scenario > >>> > >>> Is the ECHO_RESPONSE 100 % sure way to map the last incoming =20 > >>> UPDATE to certain SA? Why don't we just include the ESP_INFO? If =20 > >>> this is the case, why don't we do also for the other use cases =20 > >>> for generality's sake. > >> > >> I had always thought that the HIP daemon would use the SEQs and =20 > >> ACKs to map these packets. I do not have a problem with=20 > including =20 > >> ESP_INFO, either as a MUST or a MAY, to help implementors =20 > >> (although it would have to be treated as a protocol error if it =20 > >> didn't match the original ESP_INFO). What do other implementors =20 > >> think? >=20 > > Now rethinking this again, base draft says "The Update ID=20 > has scope =20 > > within a single HIP association, and not across multiple =20 > > associations or multiple hosts.". As a result, the update=20 > ID should =20 > > be enough information to map the incoming packet to a SA. > > > > However, requiring the use of ESP_INFO in all UPDATE packets would =20 > > be at least systematical and implementor friendlier. Less indexing =20 > > required in the implementation. Maybe it is also better for =20 > > middleboxes. >=20 > I could imagine privacy reasons why you may not want to add ESP_INFO =20 > in those UPDATE packets that you use to verify address=20 > reachability. =20 > Not particularly strong privacy reasons, but still. Hence, IMHO =20 > including ESP_INFO in those packets should be at most SHOULD, and =20 > probably MAY, if people want it. On the other hand, I don't =20 > understand this issue from the implementers' point of view,=20 > and would =20 > be very interested in hearing counter arguments. >=20 The main reason that ESP_INFO is in the first two packets is for middlebox traversal. Note that if there is no mobility-initiated rekey, there is no strict reason to include ESP_INFO in all mobility exchanges (the LOCATOR contains all the necessary information for mobility), but then you cannot guarantee that future SPI-aware middleboxes will admit the flow. However, the third UPDATE (with ECHO_RESPONSE) has the same ESP_INFO as the first, so we do not replicate it there. The main possible argument for including ESP_INFO in this third mobility packet is for SPI-aware middleboxes, if it makes it any easier for them. I agree with Pekka's point that if an implementation wants to use this info to correlate UPDATEs with ACKs, it can put the information into the nonce however it chooses. Also, note that we do not include ESP_INFO in the third packet of the rekeying exchange (Section 4.1.2 of ESP base draft), and we are trying to overlay those parameters on this mobility exchange. =20 So I would support adding it as a MAY but am not yet convinced to add more strong requirement at this time. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 16:34:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT360-0002u7-Dx; Mon, 10 Apr 2006 16:34:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT35z-0002u2-8Y for hipsec@ietf.org; Mon, 10 Apr 2006 16:34:47 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT35y-0003PF-Ld for hipsec@ietf.org; Mon, 10 Apr 2006 16:34:47 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA27140; Mon, 10 Apr 2006 13:34:32 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k3AKYWT02134; Mon, 10 Apr 2006 13:34:32 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 13:34:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] a state machine proposal for mm-03 Date: Mon, 10 Apr 2006 13:34:11 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2EFDA@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] a state machine proposal for mm-03 Thread-Index: AcZXOHH4u1lgriK8TZ6vb6zrCIvhYQFjshKQ From: "Henderson, Thomas R" To: "Miika Komu" , X-OriginalArrivalTime: 10 Apr 2006 20:34:12.0519 (UTC) FILETIME=[208C2B70:01C65CDE] X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Miika, I am catching up on this email, and I will respond inline below, trying to consider the other exchanges you've had with Pekka.=20 > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Monday, April 03, 2006 8:54 AM > To: hipsec@ietf.org > Subject: [Hipsec] a state machine proposal for mm-03 >=20 > Simplified State Machine without Peer Initiated Rekeying > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 > Note1: since there are no other HIP header types for mobility and > multihoming (other than UPDATE), the actual packet processing depends > on the parameters in the HIP packet. >=20 Agreed. > Note2: the state machine is simpler to design if we leave out the peer > initiated rekeying (section 3.2.1.2 in the draft). This way, we can > assume that the UPDATE exchange consists of three packets and that > each packet can be distinguished from each other by the precence of > LOCATOR, ECHO_REQUEST or ECHO_RESPONSE. I agree that this scenario can be eliminated from the overview section, since it may not frequently occur in practice, but I don't know whether we want to strictly forbid it. I also think that you should avoid treating these parameters as surrogates for a pseudo-mobility HIP type (i.e., LOCATOR =3D=3D mobile = I1, ECHO_REQUEST =3D=3D mobile R1, etc.). =20 LOCATOR is just sent to the peer based on local mobility/policy decision, and the UPDATE is ACKed for reliability's sake. ECHO_REQUEST/RESPONSE is a nonce exchange, used by the peer for reachability test. We describe some scenarios where these parameters can be piggybacked on the same UPDATE message, but there is no requirement to do so, and I would prefer not to constrain it in that way. For instance, we should not require that the peer send the ECHO_REQUEST, nor should we require that the ACK of the LOCATOR also contain an ECHO_REQUEST rather than be in a separate packet. I am agreeing with Pekka's point on decoupling, in general. >=20 > Note3: reusing the same state variables on both hosts. At the mobile > host (the sender of LOCATOR) it is related to the data structures of > the source IP. On the corresponding node (receiver of LOCATOR), it is > related to the destination IP. >=20 I agree with Pekka-- I do not see requirement for this and think that it may actually be constraining. > Note4: need some fresh eyes to verify that this is actually=20 > sensible :) >=20 > Send UPDATE with LOCATOR: > - Triggered at the MN depending on changes in network attachments > and according to local policies > - Removed addresses are DEPRACATED (and not included in the > LOCATOR) > - All other addresses are UNVERIFIED (and included in the LOCATOR) > - Set preferred LOCATOR depending on local policies > - Send UPDATE with LOCATOR for the CN I disagree with your proposal to try to guess what states the peer will assign to the different addresses-- I do not see the requirement to do it this way. >=20 > Receive HIP UPDATE: > - Verify the HIP packet: HMAC, SIG, the presence, dependencies and > validity of the parameters. > - If the result is failure, goto DROP. > - If success, proceed based on presence of LOCATOR, ECHO_REQUEST or > ECHO_RESPONSE (only one of them can be contained in the packet) >=20 as stated above, disagree that only one parameter type can be contained in these messages=20 > Received LOCATOR: > - For each MN address in the received LOCATOR > - State is DEPRACATED or UNKNOWN > - Goto UNVERIFIED and send ECHO_REQUEST sending ECHO_REQUEST is based on local policy decision and shouldn't be automatic. There may be lots of announced addresses that the receiver may not care about checking immediately. Also, DEPRECATED to UNVERIFIED state change requires peer to send a new lifetime to a DEPRECATED address. Your description does not have the notion of locator lifetimes. > - State is UNVERIFIED > - Resend ECHO_REQUEST and decrease retransmission timeout (same comment about sending the nonce applies). I do not understand about decreasing (rather than increasing) timeout. Shouldn't possibly the retransmissions for the address check be decoupled from receiving a new LOCATOR? > - Any other state, DROP There may be addresses in ACTIVE state that are not changed-- I think you want to add "- State is ACTIVE and address hasn't changed (do nothing)" You also should mention that any address *not* in LOCATOR is DEPRECATED immediately. =20 >=20 > Received ECHO REQUEST: > - For each MN address in the corresponding LOCATOR > - State is UNVERIFIED > - Goto ACTIVE and send ECHO_RESPONSE > - Any other state, DROP this again seems to be an instance of trying to mirror state variables, which I disagree with, and Pekka seems to have objected to also. I would rather describe it as "Received ECHO_REQUEST, send ECHO_RESPONSE" and leave it at that. >=20 > Received ECHO_RESPONSE: > - Goto DEPRACATED for all old addresses not present in LOCATOR This step is done upon receiving LOCATOR-- see above. > - For each MN address in the corresponding LOCATOR > - State is UNVERIFIED > - Otherwise goto ACTIVE > - Change preferred LOCATOR when necessary > - Any other state, DROP Would rephrase the above as " - Move the address whose reachability was confirmed by the ECHO_RESPONSE from UNVERIFIED to ACTIVE; do not change any other states" > > > Receive ESP: > > > - For the ESP address > > > - State is UNVERIFIED > > > - Verify ESP validity. Goto DROP if failed > > > - Change preferred LOCATOR when necessary > > > > Did we specify this? May make sense sometimes, but again, > > beware.... ESP doesn't protect IP source... >=20 > This was the CBA optimization. Maybe it should be mentioned=20 > explicitly. I think that what is being referred to here is that a successful decryption of ESP on a new SPI is itself a reachability check, as discussed in paragraph four of Section 5.4. This is an optional optimization. > - Process ESP if there are credits left, and decrease credits. > - Otherwise DROP I think you want to increase credits? Or are you trying to mirror the peer's credit variable (which I wouldn't understand)? > - State is ACTIVE > - Process ESP > - Any other state, DROP >=20 > Send ESP: > - Increase credits (decrease credits?) Actually, decrease only if in UNVERIFIED state; otherwise, no-op. >=20 > UPDATE retransmission timeout for LOCATOR (at MN): > - State is UNVERIFIED > - Resend and decrease retransmission counter > - Any other state > - DROP and zero retransmission counter >=20 again, address states are not relevant here. > UPDATE retransmission timeout for ECHO_REQUEST (at CN): > - State is UNVERIFIED > - Resend and decrease retransmission counter > - Any other state > - DROP and zero retransmission counter I would assume that UPDATE is trying to confirm an UNVERIFIED address, and that if the UPDATE is overcome-by-events (OBE), this timer would have been cancelled. >=20 > UPDATE retransmission timeout for ECHO_RESPONSE (occurs at=20 > the MN when no > ESP was received from the CN from a new address?): > - State is ACTIVE > - Resend and decrease retransmission counter > - Any other state > - DROP and zero retransmission counter this can just be handled by normal UPDATE mechanisms >=20 > Handling of CLOSE with ESP_INFO: > - TBD The other opinions seemed to be to not use CLOSE for this purpose. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 10 16:37:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT38x-0003Al-2N; Mon, 10 Apr 2006 16:37:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT38v-0003Ag-Au for hipsec@ietf.org; Mon, 10 Apr 2006 16:37:49 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT38t-0003Zi-Rv for hipsec@ietf.org; Mon, 10 Apr 2006 16:37:49 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 4FC002FD7; Mon, 10 Apr 2006 23:37:47 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id CDEC12F5B; Mon, 10 Apr 2006 23:37:46 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k3AKbk909037; Mon, 10 Apr 2006 23:37:46 +0300 (EEST) Date: Mon, 10 Apr 2006 23:37:46 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Nikander , hipsec@ietf.org Subject: Re: [Hipsec] a state machine proposal for mm-03 In-Reply-To: Message-ID: References: <9AEF0EF5-18B0-4D1D-8722-37DB49721A94@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org > I have a feeling that you are imposing the complexity on the design > yourself. You seem to be making assumptions that seem unnecessary and > complicating to me. For example, why do you attempt to have some kind > of mirrored and identical state machines at both ends? I see no need > for that. You also seem to try too hard or achieve a too strong > consistency between the hosts. Try to think simple, and have address- > based rather than host-based state machines. Maybe the state machines are now perhaps separated now better. I revised it based your nits online and also Tobias Heer gave some offline comments. They could be used even as simplified, example models instead of forcing them to be mandatory if the flebility/parallelity is the issue. For example, the processing rules of section 5 could be illustrated and summarized in section 5.7 with the simplified state machine. Pekka, thanks for references. I have some background reading to do. Please decide as you think is best for the draft. Other tasks await me already. == Common state machine == Receive HIP UPDATE in ESTABLISHED: - Verify the HIP packet: HMAC, SIG, the presence, dependencies and validity of the parameters. - If the result is failure, goto DROP. - If success, proceed based on presence of LOCATOR, ECHO_REQUEST or ECHO_RESPONSE (only one of them can be contained in the packet) == MN example state machine == Send UPDATE with LOCATOR: - Triggered at the MN depending on changes in network attachments and according to local policies - Removed addresses are DEPRECATED (and not included in the LOCATOR) - All other addresses are ACTIVE - Set preferred LOCATOR depending on local policies - Send UPDATE with LOCATOR for the CN Received ECHO REQUEST: - Send ECHO_RESPONSE UPDATE retransmission timeout for LOCATOR: - State is UNVERIFIED - Resend and decrease retransmission counter - Any other state - DROP and zero retransmission counter == CN example mobility state machine === Received LOCATOR: - For each MN address not present anymore in the locator - Goto DEPRECATED - For each old MN address (already known) in the received LOCATOR - State is DEPRECATED - Goto UNVERIFIED and send ECHO_REQUEST - State is ACTIVE - Stay in ACTIVE - For each new MN address in the received LOCATOR - State is UNVERIFIED - Send ECHO_REQUEST Received ECHO_RESPONSE: - For each MN address in the corresponding LOCATOR - State is UNVERIFIED or ACTIVE - Goto ACTIVE - Change preferred LOCATOR when necessary - Any other state, DROP Receive ESP: - For the ESP address - State is UNVERIFIED - Verify ESP validity. Goto DROP if failed - Process ESP if there are credits left, and decrease credits. - Otherwise DROP - State is ACTIVE - Process ESP - Any other state, DROP Send ESP: - Increase credits UPDATE retransmission timeout for ECHO_REQUEST (at CN): - State is UNVERIFIED - If retransmission counter is zero, goto DEPRECATED - Otherwise, resend and decrease retransmission counter - Any other state - DROP and zero retransmission counter ==== -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Apr 11 00:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTAyY-0001n8-WF; Tue, 11 Apr 2006 00:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTAyX-0001n3-I1 for hipsec@ietf.org; Tue, 11 Apr 2006 00:59:37 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTAyX-0007XS-0I for hipsec@ietf.org; Tue, 11 Apr 2006 00:59:37 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9BAE6212C64; Tue, 11 Apr 2006 07:59:34 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 81329212C63; Tue, 11 Apr 2006 07:59:29 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <93D6BFC7-A228-40E3-9E0F-6971A841F455@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 11 Apr 2006 07:59:28 +0300 To: Charlie Kaufman X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: HIP , Petri Jokela Subject: [Hipsec] Re: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Yes, we seem to be in violent agreement, Charlie, and that agreement concurs with what I remember that our intention was. IIRC, we never discussed this issue into this detail before. Taking the opportunity, I'd like to apply here also the "be strict in what you send, liberal in what you expect" rule here, and slightly weaken the language in other respects, too. However, this should be taken as another issue (part 1 below) and we can decide on it separately from the default rule (part 2 below). Here is my suggestion for revised text, part 1: When sending, there MUST NOT be more than six (6) HIP Suite-IDs in one HIP transform parameter. When receiving, the receiver SHOULD NOT rely on the sender not sending more than six Suite-IDs. OTOH, I am happy with the original strict text, too, if there is any reason for it. Any sensible implementation would not rely on it on receiving, anyway. I would remove the next statement: The limited number of transforms sets the maximum size of HIP_TRANSFORM parameter. OTOH, I don't remember the details of why we imposed the strict length rule in the first place. Anyone? Finally, suggested revised text, part 2: As the default configuration, the HIP_TRANSFORM parameter MUST contain at least one of the mandatory Suite-IDs. There MAY be a configuration option that allows the administrator to override this default. --Pekka On Apr 10, 2006, at 23:38, Charlie Kaufman wrote: > If what you say in your note is the intent (and I think that's a > great thing to require), then I think the text needs to be > clarified. The language I was objecting to was in section 5.2.7: > > There MUST NOT be more than six (6) HIP Suite-IDs in one HIP > transform parameter. The limited number of transforms sets the > maximum size of HIP_TRANSFORM parameter. The HIP_TRANSFORM > parameter > MUST contain at least one of the mandatory Suite-IDs. > > This implies that the HIP_TRANSFORM item is mal-formed if it does > not propose one of the mandatory Suite-IDs, which is much stronger > than saying that they must be present "in the default configuration". > > So it sounds like you and I agree. Is there anyone else out there > who wants to advocate the (current) stronger statement? > > --Charlie > > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Sunday, April 09, 2006 9:39 PM > To: Charlie Kaufman > Cc: HIP; Petri Jokela; Andrew McGregor; Petri Jokela > Subject: Re: Belovin-Rescorla analysis - HIP: NULL ESP encryption > as a mandatory algorithm > > Charlie, > > The crux of this issue seems to be that (IIRC) we'd like to mandate/ > recommend that the default configuration is one of the following: > > 1. Offer HMAC-SHA1-AES128CBC as the last resort cipher suite, _or_ > 2. Offer HMAC-SHA1-NULL as the last resort cipher suite > > That is, by default, one of the above MUST be offered. > > Now, is there something that you see problematic with such a > requirement? Maybe that the text is not clear enough in saying that > the they are just the mandatory defaults, defined in order to ensure > interoperability? > > If not, then I think we just need to clarify the text. > > --Pekka > > On Apr 8, 2006, at 9:49, Charlie Kaufman wrote: > >> I apologize that my mailer can't auto-generate the >> indentations >> and at the moment I lack the patience to do it myself. >> >> I agree with Pekka that it's important that there could be a legal >> implementation that did not offer encryption, so if you're going to >> go down this path some Null scheme has to be mandatory to implement. >> >> But I still object to picking those algorithms as mandatory to >> offer. While it guarantees interoperability between any two >> compliant implementations (which is good), it comes at a cost of >> disallowing *configurations* that only want to support some >> stronger hash or that don't want to accept NULL encryption. I don't >> know whether an RFC can say anything about the mandatory *default* >> configuration, but I believe that's what you're really trying to >> get at. >> >> --Charlie >> >> -----Original Message----- >> From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] >> Sent: Friday, April 07, 2006 12:40 AM >> To: HIP >> Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman >> Subject: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a >> mandatory algorithm >> >>>>>> There is mandatory support for ESP with HMAC-SHA1 and either >>>>>> Null or AES128CBC encryption. This is mandatory not just in the >>>>>> implementation but also in the configuration. (i.e., as written, >>>>>> the spec says that one of those two suites must be offered in >>>>>> every negotiation). >>>> >>>> The reason for this was that we would have something common >>>> between all nodes. >>> >>> But Null should not be mandatory to offer. AES128CBC would do as a >>> mandatory-to-offer. >> >> I don't understand this comment. Maybe the text is unclear (Section >> 5.2.7 I think), but AFAICS it just requires that the responder >> includes _at_least_ either HMAC-SHA1-NULL or HMAC-SHA1-AES128CBC. >> Nothing prevents it from including both and perhaps others. >> >> If you implement HMAC-SHA1-AES128CBC, it is trivial to implement >> HMAC- >> SHA1-NULL. >> >> What is wrong with this? To me this approach seems to be fine with >> me; not all connections require encryption. >> >> --Pekka >> >> > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Apr 11 01:13:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTBCB-0006ss-K7; Tue, 11 Apr 2006 01:13:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTBCA-0006sn-19 for hipsec@ietf.org; Tue, 11 Apr 2006 01:13:42 -0400 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTBC5-0007rS-Ag for hipsec@ietf.org; Tue, 11 Apr 2006 01:13:41 -0400 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id RAA12897; Tue, 11 Apr 2006 17:13:32 +1200 In-Reply-To: <93D6BFC7-A228-40E3-9E0F-6971A841F455@nomadiclab.com> References: <93D6BFC7-A228-40E3-9E0F-6971A841F455@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7ACF0021-BF3F-4CEA-9B81-837BF6931791@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Date: Tue, 11 Apr 2006 17:13:33 +1200 To: Pekka Nikander X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Charlie Kaufman , HIP , Petri Jokela Subject: [Hipsec] Re: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On 11/04/2006, at 4:59 PM, Pekka Nikander wrote: > > OTOH, I don't remember the details of why we imposed the strict > length rule in the first place. Anyone? > Because there's no mechanism for fragmentation, the packets start getting big, and there is potential for MTU issues. Andrew _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Apr 11 03:53:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTDgo-0008B8-12; Tue, 11 Apr 2006 03:53:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTDgm-0008Ar-67 for hipsec@ietf.org; Tue, 11 Apr 2006 03:53:28 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTDgi-0005Ef-SO for hipsec@ietf.org; Tue, 11 Apr 2006 03:53:28 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5CB76212C63; Tue, 11 Apr 2006 10:53:23 +0300 (EEST) Received: from [193.234.219.124] (n124.nomadiclab.com [193.234.219.124]) by n2.nomadiclab.com (Postfix) with ESMTP id DDB62212C5F; Tue, 11 Apr 2006 10:53:22 +0300 (EEST) Message-ID: <443B6070.1050301@nomadiclab.com> Date: Tue, 11 Apr 2006 10:53:20 +0300 From: Petri Jokela User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: HIP References: <4430026F.6000204@ericsson.com> In-Reply-To: <4430026F.6000204@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Charlie Kaufman , Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis: Reassembly algorithm text X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >> Around line 1829, the base spec says "All HIP implementations MUST >> employ a reassembly algorithm that is sufficiently resistant to DoS >> attacks." This statement is too vague to be useful (and arguably >> impossible). It should probably be changed to be implementer advice. Suggestion (I'm not sure if the wording is correct): "All HIP implementations have to be careful while employing a reassembly algorithm so that the algorithm is sufficiently resistant to DoS attacks. " /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Apr 11 08:04:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTHbM-0001fd-7c; Tue, 11 Apr 2006 08:04:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTHbK-0001fY-3S for hipsec@ietf.org; Tue, 11 Apr 2006 08:04:06 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTHbH-0006WM-L6 for hipsec@ietf.org; Tue, 11 Apr 2006 08:04:06 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6A2BC212C63; Tue, 11 Apr 2006 15:04:02 +0300 (EEST) Received: from [193.234.219.124] (n124.nomadiclab.com [193.234.219.124]) by n2.nomadiclab.com (Postfix) with ESMTP id F22C9212C5F; Tue, 11 Apr 2006 15:04:01 +0300 (EEST) Message-ID: <443B9B2E.7040802@nomadiclab.com> Date: Tue, 11 Apr 2006 15:03:58 +0300 From: Petri Jokela User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Pekka Nikander References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> <97F374FF-960A-4D53-A1A7-F43583624D71@nomadiclab.com> In-Reply-To: <97F374FF-960A-4D53-A1A7-F43583624D71@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: charliek@exchange.microsoft.com, HIP , Petri Jokela Subject: [Hipsec] Re: Belovin-Rescorla analysis - HIP: SHA-1 or SHA-256 as the baseline X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Pekka Nikander wrote: >>>> The HIP base document makes a normative reference to >>>> draft-laganier-ipv6-khi-01, and that document wires in both use of >>>> SHA-1 and the extraction of a particular 120 bits of the SHA-1 hash. >>>> Switching to use 120 bits of a SHA-256 hash would not be terribly >>>> difficult, but it's not clear that would be any more secure. >> >> The only way to solve this issue is to modify the ORCHID (KHI) draft. >> There is nothing we can do in the HIP base draft; we need those HITs >> defined somewhere. > > I am open to both options. If people feel that now is the right time to > move from SHA-1 to SHA-256, I'm sure we can update the ORCHID/KHI > draft. IF we decide to make PHASH independent of the HIT hash > algorithm, then the base draft needs to be updated accordingly. In any > case, we need to figure out for the base draft from where the hash > algorithms for various cases come. Right now the draft is not in good > enough shape. > > --Pekka > > There are multiple sources for used algorithms. If the key expansion hash algorithm is changed to be dependent on the ORCHID, the following hash algorithms are used in the base HIP (RHASH = Responder's HIT Hash algorithm): Where used Algorithm HIT defined in ORCHID (currently SHA-1) Puzzle RHASH - same as in ORCHID Key expansion RHASH - same as in ORCHID Signatures (pub.key algs) RSA and DSA documents (currently SHA-1) HMACs (HIP_TRANSFORM) RFC4307, RFC2451 (SHA1 or MD5) /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Apr 11 12:38:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLtE-000265-WD; Tue, 11 Apr 2006 12:38:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLtE-000260-Hq for hipsec@ietf.org; Tue, 11 Apr 2006 12:38:52 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTLtD-0000Zs-7n for hipsec@ietf.org; Tue, 11 Apr 2006 12:38:52 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id A187630C3; Tue, 11 Apr 2006 19:38:50 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 1FDB22F8D; Tue, 11 Apr 2006 19:38:50 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k3BGcmr08760; Tue, 11 Apr 2006 19:38:48 +0300 (EEST) Date: Tue, 11 Apr 2006 19:38:48 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Hipsec] a state machine proposal for mm-03 In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2EFDA@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D01A2EFDA@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 10 Apr 2006, Henderson, Thomas R wrote: > LOCATOR is just sent to the peer based on local mobility/policy > decision, and the UPDATE is ACKed for reliability's sake. > ECHO_REQUEST/RESPONSE is a nonce exchange, used by the peer for > reachability test. We describe some scenarios where these parameters > can be piggybacked on the same UPDATE message, but there is no > requirement to do so, and I would prefer not to constrain it in that > way. For instance, we should not require that the peer send the > ECHO_REQUEST, nor should we require that the ACK of the LOCATOR also > contain an ECHO_REQUEST rather than be in a separate packet. Tried to loosen up the rules in favour of modularity. See if it is now better. Not sure if it covers the peer initiated rekey case. Feel free to modify the latest proposal accordingly. If you'd still like to discard it, I think section 5 could still use some kind of summary that gathers up all of the pieces, even the optional CBA. > Agree (based on a quick look). Feel free to modify the text accordingly based on the latest version I sent. > > Handling of CLOSE with ESP_INFO: > > - TBD > > The other opinions seemed to be to not use CLOSE for this purpose. Agree. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Apr 11 14:32:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTNei-0007B1-LZ; Tue, 11 Apr 2006 14:32:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTNeh-0007Aw-PQ for hipsec@ietf.org; Tue, 11 Apr 2006 14:31:59 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTNeh-0004gF-B5 for hipsec@ietf.org; Tue, 11 Apr 2006 14:31:59 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 63DB0212C63; Tue, 11 Apr 2006 21:31:57 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B70B4212C5F; Tue, 11 Apr 2006 21:31:56 +0300 (EEST) In-Reply-To: <443B9B2E.7040802@nomadiclab.com> References: <4430026F.6000204@ericsson.com> <4434C0D3.40905@nomadiclab.com> <97F374FF-960A-4D53-A1A7-F43583624D71@nomadiclab.com> <443B9B2E.7040802@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <546DE4DA-F353-4E8C-974E-18058FE68AC0@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 11 Apr 2006 21:31:57 +0300 To: Petri Jokela X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: charliek@exchange.microsoft.com, HIP , Petri Jokela Subject: [Hipsec] Re: Belovin-Rescorla analysis - HIP: SHA-1 or SHA-256 as the baseline X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>>>> The HIP base document makes a normative reference to draft- >>>>> laganier-ipv6-khi-01, and that document wires in both use of >>>>> SHA-1 and the extraction of a particular 120 bits of the SHA-1 >>>>> hash. Switching to use 120 bits of a SHA-256 hash would not be >>>>> terribly difficult, but it's not clear that would be any more >>>>> secure. >>> >>> The only way to solve this issue is to modify the ORCHID (KHI) >>> draft. There is nothing we can do in the HIP base draft; we need >>> those HITs defined somewhere. >> I am open to both options. If people feel that now is the right >> time to move from SHA-1 to SHA-256, I'm sure we can update the >> ORCHID/KHI draft. IF we decide to make PHASH independent of the >> HIT hash algorithm, then the base draft needs to be updated >> accordingly. In any case, we need to figure out for the base >> draft from where the hash algorithms for various cases come. >> Right now the draft is not in good enough shape. >> --Pekka > > There are multiple sources for used algorithms. If the key expansion > hash algorithm is changed to be dependent on the ORCHID, the following > hash algorithms are used in the base HIP (RHASH = Responder's HIT Hash > algorithm): > > Where used Algorithm > > HIT defined in ORCHID (currently SHA-1) > Puzzle RHASH - same as in ORCHID > Key expansion RHASH - same as in ORCHID > Signatures (pub.key algs) RSA and DSA documents (currently SHA-1) > HMACs (HIP_TRANSFORM) RFC4307, RFC2451 (SHA1 or MD5) To me, determining which hash function to use in each case from these sources seems to be OK. I could even imagine a later optional payload that would allow negotiating the key derivation function; if anything, that one seems most problematic to me. HIT derivation function is naturally defined by ORCHID, and since the puzzle is merely a DoS mitigation mechanism, I don't see anything bad there either. As an alternative, would it be technically feasible to use the HMAC function from HIP_TRANSFORM for key derivation instead of RHASH? That would sound better to me, but I don't remember all the details well enough any more to be able to tell whether that would work in practise. So, I would be happy with this (or the alternative) approach. But I can't say if it is good enough from the Bellovin-Rescorla analysis point of view. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Apr 12 07:16:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTdLD-0005LG-HW; Wed, 12 Apr 2006 07:16:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTdLC-0005LB-2x for hipsec@ietf.org; Wed, 12 Apr 2006 07:16:54 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTdLA-0000zT-Ja for hipsec@ietf.org; Wed, 12 Apr 2006 07:16:54 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BE6A7212C64 for ; Wed, 12 Apr 2006 14:16:51 +0300 (EEST) Received: from [193.234.219.124] (n124.nomadiclab.com [193.234.219.124]) by n2.nomadiclab.com (Postfix) with ESMTP id 86BCA212C5F for ; Wed, 12 Apr 2006 14:16:51 +0300 (EEST) Message-ID: <443CE19F.6080102@nomadiclab.com> Date: Wed, 12 Apr 2006 14:16:47 +0300 From: Petri Jokela User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: HIP Subject: Re: [Hipsec] [Fwd: Fwd: Belovin-Rescorla analysis - HIP] References: <4430026F.6000204@ericsson.com> In-Reply-To: <4430026F.6000204@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >> 3) HMAC and encryption algorithms are negotiated, but currently SHA-1 >> and MD5 are the only registered options. In one place, the size of the >> output of the HMAC is fixed at 160 bits. This is probably a bug in the >> spec and easily fixed. Suggested fix: change the HMAC (and HMAC2) parameters so that the HMAC field is variable length. The length depends on the used hash algorithm: 5.2.9. HMAC 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC | / / / +-------------------------------+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 61505 Length length in octets, excluding Type, Length, and Padding HMAC HMAC computed over the HIP packet, excluding the HMAC parameter and any following parameters, such as HIP_SIGNATURE, HIP_SIGNATURE_2, ECHO_REQUEST, or ECHO_RESPONSE. The checksum field MUST be set to zero and the HIP header length in the HIP common header MUST be calculated not to cover any excluded parameters when the HMAC is calculated. The size of the HMAC is the natural size of the hash computation output depending on the used hash function. /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Apr 12 07:21:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTdPa-0007AQ-Tb; Wed, 12 Apr 2006 07:21:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTdPZ-0007AL-Hi for hipsec@ietf.org; Wed, 12 Apr 2006 07:21:25 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTdPY-0001CV-8i for hipsec@ietf.org; Wed, 12 Apr 2006 07:21:25 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 90FCA212C64; Wed, 12 Apr 2006 14:21:23 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 58853212C5F; Wed, 12 Apr 2006 14:21:23 +0300 (EEST) In-Reply-To: <443CE19F.6080102@nomadiclab.com> References: <4430026F.6000204@ericsson.com> <443CE19F.6080102@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <32E1B975-731B-4DFA-A790-016336F7A358@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] [Fwd: Fwd: Belovin-Rescorla analysis - HIP] Date: Wed, 12 Apr 2006 14:21:24 +0300 To: Petri Jokela X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>> 3) HMAC and encryption algorithms are negotiated, but currently >>> SHA-1 and MD5 are the only registered options. In one place, the >>> size of the output of the HMAC is fixed at 160 bits. This is >>> probably a bug in the spec and easily fixed. > > Suggested fix: change the HMAC (and HMAC2) parameters so that the HMAC > field is variable length. The length depends on the used hash > algorithm: Looks good to me. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Apr 12 08:16:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeGb-0005zY-To; Wed, 12 Apr 2006 08:16:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeG9-00052X-CE for hipsec@ietf.org; Wed, 12 Apr 2006 08:15:45 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTe6h-0002mF-U6 for hipsec@ietf.org; Wed, 12 Apr 2006 08:06:02 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 48BB4212C63; Wed, 12 Apr 2006 15:05:58 +0300 (EEST) Received: from [193.234.219.124] (n124.nomadiclab.com [193.234.219.124]) by n2.nomadiclab.com (Postfix) with ESMTP id 0B0D1212C5F; Wed, 12 Apr 2006 15:05:58 +0300 (EEST) Message-ID: <443CED21.809@nomadiclab.com> Date: Wed, 12 Apr 2006 15:05:53 +0300 From: Petri Jokela User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Hipsec] Belovin-Rescorla analysis - HIP: Opportunistic HIP References: <77F357662F8BFA4CA7074B0410171B6D01A2EFCA@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2EFCA@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: HIP , Petri Jokela , charliek@exchange.microsoft.com X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Henderson, Thomas R wrote: > > > I agree to the above proposal to avoid defining it here, because even > the option 1 described above has another possible outcome (block the > packet). This topic is worthy of a separate draft, and some alignment > with opportunistic IPsec design. > I would suggest adding a new subsection describing the situation. The descriptions of I1 and R1, as well as related packet handling text contains still some text about the possible NULL destination HIT, but no information about necessary packet handling. Reference to this new subsection is added to those points. 4.1.6. HIP Opportunistic Mode It is possible to initiate a HIP negotiation even if the destination host's HI (and HIT) is unknown. In this case the connection initializing I1 packet contains NULL as the destination HIT. This kind of connection setup is called as opportunistic mode. Opportunistic mode setup contains multiple security issues that must be carefully addressed in the implementation. The setup is vulnerable to e.g. man-in-the-middle attacks, because the initializing node does not have any public key information about the peer. The opportunistic mode is introduced in this document, but the actual connection setup process is not described thoroughly. It is expected that a document describing the opportunistic mode connection setup procedure in more details, as well as the related security issues that must be taken care of, will be written later. /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Apr 12 09:01:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeyU-0001SC-PU; Wed, 12 Apr 2006 09:01:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeyT-0001S7-9A for hipsec@ietf.org; Wed, 12 Apr 2006 09:01:33 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTeyS-0004kV-Qp for hipsec@ietf.org; Wed, 12 Apr 2006 09:01:33 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B76E6212C63; Wed, 12 Apr 2006 16:01:31 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5C1FC212C5F; Wed, 12 Apr 2006 16:01:31 +0300 (EEST) In-Reply-To: <443CED21.809@nomadiclab.com> References: <77F357662F8BFA4CA7074B0410171B6D01A2EFCA@XCH-NW-5V1.nw.nos.boeing.com> <443CED21.809@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <96F54213-F0D1-4B61-9869-AE0BCFE5ADD6@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Belovin-Rescorla analysis - HIP: Opportunistic HIP Date: Wed, 12 Apr 2006 16:01:31 +0300 To: Petri Jokela X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: charliek@exchange.microsoft.com, HIP , Petri Jokela X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >> I agree to the above proposal to avoid defining it here, because >> even >> the option 1 described above has another possible outcome (block the >> packet). This topic is worthy of a separate draft, and some >> alignment >> with opportunistic IPsec design. > > I would suggest adding a new subsection describing the situation. > The descriptions of I1 and R1, as well as related packet handling > text contains still some text about the possible NULL destination > HIT, but no information about necessary packet handling. Reference > to this new subsection is added to those points. Your text looks good overall, some minor mods below: > 4.1.6. HIP Opportunistic Mode > > It is possible to initiate a HIP negotiation even if the > destination > host's HI (and HIT) is unknown. In this case the connection s/destination host's/responder's/ > initializing I1 packet contains NULL as the destination HIT. This s/NULL/NULL (all zeros) > kind of connection setup is called as opportunistic mode. > > Opportunistic mode setup contains multiple security issues that > must There are multiple security issues involved with opportunistic mode that must > be carefully addressed in the implementation. The setup is s/The setup/Such a set up/ > vulnerable to e.g. man-in-the-middle attacks, because the s/e.g./, e.g., / > initializing node does not have any public key information about > the > peer. > > The opportunistic mode is introduced in this document, but the > actual > connection setup process is not described thoroughly. It is > expected that a document describing the opportunistic mode > connection > setup procedure in more details, as well as the related security > issues that must be taken care of, will be written later. While this document defines the concept of the opportunistic mode, and outlines the basic signalling mechanism to trigger it; i.e., send an I1 with a NULL destination HIT, this document does not specify the details of the opportunistic mode. Especially, its security properties are not discussed beyond the warning above. It is expected that a separate document will describe the opportunistic mode in more detail, including its security properties. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Apr 12 10:13:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTg5x-0008KH-GO; Wed, 12 Apr 2006 10:13:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTg5w-0008KC-4j for hipsec@ietf.org; Wed, 12 Apr 2006 10:13:20 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTg5u-00073j-Oc for hipsec@ietf.org; Wed, 12 Apr 2006 10:13:20 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA25172; Wed, 12 Apr 2006 07:13:14 -0700 (PDT) Received: from XCH-NWBH-10.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k3CEDET17251; Wed, 12 Apr 2006 07:13:14 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 07:13:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Belovin-Rescorla analysis - HIP: Opportunistic HIP Date: Wed, 12 Apr 2006 07:13:07 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2EFF1@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <96F54213-F0D1-4B61-9869-AE0BCFE5ADD6@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Belovin-Rescorla analysis - HIP: Opportunistic HIP Thread-Index: AcZeMYMl7bfBUqMzTGaQuezQHV31ywACZcZA From: "Henderson, Thomas R" To: "Pekka Nikander" , "Petri Jokela" X-OriginalArrivalTime: 12 Apr 2006 14:13:08.0787 (UTC) FILETIME=[39870830:01C65E3B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: charliek@exchange.microsoft.com, HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org =20 This looks good to me, with Pekka's proposed mods. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Apr 13 03:00:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTvoY-0000ni-L3; Thu, 13 Apr 2006 03:00:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTvoX-0000nd-6W for hipsec@ietf.org; Thu, 13 Apr 2006 03:00:25 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTvoV-0000ry-Oz for hipsec@ietf.org; Thu, 13 Apr 2006 03:00:25 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2F2BA212C63; Thu, 13 Apr 2006 10:00:22 +0300 (EEST) Received: from [193.234.219.124] (n124.nomadiclab.com [193.234.219.124]) by n2.nomadiclab.com (Postfix) with ESMTP id DEC53212C5F; Thu, 13 Apr 2006 10:00:21 +0300 (EEST) Message-ID: <443DF701.2090607@nomadiclab.com> Date: Thu, 13 Apr 2006 10:00:17 +0300 From: Petri Jokela User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: HIP References: <4430026F.6000204@ericsson.com> In-Reply-To: <4430026F.6000204@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Charlie Kaufman , Petri Jokela Subject: [Hipsec] Belovin-Rescorla analysis - HIP: NOTIFY X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >> Notifications are not acknowledged or protected from replay. Today, >> notifications are only used for diagnostics, so a third party >> filtering, duplicating, and reordering them probably can't do >> substantial damage. It does seem suspicious though. In the current draft NOTIFYs can cause some trouble if handled like said in 6.13.: 6.13. Processing NOTIFY Packets Processing NOTIFY packets is OPTIONAL. If processed, any errors noted by the NOTIFY parameter SHOULD be taken into account by the HIP state machine (e.g., by terminating a HIP handshake), and the error SHOULD be logged. It would be safer to say something like: 6.13. Processing NOTIFY Packets Processing NOTIFY packets is OPTIONAL. If processed, received errors MUST be considered only as informational and they MUST NOT result in changes in any state information. All received errors SHOULD be logged. Security Considerations: NOTIFY messages are used only for informational purposes. They are unacknowledged and unprotected. A HIP implementation cannot rely on the information received in a NOTIFY message, and it MUST NOT change any state information based on received NOTIFY messages. /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Apr 13 06:52:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTzQd-0003Vh-Qe; Thu, 13 Apr 2006 06:51:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTzQc-0003Vc-Bm for hipsec@ietf.org; Thu, 13 Apr 2006 06:51:58 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTzQa-00085w-UN for hipsec@ietf.org; Thu, 13 Apr 2006 06:51:58 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 07A9D212C63; Thu, 13 Apr 2006 13:51:55 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C19C1212C46; Thu, 13 Apr 2006 13:51:54 +0300 (EEST) In-Reply-To: <443DF701.2090607@nomadiclab.com> References: <4430026F.6000204@ericsson.com> <443DF701.2090607@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Belovin-Rescorla analysis - HIP: NOTIFY Date: Thu, 13 Apr 2006 13:51:56 +0300 To: Petri Jokela X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Charlie Kaufman , HIP , Petri Jokela X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org >>> Notifications are not acknowledged or protected from replay. >>> Today, notifications are only used for diagnostics, so a third >>> party filtering, duplicating, and reordering them probably can't >>> do substantial damage. It does seem suspicious though. > > Security Considerations: > > NOTIFY messages are used only for informational purposes. They are > unacknowledged and unprotected. A HIP implementation cannot > rely on > the information received in a NOTIFY message, and it MUST NOT > change > any state information based on received NOTIFY messages. Hmm. I thought NOTIFYs were protected from other than replay attacks; anyway, they are signed. ICMPs are supposed to be used as completely unprotected messages. Other than that, I am willing to be happy with your suggestion. OTOH, I might allow NOTIFYs resulting in "spontaneous" state machine changes; i.e., moving from one state to another if the receive host can perform that move anyway. If you say that NOTIFY strictly MUST NOT result in any changes in state information, that sounds too stringent to me. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Apr 13 07:00:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTzZH-0002ZI-LS; Thu, 13 Apr 2006 07:00:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTzZG-0002Z7-6q for hipsec@ietf.org; Thu, 13 Apr 2006 07:00:54 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTzZD-0008JN-Oh for hipsec@ietf.org; Thu, 13 Apr 2006 07:00:54 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id EA08E212C63; Thu, 13 Apr 2006 14:00:50 +0300 (EEST) Received: from [193.234.219.124] (n124.nomadiclab.com [193.234.219.124]) by n2.nomadiclab.com (Postfix) with ESMTP id B150D212C46; Thu, 13 Apr 2006 14:00:50 +0300 (EEST) Message-ID: <443E2F5C.2060603@nomadiclab.com> Date: Thu, 13 Apr 2006 14:00:44 +0300 From: Petri Jokela User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] Belovin-Rescorla analysis - HIP: NOTIFY References: <4430026F.6000204@ericsson.com> <443DF701.2090607@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Charlie Kaufman , HIP , Petri Jokela X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Pekka Nikander wrote: >>>> Notifications are not acknowledged or protected from replay. Today, >>>> notifications are only used for diagnostics, so a third party >>>> filtering, duplicating, and reordering them probably can't do >>>> substantial damage. It does seem suspicious though. >> >> Security Considerations: >> >> NOTIFY messages are used only for informational purposes. They are >> unacknowledged and unprotected. A HIP implementation cannot rely on >> the information received in a NOTIFY message, and it MUST NOT change >> any state information based on received NOTIFY messages. > > Hmm. I thought NOTIFYs were protected from other than replay attacks; > anyway, they are signed. ICMPs are supposed to be used as completely > unprotected messages. Hah, true, I just wonder what I have been looking at.... possibly the nice spring weather outside. > Other than that, I am willing to be happy with your suggestion. OTOH, I > might allow NOTIFYs resulting in "spontaneous" state machine changes; > i.e., moving from one state to another if the receive host can perform > that move anyway. If you say that NOTIFY strictly MUST NOT result in > any changes in state information, that sounds too stringent to me. Ok, NOTIFY messages are used only for informational purposes and they are unaknowledged. A HIP implementation cannot rely on the information received in a NOTIFY message because the packet may have been replayed. It SHOULD NOT change any state information based purely on a received NOTIFY message. /petri _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Apr 13 07:30:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU02B-00089v-TJ; Thu, 13 Apr 2006 07:30:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU02A-00089q-OQ for hipsec@ietf.org; Thu, 13 Apr 2006 07:30:46 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU02A-0000vm-Bh for hipsec@ietf.org; Thu, 13 Apr 2006 07:30:46 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id A828A212C63; Thu, 13 Apr 2006 14:30:45 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 66652212C46; Thu, 13 Apr 2006 14:30:45 +0300 (EEST) In-Reply-To: <443E2F5C.2060603@nomadiclab.com> References: <4430026F.6000204@ericsson.com> <443DF701.2090607@nomadiclab.com> <443E2F5C.2060603@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Belovin-Rescorla analysis - HIP: NOTIFY Date: Thu, 13 Apr 2006 14:30:47 +0300 To: Petri Jokela X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Charlie Kaufman , HIP , Petri Jokela X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org > NOTIFY messages are used only for informational purposes and they are > unaknowledged. A HIP implementation cannot rely on the information > received in a NOTIFY message because the packet may have been > replayed. > It SHOULD NOT change any state information based purely on a received > NOTIFY message. Looks good to me. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Apr 13 11:20:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU3cC-0002fi-Tk; Thu, 13 Apr 2006 11:20:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU3cB-0002fd-At for hipsec@ietf.org; Thu, 13 Apr 2006 11:20:11 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU3cA-00006J-06 for hipsec@ietf.org; Thu, 13 Apr 2006 11:20:11 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA10025; Thu, 13 Apr 2006 10:19:46 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k3DFJjN26902; Thu, 13 Apr 2006 10:19:45 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 08:19:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Apr 2006 08:19:39 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F00D@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2EFB1@XCH-NW-5V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mm-03 CBA fixes Thread-Index: AcZXNp9zVFlWgAyoQAqsLCJ8SQG/OwCVan9wAV9pt+A= From: "Henderson, Thomas R" To: "Miika Komu" , X-OriginalArrivalTime: 13 Apr 2006 15:19:40.0295 (UTC) FILETIME=[AF109170:01C65F0D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Subject: [Hipsec] mm-03 CBA fixes X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Returning to the mm draft comments from Miika. > >=20 > > > Figure 10. > >=20 > > Can the "+ address change" in the lower left corner be removed? > >=20 >=20 > I will check with Christian about this figure, as your question has > raised also a question in my mind whether it is correct. >=20 Christian has provided the following corrected figure. +-------+ +-------+ | A | | B | +-------+ +-------+ | | address |------------------------------->| credit +=3D size(packet) ACTIVE | | |------------------------------->| credit +=3D size(packet) |<-------------------------------| don't change credit | | + address change | + address verification starts | address |<-------------------------------| credit -=3D size(packet) UNVERIFIED |------------------------------->| credit +=3D size(packet) |<-------------------------------| credit -=3D size(packet) | | |<-------------------------------| credit -=3D size(packet) | X credit < size(packet) | | =3D> do not send packet! + address verification concludes | address | | ACTIVE |<-------------------------------| don't change credit | | Figure 10: Readdressing Scenario In the course of revising this, I discussed with Christian some additional clarifying text and would like to propose the following text that we worked out together: - Section 3.3.2: Add the following sentence right before the figure: "Not shown in Figure 10 are the results of credit aging (Section 5.5.2), a mechanism used to dampen possible time-shifting attacks." - Section 5.5: At the beginning of this section (before reaching 5.5.1) add: "To prevent redirection-based flooding attacks, the use of a Credit-Based Authorization (CBA) approach is mandatory when a host sends data to an UNVERIFIED locator. The following algorithm meets the security considerations for prevention of amplification and time-shifting attacks. Other forms of credit aging--- and other values for the CreditAgingFactor and CreditAgingInterval parameters in particular--- are for further study, and so are the advanced CBA techniques specified in [1]." [1] http://doc.tm.uka.de/2005/draft-vogt-mobopts-credit-based-authorization- 00.txt (note to Christian: This document [1] will need some official status or republishing as a technical report) - Section 6. Add the following sentence just before starting Section 6.1: "Security considerations for Credit-Based Authorization are discussed in [2]." [2] http://doc.tm.uka.de/2006/draft-vogt-mobopts-simple-cba-00.txt (note: Christian says that he is working with Jari to publish this draft) Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Apr 13 15:54:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU7te-0005Zz-Rv; Thu, 13 Apr 2006 15:54:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU7td-0005Wk-HT for hipsec@lists.ietf.org; Thu, 13 Apr 2006 15:54:29 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU7tb-0000rm-Tg for hipsec@lists.ietf.org; Thu, 13 Apr 2006 15:54:29 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA01799; Thu, 13 Apr 2006 12:54:21 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k3DJsLT16234; Thu, 13 Apr 2006 12:54:21 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 12:54:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] some comments for mm-03 Date: Thu, 13 Apr 2006 12:54:19 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F011@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] some comments for mm-03 Thread-Index: AcZXalj4krd1EcfFRFu+8U3gUWwO+gHq9WKw From: "Henderson, Thomas R" To: "Miika Komu" , X-OriginalArrivalTime: 13 Apr 2006 19:54:19.0810 (UTC) FILETIME=[0D9F0020:01C65F34] X-Spam-Score: 0.0 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Miika, resuming the response to your detailed coments: > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Monday, April 03, 2006 2:30 PM > To: hipsec@lists.ietf.org > Subject: Re: [Hipsec] some comments for mm-03 >=20 > > Some comments for mm-03, part 1/2 (I'll send the rest later this > > evening). >=20 > Here we go again.. decided to split the email on separate=20 > sections. Here > is (the end of section three and) section 4. >=20 > > 3.3.4. Interaction with Security Associations > > > > This document specifies a new HIP protocol parameter, the LOCATOR > > parameter (see Section 4), that allows the hosts to=20 > exchange information > > about their locator(s), and any changes in their locator(s). >=20 > This document specifies a new HIP protocol parameter, the LOCATOR > parameter (see Section 4), that allows the hosts to exchange > information about changes their locator(s). disagree with this editorial suggestion, since it is not only changes that can be conveyed in LOCATOR. >=20 > > The relation between these entities for an association negotiated as > > defined in the base specification [2] and ESP transform [5] is > > illustrated in Figure 11. >=20 > What entities? There is also something other fishy with this sentence. >=20 s/entities/levels s/negotiated/constructed > > The addresses addr1a and addr2a are the source addresses=20 > that each host > > uses in the base HIP exchange. >=20 > The addresses addr1a and addr2a are the source addresses that=20 > the hosts > use in the base HIP exchange. OK >=20 > > These are the "preferred" (and only) addresses conveyed to=20 > the peer for > > each SA; even though packets sent to any of the hosts'=20 > interfaces can > > arrive on an inbound SPI, when a host sends packets to the=20 > peer on an > > outbound SPI, it knows of a single destination address=20 > associated with > > that outbound SPI (for host1, it sends a packet on SPI2a to=20 > addr2a to > > reach host2), unless other mechanisms exist to learn of new=20 > addresses. >=20 > * Perhaps you just replace the SA with SPI because SA is not really > illustrated in the figure. > * This is an overly long sentence, suggest splitting into 2-3=20 > sentences. > * I think that "arrive on SPI", "send to peer SPI" and > "send packet on SPI" could be said in a better way. performed some cleanup as you suggested >=20 > > In this figure, a host can have multiple inbound SPIs (and,=20 > not shown, > > multiple outbound SPIs) between itself and another host. >=20 > s/between/associated with/ >=20 s/between itself and/associated with/ > > These addresses bound to an SPI are not used as SA selectors. >=20 > (I suggested writing the term "SA selector" to the terminology in the > beginning) acutally, on a message from Wed. Mar 22, 2006 to the list, Francis Dupont corrected my usage of "SA selector"-- should be "SA lookup". Have made the appropriate changes (do not use the term selector in the document anymore). >=20 > > The LOCATOR parameter allows for IP addresses and SPIs to=20 > be combined to > > form generalized locators. >=20 > I am not sure if "generalized" is the right term, but rather=20 > "locators for > suitable for IPsec use" etc. In any case, this sentence can be removed > from here as it is repeated elsewhere. removed >=20 > > Figure 12 >=20 > This figure reminds me that is it possible to have both SPI1 and SPI2 > mapping to the same ADDR21? Yes, in general, there may be different source addresses and hence=20 different paths to the same destination address. >=20 > > The main purpose of having multiple SPIs is to group the=20 > addresses into > > collections that are likely to experience fate sharing. >=20 > The main purpose of having multiple SPIs with a peer is to group the > addresses into collections that are likely to experience fate sharing. OK >=20 > > For this reason, HIP provides a mechanism to affiliate destination > > addresses with inbound SPIs, if there is a concern that anti-replay > > windows might be violated otherwise. >=20 > s/if/when/ > s/otherwise// >=20 OK > > Moreover, even if the destination addresses used for a=20 > particular SPI > > are held constant, the use of different source interfaces=20 > may also cause > > packets to fall outside of the ESP anti-replay window,=20 > since the path > > traversed is often affected by the source address or interface used. >=20 > s/if/when >=20 OK > > A host has no way to influence the source interface on=20 > which a peer uses > > to send its packets on a given SPI. >=20 > A host has no way to influence the source interface on which=20 > a peer sends > its packets using a given SPI. >=20 OK > > Hosts SHOULD consistently use the same source interface and=20 > address when > > sending to a particular destination IP address and SPI. >=20 > s/Hosts/A host/ >=20 OK > > If the LOCATOR parameter is sent in an UPDATE packet, then the > > receiver will respond with an UPDATE acknowledgment. >=20 > When the LOCATOR parameter is sent in an UPDATE packet, then the > receiver responds with an UPDATE acknowledgment. OK >=20 > > If the LOCATOR parameter is sent in a NOTIFY, I2, or R2=20 > packet, then the > > recipient may consider the LOCATOR as informational, and=20 > act only when > > it needs to activate a new address. >=20 > If the LOCATOR parameter is sent in a NOTIFY, I2, or R2 packet, the > recipient MUST consider the LOCATOR as informational, and act=20 > only when it > needs to activate a new address. >=20 > What does "act" mean here? First, there is an error here-- R2 should be R1. We corrected this elsewhere in last draft version, but this is a loose end that needs=20 changed. This also allows me to comment on a suggestion in your previous mail: > > > > > Even if the I2 packet contains LOCATOR parameters, the Responder > > > > MUST still send the R2 packet to the source address of the I2. > > > > > > I1 and I2 source address must be the same? > > > > What does it matter? I1 state is not kept by responder. >=20 > Cookies might get burned if the indexing is affected by the=20 > IP addresses > :) >=20 I1 and I2 source addresses can be different, because the responder can include a new preferred address in the R1 LOCATOR, and the=20 change in responder address might require a change in initiator source address. Now, back to the text at hand. NOTIFY perhaps should be separated from the R1/I2 cases. It may be the case that a LOCATOR in an I2 can override the preferred address used for the base exchange, so saying that it is informational may mean that the receiver can ignore it. The issue is really with NOTIFY, which could be replayed. What may work better here is to treat NOTIFY as informational, which means that it cannot drive any particular state change (this also just discussed in the Bellovin-Rescorla analysis thread). Perhaps this wording is better: " When the LOCATOR parameter is sent in an UPDATE packet, then the receiver will respond with an UPDATE acknowledgment. When the LOCATOR parameter is sent in an R1 or I2 packet, the base exchange retransmission mechanism will confirm its successful delivery. =20 LOCATORs may experimentally be used in NOTIFY packets; in this case, the recipient MUST consider the LOCATOR as informational and not immediately change the current preferred address, but can test the=20 additional locators when the need arises. The use of LOCATOR=20 in a NOTIFY message may not be compatible with middleboxes." >=20 > > The use of LOCATOR in a NOTIFY message may not be compatible with > > middleboxes. >=20 > > 4. LOCATOR parameter format >=20 > Is there are specific reason why the reserved field cannot be=20 > just flags? I do not understand this request. Aren't undefined flags the same as reserved bits? >=20 > > Length: Length in octets, excluding Type and Length fields, and > > excluding padding. >=20 > Minimum length (is a locator without any address allowed)?=20 I would say yes, and this corresponds to moving all addresses to DEPRECATED. Suggest: =20 "A LOCATOR contaning zero Locator fields is permitted but has the effect of DEPRECATING all addresses." > Maximum length? There is already a maximum for HIP Parameters field. >=20 > > Locator Length: Defines the length of the Locator field, in units of > > 4-byte words (Locators up to a maximum of 4*255 bytes are=20 > supported). >=20 > s/bytes/octets/ OK >=20 > > Locator: The locator whose semantics and encoding are=20 > indicated by the > > Locator Type field. All Locator sub-fields are integral=20 > multiples of > > four bytes in length. >=20 > It is slightly confusing that there is LOCATOR and Locator :)=20 > Perhaps this > should be noted in the terminology. Added. >=20 > s/bytes/octets/ OK >=20 > > The address is expected to become deprecated when the=20 > specified number > > of seconds has passed since the reception of the message. >=20 > Also, CLOSE can be used for premature expiration of addresses. Ignoring this one based on previous discussion. >=20 > > A deprecated address SHOULD NOT be used as an destination=20 > address if an > > alternate (non-deprecated) is available and has sufficient scope. >=20 > In the case of many alternatives, the host chooses according to > local host policies. I don't think this sentence is really needed here since the issue of picking among multiple addresses is dealt with elsewhere. >=20 > > 4.1. Traffic Type and Preferred Locator > > > > The "P" bit, when set, has scope over the corresponding Traffic Type > > that precedes it. >=20 > s/precedes it// OK >=20 > > That is, if a "P" bit is set for Traffic Type "2", for example, that > > means that the locator is preferred for data packets. >=20 > That is, when a "P" bit is set for Traffic Type "2", for=20 > example, it means > that the locator is preferred for data packets. OK >=20 > > If there is a conflict (for example, if P bit is set for an=20 > address of > > Type "0" and a different address of Type "2"), the more=20 > specific Traffic > > Type rule applies. >=20 > If there is a conflict (for example, if P bit is set for an address of > Type "0" and a different address of Type "2"), the more=20 > specific Traffic > Type rule applies (in this case it was "2"). OK >=20 > This seems to complicate the processing rules. Unless there=20 > is a special > reason for doing this, it migth be easier to forbid mixing=20 > type 0 locators > with type 1 or 2 locators. Since we do not presently define multiple LOCATORs in a single packet,=20 this would mean that we cannot handle different interfaces differently. It may be that one interface requires the separation of signaling and data, while another does not. So I'd slightly prefer to keep it open. I don't see it as seriously complicating things. >=20 > > 4.2. Locator Type and Locator >=20 > > 0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [7] (128 > > bits long). >=20 > Suggest adding: Currently, mostly for non-ESP based usage. >=20 This locator type is defined primarily for non-ESP-based usage. > > 1: The concatenation of an ESP SPI (first 32 bits) followed by an > > IPv6 address or an IPv4-in-IPv6 format IPv4 address (an=20 > additional > > 128 bits). >=20 > Suggest adding: Recommend for ESP based usage. >=20 This locator type is defined primarily for ESP-based usage. > > 4.3. UPDATE packet with included LOCATOR >=20 > Add to this section some text about the correspondence=20 > between ESP_INFO > and Type 1 LOCATORS. The relationship between the announced Locators and any ESP_INFO parameters present in the packet is defined in Section 5.2. =20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 14 13:52:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSTM-0001W9-M5; Fri, 14 Apr 2006 13:52:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSTL-0001VB-E3 for hipsec@ietf.org; Fri, 14 Apr 2006 13:52:43 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUSTK-0001X9-02 for hipsec@ietf.org; Fri, 14 Apr 2006 13:52:43 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 03280212C63; Fri, 14 Apr 2006 20:52:40 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5FCB3212C46; Fri, 14 Apr 2006 20:52:39 +0300 (EEST) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2F00D@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D01A2F00D@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6DAD1462-7959-46A9-849B-7FEA906173B2@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] mm-03 CBA fixes Date: Fri, 14 Apr 2006 20:52:42 +0300 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org > Christian has provided the following corrected figure. > > > +-------+ +-------+ > | A | | B | > +-------+ +-------+ > | | > address |------------------------------->| credit += size(packet) > ACTIVE | | > |------------------------------->| credit += size(packet) > |<-------------------------------| don't change credit > | | > + address change | > + address verification starts | > address |<-------------------------------| credit -= size(packet) > UNVERIFIED |------------------------------->| credit += size(packet) I am not convinced that increasing credits based on packets from an unverified source is a good idea. I can imagine situations where one is able to spoof the source IP address, causing a continued reflection attack. Other than that, seems ok to me. > |<-------------------------------| credit -= size(packet) > | | > |<-------------------------------| credit -= size(packet) > | X credit < size(packet) > | | => do not send packet! > + address verification concludes | > address | | > ACTIVE |<-------------------------------| don't change credit > | | > > Figure 10: Readdressing Scenario --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Apr 16 14:50:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVCKF-0004R1-Pq; Sun, 16 Apr 2006 14:50:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVCKE-0004Qu-27 for hipsec@ietf.org; Sun, 16 Apr 2006 14:50:22 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVCKC-0002Xn-ME for hipsec@ietf.org; Sun, 16 Apr 2006 14:50:22 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FVCK1-0001Ab-8y; Sun, 16 Apr 2006 20:50:11 +0200 Received: from [141.3.71.115] (i72ibm03.tm.uni-karlsruhe.de [141.3.71.115]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 7CFED853F; Sun, 16 Apr 2006 20:50:08 +0200 (CEST) Message-ID: <444291E0.8040002@tm.uka.de> Date: Sun, 16 Apr 2006 20:50:08 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.3.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] mm-03 CBA fixes References: <77F357662F8BFA4CA7074B0410171B6D01A2F00D@XCH-NW-5V1.nw.nos.boeing.com> <6DAD1462-7959-46A9-849B-7FEA906173B2@nomadiclab.com> In-Reply-To: <6DAD1462-7959-46A9-849B-7FEA906173B2@nomadiclab.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.7 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Hi Pekka. > I am not convinced that increasing credits based on packets from an > unverified source is a good idea. I can imagine situations where one > is able to spoof the source IP address, causing a continued > reflection attack. In this case, the attacker would still get credit only for packets that it has sent, so no amplification will happen. This is in line with the invariant of CBA to not permit amplification. But without amplification, why would an attacker use HIP MM to realize its reflection attack? A direct flooding attack, where the attacker itself sends the flooding packets to its victim, would have the same potential--- and it could be done without speaking the HIP MM protocol. And given that the attacker you are describing can spoof the source address of its packets, it could just as well do so during a direct flooding attack. If the attacker wants the flooding packets to be generated by a third node and propagate along a path that does not originate at the attacker itself, then the attacker could use existing reflection strategies. E.g., it could send spoofed ICMP Echo Request packets to a third node that have the victim's address as a source address. This would give the attacker a non-amplified reflection attack as well--- again, without having to speak the HIP MM protocol. Other strategies, such as spoofing the source address in TCP SYNs, would have the same effect. In fact, a TCP SYN attack might actually be more effective than a non-amplified HIP-MM-based reflection attack, because some TCP servers retransmit a TCP SYN-ACK a couple of times before they give up. This creates even some amplification. In summary, I think we are save as long as we do not allow for amplification. Even if we give the attacker credit for packets originating from an unverified address. Without amplification, the attacker has so many other options to realize a reflection attack that misusing the HIP MM protocol becomes really unattractive. And if we give a /legitimate/ mobile node credit while its address is unverified, we help it to not run out of credit before the handoff process is over. > Other than that, seems ok to me. Ok, thanks. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Pekka Nikander wrote: > >> Christian has provided the following corrected figure. >> >> >> +-------+ +-------+ >> | A | | B | >> +-------+ +-------+ >> | | >> address |------------------------------->| credit += size(packet) >> ACTIVE | | >> |------------------------------->| credit += size(packet) >> |<-------------------------------| don't change credit >> | | >> + address change | >> + address verification starts | >> address |<-------------------------------| credit -= size(packet) >> UNVERIFIED |------------------------------->| credit += size(packet) > > > I am not convinced that increasing credits based on packets from an unverified source is a good idea. I can imagine situations where one is able to spoof the source IP address, causing a continued reflection attack. > > Other than that, seems ok to me. > >> |<-------------------------------| credit -= size(packet) >> | | >> |<-------------------------------| credit -= size(packet) >> | X credit < size(packet) >> | | => do not send packet! >> + address verification concludes | >> address | | >> ACTIVE |<-------------------------------| don't change credit >> | | >> >> Figure 10: Readdressing Scenario > > > > > --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 17 15:17:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVZDw-0003uK-OS; Mon, 17 Apr 2006 15:17:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVZDu-0003uF-TJ for hipsec@lists.ietf.org; Mon, 17 Apr 2006 15:17:22 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVZDt-0007xr-BP for hipsec@lists.ietf.org; Mon, 17 Apr 2006 15:17:22 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 768442FCF; Mon, 17 Apr 2006 22:17:18 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 8AB5D2F6C; Mon, 17 Apr 2006 22:17:17 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id k3HJHGE17206; Mon, 17 Apr 2006 22:17:16 +0300 (EEST) Date: Mon, 17 Apr 2006 22:17:15 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Hipsec] some comments for mm-03 In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2F011@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D01A2F011@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: hipsec@lists.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Thu, 13 Apr 2006, Henderson, Thomas R wrote: > > > 3.3.4. Interaction with Security Associations > > > > > > This document specifies a new HIP protocol parameter, the LOCATOR > > > parameter (see Section 4), that allows the hosts to > > exchange information > > > about their locator(s), and any changes in their locator(s). > > > > This document specifies a new HIP protocol parameter, the LOCATOR > > parameter (see Section 4), that allows the hosts to exchange > > information about changes their locator(s). > > disagree with this editorial suggestion, since it is not only changes > that > can be conveyed in LOCATOR. Ok. > > > Figure 12 > > > > This figure reminds me that is it possible to have both SPI1 and SPI2 > > mapping to the same ADDR21? > > Yes, in general, there may be different source addresses and hence > different paths to the same destination address. Maybe this could be also mentioned briefly in the text. It is not obvious from figure or text. > > > > > Even if the I2 packet contains LOCATOR parameters, the Responder > > > > > MUST still send the R2 packet to the source address of the I2. > > > > > > > > I1 and I2 source address must be the same? > > > > > > What does it matter? I1 state is not kept by responder. > > > > Cookies might get burned if the indexing is affected by the > > IP addresses > > :) > > > I1 and I2 source addresses can be different, because the responder > can include a new preferred address in the R1 LOCATOR, and the > change in responder address might require a change in initiator > source address. Let me further illustrate my original point. In the Appendix A. (Using Responder Puzzles) of base draft, an example puzzle algorithm is illustrated. Even though the algorithm is only illustrative, I believe that any DoS resistant puzzle algo will use the I1 and I2 source IP address as part of the indexing scheme in practice, and this will most probably cause the base exchange to fail. The initiator keeps retransmitting I2 packets from I2_SENT state and responder just drops them due to failed cookie solutions. I believe that this is a very practical and real problem; I've encountered similar problems many times in our implementation, albeit on when implementing other things (NAT, rvs). > Now, back to the text at hand. NOTIFY perhaps should be separated > from the R1/I2 cases. It may be the case that a LOCATOR in an I2 > can override the preferred address used for the base exchange, so > saying that it is informational may mean that the receiver can ignore > it. The issue is really with NOTIFY, which could be replayed. What > may work better here is to treat NOTIFY as informational, which means > that it cannot drive any particular state change (this also just > discussed in the Bellovin-Rescorla analysis thread). Yes. > Perhaps this wording is better: > > " When the LOCATOR parameter is sent in an UPDATE packet, then the > receiver will respond with an UPDATE acknowledgment. When the > LOCATOR parameter is sent in an R1 or I2 packet, the base > exchange > retransmission mechanism will confirm its successful delivery. > LOCATORs may experimentally be used in NOTIFY packets; in this > case, > the recipient MUST consider the LOCATOR as informational and not > immediately change the current preferred address, but can test > the > additional locators when the need arises. The use of LOCATOR > in a NOTIFY message may not be compatible with middleboxes." The wording is better, but I claim that there is still a practical problem and important problem with cookie indexing. Perhaps we can just mention somewhere in the text (3.2.8. Initiating the protocol in R1 or I2?) something like this: I1 and I2 may be arriving from the different source addresses if the LOCATOR parameter is present in R1. In this case, implementations using pre-created R1 indexed with IP addresses may be failing cookie solutions of I2 packets inadvertly. As a solution, the responder's R1 indexing mechanism must be flexible enough to accomodate the situation when R1 includes a LOCATOR parameter. > > > The use of LOCATOR in a NOTIFY message may not be compatible with > > > middleboxes. > > > > > 4. LOCATOR parameter format > > > > Is there are specific reason why the reserved field cannot be > > just flags? > > I do not understand this request. Aren't undefined flags the same > as reserved bits? Effectively yes. However, now thinking this again, the difference in using "reserved bits" rather than "undefined flags" may be that reserved bits could be allocated as a type field rather than single bit flags. As a consequence, it is more modular. So I am fine with this as it is, it seems to be case also in the base draft. > > > Length: Length in octets, excluding Type and Length fields, and > > > excluding padding. > > > > Minimum length (is a locator without any address allowed)? > > I would say yes, and this corresponds to moving all addresses to > DEPRECATED. > > Suggest: > "A LOCATOR contaning zero Locator fields > is permitted but has the effect of DEPRECATING all addresses." Excellent. > > > A deprecated address SHOULD NOT be used as an destination > > address if an > > > alternate (non-deprecated) is available and has sufficient scope. > > > > In the case of many alternatives, the host chooses according to > > local host policies. > > I don't think this sentence is really needed here since the issue > of picking among multiple addresses is dealt with elsewhere. Fine. > > This seems to complicate the processing rules. Unless there > > is a special > > reason for doing this, it migth be easier to forbid mixing > > type 0 locators > > with type 1 or 2 locators. > > Since we do not presently define multiple LOCATORs in a single packet, > this would mean that we cannot handle different interfaces differently. > It may be that one interface requires the separation of signaling and > data, while another does not. So I'd slightly prefer to keep it open. > I don't see it as seriously complicating things. Fine. > > > 4.2. Locator Type and Locator > > > > > 0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [7] (128 > > > bits long). > > > > Suggest adding: Currently, mostly for non-ESP based usage. > > > > This locator type is defined primarily for non-ESP-based usage. > > > > 1: The concatenation of an ESP SPI (first 32 bits) followed by an > > > IPv6 address or an IPv4-in-IPv6 format IPv4 address (an > > additional > > > 128 bits). > > > > Suggest adding: Recommend for ESP based usage. > > > This locator type is defined primarily for ESP-based usage. Suggest adding the proposed hints for the sake of ease-of-readability. If I recall correctly, I started to wonder the difference between the locator types at this point. After reading the whole draft, I just added the sentences that would have satisfied my curiousity on the first reading round. > > > 4.3. UPDATE packet with included LOCATOR > > > > Add to this section some text about the correspondence > > between ESP_INFO > > and Type 1 LOCATORS. > > The relationship between the > announced Locators and any ESP_INFO parameters present in the packet > is defined in Section 5.2. This was a readability note because the text references something that has not been discussed yet. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Apr 18 03:35:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVkjl-00028I-Pg; Tue, 18 Apr 2006 03:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVkjj-00027Z-RJ for hipsec@ietf.org; Tue, 18 Apr 2006 03:34:59 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVkdr-0002l1-2o for hipsec@ietf.org; Tue, 18 Apr 2006 03:28:56 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4C59D212C54; Tue, 18 Apr 2006 10:28:41 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9C534212C46; Tue, 18 Apr 2006 10:28:40 +0300 (EEST) In-Reply-To: <444291E0.8040002@tm.uka.de> References: <77F357662F8BFA4CA7074B0410171B6D01A2F00D@XCH-NW-5V1.nw.nos.boeing.com> <6DAD1462-7959-46A9-849B-7FEA906173B2@nomadiclab.com> <444291E0.8040002@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] mm-03 CBA fixes Date: Tue, 18 Apr 2006 10:28:46 +0300 To: Christian Vogt X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org > In summary, I think we are save as long as we do not allow for > amplification. Even if we give the attacker credit for packets > originating from an unverified address. Without amplification, the > attacker has so many other options to realize a reflection attack that > misusing the HIP MM protocol becomes really unattractive. > > And if we give a /legitimate/ mobile node credit while its address is > unverified, we help it to not run out of credit before the handoff > process is over. Hmm. I am still a little bit worried. As you mention, there are easier ways to cause reflection today, but what about the future where it may not be so. What about crediting the incoming traffic but not crediting it fully? For example, instead of increasing the credits by sizeof (incoming packet) just increase them by 0.5 * sizeof(incoming packet)? That would still allow the moving host to send in traffic to increase credits but would make the system as an attack vehicle much less attractive. Right now I am worried about a situation where the attacker creates the association, immediately signals a mobility event (without accumulating *any* credits at all), and then making the reflection to continue by sending packets with spoofed source address. For the reverse case where the attacker accumulates a big credit and then "flushes" it to a victim address, IIRC we have already mechanisms for, don't we? Taking a step back, we have to strike a balance between security (conservatism) and optimisation (optimism). The optimistic view is that it is good if the mobile host can keep functioning for a longish time it may take to verify the new address. The conservative view is that the shorter time the potential attacker can get traffic sent to the victim's address, the better. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Apr 19 14:54:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWHoA-0004jW-QC; Wed, 19 Apr 2006 14:53:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWHo9-0004jR-Pb for hipsec@ietf.org; Wed, 19 Apr 2006 14:53:45 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWHo5-00014J-7o for hipsec@ietf.org; Wed, 19 Apr 2006 14:53:45 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FWHnv-0006xE-5q; Wed, 19 Apr 2006 20:53:37 +0200 Received: from [192.168.11.142] (unknown [192.76.146.31]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id CC3F3864F; Wed, 19 Apr 2006 20:53:30 +0200 (CEST) Message-ID: <4446871C.4010504@tm.uka.de> Date: Wed, 19 Apr 2006 20:53:16 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.3.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] mm-03 CBA fixes References: <77F357662F8BFA4CA7074B0410171B6D01A2F00D@XCH-NW-5V1.nw.nos.boeing.com> <6DAD1462-7959-46A9-849B-7FEA906173B2@nomadiclab.com> <444291E0.8040002@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.8 (/) X-Spam-Status: No X-Spam-Report: 3.5 BAD_CREDIT BODY: Eliminate Bad Credit -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -1.8 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.3 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Pekka - > Hmm. I am still a little bit worried. As you mention, there are > easier ways to cause reflection today, but what about the future > where it may not be so. > > What about crediting the incoming traffic but not crediting it > fully? For example, instead of increasing the credits by sizeof > (incoming packet) just increase them by 0.5 * sizeof(incoming > packet)? That would still allow the moving host to send in traffic > to increase credits but would make the system as an attack vehicle > much less attractive. Actually, it /is/ technically feasible to give no credit for packets received from an unverified IP address. But one should note that, in this case, the protocol becomes more sensitive to the chosen parameters of credit aging (CreditAgingFactor and CreditAgingInterval). The reason is that, since a MN would not be able to increase its credit during the handoff period, the performance of applications during the handoff would solely depend on the amount of credit that was built up /before/ the handoff. This credit amount is limited by credit aging. Contrariwise, credit aging has no impact on credit that is directly used. Credit-aging parameters could therefore be stricter--- with a benefitial effect on security--- if the MN would be able to earn credit while its IP address is unverified. Anyway, I think that the credit-aging parameters currently defined in draft-ietf-hip-mm-03.txt provide a reasonable trade-off between security and application performance. They allow a MN downloading a file via TCP to obtain the credit it requires for a 500ms reachability-verification period. See [1] for a calculation. And as [1] shows--- and as we have also seen in our testbed---, application performance is also fine with these parameters, even if no credit is given while the MN's IP address is unverified. [1] http://www.atm.tut.fi/list-archive/MIPshop-2005/msg00153.html > Right now I am worried about a situation where the attacker creates > the association, immediately signals a mobility event (without > accumulating *any* credits at all), and then making the reflection to > continue by sending packets with spoofed source address. For the > reverse case where the attacker accumulates a big credit and then > "flushes" it to a victim address, IIRC we have already mechanisms > for, don't we? Right, this is why we exponenially age existing credit. I.e., the credit that a MN (or an attacker) shrinks over time. Building up credit over a long time and flushing it all at once thence becomes impossible. > Taking a step back, we have to strike a balance between security > (conservatism) and optimisation (optimism). The optimistic view is > that it is good if the mobile host can keep functioning for a longish > time it may take to verify the new address. The conservative view > is that the shorter time the potential attacker can get traffic sent > to the victim's address, the better. Yes. And, as said above, the parameters of credit aging contribute to this balance as well. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Pekka Nikander wrote: >> In summary, I think we are save as long as we do not allow for >> amplification. Even if we give the attacker credit for packets >> originating from an unverified address. Without amplification, the >> attacker has so many other options to realize a reflection attack >> that misusing the HIP MM protocol becomes really unattractive. >> >> And if we give a /legitimate/ mobile node credit while its address >> is unverified, we help it to not run out of credit before the >> handoff process is over. > > > Hmm. I am still a little bit worried. As you mention, there are > easier ways to cause reflection today, but what about the future > where it may not be so. > > What about crediting the incoming traffic but not crediting it > fully? For example, instead of increasing the credits by sizeof > (incoming packet) just increase them by 0.5 * sizeof(incoming > packet)? That would still allow the moving host to send in traffic > to increase credits but would make the system as an attack vehicle > much less attractive. > > Right now I am worried about a situation where the attacker creates > the association, immediately signals a mobility event (without > accumulating *any* credits at all), and then making the reflection to > continue by sending packets with spoofed source address. For the > reverse case where the attacker accumulates a big credit and then > "flushes" it to a victim address, IIRC we have already mechanisms > for, don't we? > > Taking a step back, we have to strike a balance between security > (conservatism) and optimisation (optimism). The optimistic view is > that it is good if the mobile host can keep functioning for a longish > time it may take to verify the new address. The conservative view > is that the shorter time the potential attacker can get traffic sent > to the victim's address, the better. > > --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Apr 20 09:11:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWYw8-0000jr-NS; Thu, 20 Apr 2006 09:11:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWYw6-0000jg-Rh for hipsec@ietf.org; Thu, 20 Apr 2006 09:11:06 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWYw6-0006lD-AS for hipsec@ietf.org; Thu, 20 Apr 2006 09:11:06 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B0C3A4F0001; Thu, 20 Apr 2006 15:11:05 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 15:11:05 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 15:11:04 +0200 Received: from [131.160.37.58] (EGUUG000L5C5TEU.lmf.ericsson.se [131.160.37.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C8872236B; Thu, 20 Apr 2006 16:11:04 +0300 (EEST) Message-ID: <44478868.2090803@ericsson.com> Date: Thu, 20 Apr 2006 16:11:04 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2006 13:11:04.0954 (UTC) FILETIME=[E14135A0:01C6647B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.6 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Subject: [Hipsec] [Fwd: FW: IESG Statement: Normative and Informative References] X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Folks, FYI: this was the conclusion of the discussions initiated by our question to the IESG on the references to work in progress in the HIP specification, which will be an Experimental RFC. In brief, we cannot have normative references to work in progress. Cheers, Gonzalo ------ Forwarded Message From: IESG Secretary Date: Wed, 19 Apr 2006 09:50:00 -0400 To: IETF Announcement list Subject: IESG Statement: Normative and Informative References Normative and Informative References Nearly all RFCs contain citations to other documents, and these are listed in a References section near the end of the RFC. There are many styles for references, and the RFCs have one of their own. Please follow the reference style used in recent RFCs. Please note that for documents that have been assigned an STD or BCP number, the number must be included in the reference. Within an RFC, references to other documents fall into two general categories: "normative" and "informative". Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. An informative reference is not normative; rather, it only provides additional information. For example, an informative reference might provide background or historical information. Informative references are not required to implement the technology in the RFC. Note 1: Even references that are relevant only for optional features must be classified as normative if they meet the above conditions for normative references. Note 2: It is not considered necessary to cite basic specifications that may be safely assumed to be known to practitioners (for example, RFC 791 need not be cited in every specification that mentions IPv4). Note 3: The normative/informative distinction is relevant in any document that amounts to a technical specification, even if its intended status is Experimental or Informational. Note 4: Normative references in RFCs cannot be to "work in progress" documents such as Internet Drafts. Drafts with such references will not be published as RFCs until the references are also published. The distinction between normative and informative references is often important. The IETF standards process according to RFC 2026 and RFC 3967, and the RFC Editor publication process, both need to know whether a reference to a work in progress is normative. An RFC cannot be published until all of the documents that it lists as normative references have been published. In practice, this often results in the simultaneous publication of a group of interrelated RFCs. For these reasons, the IESG and the RFC Editor have established guidelines that will request separate reference lists for normative and informative references in Internet Drafts and RFCs. For example, if both types are present, there would be two reference subsections, numbered s.1 and s.2 for example: s.1. Normative References xxx ... xxx s.2. Informative References xxx ... xxx Of course, if there is only one type of reference, only one section is needed. The IESG _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ------ End of Forwarded Message _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 21 16:23:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX29d-0008HY-Rh; Fri, 21 Apr 2006 16:23:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX29d-0008HT-AQ for hipsec@lists.ietf.org; Fri, 21 Apr 2006 16:23:01 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX29c-0004R1-EQ for hipsec@lists.ietf.org; Fri, 21 Apr 2006 16:23:01 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA11145; Fri, 21 Apr 2006 13:22:59 -0700 (PDT) Received: from XCH-NWBH-10.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k3LKMxo17572; Fri, 21 Apr 2006 13:22:59 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 13:22:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] some comments for mm-03 Date: Fri, 21 Apr 2006 13:22:51 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F09B@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] some comments for mm-03 Thread-Index: AcZXdABKSqkxxr8FRAuBKV6MUuSLqgKsOufA From: "Henderson, Thomas R" To: "Miika Komu" , X-OriginalArrivalTime: 21 Apr 2006 20:22:51.0742 (UTC) FILETIME=[5D5117E0:01C66581] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8e140a89d08e89747ee196e282ac2228 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Miika, I'm still plowing through your comments:=20 > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Monday, April 03, 2006 4:06 PM > To: hipsec@lists.ietf.org > Subject: Re: [Hipsec] some comments for mm-03 >=20 > On Tue, 4 Apr 2006, Miika Komu wrote: >=20 > > > Some comments for mm-03, part 1/2 (I'll send the rest later this > > > evening). > > > > Here we go again.. decided to split the email on separate=20 > sections. Here > > is (the end of section three and) section 4. >=20 > And here are comments from section five. >=20 > > 5. Processing rules >=20 > (perhaps a tiny intro) "This section describes rules for sending and receiving the LOCATOR parameter, testing address reachability, and using Credit-Based Authorization (CBA) on UNVERIFIED locators." >=20 > > 5.1. Locator data structure and status > > > > Rapidly sending conflicting LOCATORs SHOULD be avoided. >=20 > What conflicting means here? I changed to "Rapidly sending LOCATORs that force the peer to change=20 the preferred address SHOULD be avoided." >=20 > This section does not talk about selecting the source address for a > locator to be sent. Suggest adding text on what to choose as=20 > the source > address: the newly obtained locator or, in the case of=20 > multiple obtained > locators, selection according to a local policy. >=20 I would prefer that source address selection is out of scope of this draft, beyond referring to RFC 3484. Marcelo Bagnulo has written a recent draft that states that shim6 multihoming will require additional work beyond RFC 3484: draft-bagnulo-shim6-addr-selection-00 IMO, this is a piece of the multihoming work that is for further study, and probably can build on future work done in shim6. I added a comment in the Section 3.1.3 to this effect. > > 3. Host multihoming (addition of an address). We only describe the > > simple case of adding an additional address to a single-homed, > > non-mobile host. >=20 > s/single-homed/multi-homed/=20 s/single-homed/(previously) single-homed/ >=20 > > To do this, the multihomed host creates a new inbound SA=20 > and creates a > > new ESP_INFO parameter with an "Old SPI" parameter of "0",=20 > a "New SPI" > > parameter corresponding to the new SPI, and a "Keymat=20 > Index" as selected > > by local policy. >=20 > To do this, the multihomed host creates a new inbound SA and=20 > creates a new > SPI. For the outgoing UPDATE message, it inserts an ESP_INFO parameter > with an "Old SPI" field of "0", a "New SPI" field=20 > corresponding to the new > SPI, and a "Keymat Index" as selected by local policy. OK >=20 > > 5.3. Handling received LOCATORs > > > > A host SHOULD be prepared to receive a LOCATOR parameter in any HIP > > packet, excluding I1. >=20 > ...and CLOSE and notify? s/in any HIP packet, excluding I1/in the following HIP packets: R1, I2, UPDATE, and NOTIFY/ >=20 > > The ESP_INFO parameter is included if there is a need to=20 > rekey or key a > > new SPI >=20 > s/if/when/ >=20 OK > > The LOCATOR parameter contains a complete map of the=20 > locators that the > > host wishes to make or keep active for the HIP association. >=20 > Currently, only a single ESP_INFO and LOCATOR are allowed in a HIP > message. I think this comment does not require any actions. >=20 > > 1. The host checks if the New SPI listed in the ESP_INFO is a new > > one. If it is a new one, it creates a new inbound SA with that > > SPI that contains no addresses. If it is an existing one, it > > prepares to change the address set on the existing SPI. >=20 > If the SPI is invalid, the packet MUST be dropped. I believe that this sentence needs the following correction (and not your proposed modification): s/new inbound/new outbound/ >=20 > > 2. For each locator listed in the LOCATOR parameter, check that the > > address therein is a legal unicast or anycast address. That is, > > the address MUST NOT be a broadcast or multicast address. the > > local host, since it may be allowed that the host runs HIP with > > itself. >=20 > Also, when receiving link local addresses, they should be=20 > used only when > no public addresses are present. The link local addresses may create > reachability problems after the host moves to another network. This clarification pertains to the sending of LOCATOR, not receiving. I added the following to section 5.2, third paragraph: "Hosts MUST NOT announce broadcast or multicast addresses in LOCATORs. =20 The announcement of link-local addresses is a policy decision; such addresses used as preferred locators will create reachability problems when the host moves to another link." >=20 > > 3. For each Type 1 address listed in the LOCATOR=20 > parameter, check if > > the address is already bound to the SPI indicated. >=20 > For each Type 1 address listed in the LOCATOR parameter, the=20 > host checks > if the address is already bound to the SPI indicated. OK >=20 > > Mark all addresses on the SPI that were NOT listed in the LOCATOR > > parameter as DEPRECATED. >=20 > Mark all addresses corresponding to the SPI that were NOT=20 > listed in the > LOCATOR parameter as DEPRECATED. OK >=20 > > As a result, the SPI now contains any addresses listed in=20 > the LOCATOR > > parameter either as UNVERIFIED or ACTIVE, and any old addresses not > > listed in the LOCATOR parameter as DEPRECATED. >=20 > As a result, the addresses listed in the LOCATOR parameter=20 > have a either > state of UNVERIFIED or ACTIVE, and any old addresses not listed in the > LOCATOR parameter have a state of DEPRECATED. OK >=20 > > 4. If the LOCATOR is paired with an ESP_INFO parameter,=20 > the ESP_INFO > > parameter is processed as follows: >=20 > 4. Here, it is assumed that the LOCATOR is paired with an ESP_INFO > which is processed as follows: >=20 > Should this be actually the first bullet instead of fourth? Yes. I think there are a few misalignments of this section. =20 Recall that we were talking about making the processing more modular (process ESP_INFO then process LOCATOR) Here is how I propose to fix this section: " The processing of ESP_INFO and LOCATOR parameters is intended to be modular and support future generalization to the inclusion of multiple ESP_INFO and/or multiple LOCATOR parameters. A host SHOULD first process the ESP_INFO before the LOCATOR, since the ESP_INFO may contain a new SPI value mapped to an existing SPI, while a Type 1 locator will only contain reference to the new SPI. When a host receives a validated HIP UPDATE with a LOCATOR and ESP_INFO parameter, it processes the ESP_INFO as follows. The ESP_INFO parameter indicates whether a SA is being rekeyed, created, deprecated, or just identified for the benefit of middleboxes. The host examines the Old SPI and New SPI values in the ESP_INFO parameter: 1. (no rekeying) If the Old SPI is equal to the New SPI and both correspond to an existing SPI, the ESP_INFO is gratuitous (provided for middleboxes) and no rekeying is necessary. 2. (rekeying) If the Old SPI indicates an existing SPI and the New SPI is a different non-zero value, the existing SA is being rekeyed and the host follows HIP ESP rekeying procedures by creating a new outbound SA with an SPI corresponding to the New SPI, with no addresses bound to this SPI. Note that Locators in the LOCATOR parameter will reference this new SPI instead of the old SPI. 3. (new SA) If the Old SPI value is zero and the New SPI is a new non-zero value, then a new SA is being requested by the peer. This case is also treated like a rekeying event; the receiving host must create a new SA and respond with an UPDATE ACK. 4. (deprecating of SA) If the Old SPI indicates an existing SPI and the New SPI is zero, the SA is being deprecated and all locators uniquely bound to the SPI are put into DEPRECATED state. If none of the above cases apply, a protocol error has occurred and the processing of the UPDATE is stopped. Next, the locators in the LOCATOR parameter are processed. For each locator listed in the LOCATOR parameter, check that the address therein is a legal unicast or anycast address. That is, the address MUST NOT be a broadcast or multicast address. Note that some implementations MAY accept addresses that indicate the local host, since it may be allowed that the host runs HIP with itself. The below assumes that all Locators are of Type 1 with a Traffic Type of 0; other cases are for further study. For each Type 1 address listed in the LOCATOR parameter, the host checks whether the address is already bound to the SPI indicated. If the address is already bound, its lifetime is updated. If the status of the address is DEPRECATED, the status is changed to UNVERIFIED. If the address is not already bound, the address is added, and its status is set to UNVERIFIED. Mark all addresses corresponding to the SPI that were NOT listed in the LOCATOR parameter as DEPRECATED. As a result, at the end of processing, the addresses listed in the LOCATOR parameter have either a state of UNVERIFIED or ACTIVE, and any old addresses on the old SA not listed in the LOCATOR parameter have a state of DEPRECATED. Once the host has processed the locators, if the LOCATOR parameter contains a new Preferred locator, the host SHOULD initiate a change of the Preferred locator. This requires that the host first verifies reachability of the associated address, and only then changes the Preferred locator. See Section 5.5." >=20 > (suggest using a different numbering style, e.g. letters, for the > following bullets) >=20 > > 1. If the Old SPI indicates an existing SPI and the New SPI is a > > different non-zero value, the existing SA is being rekeyed > > and the host follows HIP ESP rekeying procedures. Note that > > the Locators in the LOCATOR parameter will use this New SPI > > instead of the Old SPI. >=20 > Do you mean Type 0 Locators? Type 1 Locators have an=20 > additional SPI field. Type 1 (clarified this) >=20 > > 2. If... >=20 > When... >=20 > > 3. If the Old SPI indicates an existing SPI and the New SPI is > > zero, the SPI is being deprecated and all locators uniquely > > bound to the SPI are put into DEPRECATED state. >=20 > s/If/When/ these two I think I will just ignore (I think "if" is OK here). >=20 > Is the LOCATOR still processed, and if yes, how? yes it is processed (new text clarifies this) >=20 > > 4. If the Old SPI equals the New SPI and both correspond to an > > existing SPI, the ESP_INFO is gratuitous (provided for > > middleboxes) and no rekeying is necessary. >=20 > s/equals/equals to/ OK >=20 > 5. Otherwise, drop? I added: " If none of the above cases apply, a protocol error has occurred and the processing of the UPDATE is stopped." >=20 > > 5. Mark all locators on each SPI that were NOT listed in=20 > the LOCATOR > > parameter as DEPRECATED. >=20 > s/on/for/ this text went away >=20 > > Once the host has updated the SPI, if the LOCATOR parameter contains > > a new preferred locator, the host SHOULD initiate a change of the > > preferred locator. This requires that the host first verifies > > reachability of the associated address, and only then changes the > > preferred locator. See Section 5.6. >=20 > Once the host has updated the SPI and the LOCATOR parameter=20 > contains a new > preferred locator, the host SHOULD first verify the=20 > reachability of the > preferred locator. Only after that the host uses it for ESP=20 > communication > with the peer. See Section 5.6. I like the former text better. >=20 > > 5.4. Verifying address reachability >=20 > I'd say explicitly the following somewhere in this chapter=20 > because it is > really manifested in the text: >=20 > All of the new addresses received in a locator MUST be verified > separately. This means that for each UPDATE with LOCATOR with N new > Locators, N UPDATE ECHO_REQUEST packets must be sent and accepted. The > source address of ECHO_REQUEST is the preferred address of=20 > the local host. I disagree that the preferred address is the source address of ECHO_REQUEST in all cases-- it may not be even in the same address family as the address being tested. Also, there is the possibility that other messages serve as a surrogate for the nonce-- see end of paragraph 2. I don't know whether there is much value in adding further clarification as you suggest because it seems to me to be pretty clear already. >=20 > > For example, if the host is changing its SPI and is sending=20 > an ESP_INFO > > to the peer, the new SPI value SHOULD be random and the value MAY be > > copied into an ECHO_REQUEST sent in the rekeying UPDATE. >=20 > s/if/when/ OK >=20 > > If the host is not rekeying, it MAY still use the=20 > ECHO_REQUEST parameter > > in an UPDATE message sent to the new address. >=20 > However, when the host is not changing its SPI, the MAY still add the > ECHO_REQUEST parameter in an UPDATE message sent to the new address. OK >=20 > > Note that in the case of receiving a LOCATOR on an R1 and=20 > replying with > > an I2, receiving the corresponding R2 is sufficient proof of > > reachability for the Responder's preferred address. >=20 > Note that in the case of receiving a new LOCATOR in an R1 and replying > with an I2 to the new address in the LOCATOR, receiving the=20 > corresponding > R2 from the new address is sufficient proof of reachability for the > Responder's preferred address. OK (did not use the word "new" preceding LOCATOR). I went back and checked the text on sending LOCATOR in R1 and I2, and noticed that we said "one or more LOCATORs" there, so I changed it back to say "a LOCATOR" (i.e., singular). Note that these locators in the R1 must be Type 0 locators since no SAs are set up yet. So I added the following sentence to the end of Section 5.2: "Note that the inclusion of LOCATOR in an R1 packet requires the use of Type "0" locators since no SAs are set up at that point." That should cover the R1 case adequately for now. >=20 > > In some cases, it may be sufficient to use the arrival of data on a > > newly advertised SA as implicit address reachability verification, > > instead of waiting for the confirmation via a HIP packet=20 > (e.g., Figure > > 14). >=20 > In some cases, it MAY be sufficient to use the arrival of=20 > data on a newly > advertised SA as implicit address reachability verification=20 > as depicted in > Figure 14, instead of waiting for the confirmation via a HIP packet. OK >=20 > > Marking the address ACTIVE as a part of receiving data on=20 > the SA is an > > idempotent operation, and does not cause any harm. >=20 > Incorrect. The state is not changed as described 5.5.1. I deleted this sentence because I didn't think it added anything. >=20 > > Figure 14 >=20 > I think the names of "Mobile Host" and "Peer Host" could be=20 > swapped since > it is the "Peer Host" that is sending the SPI.=20 Mobility and multihoming are kind of conflated in this figure. I think that it is correctly labeled for the mobility case (we are talking about the use of the new SA instead of the reception of ECHO_RESPONSE allowing the right hand side host to move the address to ACTIVE). I think I will delete the "in R2, or" clause in the figure and just make it refer to mobility. > Maybe "Peer=20 > Host" can be > changed to "Corresponding Node". Elsewhere we have referred to Peer Host-- I will keep it the same. >=20 > > 5.5. Credit-Based Authorization >=20 > Add an intro. "CBA can be used to minimize the side effects=20 > of handovers. > It allows sending of data before address reachability test has been > completed to avoid transport layer timing problems. However,=20 > CBA cannot be > used for redirection amplification attacks." I added a separate intro (discussed in a separate email regarding CBA issues). >=20 > > 5.5.1. Handling Payload Packets >=20 > > When the host has a packet to be sent to the peer, if the peers > > preferred locator is listed as UNVERIFIED and no alternative locator > > with status ACTIVE is available, the host checks whether it=20 > can send the > > packet to the UNVERIFIED locator: The packet SHOULD be sent=20 > if the value > > of the credit counter is higher than the size of the=20 > outbound packet. >=20 > When the host has a packet to be sent to the peer, and when the peers > preferred locator is listed as UNVERIFIED and no alternative=20 > locator with > status ACTIVE is available, the host checks whether it can=20 > send the packet > to the UNVERIFIED locator. The packet SHOULD be sent if the=20 > value of the > credit counter is higher than the size of the outbound packet. OK >=20 > > 5.5.2. Credit Aging >=20 > Is not obvious to me what should be the initial credit size? My guess is zero. >=20 > > Credit aging may be implemented by multiplying credit=20 > counters with a > > factor, CreditAgingFactor, less than one in fixed time intervals of > > CreditAgingInterval length. >=20 > s/one/once/ ? I think it should be: CreditAgingFactor (a fractional value less than one), in fixed time... >=20 > > 5.6. Changing the preferred locator >=20 > 5.6. Changing the Preferred Locator Elsewhere it is "Preferred locator" so I have made it uniform throughout the document. >=20 > This section could be moved before CBA, that is, between=20 > sections 5.4 and > 5.5. Agreed. I moved it to after existing 5.4. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 21 16:48:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX2YH-0005lo-Ui; Fri, 21 Apr 2006 16:48:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX2YG-0005lb-Kh for hipsec@ietf.org; Fri, 21 Apr 2006 16:48:28 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX2YF-0005ca-Ck for hipsec@ietf.org; Fri, 21 Apr 2006 16:48:28 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA24080; Fri, 21 Apr 2006 15:48:17 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k3LKmGo14181; Fri, 21 Apr 2006 15:48:16 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 13:48:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] some comments for mm-03: including ESP-INFO in all(relevant) UPDATES Date: Fri, 21 Apr 2006 13:48:11 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F09C@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] some comments for mm-03: including ESP-INFO in all(relevant) UPDATES Thread-Index: AcZcmJEoBXtzaGFhSqiKDIQKzliWHAI7CzfQ From: "Henderson, Thomas R" To: "Miika Komu" , "Pekka Nikander" X-OriginalArrivalTime: 21 Apr 2006 20:48:11.0818 (UTC) FILETIME=[E75A48A0:01C66584] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Monday, April 10, 2006 5:16 AM > To: Pekka Nikander > Cc: Henderson, Thomas R; hipsec@ietf.org > Subject: Re: [Hipsec] some comments for mm-03: including=20 > ESP-INFO in all(relevant) UPDATES >=20 > On Mon, 10 Apr 2006, Pekka Nikander wrote: >=20 > > > My point was to reduce the number of indexing mechanisms=20 > required in > > > the implementations. When you receive an UPDATE packet=20 > containing an > > > ECHO RESPONSE but without ESP_INFO, you need yet another=20 > index (the > > > UPDATE ID) to map the packet to the corresponding SA.=20 > However, if we > > > had the the ESP_INFO included, we'd find the SA just with=20 > the existing > > > SPI search mechanisms that are already required for base exchange. > > > > How come? Why don't you just include the necessary info in you > > ECHO_REQUEST? You can even include a direct memory pointer if you > > dare (but I wouldn't do that... :-) You are free to include any > > information you want there, aren't you? >=20 > You are correct. The implementation can "hide" e.g. a SPI in the > ECHO_REQUEST or even in SEQ/ACK update if this explicit=20 > handling is not > wanted. So, it appears now to me that this idea can be=20 > forgotten. However, > I'd like to see a hint for the silly implementor in section 5.4. I am not sure what hint you are looking for. Placing the SPI in the ECHO_REQUEST is discussed in the second paragraph of Section 5.4 already. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 21 17:11:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX2ub-0007kP-07; Fri, 21 Apr 2006 17:11:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX2ua-0007kK-1I for hipsec@lists.ietf.org; Fri, 21 Apr 2006 17:11:32 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX2uY-00074P-Ke for hipsec@lists.ietf.org; Fri, 21 Apr 2006 17:11:32 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA19225; Fri, 21 Apr 2006 16:11:25 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k3LLBP502070; Fri, 21 Apr 2006 14:11:25 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 14:11:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] some comments for mm-03 Date: Fri, 21 Apr 2006 14:11:22 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F09D@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] some comments for mm-03 Thread-Index: AcZYg2Qn/gn19RH7T7uqVhaLFSzIWwM/jyjg From: "Henderson, Thomas R" To: "Miika Komu" , X-OriginalArrivalTime: 21 Apr 2006 21:11:22.0673 (UTC) FILETIME=[245DEA10:01C66588] X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Here is the response to the last batch of initial comments: =20 > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Wednesday, April 05, 2006 12:34 AM > To: hipsec@lists.ietf.org > Subject: Re: [Hipsec] some comments for mm-03 >=20 > My last comments, from section six: >=20 > > 6. Security Considerations > > > > If no precautionary measures are taken, an attacker could=20 > misuse this > > feature to impersonate a victim's peer from any arbitrary location. >=20 > s/this/the redirection/ OK >=20 > > If an attacker somehow uses a bug in the implementation or=20 > weakness in > > some protocol to redirect a HIP connection, the original owner can > > always reclaim their connection (they can always prove=20 > ownership of the > > private key associated with their public HI). >=20 > How is this possible if the private key is compromised? As pekka suggested, this case is out of scope. >=20 > > MitM attacks are always possible if the attacker is present=20 > during the > > initial HIP base exchange and if the hosts do not authenticate each > > other's identities, but once the base exchange has taken=20 > place even a > > MitM cannot steal an opportunistic HIP connection because it is very > > difficult for an attacker to create an UPDATE packet (or=20 > any HIP packet) > > that will be accepted as a legitimate update. >=20 > This was mostly a readibility comment. I suggest changing the text as > follows: >=20 > MitM attacks are always possible when the attacker is present=20 > during the > initial HIP base exchange and the hosts do not authenticate=20 > each other's > identities. However, once the opportunistic base exchange has=20 > taken place, > even a MitM cannot steal the HIP connection anymore because it is very > difficult for an attacker to create an UPDATE packet (or any=20 > HIP packet) > that will be accepted as a legitimate update. >=20 OK > > 6.2. Denial of Service attacks >=20 > > This threat is mitigated through reachability checks and=20 > credit-based > > authorization. >=20 > This threat is mitigated through reachability checks and credit-based > authorization strategies. I think Christian would object to this additional word because it may suggest that alternate CBA strategies are equivalent, so I will leave it out. >=20 > > As a result, the combination of a reachability check and=20 > credit-based > > authorization makes a HIP redirection-based flooding attack=20 > as effective > > and applicable as a normal, direct flooding attack in which=20 > the attacker > > itself sends the flooding traffic to the victim. >=20 > As a result, the combination of a reachability check and credit-based > authorization degrades a HIP redirection-based flooding attack to the > level of a direct flooding attack in which the attacker=20 > itself sends the > flooding traffic to the victim. s/degrades/lowers otherwise, I'm OK with the change >=20 > > First, when a reachability packet is received, this nonce=20 > packet MUST be > > ignored if the HIT is not one that is currently active. >=20 > First, when a reachability packet is received, the nonce in the packet > MUST be ignored if the HIT is not one that is currently active. >=20 > What does a currently active HIT mean? You probably mean address... No, I think it pertains to the case when multiple HITs are on a host-- I have tried to clarify this. >=20 > > Second, if the attacker is a MitM asnd can capture this nonce packet > > then it can respond to it, in which case it is possible for=20 > an attacker > > to redirect the connection. >=20 > How? I think it would require the ECHO_REQUEST/RESPONSE to be outside the signature, and for another HIP packet to be available to be replayed. I think that is unlikely scenario in this case. But reading this has raised an interesting question in my mind. Currently, there is no requirement for the nonce to be signed. The base spec and this spec do not specify whether ECHO_REQUEST is inside or outside the signature. Should it be one way or the other? I think that the last paragraph in Section 6.2.1 can be safely deleted. >=20 > > 6.2.2. Memory/Computational exhaustion DoS attacks >=20 > Suggest adding some text that central servers may have to deal with > multiple mobile clients that change their location rapidly. This may > burn too many CPU cycles of the server, and in such a case,=20 > the server may > want to e.g. increase its SA lifetimes or increase cookie=20 > difficulty to > slow down acceptance of new connections. How about: " A central server that has to deal with a large number of mobile clients may consider increasing the SA lifetimes to try to slow down the rate of rekeying UPDATEs or increasing the cookie difficulty to slow down the rate of attack-oriented connections." >=20 > > 6.3. Mixed deployment environment >=20 > s/user/host/ in this section? > s/their/its/ in this section >=20 > I did not get the purpose of this section. If you user A uses=20 > IPsec, user > B does not get anything meaninful even though the IPsec data=20 > is redirected > from A to B. >=20 > > ..connection with and then attempts to use a IPv6 change of address > > request to steal the HIP user's connection. >=20 > ..connection with and then attempts to change its IPv6=20 > address to steal > the HIP user's connection. s/IPv6/IP/; otherwise OK Also, I changed the last case a little bit as follows: " A HIP host attempts to steal a non-HIP host's session. A HIP host could spoof the non-HIP host's IP address during the base exchange or set the non-HIP host's IP address as its preferred address via an UPDATE. Other possibilities exist but a simple solution is to prevent use of HIP address check information to influence non-HIP sessions." >=20 > > 4. .. >=20 > What is a session here? TCP session? upper layer session-- TCP or otherwise >=20 >=20 > --=20 > Miika Komu miika@iki.fi http://www.iki.fi/miika/ >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 21 17:24:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX36m-0003P9-Ff; Fri, 21 Apr 2006 17:24:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX36l-0003P2-Dp for hipsec@lists.ietf.org; Fri, 21 Apr 2006 17:24:07 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX36k-00083v-Vs for hipsec@lists.ietf.org; Fri, 21 Apr 2006 17:24:07 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA16346; Fri, 21 Apr 2006 14:23:58 -0700 (PDT) Received: from XCH-NWBH-10.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k3LLNvo13458; Fri, 21 Apr 2006 16:23:57 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 14:23:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] some comments for mm-03 Date: Fri, 21 Apr 2006 14:23:54 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F09E@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] some comments for mm-03 Thread-Index: AcZiVMSMHW6Ql0fnQk6wR+Lwp4MbOADM2pGg From: "Henderson, Thomas R" To: "Miika Komu" X-OriginalArrivalTime: 21 Apr 2006 21:23:55.0265 (UTC) FILETIME=[E4F25710:01C66589] X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: hipsec@lists.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi]=20 > Sent: Monday, April 17, 2006 12:17 PM > To: Henderson, Thomas R > Cc: hipsec@lists.ietf.org > Subject: RE: [Hipsec] some comments for mm-03 >=20 > > > > Figure 12 > > > > > > This figure reminds me that is it possible to have both=20 > SPI1 and SPI2 > > > mapping to the same ADDR21? > > > > Yes, in general, there may be different source addresses and hence > > different paths to the same destination address. >=20 > Maybe this could be also mentioned briefly in the text. It is=20 > not obvious > from figure or text. I have looked at this and am not sure whether there is an easy way to add this without complicating the description more than necessary-- I would be willing to consider a specific proposal, though. >=20 > > > > > > Even if the I2 packet contains LOCATOR parameters,=20 > the Responder > > > > > > MUST still send the R2 packet to the source address=20 > of the I2. > > > > > > > > > > I1 and I2 source address must be the same? > > > > > > > > What does it matter? I1 state is not kept by responder. > > > > > > Cookies might get burned if the indexing is affected by the > > > IP addresses > > > :) > > > > > I1 and I2 source addresses can be different, because the responder > > can include a new preferred address in the R1 LOCATOR, and the > > change in responder address might require a change in initiator > > source address. >=20 > Let me further illustrate my original point. In the Appendix A. (Using > Responder Puzzles) of base draft, an example puzzle algorithm is > illustrated. Even though the algorithm is only illustrative, I believe > that any DoS resistant puzzle algo will use the I1 and I2 source IP > address as part of the indexing scheme in practice, and this will most > probably cause the base exchange to fail. The initiator keeps > retransmitting I2 packets from I2_SENT state and responder=20 > just drops them > due to failed cookie solutions. I believe that this is a very=20 > practical > and real problem; I've encountered similar problems many times in our > implementation, albeit on when implementing other things (NAT, rvs). I see your practical point. It seems to me that a host sending a R1 LOCATOR should not use the algorithm in Appendix A in the base draft without some modification. Maybe there should be a note to that effect. >=20 > > Perhaps this wording is better: > > > > " When the LOCATOR parameter is sent in an UPDATE=20 > packet, then the > > receiver will respond with an UPDATE=20 > acknowledgment. When the > > LOCATOR parameter is sent in an R1 or I2 packet, the base > > exchange > > retransmission mechanism will confirm its=20 > successful delivery. > > LOCATORs may experimentally be used in NOTIFY=20 > packets; in this > > case, > > the recipient MUST consider the LOCATOR as=20 > informational and not > > immediately change the current preferred address,=20 > but can test > > the > > additional locators when the need arises. The use=20 > of LOCATOR > > in a NOTIFY message may not be compatible with middleboxes." >=20 > The wording is better, but I claim that there is still a=20 > practical problem > and important problem with cookie indexing. Perhaps we can=20 > just mention > somewhere in the text (3.2.8. Initiating the protocol in R1 or I2?) > something like this: >=20 > I1 and I2 may be arriving from the different source addresses if the > LOCATOR parameter is present in R1. In this case,=20 > implementations using > pre-created R1 indexed with IP addresses may be failing=20 > cookie solutions > of I2 packets inadvertly. As a solution, the responder's R1 indexing > mechanism must be flexible enough to accomodate the situation when R1 > includes a LOCATOR parameter. I am willing to add this-- thanks for pointing it out. >=20 > > > > The use of LOCATOR in a NOTIFY message may not be=20 > compatible with > > > > middleboxes. > > > > > > > 4. LOCATOR parameter format > > > > > > Is there are specific reason why the reserved field cannot be > > > just flags? > > > > I do not understand this request. Aren't undefined flags the same > > as reserved bits? >=20 > Effectively yes. However, now thinking this again, the=20 > difference in using > "reserved bits" rather than "undefined flags" may be that=20 > reserved bits > could be allocated as a type field rather than single bit flags. As a > consequence, it is more modular. So I am fine with this as it=20 > is, it seems > to be case also in the base draft. OK, will leave it as is. >=20 > > > > 4.2. Locator Type and Locator > > > > > > > 0: An IPv6 address or an IPv4-in-IPv6 format IPv4=20 > address [7] (128 > > > > bits long). > > > > > > Suggest adding: Currently, mostly for non-ESP based usage. > > > > > > > This locator type is defined primarily for non-ESP-based usage. > > > > > > 1: The concatenation of an ESP SPI (first 32 bits)=20 > followed by an > > > > IPv6 address or an IPv4-in-IPv6 format IPv4 address (an > > > additional > > > > 128 bits). > > > > > > Suggest adding: Recommend for ESP based usage. > > > > > This locator type is defined primarily for ESP-based usage. >=20 > Suggest adding the proposed hints for the sake of=20 > ease-of-readability. If > I recall correctly, I started to wonder the difference between the > locator types at this point. After reading the whole draft, I=20 > just added > the sentences that would have satisfied my curiousity on the=20 > first reading > round. I did add those hints-- in my response, I should have made it clearer by enclosing them in quotes. >=20 > > > > 4.3. UPDATE packet with included LOCATOR > > > > > > Add to this section some text about the correspondence > > > between ESP_INFO > > > and Type 1 LOCATORS. > > > > The relationship between the > > announced Locators and any ESP_INFO parameters present=20 > in the packet > > is defined in Section 5.2. >=20 > This was a readability note because the text references=20 > something that has > not been discussed yet. >=20 Ditto-- I actually added the above sentence, but didn't enclose it in quotes, so you misunderstood my comment. (i.e., it is now in there) Tom=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Apr 21 18:53:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX4V0-00024F-CE; Fri, 21 Apr 2006 18:53:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX4Ux-00022u-AW for hipsec@ietf.org; Fri, 21 Apr 2006 18:53:11 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX4Pf-0004zu-IL for hipsec@ietf.org; Fri, 21 Apr 2006 18:47:44 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA03297 for ; Fri, 21 Apr 2006 15:47:42 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k3LMlgG29290 for ; Fri, 21 Apr 2006 17:47:42 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 15:47:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Apr 2006 15:47:17 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F0A6@XCH-NW-5V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comment resolution on draft-ietf-hip-mm-03.txt Thread-Index: AcZllYrGHbR20mV8QZmOCXNGHWoCBQ== From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 21 Apr 2006 22:47:18.0377 (UTC) FILETIME=[8B08A590:01C66595] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [Hipsec] comment resolution on draft-ietf-hip-mm-03.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org All, I've now gone through all of the comments received on the mobility management draft, which was WGLCed in March. The revised version of the draft, corresponding to the email that has been sent out, can be found at: http://www.openhip.org/ietf/drafts/draft-ietf-hip-mm-04-pre.txt Miika Komu gave a really thorough review-- thanks very much! The review has raised a small number of open issues, which I'd like to summarize here: 1. Miika has proposed a section on a HIP mobility management state machine, and I've refrained from adding it until hearing from other opinions. I am not sure it is needed. 2. Pekka has questioned the wisdom of granting credit for packets received from an unverified source, in the CBA algorithm. The discussion has not resulted in a proposed text change; Pekka has not responded to Christian's latest message on the topic. 3. The draft makes no statement on whether nonces for address reachability should be included within or outside of the signature. Since UPDATEs are not precomputed, it seems to me that the nonces could safely be included in the signature, unlike the base exchange case. 4. Miika has proposed to make the sending of ESP_INFO in the third UPDATE packet into a "MAY". Right now, it is not mentioned as a possibility. Does this need to be explicit? 5. Whether "LOCATOR" vs "Locator" (differentiating between the two based on letter case) is too confusing, and we should find some other word choice for one of them. 6. Should there be a maximum length of a LOCATOR, or should it just be bounded by maximum lengths of the HIP Parameters field? Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Apr 22 05:22:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXEJX-000475-Uo; Sat, 22 Apr 2006 05:22:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXEJW-00046g-GF for hipsec@lists.ietf.org; Sat, 22 Apr 2006 05:22:02 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXEJU-00048Z-5X for hipsec@lists.ietf.org; Sat, 22 Apr 2006 05:22:02 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 4F64531B7; Sat, 22 Apr 2006 12:21:59 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 9F8DE307A; Sat, 22 Apr 2006 12:21:57 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3) with ESMTP id k3M9LuJv014796; Sat, 22 Apr 2006 12:21:57 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Sat, 22 Apr 2006 12:21:55 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: RE: [Hipsec] some comments for mm-03 In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2F09E@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D01A2F09E@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: hipsec@lists.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Fri, 21 Apr 2006, Henderson, Thomas R wrote: >> -----Original Message----- >> From: Miika Komu [mailto:miika@iki.fi] >> Sent: Monday, April 17, 2006 12:17 PM >> To: Henderson, Thomas R >> Cc: hipsec@lists.ietf.org >> Subject: RE: [Hipsec] some comments for mm-03 >> >>>>> Figure 12 >>>> >>>> This figure reminds me that is it possible to have both >> SPI1 and SPI2 >>>> mapping to the same ADDR21? >>> >>> Yes, in general, there may be different source addresses and hence >>> different paths to the same destination address. >> >> Maybe this could be also mentioned briefly in the text. It is >> not obvious >> from figure or text. > > I have looked at this and am not sure whether there is an easy way to > add this without complicating the description more than necessary-- I > would be willing to consider a specific proposal, though. I think this is notified in the text already: An address may appear on more than one SPI. This creates no ambiguity since the receiver will ignore the IP addresses during SA lookup anyway. However, this document does not specify such cases. This text is fine. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Apr 22 05:30:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXERi-0000Dz-Q5; Sat, 22 Apr 2006 05:30:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXERh-0000Do-Nc for hipsec@ietf.org; Sat, 22 Apr 2006 05:30:29 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXERg-0004PG-Dv for hipsec@ietf.org; Sat, 22 Apr 2006 05:30:29 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id D86F6303B; Sat, 22 Apr 2006 12:30:27 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 7335B3025; Sat, 22 Apr 2006 12:30:27 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3) with ESMTP id k3M9UQvp014995; Sat, 22 Apr 2006 12:30:27 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Sat, 22 Apr 2006 12:30:26 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Henderson, Thomas R" Subject: Re: [Hipsec] comment resolution on draft-ietf-hip-mm-03.txt In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2F0A6@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D01A2F0A6@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org On Fri, 21 Apr 2006, Henderson, Thomas R wrote: > Miika Komu gave a really thorough review-- thanks very much! My pleasure. Thanks Thomas for your patience - the draft is now in better shape. > 3. The draft makes no statement on whether nonces for address > reachability should be included within or outside of the signature. > Since UPDATEs are not precomputed, it seems to me that the nonces could > safely be included in the signature, unlike the base exchange case. I'd put the nonces inside signatures unless there is a really good reason not to. For the rest of open issues, I'd like to hear opinions from others as I have told mine. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gg-7X; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNrbJ-0000KU-E5 for hipsec@ietf.org; Mon, 27 Mar 2006 08:17:41 -0500 Received: from [203.197.196.2] (helo=mail2.iitk.ac.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNrbH-0005no-JE for hipsec@ietf.org; Mon, 27 Mar 2006 08:17:41 -0500 Received: from antivirus.cc.iitk.ac.in (antivirus.cc.iitk.ac.in [172.31.1.102]) by mail2.iitk.ac.in (8.12.8/8.12.8) with ESMTP id k2RDLgmm020113; Mon, 27 Mar 2006 18:51:43 +0530 Received: from dilbert ([172.26.78.65]) by antivirus.cc.iitk.ac.in (8.13.1/8.13.1) with SMTP id k2RDHU4M023703; Mon, 27 Mar 2006 18:47:30 +0530 Message-ID: <001a01c651a3$7819e580$414e1aac@dilbert> From: "Bagri" To: Date: Mon, 27 Mar 2006 19:06:31 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Subject: [Hipsec] Bellovin-Rescorla analysis X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0203030242==" Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0203030242== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C651D1.8EBCF240" This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C651D1.8EBCF240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I was working on the Bellovin-Rescorla analysis. I was assigned the task = by Andrei Gurtov. i needed some inputs regarding details required: =20 - Do we need a mathematical analysis? If yes, I have very little = backgorund in mathematics of cryptography but have grasped some concepts = and can try my hand but might need more time. - I was preparing a document on fesibility and necessity of upgrading = hash function in HIP and the tradeoffs if we dont do it. - Any other details you would like me to include in the analysis. Thanks Abhijit ------=_NextPart_000_0013_01C651D1.8EBCF240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I was working on the Bellovin-Rescorla = analysis. I=20 was assigned the task by Andrei Gurtov. i needed some inputs regarding = details=20 required:
  
- Do we need a mathematical analysis? If = yes, I=20 have very little backgorund in mathematics of cryptography but have = grasped=20 some concepts and can try my hand but might need more time.
- I = was=20 preparing a document on fesibility and necessity of upgrading  hash = function in HIP and From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gg-7X; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNrbJ-0000KU-E5 for hipsec@ietf.org; Mon, 27 Mar 2006 08:17:41 -0500 Received: from [203.197.196.2] (helo=mail2.iitk.ac.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNrbH-0005no-JE for hipsec@ietf.org; Mon, 27 Mar 2006 08:17:41 -0500 Received: from antivirus.cc.iitk.ac.in (antivirus.cc.iitk.ac.in [172.31.1.102]) by mail2.iitk.ac.in (8.12.8/8.12.8) with ESMTP id k2RDLgmm020113; Mon, 27 Mar 2006 18:51:43 +0530 Received: from dilbert ([172.26.78.65]) by antivirus.cc.iitk.ac.in (8.13.1/8.13.1) with SMTP id k2RDHU4M023703; Mon, 27 Mar 2006 18:47:30 +0530 Message-ID: <001a01c651a3$7819e580$414e1aac@dilbert> From: "Bagri" To: Date: Mon, 27 Mar 2006 19:06:31 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Subject: [Hipsec] Bellovin-Rescorla analysis X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0203030242==" Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0203030242== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C651D1.8EBCF240" This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C651D1.8EBCF240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I was working on the Bellovin-Rescorla analysis. I was assigned the task = by Andrei Gurtov. i needed some inputs regarding details required: =20 - Do we need a mathematical analysis? If yes, I have very little = backgorund in mathematics of cryptography but have grasped some concepts = and can try my hand but might need more time. - I was preparing a document on fesibility and necessity of upgrading = hash function in HIP and the tradeoffs if we dont do it. - Any other details you would like me to include in the analysis. Thanks Abhijit ------=_NextPart_000_0013_01C651D1.8EBCF240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I was working on the Bellovin-Rescorla = analysis. I=20 was assigned the task by Andrei Gurtov. i needed some inputs regarding = details=20 required:
  
- Do we need a mathematical analysis? If = yes, I=20 have very little backgorund in mathematics of cryptography but have = grasped=20 some concepts and can try my hand but might need more time.
- I = was=20 preparing a document on fesibility and necessity of upgrading  hash = function in HIP and From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gg-7X; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNrbJ-0000KU-E5 for hipsec@ietf.org; Mon, 27 Mar 2006 08:17:41 -0500 Received: from [203.197.196.2] (helo=mail2.iitk.ac.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNrbH-0005no-JE for hipsec@ietf.org; Mon, 27 Mar 2006 08:17:41 -0500 Received: from antivirus.cc.iitk.ac.in (antivirus.cc.iitk.ac.in [172.31.1.102]) by mail2.iitk.ac.in (8.12.8/8.12.8) with ESMTP id k2RDLgmm020113; Mon, 27 Mar 2006 18:51:43 +0530 Received: from dilbert ([172.26.78.65]) by antivirus.cc.iitk.ac.in (8.13.1/8.13.1) with SMTP id k2RDHU4M023703; Mon, 27 Mar 2006 18:47:30 +0530 Message-ID: <001a01c651a3$7819e580$414e1aac@dilbert> From: "Bagri" To: Date: Mon, 27 Mar 2006 19:06:31 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Subject: [Hipsec] Bellovin-Rescorla analysis X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0203030242==" Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0203030242== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C651D1.8EBCF240" This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C651D1.8EBCF240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I was working on the Bellovin-Rescorla analysis. I was assigned the task = by Andrei Gurtov. i needed some inputs regarding details required: =20 - Do we need a mathematical analysis? If yes, I have very little = backgorund in mathematics of cryptography but have grasped some concepts = and can try my hand but might need more time. - I was preparing a document on fesibility and necessity of upgrading = hash function in HIP and the tradeoffs if we dont do it. - Any other details you would like me to include in the analysis. Thanks Abhijit ------=_NextPart_000_0013_01C651D1.8EBCF240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I was working on the Bellovin-Rescorla = analysis. I=20 was assigned the task by Andrei Gurtov. i needed some inputs regarding = details=20 required:
  
- Do we need a mathematical analysis? If = yes, I=20 have very little backgorund in mathematics of cryptography but have = grasped=20 some concepts and can try my hand but might need more time.
- I = was=20 preparing a document on fesibility and necessity of upgrading  hash = function in HIP and From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gg-7X; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNrbJ-0000KU-E5 for hipsec@ietf.org; Mon, 27 Mar 2006 08:17:41 -0500 Received: from [203.197.196.2] (helo=mail2.iitk.ac.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNrbH-0005no-JE for hipsec@ietf.org; Mon, 27 Mar 2006 08:17:41 -0500 Received: from antivirus.cc.iitk.ac.in (antivirus.cc.iitk.ac.in [172.31.1.102]) by mail2.iitk.ac.in (8.12.8/8.12.8) with ESMTP id k2RDLgmm020113; Mon, 27 Mar 2006 18:51:43 +0530 Received: from dilbert ([172.26.78.65]) by antivirus.cc.iitk.ac.in (8.13.1/8.13.1) with SMTP id k2RDHU4M023703; Mon, 27 Mar 2006 18:47:30 +0530 Message-ID: <001a01c651a3$7819e580$414e1aac@dilbert> From: "Bagri" To: Date: Mon, 27 Mar 2006 19:06:31 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Subject: [Hipsec] Bellovin-Rescorla analysis X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0203030242==" Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0203030242== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C651D1.8EBCF240" This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C651D1.8EBCF240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I was working on the Bellovin-Rescorla analysis. I was assigned the task = by Andrei Gurtov. i needed some inputs regarding details required: =20 - Do we need a mathematical analysis? If yes, I have very little = backgorund in mathematics of cryptography but have grasped some concepts = and can try my hand but might need more time. - I was preparing a document on fesibility and necessity of upgrading = hash function in HIP and the tradeoffs if we dont do it. - Any other details you would like me to include in the analysis. Thanks Abhijit ------=_NextPart_000_0013_01C651D1.8EBCF240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I was working on the Bellovin-Rescorla = analysis. I=20 was assigned the task by Andrei Gurtov. i needed some inputs regarding = details=20 required:
  
- Do we need a mathematical analysis? If = yes, I=20 have very little backgorund in mathematics of cryptography but have = grasped=20 some concepts and can try my hand but might need more time.
- I = was=20 preparing a document on fesibility and necessity of upgrading  hash = function in HIP and From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gg-7X; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNrbJ-0000KU-E5 for hipsec@ietf.org; Mon, 27 Mar 2006 08:17:41 -0500 Received: from [203.197.196.2] (helo=mail2.iitk.ac.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNrbH-0005no-JE for hipsec@ietf.org; Mon, 27 Mar 2006 08:17:41 -0500 Received: from antivirus.cc.iitk.ac.in (antivirus.cc.iitk.ac.in [172.31.1.102]) by mail2.iitk.ac.in (8.12.8/8.12.8) with ESMTP id k2RDLgmm020113; Mon, 27 Mar 2006 18:51:43 +0530 Received: from dilbert ([172.26.78.65]) by antivirus.cc.iitk.ac.in (8.13.1/8.13.1) with SMTP id k2RDHU4M023703; Mon, 27 Mar 2006 18:47:30 +0530 Message-ID: <001a01c651a3$7819e580$414e1aac@dilbert> From: "Bagri" To: Date: Mon, 27 Mar 2006 19:06:31 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Subject: [Hipsec] Bellovin-Rescorla analysis X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0203030242==" Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0203030242== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C651D1.8EBCF240" This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C651D1.8EBCF240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I was working on the Bellovin-Rescorla analysis. I was assigned the task = by Andrei Gurtov. i needed some inputs regarding details required: =20 - Do we need a mathematical analysis? If yes, I have very little = backgorund in mathematics of cryptography but have grasped some concepts = and can try my hand but might need more time. - I was preparing a document on fesibility and necessity of upgrading = hash function in HIP and the tradeoffs if we dont do it. - Any other details you would like me to include in the analysis. Thanks Abhijit ------=_NextPart_000_0013_01C651D1.8EBCF240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I was working on the Bellovin-Rescorla = analysis. I=20 was assigned the task by Andrei Gurtov. i needed some inputs regarding = details=20 required:
  
- Do we need a mathematical analysis? If = yes, I=20 have very little backgorund in mathematics of cryptography but have = grasped=20 some concepts and can try my hand but might need more time.
- I = was=20 preparing a document on fesibility and necessity of upgrading  hash = function in HIP and From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gg-7X; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNrbJ-0000KU-E5 for hipsec@ietf.org; Mon, 27 Mar 2006 08:17:41 -0500 Received: from [203.197.196.2] (helo=mail2.iitk.ac.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNrbH-0005no-JE for hipsec@ietf.org; Mon, 27 Mar 2006 08:17:41 -0500 Received: from antivirus.cc.iitk.ac.in (antivirus.cc.iitk.ac.in [172.31.1.102]) by mail2.iitk.ac.in (8.12.8/8.12.8) with ESMTP id k2RDLgmm020113; Mon, 27 Mar 2006 18:51:43 +0530 Received: from dilbert ([172.26.78.65]) by antivirus.cc.iitk.ac.in (8.13.1/8.13.1) with SMTP id k2RDHU4M023703; Mon, 27 Mar 2006 18:47:30 +0530 Message-ID: <001a01c651a3$7819e580$414e1aac@dilbert> From: "Bagri" To: Date: Mon, 27 Mar 2006 19:06:31 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Subject: [Hipsec] Bellovin-Rescorla analysis X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0203030242==" Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0203030242== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C651D1.8EBCF240" This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C651D1.8EBCF240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I was working on the Bellovin-Rescorla analysis. I was assigned the task = by Andrei Gurtov. i needed some inputs regarding details required: =20 - Do we need a mathematical analysis? If yes, I have very little = backgorund in mathematics of cryptography but have grasped some concepts = and can try my hand but might need more time. - I was preparing a document on fesibility and necessity of upgrading = hash function in HIP and the tradeoffs if we dont do it. - Any other details you would like me to include in the analysis. Thanks Abhijit ------=_NextPart_000_0013_01C651D1.8EBCF240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I was working on the Bellovin-Rescorla = analysis. I=20 was assigned the task by Andrei Gurtov. i needed some inputs regarding = details=20 required:
  
- Do we need a mathematical analysis? If = yes, I=20 have very little backgorund in mathematics of cryptography but have = grasped=20 some concepts and can try my hand but might need more time.
- I = was=20 preparing a document on fesibility and necessity of upgrading  hash = function in HIP and the tradeoffs if we dont do it.
- Any other = details you=20 would like me to include in the analysis.
 
Thanks
Abhijit

 ------=_NextPart_000_0013_01C651D1.8EBCF240-- --===============0203030242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0203030242==-- From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001h2-Ry; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT39u-0003JQ-0b for hipsec@ietf.org; Mon, 10 Apr 2006 16:38:50 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT39t-0003dG-Gu for hipsec@ietf.org; Mon, 10 Apr 2006 16:38:49 -0400 Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 13:38:49 -0700 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.516.5; Mon, 10 Apr 2006 13:38:48 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 13:38:48 -0700 From: Charlie Kaufman To: Pekka Nikander Date: Mon, 10 Apr 2006 13:38:43 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm Thread-Index: AcZcWLltk2aNO4sRRTCowE14+zQ6cQAhI0nw Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: x-recipient-p2-type: Cc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Apr 2006 20:38:48.0380 (UTC) FILETIME=[C4F937C0:01C65CDE] X-SCL: -1 x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP , Andrew, Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org If what you say in your note is the intent (and I think that's a great thin= g to require), then I think the text needs to be clarified. The language I = was objecting to was in section 5.2.7: There MUST NOT be more than six (6) HIP Suite-IDs in one HIP transform parameter. The limited number of the tradeoffs if we dont do it.
- Any other = details you=20 would like me to include in the analysis.
 
Thanks
Abhijit

 ------=_NextPart_000_0013_01C651D1.8EBCF240-- --===============0203030242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0203030242==-- From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001h2-Ry; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT39u-0003JQ-0b for hipsec@ietf.org; Mon, 10 Apr 2006 16:38:50 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT39t-0003dG-Gu for hipsec@ietf.org; Mon, 10 Apr 2006 16:38:49 -0400 Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 13:38:49 -0700 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.516.5; Mon, 10 Apr 2006 13:38:48 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 13:38:48 -0700 From: Charlie Kaufman To: Pekka Nikander Date: Mon, 10 Apr 2006 13:38:43 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm Thread-Index: AcZcWLltk2aNO4sRRTCowE14+zQ6cQAhI0nw Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: x-recipient-p2-type: Cc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Apr 2006 20:38:48.0380 (UTC) FILETIME=[C4F937C0:01C65CDE] X-SCL: -1 x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP , Andrew, Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org If what you say in your note is the intent (and I think that's a great thin= g to require), then I think the text needs to be clarified. The language I = was objecting to was in section 5.2.7: There MUST NOT be more than six (6) HIP Suite-IDs in one HIP transform parameter. The limited number of the tradeoffs if we dont do it.
- Any other = details you=20 would like me to include in the analysis.
 
Thanks
Abhijit

 ------=_NextPart_000_0013_01C651D1.8EBCF240-- --===============0203030242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0203030242==-- From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001h2-Ry; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT39u-0003JQ-0b for hipsec@ietf.org; Mon, 10 Apr 2006 16:38:50 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT39t-0003dG-Gu for hipsec@ietf.org; Mon, 10 Apr 2006 16:38:49 -0400 Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 13:38:49 -0700 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.516.5; Mon, 10 Apr 2006 13:38:48 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 13:38:48 -0700 From: Charlie Kaufman To: Pekka Nikander Date: Mon, 10 Apr 2006 13:38:43 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm Thread-Index: AcZcWLltk2aNO4sRRTCowE14+zQ6cQAhI0nw Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: x-recipient-p2-type: Cc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Apr 2006 20:38:48.0380 (UTC) FILETIME=[C4F937C0:01C65CDE] X-SCL: -1 x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP , Andrew, Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org If what you say in your note is the intent (and I think that's a great thin= g to require), then I think the text needs to be clarified. The language I = was objecting to was in section 5.2.7: There MUST NOT be more than six (6) HIP Suite-IDs in one HIP transform parameter. The limited number of the tradeoffs if we dont do it.
- Any other = details you=20 would like me to include in the analysis.
 
Thanks
Abhijit

 ------=_NextPart_000_0013_01C651D1.8EBCF240-- --===============0203030242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0203030242==-- From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001h2-Ry; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT39u-0003JQ-0b for hipsec@ietf.org; Mon, 10 Apr 2006 16:38:50 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT39t-0003dG-Gu for hipsec@ietf.org; Mon, 10 Apr 2006 16:38:49 -0400 Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 13:38:49 -0700 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.516.5; Mon, 10 Apr 2006 13:38:48 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 13:38:48 -0700 From: Charlie Kaufman To: Pekka Nikander Date: Mon, 10 Apr 2006 13:38:43 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm Thread-Index: AcZcWLltk2aNO4sRRTCowE14+zQ6cQAhI0nw Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: x-recipient-p2-type: Cc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Apr 2006 20:38:48.0380 (UTC) FILETIME=[C4F937C0:01C65CDE] X-SCL: -1 x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP , Andrew, Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org If what you say in your note is the intent (and I think that's a great thin= g to require), then I think the text needs to be clarified. The language I = was objecting to was in section 5.2.7: There MUST NOT be more than six (6) HIP Suite-IDs in one HIP transform parameter. The limited number of the tradeoffs if we dont do it.
- Any other = details you=20 would like me to include in the analysis.
 
Thanks
Abhijit

 ------=_NextPart_000_0013_01C651D1.8EBCF240-- --===============0203030242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0203030242==-- From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001h2-Ry; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT39u-0003JQ-0b for hipsec@ietf.org; Mon, 10 Apr 2006 16:38:50 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT39t-0003dG-Gu for hipsec@ietf.org; Mon, 10 Apr 2006 16:38:49 -0400 Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 13:38:49 -0700 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.516.5; Mon, 10 Apr 2006 13:38:48 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 13:38:48 -0700 From: Charlie Kaufman To: Pekka Nikander Date: Mon, 10 Apr 2006 13:38:43 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm Thread-Index: AcZcWLltk2aNO4sRRTCowE14+zQ6cQAhI0nw Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: x-recipient-p2-type: Cc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Apr 2006 20:38:48.0380 (UTC) FILETIME=[C4F937C0:01C65CDE] X-SCL: -1 x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP , Andrew, Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org If what you say in your note is the intent (and I think that's a great thin= g to require), then I think the text needs to be clarified. The language I = was objecting to was in section 5.2.7: There MUST NOT be more than six (6) HIP Suite-IDs in one HIP transform parameter. The limited number of the tradeoffs if we dont do it.
- Any other = details you=20 would like me to include in the analysis.
 
Thanks
Abhijit

 ------=_NextPart_000_0013_01C651D1.8EBCF240-- --===============0203030242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0203030242==-- From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001h2-Ry; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT39u-0003JQ-0b for hipsec@ietf.org; Mon, 10 Apr 2006 16:38:50 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT39t-0003dG-Gu for hipsec@ietf.org; Mon, 10 Apr 2006 16:38:49 -0400 Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 13:38:49 -0700 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.516.5; Mon, 10 Apr 2006 13:38:48 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 13:38:48 -0700 From: Charlie Kaufman To: Pekka Nikander Date: Mon, 10 Apr 2006 13:38:43 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm Thread-Index: AcZcWLltk2aNO4sRRTCowE14+zQ6cQAhI0nw Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: x-recipient-p2-type: Cc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Apr 2006 20:38:48.0380 (UTC) FILETIME=[C4F937C0:01C65CDE] X-SCL: -1 x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP , Andrew, Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org If what you say in your note is the intent (and I think that's a great thin= g to require), then I think the text needs to be clarified. The language I = was objecting to was in section 5.2.7: There MUST NOT be more than six (6) HIP Suite-IDs in one HIP transform parameter. The limited number of transforms sets the maximum size of HIP_TRANSFORM parameter. The HIP_TRANSFORM parameter MUST contain at least one of the mandatory Suite-IDs. This implies that the HIP_TRANSFORM item is mal-formed if it does not propo= se one of the mandatory Suite-IDs, which is much stronger than saying that = they must be present "in the default configuration". So it sounds like you and I agree. Is there anyone else out there who wants= to advocate the (current) stronger statement? --Charlie -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Sent: Sunday, April 09, 2006 9:39 PM To: Charlie Kaufman Cc: HIP; Petri Jokela; Andrew McGregor; Petri Jokela Subject: Re: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mand= atory algorithm Charlie, The crux of this issue seems to be that (IIRC) we'd like to mandate/ recommend that the default configuration is one of the following: 1. Offer HMAC-SHA1-AES128CBC as the last resort cipher suite, _or_ 2. Offer HMAC-SHA1-NULL as the last resort cipher suite That is, by default, one of the above MUST be offered. Now, is there something that you see problematic with such a requirement? Maybe that the text is not clear enough in saying that the they are just the mandatory defaults, defined in order to ensure interoperability? If not, then I think we just need to clarify the text. --Pekka On Apr 8, 2006, at 9:49, Charlie Kaufman wrote: > I apologize that my mailer can't auto-generate the >> indentations > and at the moment I lack the patience to do it myself. > > I agree with Pekka that it's important that there could be a legal > implementation that did not offer encryption, so if you're going to > go down this path some Null scheme has to be mandatory to implement. > > But I still object to picking those algorithms as mandatory to > offer. While it guarantees interoperability between any two > compliant implementations (which is good), it comes at a cost of > disallowing *configurations* that only want to support some > stronger hash or that don't want to accept NULL encryption. I don't > know whether an RFC can say anything about the mandatory *default* > configuration, but I believe that's what you're really trying to > get at. > > --Charlie > > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Friday, April 07, 2006 12:40 AM > To: HIP > Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman > Subject: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a > mandatory algorithm > >>>>> There is mandatory support for ESP with HMAC-SHA1 and either >>>>> Null or AES128CBC encryption. This is mandatory not just in the >>>>> implementation but also in the configuration. (i.e., as written, >>>>> the spec says that one of those two suites must be offered in >>>>> every negotiation). >>> >>> The reason for this was that we would have something common >>> between all nodes. >> >> But Null should not be mandatory to offer. AES128CBC would do as a >> mandatory-to-offer. > > I don't understand this comment. Maybe the text is unclear (Section > 5.2.7 I think), but AFAICS it just requires that the responder > includes _at_least_ either HMAC-SHA1-NULL or HMAC-SHA1-AES128CBC. > Nothing prevents it from including both and perhaps others. > > If you implement HMAC-SHA1-AES128CBC, it is trivial to implement HMAC- > SHA1-NULL. > > What is wrong with this? To me this approach seems to be fine with > me; not all connections require encryption. > > --Pekka > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gb-2K; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM57B-0001aC-1x for hipsec@ietf.org; Wed, 22 Mar 2006 10:19:13 -0500 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM579-0003QF-IQ for hipsec@ietf.org; Wed, 22 Mar 2006 10:19:13 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k2MFJ75e002864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Mar 2006 17:19:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k2MFJ5Eg020825; Wed, 22 Mar 2006 17:19:05 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17441.27369.815262.312383@fireball.acr.fi> Date: Wed, 22 Mar 2006 17:19:05 +0200 From: Tero Kivinen To: "Henderson, Thomas R" Subject: [Hipsec] BEET vs. tunnel/HCoIPsec In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 6 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Henderson, Thomas R writes: > The possible advantages of BEET over HCoIPsec might be: > - BEET seems to have (mostly) worked out how to handle different IP > address families in inner and outer headers, whereas I don't see that > capability in IPsec tunnel mode. IPsec tunnel mode can have different IP address families in inner and outer headers. As we simply add new IP-header in the tunnel mode it can be in any address family. With IKEv2 you can even create tunnel mode SA using for example IPv4 as outer IP family, and IP packets inside the tunnel could be either IPv4 and IPv6. -- kivinen@safenet-inc.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gq-L7; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS7GR-0000bm-T6 for hipsec@ietf.org; Sat, 08 Apr 2006 02:49:43 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS7GR-0007uX-FB for hipsec@ietf.org; Sat, 08 Apr 2006 02:49:43 -0400 Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 23:49:42 -0700 Received: from df-hub-02.exchange.corp.microsoft.com (157.54.70.52) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.516.4; Fri, 7 Apr 2006 23:49:31 -0700 Received: from df-beagle-msg.exchange.corp.microsoft.com ([157.54.69.136]) by df-hub-02.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 23:49:32 -0700 From: Charlie Kaufman To: Pekka Nikander , HIP Date: Fri, 7 Apr 2006 23:13 -0500 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM579-0003QF-IQ for hipsec@ietf.org; Wed, 22 Mar 2006 10:19:13 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k2MFJ75e002864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Mar 2006 17:19:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k2MFJ5Eg020825; Wed, 22 Mar 2006 17:19:05 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17441.27369.815262.312383@fireball.acr.fi> Date: Wed, 22 Mar 2006 17:19:05 +0200 From: Tero Kivinen To: "Henderson, Thomas R" Subject: [Hipsec] BEET vs. tunnel/HCoIPsec In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 6 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Henderson, Thomas R writes: > The possible advantages of BEET over HCoIPsec might be: > - BEET seems to have (mostly) worked out how to handle different IP > address families in inner and outer headers, whereas I don't see that > capability in IPsec tunnel mode. IPsec tunnel mode can have different IP address families in inner and outer headers. As we simply add new IP-header in the tunnel mode it can be in any address family. With IKEv2 you can even create tunnel mode SA using for example IPv4 as outer IP family, and IP packets inside the tunnel could be either IPv4 and IPv6. -- kivinen@safenet-inc.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gq-L7; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS7GR-0000bm-T6 for hipsec@ietf.org; Sat, 08 Apr 2006 02:49:43 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS7GR-0007uX-FB for hipsec@ietf.org; Sat, 08 Apr 2006 02:49:43 -0400 Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 23:49:42 -0700 Received: from df-hub-02.exchange.corp.microsoft.com (157.54.70.52) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.516.4; Fri, 7 Apr 2006 23:49:31 -0700 Received: from df-beagle-msg.exchange.corp.microsoft.com ([157.54.69.136]) by df-hub-02.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 23:49:32 -0700 From: Charlie Kaufman To: Pekka Nikander , HIP Date: Fri, 7 Apr 2006 23:13 -0500 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM579-0003QF-IQ for hipsec@ietf.org; Wed, 22 Mar 2006 10:19:13 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k2MFJ75e002864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Mar 2006 17:19:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k2MFJ5Eg020825; Wed, 22 Mar 2006 17:19:05 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17441.27369.815262.312383@fireball.acr.fi> Date: Wed, 22 Mar 2006 17:19:05 +0200 From: Tero Kivinen To: "Henderson, Thomas R" Subject: [Hipsec] BEET vs. tunnel/HCoIPsec In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 6 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Henderson, Thomas R writes: > The possible advantages of BEET over HCoIPsec might be: > - BEET seems to have (mostly) worked out how to handle different IP > address families in inner and outer headers, whereas I don't see that > capability in IPsec tunnel mode. IPsec tunnel mode can have different IP address families in inner and outer headers. As we simply add new IP-header in the tunnel mode it can be in any address family. With IKEv2 you can even create tunnel mode SA using for example IPv4 as outer IP family, and IP packets inside the tunnel could be either IPv4 and IPv6. -- kivinen@safenet-inc.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gq-L7; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS7GR-0000bm-T6 for hipsec@ietf.org; Sat, 08 Apr 2006 02:49:43 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS7GR-0007uX-FB for hipsec@ietf.org; Sat, 08 Apr 2006 02:49:43 -0400 Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 23:49:42 -0700 Received: from df-hub-02.exchange.corp.microsoft.com (157.54.70.52) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.516.4; Fri, 7 Apr 2006 23:49:31 -0700 Received: from df-beagle-msg.exchange.corp.microsoft.com ([157.54.69.136]) by df-hub-02.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 23:49:32 -0700 From: Charlie Kaufman To: Pekka Nikander , HIP Date: Fri, 7 Apr 2006 23:13 -0500 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM579-0003QF-IQ for hipsec@ietf.org; Wed, 22 Mar 2006 10:19:13 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k2MFJ75e002864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Mar 2006 17:19:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k2MFJ5Eg020825; Wed, 22 Mar 2006 17:19:05 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17441.27369.815262.312383@fireball.acr.fi> Date: Wed, 22 Mar 2006 17:19:05 +0200 From: Tero Kivinen To: "Henderson, Thomas R" Subject: [Hipsec] BEET vs. tunnel/HCoIPsec In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 6 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Henderson, Thomas R writes: > The possible advantages of BEET over HCoIPsec might be: > - BEET seems to have (mostly) worked out how to handle different IP > address families in inner and outer headers, whereas I don't see that > capability in IPsec tunnel mode. IPsec tunnel mode can have different IP address families in inner and outer headers. As we simply add new IP-header in the tunnel mode it can be in any address family. With IKEv2 you can even create tunnel mode SA using for example IPv4 as outer IP family, and IP packets inside the tunnel could be either IPv4 and IPv6. -- kivinen@safenet-inc.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gq-L7; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS7GR-0000bm-T6 for hipsec@ietf.org; Sat, 08 Apr 2006 02:49:43 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS7GR-0007uX-FB for hipsec@ietf.org; Sat, 08 Apr 2006 02:49:43 -0400 Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 23:49:42 -0700 Received: from df-hub-02.exchange.corp.microsoft.com (157.54.70.52) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.516.4; Fri, 7 Apr 2006 23:49:31 -0700 Received: from df-beagle-msg.exchange.corp.microsoft.com ([157.54.69.136]) by df-hub-02.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 23:49:32 -0700 From: Charlie Kaufman To: Pekka Nikander , HIP Date: Fri, 7 Apr 2006 23:13 -0500 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM579-0003QF-IQ for hipsec@ietf.org; Wed, 22 Mar 2006 10:19:13 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k2MFJ75e002864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Mar 2006 17:19:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k2MFJ5Eg020825; Wed, 22 Mar 2006 17:19:05 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17441.27369.815262.312383@fireball.acr.fi> Date: Wed, 22 Mar 2006 17:19:05 +0200 From: Tero Kivinen To: "Henderson, Thomas R" Subject: [Hipsec] BEET vs. tunnel/HCoIPsec In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 6 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Henderson, Thomas R writes: > The possible advantages of BEET over HCoIPsec might be: > - BEET seems to have (mostly) worked out how to handle different IP > address families in inner and outer headers, whereas I don't see that > capability in IPsec tunnel mode. IPsec tunnel mode can have different IP address families in inner and outer headers. As we simply add new IP-header in the tunnel mode it can be in any address family. With IKEv2 you can even create tunnel mode SA using for example IPv4 as outer IP family, and IP packets inside the tunnel could be either IPv4 and IPv6. -- kivinen@safenet-inc.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gq-L7; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS7GR-0000bm-T6 for hipsec@ietf.org; Sat, 08 Apr 2006 02:49:43 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS7GR-0007uX-FB for hipsec@ietf.org; Sat, 08 Apr 2006 02:49:43 -0400 Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 23:49:42 -0700 Received: from df-hub-02.exchange.corp.microsoft.com (157.54.70.52) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.516.4; Fri, 7 Apr 2006 23:49:31 -0700 Received: from df-beagle-msg.exchange.corp.microsoft.com ([157.54.69.136]) by df-hub-02.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 23:49:32 -0700 From: Charlie Kaufman To: Pekka Nikander , HIP Date: Fri, 7 Apr 2006 23:13 -0500 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM579-0003QF-IQ for hipsec@ietf.org; Wed, 22 Mar 2006 10:19:13 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id k2MFJ75e002864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Mar 2006 17:19:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id k2MFJ5Eg020825; Wed, 22 Mar 2006 17:19:05 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17441.27369.815262.312383@fireball.acr.fi> Date: Wed, 22 Mar 2006 17:19:05 +0200 From: Tero Kivinen To: "Henderson, Thomas R" Subject: [Hipsec] BEET vs. tunnel/HCoIPsec In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D01A2EEE7@XCH-NW-5V1.nw.nos.boeing.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 6 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Henderson, Thomas R writes: > The possible advantages of BEET over HCoIPsec might be: > - BEET seems to have (mostly) worked out how to handle different IP > address families in inner and outer headers, whereas I don't see that > capability in IPsec tunnel mode. IPsec tunnel mode can have different IP address families in inner and outer headers. As we simply add new IP-header in the tunnel mode it can be in any address family. With IKEv2 you can even create tunnel mode SA using for example IPv4 as outer IP family, and IP packets inside the tunnel could be either IPv4 and IPv6. -- kivinen@safenet-inc.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gq-L7; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FS7GR-0000bm-T6 for hipsec@ietf.org; Sat, 08 Apr 2006 02:49:43 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FS7GR-0007uX-FB for hipsec@ietf.org; Sat, 08 Apr 2006 02:49:43 -0400 Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 23:49:42 -0700 Received: from df-hub-02.exchange.corp.microsoft.com (157.54.70.52) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.516.4; Fri, 7 Apr 2006 23:49:31 -0700 Received: from df-beagle-msg.exchange.corp.microsoft.com ([157.54.69.136]) by df-hub-02.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 23:49:32 -0700 From: Charlie Kaufman To: Pekka Nikander , HIP Date: Fri, 7 Apr 2006 23:49:30 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm Thread-Index: AcZaJ7AFx42mpXvdSvCnfE2iYPM0+wAr1HGQ Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RulesExecuted: True X-OriginalArrivalTime: 08 Apr 2006 06:49:32.0151 (UTC) FILETIME=[971FB070:01C65AD8] x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org I apologize that my mailer can't auto-generate the >> indentations and at t= he moment I lack the patience to do it myself. I agree with Pekka that it's important that there could be a legal implemen= tation that did not offer encryption, so if you're going to go down this pa= th some Null scheme has to be mandatory to implement. But I still object to picking those algorithms as mandatory to offer. While= it guarantees interoperability between any two compliant implementations (= which is good), it comes at a cost of disallowing *configurations* that onl= y want to support some stronger hash or that don't want to accept NULL encr= yption. I don't know whether an RFC can say anything about the mandatory *d= efault* configuration, but I believe that's what you're really trying to ge= t at. --Charlie -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Sent: Friday, April 07, 2006 12:40 AM To: HIP Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman Subject: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandator= y algorithm >>>> There is mandatory support for ESP with HMAC-SHA1 and either >>>> Null or AES128CBC encryption. This is mandatory not just in the >>>> implementation but also in the configuration. (i.e., as written, >>>> the spec says that one of those two suites must be offered in >>>> every negotiation). >> >> The reason for this was that we would have something common >> between all nodes. > > But Null should not be mandatory to offer. AES128CBC would do as a > mandatory-to-offer. I don't understand this comment. Maybe the text is unclear (Section 5.2.7 I think), but AFAICS it just requires that the responder includes _at_least_ either HMAC-SHA1-NULL or HMAC-SHA1-AES128CBC. Nothing prevents it from including both and perhaps others. If you implement HMAC-SHA1-AES128CBC, it is trivial to implement HMAC- SHA1-NULL. What is wrong with this? To me this approach seems to be fine with me; not all connections require encryption. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gl-Eh; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRvoP-0001mG-K549:30 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm Thread-Index: AcZaJ7AFx42mpXvdSvCnfE2iYPM0+wAr1HGQ Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RulesExecuted: True X-OriginalArrivalTime: 08 Apr 2006 06:49:32.0151 (UTC) FILETIME=[971FB070:01C65AD8] x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org I apologize that my mailer can't auto-generate the >> indentations and at t= he moment I lack the patience to do it myself. I agree with Pekka that it's important that there could be a legal implemen= tation that did not offer encryption, so if you're going to go down this pa= th some Null scheme has to be mandatory to implement. But I still object to picking those algorithms as mandatory to offer. While= it guarantees interoperability between any two compliant implementations (= which is good), it comes at a cost of disallowing *configurations* that onl= y want to support some stronger hash or that don't want to accept NULL encr= yption. I don't know whether an RFC can say anything about the mandatory *d= efault* configuration, but I believe that's what you're really trying to ge= t at. --Charlie -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Sent: Friday, April 07, 2006 12:40 AM To: HIP Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman Subject: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandator= y algorithm >>>> There is mandatory support for ESP with HMAC-SHA1 and either >>>> Null or AES128CBC encryption. This is mandatory not just in the >>>> implementation but also in the configuration. (i.e., as written, >>>> the spec says that one of those two suites must be offered in >>>> every negotiation). >> >> The reason for this was that we would have something common >> between all nodes. > > But Null should not be mandatory to offer. AES128CBC would do as a > mandatory-to-offer. I don't understand this comment. Maybe the text is unclear (Section 5.2.7 I think), but AFAICS it just requires that the responder includes _at_least_ either HMAC-SHA1-NULL or HMAC-SHA1-AES128CBC. Nothing prevents it from including both and perhaps others. If you implement HMAC-SHA1-AES128CBC, it is trivial to implement HMAC- SHA1-NULL. What is wrong with this? To me this approach seems to be fine with me; not all connections require encryption. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gl-Eh; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRvoP-0001mG-K549:30 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm Thread-Index: AcZaJ7AFx42mpXvdSvCnfE2iYPM0+wAr1HGQ Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RulesExecuted: True X-OriginalArrivalTime: 08 Apr 2006 06:49:32.0151 (UTC) FILETIME=[971FB070:01C65AD8] x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org I apologize that my mailer can't auto-generate the >> indentations and at t= he moment I lack the patience to do it myself. I agree with Pekka that it's important that there could be a legal implemen= tation that did not offer encryption, so if you're going to go down this pa= th some Null scheme has to be mandatory to implement. But I still object to picking those algorithms as mandatory to offer. While= it guarantees interoperability between any two compliant implementations (= which is good), it comes at a cost of disallowing *configurations* that onl= y want to support some stronger hash or that don't want to accept NULL encr= yption. I don't know whether an RFC can say anything about the mandatory *d= efault* configuration, but I believe that's what you're really trying to ge= t at. --Charlie -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Sent: Friday, April 07, 2006 12:40 AM To: HIP Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman Subject: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandator= y algorithm >>>> There is mandatory support for ESP with HMAC-SHA1 and either >>>> Null or AES128CBC encryption. This is mandatory not just in the >>>> implementation but also in the configuration. (i.e., as written, >>>> the spec says that one of those two suites must be offered in >>>> every negotiation). >> >> The reason for this was that we would have something common >> between all nodes. > > But Null should not be mandatory to offer. AES128CBC would do as a > mandatory-to-offer. I don't understand this comment. Maybe the text is unclear (Section 5.2.7 I think), but AFAICS it just requires that the responder includes _at_least_ either HMAC-SHA1-NULL or HMAC-SHA1-AES128CBC. Nothing prevents it from including both and perhaps others. If you implement HMAC-SHA1-AES128CBC, it is trivial to implement HMAC- SHA1-NULL. What is wrong with this? To me this approach seems to be fine with me; not all connections require encryption. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gl-Eh; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRvoP-0001mG-K549:30 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm Thread-Index: AcZaJ7AFx42mpXvdSvCnfE2iYPM0+wAr1HGQ Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RulesExecuted: True X-OriginalArrivalTime: 08 Apr 2006 06:49:32.0151 (UTC) FILETIME=[971FB070:01C65AD8] x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org I apologize that my mailer can't auto-generate the >> indentations and at t= he moment I lack the patience to do it myself. I agree with Pekka that it's important that there could be a legal implemen= tation that did not offer encryption, so if you're going to go down this pa= th some Null scheme has to be mandatory to implement. But I still object to picking those algorithms as mandatory to offer. While= it guarantees interoperability between any two compliant implementations (= which is good), it comes at a cost of disallowing *configurations* that onl= y want to support some stronger hash or that don't want to accept NULL encr= yption. I don't know whether an RFC can say anything about the mandatory *d= efault* configuration, but I believe that's what you're really trying to ge= t at. --Charlie -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Sent: Friday, April 07, 2006 12:40 AM To: HIP Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman Subject: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandator= y algorithm >>>> There is mandatory support for ESP with HMAC-SHA1 and either >>>> Null or AES128CBC encryption. This is mandatory not just in the >>>> implementation but also in the configuration. (i.e., as written, >>>> the spec says that one of those two suites must be offered in >>>> every negotiation). >> >> The reason for this was that we would have something common >> between all nodes. > > But Null should not be mandatory to offer. AES128CBC would do as a > mandatory-to-offer. I don't understand this comment. Maybe the text is unclear (Section 5.2.7 I think), but AFAICS it just requires that the responder includes _at_least_ either HMAC-SHA1-NULL or HMAC-SHA1-AES128CBC. Nothing prevents it from including both and perhaps others. If you implement HMAC-SHA1-AES128CBC, it is trivial to implement HMAC- SHA1-NULL. What is wrong with this? To me this approach seems to be fine with me; not all connections require encryption. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gl-Eh; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRvoP-0001mG-K549:30 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm Thread-Index: AcZaJ7AFx42mpXvdSvCnfE2iYPM0+wAr1HGQ Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RulesExecuted: True X-OriginalArrivalTime: 08 Apr 2006 06:49:32.0151 (UTC) FILETIME=[971FB070:01C65AD8] x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org I apologize that my mailer can't auto-generate the >> indentations and at t= he moment I lack the patience to do it myself. I agree with Pekka that it's important that there could be a legal implemen= tation that did not offer encryption, so if you're going to go down this pa= th some Null scheme has to be mandatory to implement. But I still object to picking those algorithms as mandatory to offer. While= it guarantees interoperability between any two compliant implementations (= which is good), it comes at a cost of disallowing *configurations* that onl= y want to support some stronger hash or that don't want to accept NULL encr= yption. I don't know whether an RFC can say anything about the mandatory *d= efault* configuration, but I believe that's what you're really trying to ge= t at. --Charlie -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Sent: Friday, April 07, 2006 12:40 AM To: HIP Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman Subject: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandator= y algorithm >>>> There is mandatory support for ESP with HMAC-SHA1 and either >>>> Null or AES128CBC encryption. This is mandatory not just in the >>>> implementation but also in the configuration. (i.e., as written, >>>> the spec says that one of those two suites must be offered in >>>> every negotiation). >> >> The reason for this was that we would have something common >> between all nodes. > > But Null should not be mandatory to offer. AES128CBC would do as a > mandatory-to-offer. I don't understand this comment. Maybe the text is unclear (Section 5.2.7 I think), but AFAICS it just requires that the responder includes _at_least_ either HMAC-SHA1-NULL or HMAC-SHA1-AES128CBC. Nothing prevents it from including both and perhaps others. If you implement HMAC-SHA1-AES128CBC, it is trivial to implement HMAC- SHA1-NULL. What is wrong with this? To me this approach seems to be fine with me; not all connections require encryption. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gl-Eh; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRvoP-0001mG-K549:30 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm Thread-Index: AcZaJ7AFx42mpXvdSvCnfE2iYPM0+wAr1HGQ Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RulesExecuted: True X-OriginalArrivalTime: 08 Apr 2006 06:49:32.0151 (UTC) FILETIME=[971FB070:01C65AD8] x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandatory algorithm X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org I apologize that my mailer can't auto-generate the >> indentations and at t= he moment I lack the patience to do it myself. I agree with Pekka that it's important that there could be a legal implemen= tation that did not offer encryption, so if you're going to go down this pa= th some Null scheme has to be mandatory to implement. But I still object to picking those algorithms as mandatory to offer. While= it guarantees interoperability between any two compliant implementations (= which is good), it comes at a cost of disallowing *configurations* that onl= y want to support some stronger hash or that don't want to accept NULL encr= yption. I don't know whether an RFC can say anything about the mandatory *d= efault* configuration, but I believe that's what you're really trying to ge= t at. --Charlie -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Sent: Friday, April 07, 2006 12:40 AM To: HIP Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman Subject: Belovin-Rescorla analysis - HIP: NULL ESP encryption as a mandator= y algorithm >>>> There is mandatory support for ESP with HMAC-SHA1 and either >>>> Null or AES128CBC encryption. This is mandatory not just in the >>>> implementation but also in the configuration. (i.e., as written, >>>> the spec says that one of those two suites must be offered in >>>> every negotiation). >> >> The reason for this was that we would have something common >> between all nodes. > > But Null should not be mandatory to offer. AES128CBC would do as a > mandatory-to-offer. I don't understand this comment. Maybe the text is unclear (Section 5.2.7 I think), but AFAICS it just requires that the responder includes _at_least_ either HMAC-SHA1-NULL or HMAC-SHA1-AES128CBC. Nothing prevents it from including both and perhaps others. If you implement HMAC-SHA1-AES128CBC, it is trivial to implement HMAC- SHA1-NULL. What is wrong with this? To me this approach seems to be fine with me; not all connections require encryption. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudm-0001gl-Eh; Mon, 24 Apr 2006 02:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRvoP-0001mG-K5 for hipsec@ietf.org; Fri, 07 Apr 2006 14:36:01 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRvoN-0000f0-5C for hipsec@ietf.org; Fri, 07 Apr 2006 14:36:01 -0400 Received: from df-gwy-06.exchange.corp.microsoft.com ([157.54.63.150]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 11:35:58 -0700 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-06.exchange.corp.microsoft.com (157.54.63.150) with Microsoft SMTP Server id 8.0.516.4; Fri, 7 Apr 2006 11:35:57 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 11:35:57 -0700 From: Charlie Kaufman To: Pekka Nikander , HIP Date: Fri, 7 Apr 2006 11:35:56 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: Opportunistic HIP Thread-Index: AcZaJ9TTa4rgMhiRRzSi9KQ6nEKHlgASHyvQ Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Apr 2006 18:35:57.0920 (UTC) FILETIME=[1C990600:01C65A72] X-SCL: -1 x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: Opportunistic HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Noting explicitly in the document that it does not define how to do opportu= nistic HIP would be reasonable. You could also comment on why all of the ob= vious solutions have serious problems. I would expect a real implementation would include a "cache" of addresses w= ith which HIP negotiations have succeeded and failed recently, and would pr= obably treat a response packet differently from one where it is initiating = the connection. It would probably be unacceptable to have the opportunistic= negotiation to introduce a long real time delay in connection setup with e= very non-HIP enabled node, but it might be acceptable to have such a delay = in the case where that node "recently" successfully negotiated HIP. The low order 64 bits of the address might also provide heuristic clues as = to whether the node is HIP-capable. --Charlie -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Sent: Friday, April 07, 2006 12:39 AM To: HIP Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman Subject: Belovin-Rescorla analysis - HIP: Opportunistic HIP >>>> When doing "opportunistic" HIP negotiation, when node A wants to >>>> send to node B and doesn't know whether node B supports HIP, it has >>>> three choices: 1) It can hold the first packet to B while it tries >>>> to negotiate HIP, and if that fails send the first packet >>>> unprotected; 2) It can forward the first packet unprotected and in >>>> parallel try to negotiate HIP. If the negotiation succeeds, it can >>>> start using the ESP for hipsec@ietf.org; Fri, 07 Apr 2006 14:36:01 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRvoN-0000f0-5C for hipsec@ietf.org; Fri, 07 Apr 2006 14:36:01 -0400 Received: from df-gwy-06.exchange.corp.microsoft.com ([157.54.63.150]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 11:35:58 -0700 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-06.exchange.corp.microsoft.com (157.54.63.150) with Microsoft SMTP Server id 8.0.516.4; Fri, 7 Apr 2006 11:35:57 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 11:35:57 -0700 From: Charlie Kaufman To: Pekka Nikander , HIP Date: Fri, 7 Apr 2006 11:35:56 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: Opportunistic HIP Thread-Index: AcZaJ9TTa4rgMhiRRzSi9KQ6nEKHlgASHyvQ Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Apr 2006 18:35:57.0920 (UTC) FILETIME=[1C990600:01C65A72] X-SCL: -1 x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: Opportunistic HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Noting explicitly in the document that it does not define how to do opportu= nistic HIP would be reasonable. You could also comment on why all of the ob= vious solutions have serious problems. I would expect a real implementation would include a "cache" of addresses w= ith which HIP negotiations have succeeded and failed recently, and would pr= obably treat a response packet differently from one where it is initiating = the connection. It would probably be unacceptable to have the opportunistic= negotiation to introduce a long real time delay in connection setup with e= very non-HIP enabled node, but it might be acceptable to have such a delay = in the case where that node "recently" successfully negotiated HIP. The low order 64 bits of the address might also provide heuristic clues as = to whether the node is HIP-capable. --Charlie -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Sent: Friday, April 07, 2006 12:39 AM To: HIP Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman Subject: Belovin-Rescorla analysis - HIP: Opportunistic HIP >>>> When doing "opportunistic" HIP negotiation, when node A wants to >>>> send to node B and doesn't know whether node B supports HIP, it has >>>> three choices: 1) It can hold the first packet to B while it tries >>>> to negotiate HIP, and if that fails send the first packet >>>> unprotected; 2) It can forward the first packet unprotected and in >>>> parallel try to negotiate HIP. If the negotiation succeeds, it can >>>> start using the ESP for hipsec@ietf.org; Fri, 07 Apr 2006 14:36:01 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRvoN-0000f0-5C for hipsec@ietf.org; Fri, 07 Apr 2006 14:36:01 -0400 Received: from df-gwy-06.exchange.corp.microsoft.com ([157.54.63.150]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 11:35:58 -0700 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-06.exchange.corp.microsoft.com (157.54.63.150) with Microsoft SMTP Server id 8.0.516.4; Fri, 7 Apr 2006 11:35:57 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 11:35:57 -0700 From: Charlie Kaufman To: Pekka Nikander , HIP Date: Fri, 7 Apr 2006 11:35:56 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: Opportunistic HIP Thread-Index: AcZaJ9TTa4rgMhiRRzSi9KQ6nEKHlgASHyvQ Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Apr 2006 18:35:57.0920 (UTC) FILETIME=[1C990600:01C65A72] X-SCL: -1 x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: Opportunistic HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Noting explicitly in the document that it does not define how to do opportu= nistic HIP would be reasonable. You could also comment on why all of the ob= vious solutions have serious problems. I would expect a real implementation would include a "cache" of addresses w= ith which HIP negotiations have succeeded and failed recently, and would pr= obably treat a response packet differently from one where it is initiating = the connection. It would probably be unacceptable to have the opportunistic= negotiation to introduce a long real time delay in connection setup with e= very non-HIP enabled node, but it might be acceptable to have such a delay = in the case where that node "recently" successfully negotiated HIP. The low order 64 bits of the address might also provide heuristic clues as = to whether the node is HIP-capable. --Charlie -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Sent: Friday, April 07, 2006 12:39 AM To: HIP Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman Subject: Belovin-Rescorla analysis - HIP: Opportunistic HIP >>>> When doing "opportunistic" HIP negotiation, when node A wants to >>>> send to node B and doesn't know whether node B supports HIP, it has >>>> three choices: 1) It can hold the first packet to B while it tries >>>> to negotiate HIP, and if that fails send the first packet >>>> unprotected; 2) It can forward the first packet unprotected and in >>>> parallel try to negotiate HIP. If the negotiation succeeds, it can >>>> start using the ESP for hipsec@ietf.org; Fri, 07 Apr 2006 14:36:01 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRvoN-0000f0-5C for hipsec@ietf.org; Fri, 07 Apr 2006 14:36:01 -0400 Received: from df-gwy-06.exchange.corp.microsoft.com ([157.54.63.150]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 11:35:58 -0700 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-06.exchange.corp.microsoft.com (157.54.63.150) with Microsoft SMTP Server id 8.0.516.4; Fri, 7 Apr 2006 11:35:57 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 11:35:57 -0700 From: Charlie Kaufman To: Pekka Nikander , HIP Date: Fri, 7 Apr 2006 11:35:56 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: Opportunistic HIP Thread-Index: AcZaJ9TTa4rgMhiRRzSi9KQ6nEKHlgASHyvQ Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Apr 2006 18:35:57.0920 (UTC) FILETIME=[1C990600:01C65A72] X-SCL: -1 x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: Opportunistic HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Noting explicitly in the document that it does not define how to do opportu= nistic HIP would be reasonable. You could also comment on why all of the ob= vious solutions have serious problems. I would expect a real implementation would include a "cache" of addresses w= ith which HIP negotiations have succeeded and failed recently, and would pr= obably treat a response packet differently from one where it is initiating = the connection. It would probably be unacceptable to have the opportunistic= negotiation to introduce a long real time delay in connection setup with e= very non-HIP enabled node, but it might be acceptable to have such a delay = in the case where that node "recently" successfully negotiated HIP. The low order 64 bits of the address might also provide heuristic clues as = to whether the node is HIP-capable. --Charlie -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Sent: Friday, April 07, 2006 12:39 AM To: HIP Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman Subject: Belovin-Rescorla analysis - HIP: Opportunistic HIP >>>> When doing "opportunistic" HIP negotiation, when node A wants to >>>> send to node B and doesn't know whether node B supports HIP, it has >>>> three choices: 1) It can hold the first packet to B while it tries >>>> to negotiate HIP, and if that fails send the first packet >>>> unprotected; 2) It can forward the first packet unprotected and in >>>> parallel try to negotiate HIP. If the negotiation succeeds, it can >>>> start using the ESP for hipsec@ietf.org; Fri, 07 Apr 2006 14:36:01 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRvoN-0000f0-5C for hipsec@ietf.org; Fri, 07 Apr 2006 14:36:01 -0400 Received: from df-gwy-06.exchange.corp.microsoft.com ([157.54.63.150]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 11:35:58 -0700 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-06.exchange.corp.microsoft.com (157.54.63.150) with Microsoft SMTP Server id 8.0.516.4; Fri, 7 Apr 2006 11:35:57 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 11:35:57 -0700 From: Charlie Kaufman To: Pekka Nikander , HIP Date: Fri, 7 Apr 2006 11:35:56 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: Opportunistic HIP Thread-Index: AcZaJ9TTa4rgMhiRRzSi9KQ6nEKHlgASHyvQ Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Apr 2006 18:35:57.0920 (UTC) FILETIME=[1C990600:01C65A72] X-SCL: -1 x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: Opportunistic HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Noting explicitly in the document that it does not define how to do opportu= nistic HIP would be reasonable. You could also comment on why all of the ob= vious solutions have serious problems. I would expect a real implementation would include a "cache" of addresses w= ith which HIP negotiations have succeeded and failed recently, and would pr= obably treat a response packet differently from one where it is initiating = the connection. It would probably be unacceptable to have the opportunistic= negotiation to introduce a long real time delay in connection setup with e= very non-HIP enabled node, but it might be acceptable to have such a delay = in the case where that node "recently" successfully negotiated HIP. The low order 64 bits of the address might also provide heuristic clues as = to whether the node is HIP-capable. --Charlie -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Sent: Friday, April 07, 2006 12:39 AM To: HIP Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman Subject: Belovin-Rescorla analysis - HIP: Opportunistic HIP >>>> When doing "opportunistic" HIP negotiation, when node A wants to >>>> send to node B and doesn't know whether node B supports HIP, it has >>>> three choices: 1) It can hold the first packet to B while it tries >>>> to negotiate HIP, and if that fails send the first packet >>>> unprotected; 2) It can forward the first packet unprotected and in >>>> parallel try to negotiate HIP. If the negotiation succeeds, it can >>>> start using the ESP for hipsec@ietf.org; Fri, 07 Apr 2006 14:36:01 -0400 Received: from mail4.exchange.microsoft.com ([131.107.1.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRvoN-0000f0-5C for hipsec@ietf.org; Fri, 07 Apr 2006 14:36:01 -0400 Received: from df-gwy-06.exchange.corp.microsoft.com ([157.54.63.150]) by mail4.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 11:35:58 -0700 Received: from df-hub-01.exchange.corp.microsoft.com (157.54.69.171) by df-gwy-06.exchange.corp.microsoft.com (157.54.63.150) with Microsoft SMTP Server id 8.0.516.4; Fri, 7 Apr 2006 11:35:57 -0700 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 11:35:57 -0700 From: Charlie Kaufman To: Pekka Nikander , HIP Date: Fri, 7 Apr 2006 11:35:56 -0700 Thread-Topic: Belovin-Rescorla analysis - HIP: Opportunistic HIP Thread-Index: AcZaJ9TTa4rgMhiRRzSi9KQ6nEKHlgASHyvQ Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Apr 2006 18:35:57.0920 (UTC) FILETIME=[1C990600:01C65A72] X-SCL: -1 x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: Petri Jokela Subject: [Hipsec] RE: Belovin-Rescorla analysis - HIP: Opportunistic HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Noting explicitly in the document that it does not define how to do opportu= nistic HIP would be reasonable. You could also comment on why all of the ob= vious solutions have serious problems. I would expect a real implementation would include a "cache" of addresses w= ith which HIP negotiations have succeeded and failed recently, and would pr= obably treat a response packet differently from one where it is initiating = the connection. It would probably be unacceptable to have the opportunistic= negotiation to introduce a long real time delay in connection setup with e= very non-HIP enabled node, but it might be acceptable to have such a delay = in the case where that node "recently" successfully negotiated HIP. The low order 64 bits of the address might also provide heuristic clues as = to whether the node is HIP-capable. --Charlie -----Original Message----- From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] Sent: Friday, April 07, 2006 12:39 AM To: HIP Cc: Petri Jokela; Andrew McGregor; Petri Jokela; Charlie Kaufman Subject: Belovin-Rescorla analysis - HIP: Opportunistic HIP >>>> When doing "opportunistic" HIP negotiation, when node A wants to >>>> send to node B and doesn't know whether node B supports HIP, it has >>>> three choices: 1) It can hold the first packet to B while it tries >>>> to negotiate HIP, and if that fails send the first packet >>>> unprotected; 2) It can forward the first packet unprotected and in >>>> parallel try to negotiate HIP. If the negotiation succeeds, it can >>>> start using the ESP tunnel; or 3) it can not try to negotiate HIP. >>>> Each of these mechanisms has problems. The spec should offer some >>>> guidance. It's possible this is provided in one of the other HIP >>>> documents. >> >> Maybe a recommendation: >> >> 6.6. Initiating a HIP connection >> >> The host should try to establish an opportunistic mode HIP >> association sending at most I1_RETRIES_MAX I1 packets. If it does not >> receive any R1s, it can try to initiate the connection without HIP >> if local policy allows. > > And use option 1 in the meantime. 2 has many problems, because > migrating a non-HIP connection to HIP is probably hard to implement. I would be tempted to make it explicit that this document does not define h= ow to do opportunistic HIP but simply provides hooks for it, a full definit= ion being expected to be available in some future document. Opinions? --Pekka inions? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudn-0001kL-CW; Mon, 24 Apr 2006 02:33:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW43i-0007l9-SK; Wed, 19 Apr 2006 00:12:54 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW43e-0002Ic-0W; Wed, 19 Apr 2006 00:12:54 -0400 Received: from gihm3.apnic.net (protege.telstra.net [203.50.0.194] (may be forged)) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k3J4CjDH042344; Wed, 19 Apr 2006 14:12:45 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060419140221.02cf0900@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 19 Apr 2006 14:12:36 +1000 To: Julien Laganier , Internet Area From: Geoff Huston In-Reply-To: <200603161624.16174.julien.IETF@laposte.net> References: <200603161624.16174.julien.IETF@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP Subject: [Hipsec] Re: [Int-area] Fwd: I-D ACTION:draft-laganier-ipv6-khi-01.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org At 01:24 AM 17/03/2006, Julien Laganier wrote: >[ Cross-posted to HIP WG and IPv6 WG. ] >[ Please reply _only_ to the INT area. ] > >Folks, > >draft-laganier-ipv6-khi-01.txt has been updated based on feedback >received from IETFers. > >The HIP base specification currently has a hard dependency on this >draft and therefore it would be desirable to have it published as an >RFC as soon as possible, since the HIP base specification is now >quite mature. This draft intent is to make it possible for existing >applications running on a HIP node to use both HIP and IPv6 at the >same time, in the hope that it will foster the HIP experiment. > >Your opinions on moving forward with this draft are more than >welcomed. I provided the following comments to Jari as AD, and he suggested that I forward the comments to the Internet Area mail list. I have read this draft, and have the following comments: 1. I find the following text to be very unclear: "...they are expectedtunnel; or 3) it can not try to negotiate HIP. >>>> Each of these mechanisms has problems. The spec should offer some >>>> guidance. It's possible this is provided in one of the other HIP >>>> documents. >> >> Maybe a recommendation: >> >> 6.6. Initiating a HIP connection >> >> The host should try to establish an opportunistic mode HIP >> association sending at most I1_RETRIES_MAX I1 packets. If it does not >> receive any R1s, it can try to initiate the connection without HIP >> if local policy allows. > > And use option 1 in the meantime. 2 has many problems, because > migrating a non-HIP connection to HIP is probably hard to implement. I would be tempted to make it explicit that this document does not define h= ow to do opportunistic HIP but simply provides hooks for it, a full definit= ion being expected to be available in some future document. Opinions? --Pekka inions? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudn-0001kL-CW; Mon, 24 Apr 2006 02:33:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW43i-0007l9-SK; Wed, 19 Apr 2006 00:12:54 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW43e-0002Ic-0W; Wed, 19 Apr 2006 00:12:54 -0400 Received: from gihm3.apnic.net (protege.telstra.net [203.50.0.194] (may be forged)) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k3J4CjDH042344; Wed, 19 Apr 2006 14:12:45 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060419140221.02cf0900@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 19 Apr 2006 14:12:36 +1000 To: Julien Laganier , Internet Area From: Geoff Huston In-Reply-To: <200603161624.16174.julien.IETF@laposte.net> References: <200603161624.16174.julien.IETF@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP Subject: [Hipsec] Re: [Int-area] Fwd: I-D ACTION:draft-laganier-ipv6-khi-01.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org At 01:24 AM 17/03/2006, Julien Laganier wrote: >[ Cross-posted to HIP WG and IPv6 WG. ] >[ Please reply _only_ to the INT area. ] > >Folks, > >draft-laganier-ipv6-khi-01.txt has been updated based on feedback >received from IETFers. > >The HIP base specification currently has a hard dependency on this >draft and therefore it would be desirable to have it published as an >RFC as soon as possible, since the HIP base specification is now >quite mature. This draft intent is to make it possible for existing >applications running on a HIP node to use both HIP and IPv6 at the >same time, in the hope that it will foster the HIP experiment. > >Your opinions on moving forward with this draft are more than >welcomed. I provided the following comments to Jari as AD, and he suggested that I forward the comments to the Internet Area mail list. I have read this draft, and have the following comments: 1. I find the following text to be very unclear: "...they are expectedtunnel; or 3) it can not try to negotiate HIP. >>>> Each of these mechanisms has problems. The spec should offer some >>>> guidance. It's possible this is provided in one of the other HIP >>>> documents. >> >> Maybe a recommendation: >> >> 6.6. Initiating a HIP connection >> >> The host should try to establish an opportunistic mode HIP >> association sending at most I1_RETRIES_MAX I1 packets. If it does not >> receive any R1s, it can try to initiate the connection without HIP >> if local policy allows. > > And use option 1 in the meantime. 2 has many problems, because > migrating a non-HIP connection to HIP is probably hard to implement. I would be tempted to make it explicit that this document does not define h= ow to do opportunistic HIP but simply provides hooks for it, a full definit= ion being expected to be available in some future document. Opinions? --Pekka inions? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudn-0001kL-CW; Mon, 24 Apr 2006 02:33:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW43i-0007l9-SK; Wed, 19 Apr 2006 00:12:54 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW43e-0002Ic-0W; Wed, 19 Apr 2006 00:12:54 -0400 Received: from gihm3.apnic.net (protege.telstra.net [203.50.0.194] (may be forged)) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k3J4CjDH042344; Wed, 19 Apr 2006 14:12:45 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060419140221.02cf0900@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 19 Apr 2006 14:12:36 +1000 To: Julien Laganier , Internet Area From: Geoff Huston In-Reply-To: <200603161624.16174.julien.IETF@laposte.net> References: <200603161624.16174.julien.IETF@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP Subject: [Hipsec] Re: [Int-area] Fwd: I-D ACTION:draft-laganier-ipv6-khi-01.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org At 01:24 AM 17/03/2006, Julien Laganier wrote: >[ Cross-posted to HIP WG and IPv6 WG. ] >[ Please reply _only_ to the INT area. ] > >Folks, > >draft-laganier-ipv6-khi-01.txt has been updated based on feedback >received from IETFers. > >The HIP base specification currently has a hard dependency on this >draft and therefore it would be desirable to have it published as an >RFC as soon as possible, since the HIP base specification is now >quite mature. This draft intent is to make it possible for existing >applications running on a HIP node to use both HIP and IPv6 at the >same time, in the hope that it will foster the HIP experiment. > >Your opinions on moving forward with this draft are more than >welcomed. I provided the following comments to Jari as AD, and he suggested that I forward the comments to the Internet Area mail list. I have read this draft, and have the following comments: 1. I find the following text to be very unclear: "...they are expectedtunnel; or 3) it can not try to negotiate HIP. >>>> Each of these mechanisms has problems. The spec should offer some >>>> guidance. It's possible this is provided in one of the other HIP >>>> documents. >> >> Maybe a recommendation: >> >> 6.6. Initiating a HIP connection >> >> The host should try to establish an opportunistic mode HIP >> association sending at most I1_RETRIES_MAX I1 packets. If it does not >> receive any R1s, it can try to initiate the connection without HIP >> if local policy allows. > > And use option 1 in the meantime. 2 has many problems, because > migrating a non-HIP connection to HIP is probably hard to implement. I would be tempted to make it explicit that this document does not define h= ow to do opportunistic HIP but simply provides hooks for it, a full definit= ion being expected to be available in some future document. Opinions? --Pekka inions? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudn-0001kL-CW; Mon, 24 Apr 2006 02:33:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW43i-0007l9-SK; Wed, 19 Apr 2006 00:12:54 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW43e-0002Ic-0W; Wed, 19 Apr 2006 00:12:54 -0400 Received: from gihm3.apnic.net (protege.telstra.net [203.50.0.194] (may be forged)) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k3J4CjDH042344; Wed, 19 Apr 2006 14:12:45 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060419140221.02cf0900@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 19 Apr 2006 14:12:36 +1000 To: Julien Laganier , Internet Area From: Geoff Huston In-Reply-To: <200603161624.16174.julien.IETF@laposte.net> References: <200603161624.16174.julien.IETF@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP Subject: [Hipsec] Re: [Int-area] Fwd: I-D ACTION:draft-laganier-ipv6-khi-01.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org At 01:24 AM 17/03/2006, Julien Laganier wrote: >[ Cross-posted to HIP WG and IPv6 WG. ] >[ Please reply _only_ to the INT area. ] > >Folks, > >draft-laganier-ipv6-khi-01.txt has been updated based on feedback >received from IETFers. > >The HIP base specification currently has a hard dependency on this >draft and therefore it would be desirable to have it published as an >RFC as soon as possible, since the HIP base specification is now >quite mature. This draft intent is to make it possible for existing >applications running on a HIP node to use both HIP and IPv6 at the >same time, in the hope that it will foster the HIP experiment. > >Your opinions on moving forward with this draft are more than >welcomed. I provided the following comments to Jari as AD, and he suggested that I forward the comments to the Internet Area mail list. I have read this draft, and have the following comments: 1. I find the following text to be very unclear: "...they are expectedtunnel; or 3) it can not try to negotiate HIP. >>>> Each of these mechanisms has problems. The spec should offer some >>>> guidance. It's possible this is provided in one of the other HIP >>>> documents. >> >> Maybe a recommendation: >> >> 6.6. Initiating a HIP connection >> >> The host should try to establish an opportunistic mode HIP >> association sending at most I1_RETRIES_MAX I1 packets. If it does not >> receive any R1s, it can try to initiate the connection without HIP >> if local policy allows. > > And use option 1 in the meantime. 2 has many problems, because > migrating a non-HIP connection to HIP is probably hard to implement. I would be tempted to make it explicit that this document does not define h= ow to do opportunistic HIP but simply provides hooks for it, a full definit= ion being expected to be available in some future document. Opinions? --Pekka inions? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudn-0001kL-CW; Mon, 24 Apr 2006 02:33:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW43i-0007l9-SK; Wed, 19 Apr 2006 00:12:54 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW43e-0002Ic-0W; Wed, 19 Apr 2006 00:12:54 -0400 Received: from gihm3.apnic.net (protege.telstra.net [203.50.0.194] (may be forged)) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k3J4CjDH042344; Wed, 19 Apr 2006 14:12:45 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060419140221.02cf0900@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 19 Apr 2006 14:12:36 +1000 To: Julien Laganier , Internet Area From: Geoff Huston In-Reply-To: <200603161624.16174.julien.IETF@laposte.net> References: <200603161624.16174.julien.IETF@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP Subject: [Hipsec] Re: [Int-area] Fwd: I-D ACTION:draft-laganier-ipv6-khi-01.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org At 01:24 AM 17/03/2006, Julien Laganier wrote: >[ Cross-posted to HIP WG and IPv6 WG. ] >[ Please reply _only_ to the INT area. ] > >Folks, > >draft-laganier-ipv6-khi-01.txt has been updated based on feedback >received from IETFers. > >The HIP base specification currently has a hard dependency on this >draft and therefore it would be desirable to have it published as an >RFC as soon as possible, since the HIP base specification is now >quite mature. This draft intent is to make it possible for existing >applications running on a HIP node to use both HIP and IPv6 at the >same time, in the hope that it will foster the HIP experiment. > >Your opinions on moving forward with this draft are more than >welcomed. I provided the following comments to Jari as AD, and he suggested that I forward the comments to the Internet Area mail list. I have read this draft, and have the following comments: 1. I find the following text to be very unclear: "...they are expectedtunnel; or 3) it can not try to negotiate HIP. >>>> Each of these mechanisms has problems. The spec should offer some >>>> guidance. It's possible this is provided in one of the other HIP >>>> documents. >> >> Maybe a recommendation: >> >> 6.6. Initiating a HIP connection >> >> The host should try to establish an opportunistic mode HIP >> association sending at most I1_RETRIES_MAX I1 packets. If it does not >> receive any R1s, it can try to initiate the connection without HIP >> if local policy allows. > > And use option 1 in the meantime. 2 has many problems, because > migrating a non-HIP connection to HIP is probably hard to implement. I would be tempted to make it explicit that this document does not define h= ow to do opportunistic HIP but simply provides hooks for it, a full definit= ion being expected to be available in some future document. Opinions? --Pekka inions? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Apr 24 02:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXudn-0001kL-CW; Mon, 24 Apr 2006 02:33:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FW43i-0007l9-SK; Wed, 19 Apr 2006 00:12:54 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FW43e-0002Ic-0W; Wed, 19 Apr 2006 00:12:54 -0400 Received: from gihm3.apnic.net (protege.telstra.net [203.50.0.194] (may be forged)) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k3J4CjDH042344; Wed, 19 Apr 2006 14:12:45 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060419140221.02cf0900@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 19 Apr 2006 14:12:36 +1000 To: Julien Laganier , Internet Area From: Geoff Huston In-Reply-To: <200603161624.16174.julien.IETF@laposte.net> References: <200603161624.16174.julien.IETF@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-Mailman-Approved-At: Mon, 24 Apr 2006 02:33:44 -0400 Cc: HIP Subject: [Hipsec] Re: [Int-area] Fwd: I-D ACTION:draft-laganier-ipv6-khi-01.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org At 01:24 AM 17/03/2006, Julien Laganier wrote: >[ Cross-posted to HIP WG and IPv6 WG. ] >[ Please reply _only_ to the INT area. ] > >Folks, > >draft-laganier-ipv6-khi-01.txt has been updated based on feedback >received from IETFers. > >The HIP base specification currently has a hard dependency on this >draft and therefore it would be desirable to have it published as an >RFC as soon as possible, since the HIP base specification is now >quite mature. This draft intent is to make it possible for existing >applications running on a HIP node to use both HIP and IPv6 at the >same time, in the hope that it will foster the HIP experiment. > >Your opinions on moving forward with this draft are more than >welcomed. I provided the following comments to Jari as AD, and he suggested that I forward the comments to the Internet Area mail list. I have read this draft, and have the following comments: 1. I find the following text to be very unclear: "...they are expected to be routable at an overlay level. Consequently, while they are considered as non-routable addresses from the IPv6 layer point of view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses." I _think_ what the authors are saying here is that in order to preserve the syntax and some subset of the semantics at the application layer of 'conventional' IP address use, they want to preserve the some of the characteristics of a 128 bit identifier. But perhaps this could be better expressed in the document. "routeable at an overlay level" doesn't make a huge amount of sense to me. 2. "globally unique in a statistical sense" I _wish_ authors would not use such imprecise terms. It is essentially meaningless in that "uniqueness" is an absolute term, rather than a statement of statistical probability. Either they are unique or they are not. In this case it would appear that they are not unique. 3. I find hard to follow: "As these identifiers are expected to be used alongside with IPv6 addresses at both applications and APIs, co-ordination is desired to make sure that an ORCHID is not inappropriately taken for a vanilla IPv6 address and vice versa. In practice, allocation of a separate prefix for ORCHIDs seems to suffice, making them compatible with IPv6 addresses at the upper layers while simultaneously making it trivial to prevent their usage at the IP layer." This seems unnecessary and inappropriate. It seems to add an element of fuzziness and confusion to the entire case being made. You _can't_ have it both ways and it seems to me that stealing unicast addresses at the forwarding plane to use as an application layer identity realm without any unicast semantics is not terribly sensible. 4. I'm not sure that I can agree with: " A specific danger would be realised if the IETF community later decided to use the ORCHID prefix for some different purpose. In that case, hosts using the ORCHID prefix would be, for practical purposes, unable to use the prefix for the other, new purpose. That would lead to partial balkanisation of the Internet, similar to what has happened as a result of historical hijackings of non-RFC1918 IPv4 addresses for private use." This appears to be factually incorrect - if indeed these are truly application level identifiers then the similarity to RFC1918 address use is not a sustainable proposition. 5. General Comments Identifier realms are generally expensive and hard to construct in useful and meaningful ways. The temptation to steal from existing identifier realms and reuse the tokens in another context is always present, and, invariably dangerous and often ill-advised (one only needs to refer to RR type proliferation in the DNS as an example of such overloading of identity in ways that are often unhelpful). In reading this draft I remain unconvinced that stealing bits from the forwarding plane identity realm (ip unicast addresses) is a Good Idea. The essential problem here remains the same problem in any form of compound layered identity realm that disambiguates the "who" from the "where" and "how": How to obtain from the "who" identity a useful mapping to a current valid "where" and to do so in a robust and valid manner. The draft appears to be curiously silent on this essential problem, and as such the draft appears not to head anywhere productive in its present form in furthering our understanding of the implications of this form of disambiguation of identity. I suspect that the essential attributes of any decent solution in this form of identity realm lie in structured rather than unstructured opportunistic identity spaces - the structure aids in the mechanism of unique solutions of a mapping question (what unicast forwarding address should I map to when all I have at the moment this identifier value of the remote party with whom I wish to communicate with?) i.e. "uniqueness" is a tough, expensive and useful concept. You can to be routable at an overlay level. Consequently, while they are considered as non-routable addresses from the IPv6 layer point of view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses." I _think_ what the authors are saying here is that in order to preserve the syntax and some subset of the semantics at the application layer of 'conventional' IP address use, they want to preserve the some of the characteristics of a 128 bit identifier. But perhaps this could be better expressed in the document. "routeable at an overlay level" doesn't make a huge amount of sense to me. 2. "globally unique in a statistical sense" I _wish_ authors would not use such imprecise terms. It is essentially meaningless in that "uniqueness" is an absolute term, rather than a statement of statistical probability. Either they are unique or they are not. In this case it would appear that they are not unique. 3. I find hard to follow: "As these identifiers are expected to be used alongside with IPv6 addresses at both applications and APIs, co-ordination is desired to make sure that an ORCHID is not inappropriately taken for a vanilla IPv6 address and vice versa. In practice, allocation of a separate prefix for ORCHIDs seems to suffice, making them compatible with IPv6 addresses at the upper layers while simultaneously making it trivial to prevent their usage at the IP layer." This seems unnecessary and inappropriate. It seems to add an element of fuzziness and confusion to the entire case being made. You _can't_ have it both ways and it seems to me that stealing unicast addresses at the forwarding plane to use as an application layer identity realm without any unicast semantics is not terribly sensible. 4. I'm not sure that I can agree with: " A specific danger would be realised if the IETF community later decided to use the ORCHID prefix for some different purpose. In that case, hosts using the ORCHID prefix would be, for practical purposes, unable to use the prefix for the other, new purpose. That would lead to partial balkanisation of the Internet, similar to what has happened as a result of historical hijackings of non-RFC1918 IPv4 addresses for private use." This appears to be factually incorrect - if indeed these are truly application level identifiers then the similarity to RFC1918 address use is not a sustainable proposition. 5. General Comments Identifier realms are generally expensive and hard to construct in useful and meaningful ways. The temptation to steal from existing identifier realms and reuse the tokens in another context is always present, and, invariably dangerous and often ill-advised (one only needs to refer to RR type proliferation in the DNS as an example of such overloading of identity in ways that are often unhelpful). In reading this draft I remain unconvinced that stealing bits from the forwarding plane identity realm (ip unicast addresses) is a Good Idea. The essential problem here remains the same problem in any form of compound layered identity realm that disambiguates the "who" from the "where" and "how": How to obtain from the "who" identity a useful mapping to a current valid "where" and to do so in a robust and valid manner. The draft appears to be curiously silent on this essential problem, and as such the draft appears not to head anywhere productive in its present form in furthering our understanding of the implications of this form of disambiguation of identity. I suspect that the essential attributes of any decent solution in this form of identity realm lie in structured rather than unstructured opportunistic identity spaces - the structure aids in the mechanism of unique solutions of a mapping question (what unicast forwarding address should I map to when all I have at the moment this identifier value of the remote party with whom I wish to communicate with?) i.e. "uniqueness" is a tough, expensive and useful concept. You can to be routable at an overlay level. Consequently, while they are considered as non-routable addresses from the IPv6 layer point of view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses." I _think_ what the authors are saying here is that in order to preserve the syntax and some subset of the semantics at the application layer of 'conventional' IP address use, they want to preserve the some of the characteristics of a 128 bit identifier. But perhaps this could be better expressed in the document. "routeable at an overlay level" doesn't make a huge amount of sense to me. 2. "globally unique in a statistical sense" I _wish_ authors would not use such imprecise terms. It is essentially meaningless in that "uniqueness" is an absolute term, rather than a statement of statistical probability. Either they are unique or they are not. In this case it would appear that they are not unique. 3. I find hard to follow: "As these identifiers are expected to be used alongside with IPv6 addresses at both applications and APIs, co-ordination is desired to make sure that an ORCHID is not inappropriately taken for a vanilla IPv6 address and vice versa. In practice, allocation of a separate prefix for ORCHIDs seems to suffice, making them compatible with IPv6 addresses at the upper layers while simultaneously making it trivial to prevent their usage at the IP layer." This seems unnecessary and inappropriate. It seems to add an element of fuzziness and confusion to the entire case being made. You _can't_ have it both ways and it seems to me that stealing unicast addresses at the forwarding plane to use as an application layer identity realm without any unicast semantics is not terribly sensible. 4. I'm not sure that I can agree with: " A specific danger would be realised if the IETF community later decided to use the ORCHID prefix for some different purpose. In that case, hosts using the ORCHID prefix would be, for practical purposes, unable to use the prefix for the other, new purpose. That would lead to partial balkanisation of the Internet, similar to what has happened as a result of historical hijackings of non-RFC1918 IPv4 addresses for private use." This appears to be factually incorrect - if indeed these are truly application level identifiers then the similarity to RFC1918 address use is not a sustainable proposition. 5. General Comments Identifier realms are generally expensive and hard to construct in useful and meaningful ways. The temptation to steal from existing identifier realms and reuse the tokens in another context is always present, and, invariably dangerous and often ill-advised (one only needs to refer to RR type proliferation in the DNS as an example of such overloading of identity in ways that are often unhelpful). In reading this draft I remain unconvinced that stealing bits from the forwarding plane identity realm (ip unicast addresses) is a Good Idea. The essential problem here remains the same problem in any form of compound layered identity realm that disambiguates the "who" from the "where" and "how": How to obtain from the "who" identity a useful mapping to a current valid "where" and to do so in a robust and valid manner. The draft appears to be curiously silent on this essential problem, and as such the draft appears not to head anywhere productive in its present form in furthering our understanding of the implications of this form of disambiguation of identity. I suspect that the essential attributes of any decent solution in this form of identity realm lie in structured rather than unstructured opportunistic identity spaces - the structure aids in the mechanism of unique solutions of a mapping question (what unicast forwarding address should I map to when all I have at the moment this identifier value of the remote party with whom I wish to communicate with?) i.e. "uniqueness" is a tough, expensive and useful concept. You can to be routable at an overlay level. Consequently, while they are considered as non-routable addresses from the IPv6 layer point of view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses." I _think_ what the authors are saying here is that in order to preserve the syntax and some subset of the semantics at the application layer of 'conventional' IP address use, they want to preserve the some of the characteristics of a 128 bit identifier. But perhaps this could be better expressed in the document. "routeable at an overlay level" doesn't make a huge amount of sense to me. 2. "globally unique in a statistical sense" I _wish_ authors would not use such imprecise terms. It is essentially meaningless in that "uniqueness" is an absolute term, rather than a statement of statistical probability. Either they are unique or they are not. In this case it would appear that they are not unique. 3. I find hard to follow: "As these identifiers are expected to be used alongside with IPv6 addresses at both applications and APIs, co-ordination is desired to make sure that an ORCHID is not inappropriately taken for a vanilla IPv6 address and vice versa. In practice, allocation of a separate prefix for ORCHIDs seems to suffice, making them compatible with IPv6 addresses at the upper layers while simultaneously making it trivial to prevent their usage at the IP layer." This seems unnecessary and inappropriate. It seems to add an element of fuzziness and confusion to the entire case being made. You _can't_ have it both ways and it seems to me that stealing unicast addresses at the forwarding plane to use as an application layer identity realm without any unicast semantics is not terribly sensible. 4. I'm not sure that I can agree with: " A specific danger would be realised if the IETF community later decided to use the ORCHID prefix for some different purpose. In that case, hosts using the ORCHID prefix would be, for practical purposes, unable to use the prefix for the other, new purpose. That would lead to partial balkanisation of the Internet, similar to what has happened as a result of historical hijackings of non-RFC1918 IPv4 addresses for private use." This appears to be factually incorrect - if indeed these are truly application level identifiers then the similarity to RFC1918 address use is not a sustainable proposition. 5. General Comments Identifier realms are generally expensive and hard to construct in useful and meaningful ways. The temptation to steal from existing identifier realms and reuse the tokens in another context is always present, and, invariably dangerous and often ill-advised (one only needs to refer to RR type proliferation in the DNS as an example of such overloading of identity in ways that are often unhelpful). In reading this draft I remain unconvinced that stealing bits from the forwarding plane identity realm (ip unicast addresses) is a Good Idea. The essential problem here remains the same problem in any form of compound layered identity realm that disambiguates the "who" from the "where" and "how": How to obtain from the "who" identity a useful mapping to a current valid "where" and to do so in a robust and valid manner. The draft appears to be curiously silent on this essential problem, and as such the draft appears not to head anywhere productive in its present form in furthering our understanding of the implications of this form of disambiguation of identity. I suspect that the essential attributes of any decent solution in this form of identity realm lie in structured rather than unstructured opportunistic identity spaces - the structure aids in the mechanism of unique solutions of a mapping question (what unicast forwarding address should I map to when all I have at the moment this identifier value of the remote party with whom I wish to communicate with?) i.e. "uniqueness" is a tough, expensive and useful concept. You can to be routable at an overlay level. Consequently, while they are considered as non-routable addresses from the IPv6 layer point of view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses." I _think_ what the authors are saying here is that in order to preserve the syntax and some subset of the semantics at the application layer of 'conventional' IP address use, they want to preserve the some of the characteristics of a 128 bit identifier. But perhaps this could be better expressed in the document. "routeable at an overlay level" doesn't make a huge amount of sense to me. 2. "globally unique in a statistical sense" I _wish_ authors would not use such imprecise terms. It is essentially meaningless in that "uniqueness" is an absolute term, rather than a statement of statistical probability. Either they are unique or they are not. In this case it would appear that they are not unique. 3. I find hard to follow: "As these identifiers are expected to be used alongside with IPv6 addresses at both applications and APIs, co-ordination is desired to make sure that an ORCHID is not inappropriately taken for a vanilla IPv6 address and vice versa. In practice, allocation of a separate prefix for ORCHIDs seems to suffice, making them compatible with IPv6 addresses at the upper layers while simultaneously making it trivial to prevent their usage at the IP layer." This seems unnecessary and inappropriate. It seems to add an element of fuzziness and confusion to the entire case being made. You _can't_ have it both ways and it seems to me that stealing unicast addresses at the forwarding plane to use as an application layer identity realm without any unicast semantics is not terribly sensible. 4. I'm not sure that I can agree with: " A specific danger would be realised if the IETF community later decided to use the ORCHID prefix for some different purpose. In that case, hosts using the ORCHID prefix would be, for practical purposes, unable to use the prefix for the other, new purpose. That would lead to partial balkanisation of the Internet, similar to what has happened as a result of historical hijackings of non-RFC1918 IPv4 addresses for private use." This appears to be factually incorrect - if indeed these are truly application level identifiers then the similarity to RFC1918 address use is not a sustainable proposition. 5. General Comments Identifier realms are generally expensive and hard to construct in useful and meaningful ways. The temptation to steal from existing identifier realms and reuse the tokens in another context is always present, and, invariably dangerous and often ill-advised (one only needs to refer to RR type proliferation in the DNS as an example of such overloading of identity in ways that are often unhelpful). In reading this draft I remain unconvinced that stealing bits from the forwarding plane identity realm (ip unicast addresses) is a Good Idea. The essential problem here remains the same problem in any form of compound layered identity realm that disambiguates the "who" from the "where" and "how": How to obtain from the "who" identity a useful mapping to a current valid "where" and to do so in a robust and valid manner. The draft appears to be curiously silent on this essential problem, and as such the draft appears not to head anywhere productive in its present form in furthering our understanding of the implications of this form of disambiguation of identity. I suspect that the essential attributes of any decent solution in this form of identity realm lie in structured rather than unstructured opportunistic identity spaces - the structure aids in the mechanism of unique solutions of a mapping question (what unicast forwarding address should I map to when all I have at the moment this identifier value of the remote party with whom I wish to communicate with?) i.e. "uniqueness" is a tough, expensive and useful concept. You can to be routable at an overlay level. Consequently, while they are considered as non-routable addresses from the IPv6 layer point of view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses." I _think_ what the authors are saying here is that in order to preserve the syntax and some subset of the semantics at the application layer of 'conventional' IP address use, they want to preserve the some of the characteristics of a 128 bit identifier. But perhaps this could be better expressed in the document. "routeable at an overlay level" doesn't make a huge amount of sense to me. 2. "globally unique in a statistical sense" I _wish_ authors would not use such imprecise terms. It is essentially meaningless in that "uniqueness" is an absolute term, rather than a statement of statistical probability. Either they are unique or they are not. In this case it would appear that they are not unique. 3. I find hard to follow: "As these identifiers are expected to be used alongside with IPv6 addresses at both applications and APIs, co-ordination is desired to make sure that an ORCHID is not inappropriately taken for a vanilla IPv6 address and vice versa. In practice, allocation of a separate prefix for ORCHIDs seems to suffice, making them compatible with IPv6 addresses at the upper layers while simultaneously making it trivial to prevent their usage at the IP layer." This seems unnecessary and inappropriate. It seems to add an element of fuzziness and confusion to the entire case being made. You _can't_ have it both ways and it seems to me that stealing unicast addresses at the forwarding plane to use as an application layer identity realm without any unicast semantics is not terribly sensible. 4. I'm not sure that I can agree with: " A specific danger would be realised if the IETF community later decided to use the ORCHID prefix for some different purpose. In that case, hosts using the ORCHID prefix would be, for practical purposes, unable to use the prefix for the other, new purpose. That would lead to partial balkanisation of the Internet, similar to what has happened as a result of historical hijackings of non-RFC1918 IPv4 addresses for private use." This appears to be factually incorrect - if indeed these are truly application level identifiers then the similarity to RFC1918 address use is not a sustainable proposition. 5. General Comments Identifier realms are generally expensive and hard to construct in useful and meaningful ways. The temptation to steal from existing identifier realms and reuse the tokens in another context is always present, and, invariably dangerous and often ill-advised (one only needs to refer to RR type proliferation in the DNS as an example of such overloading of identity in ways that are often unhelpful). In reading this draft I remain unconvinced that stealing bits from the forwarding plane identity realm (ip unicast addresses) is a Good Idea. The essential problem here remains the same problem in any form of compound layered identity realm that disambiguates the "who" from the "where" and "how": How to obtain from the "who" identity a useful mapping to a current valid "where" and to do so in a robust and valid manner. The draft appears to be curiously silent on this essential problem, and as such the draft appears not to head anywhere productive in its present form in furthering our understanding of the implications of this form of disambiguation of identity. I suspect that the essential attributes of any decent solution in this form of identity realm lie in structured rather than unstructured opportunistic identity spaces - the structure aids in the mechanism of unique solutions of a mapping question (what unicast forwarding address should I map to when all I have at the moment this identifier value of the remote party with whom I wish to communicate with?) i.e. "uniqueness" is a tough, expensive and useful concept. You can dilute uniquess by heading into unstructured opportunistic token realms but you lose determinism and efficiency when attempting to manipulate such identities as a precursor to communication. I don't think this draft proposes any novel way around this aspect of identity realms. I suspect that the architecture behind shim6 is about as cheap as you can get in this area of attempting to pull arapt identity from location - don't invent a new identity realm but use any initial "where" locator as a surrogate host-to-host identity token and allow local context dynamic mappings to hang off this initial association. If you want more robust and persistent identity realms then you end up in another question - in the long run any other identity realm starts to look so much like the DNS that the question becomes "whjy not use the DNS anyway". *(Maybe the IAB should have published draft-iab-identities rather than letting it die (see section 4.5 in particular) as I suspect that much of what else could be said here is already said there.) Geoff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec dilute uniquess by heading into unstructured opportunistic token realms but you lose determinism and efficiency when attempting to manipulate such identities as a precursor to communication. I don't think this draft proposes any novel way around this aspect of identity realms. I suspect that the architecture behind shim6 is about as cheap as you can get in this area of attempting to pull arapt identity from location - don't invent a new identity realm but use any initial "where" locator as a surrogate host-to-host identity token and allow local context dynamic mappings to hang off this initial association. If you want more robust and persistent identity realms then you end up in another question - in the long run any other identity realm starts to look so much like the DNS that the question becomes "whjy not use the DNS anyway". *(Maybe the IAB should have published draft-iab-identities rather than letting it die (see section 4.5 in particular) as I suspect that much of what else could be said here is already said there.) Geoff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec dilute uniquess by heading into unstructured opportunistic token realms but you lose determinism and efficiency when attempting to manipulate such identities as a precursor to communication. I don't think this draft proposes any novel way around this aspect of identity realms. I suspect that the architecture behind shim6 is about as cheap as you can get in this area of attempting to pull arapt identity from location - don't invent a new identity realm but use any initial "where" locator as a surrogate host-to-host identity token and allow local context dynamic mappings to hang off this initial association. If you want more robust and persistent identity realms then you end up in another question - in the long run any other identity realm starts to look so much like the DNS that the question becomes "whjy not use the DNS anyway". *(Maybe the IAB should have published draft-iab-identities rather than letting it die (see section 4.5 in particular) as I suspect that much of what else could be said here is already said there.) Geoff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec dilute uniquess by heading into unstructured opportunistic token realms but you lose determinism and efficiency when attempting to manipulate such identities as a precursor to communication. I don't think this draft proposes any novel way around this aspect of identity realms. I suspect that the architecture behind shim6 is about as cheap as you can get in this area of attempting to pull arapt identity from location - don't invent a new identity realm but use any initial "where" locator as a surrogate host-to-host identity token and allow local context dynamic mappings to hang off this initial association. If you want more robust and persistent identity realms then you end up in another question - in the long run any other identity realm starts to look so much like the DNS that the question becomes "whjy not use the DNS anyway". *(Maybe the IAB should have published draft-iab-identities rather than letting it die (see section 4.5 in particular) as I suspect that much of what else could be said here is already said there.) Geoff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec dilute uniquess by heading into unstructured opportunistic token realms but you lose determinism and efficiency when attempting to manipulate such identities as a precursor to communication. I don't think this draft proposes any novel way around this aspect of identity realms. I suspect that the architecture behind shim6 is about as cheap as you can get in this area of attempting to pull arapt identity from location - don't invent a new identity realm but use any initial "where" locator as a surrogate host-to-host identity token and allow local context dynamic mappings to hang off this initial association. If you want more robust and persistent identity realms then you end up in another question - in the long run any other identity realm starts to look so much like the DNS that the question becomes "whjy not use the DNS anyway". *(Maybe the IAB should have published draft-iab-identities rather than letting it die (see section 4.5 in particular) as I suspect that much of what else could be said here is already said there.) Geoff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec dilute uniquess by heading into unstructured opportunistic token realms but you lose determinism and efficiency when attempting to manipulate such identities as a precursor to communication. I don't think this draft proposes any novel way around this aspect of identity realms. I suspect that the architecture behind shim6 is about as cheap as you can get in this area of attempting to pull arapt identity from location - don't invent a new identity realm but use any initial "where" locator as a surrogate host-to-host identity token and allow local context dynamic mappings to hang off this initial association. If you want more robust and persistent identity realms then you end up in another question - in the long run any other identity realm starts to look so much like the DNS that the question becomes "whjy not use the DNS anyway". *(Maybe the IAB should have published draft-iab-identities rather than letting it die (see section 4.5 in particular) as I suspect that much of what else could be said here is already said there.) Geoff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Apr 25 10:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYOnX-00052f-Lm; Tue, 25 Apr 2006 10:45:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYOnW-00052a-VW for hipsec@ietf.org; Tue, 25 Apr 2006 10:45:50 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYOnV-0003LC-Gh for hipsec@ietf.org; Tue, 25 Apr 2006 10:45:50 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA12484; Tue, 25 Apr 2006 07:45:40 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k3PEjdr15276; Tue, 25 Apr 2006 07:45:40 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Apr 2006 07:45:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Apr 2006 07:45:36 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D01A2F0BA@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IRSG] review of document draft-irtf-hiprg-nat-01 Thread-Index: AcZUImHV7RtjFk2ZTZq+XI3l4uDuvgUTt9eA From: "Henderson, Thomas R" To: "Fall, Kevin" X-OriginalArrivalTime: 25 Apr 2006 14:45:36.0704 (UTC) FILETIME=[E9F25400:01C66876] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: hipsec-rg@honor.trusecure.com, hipsec@ietf.org Subject: [Hipsec] RE: [IRSG] review of document draft-irtf-hiprg-nat-01 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: hipsec-bounces@lists.ietf.org Kevin, I wanted to respond to those comments of yours that were not specific to the NAT draft but to HIP in general. > -----Original Message----- > From: Fall, Kevin [mailto:kevin.fall@intel.com]=20 > Sent: Thursday, March 30, 2006 9:50 AM > To: Internet Research Steering Group > Subject: [IRSG] review of document draft-irtf-hiprg-nat-01 >=20 (snip) >=20 > The discussion of NATP points out that the IPv4 HIP base exchange > doesn't contain port numbers. Is this fundamental? Could the HIP > exchange be carried, e.g. over UDP. I think something to=20 > this effect is > mentioned later in section 6, but not in exactly that form. Yes, the IETF HIP WG is discussing a recharter that would focus on a UDP-based encapsulation for NAT traversal. There are two drafts on this topic: http://www.ietf.org/internet-drafts/draft-schmitt-hip-nat-traversal-00.t xt http://www.ietf.org/internet-drafts/draft-nikander-hip-path-01.txt >=20 > I am curious also about whether the TCP alternate checksum (RFC1146) > when the TCP pseudoheader cksum computation is changed to=20 > work on HITs. > Again, this may be a comment on the IETF doc rather than this=20 > IRTF doc. If I understand correctly, the TCP alternate checksums are just different algorithms applied to the same pseudoheader and payload. I also don't know if they are used in practice, or if they have been applied to IPv6. It seems that the alternate checksums could also use HITs or LSIs in place of IP addresses in the pseudoheader.=20 >=20 > -- comments on the IETF document draft-ietf-hip-arch -- >=20 > HIP seems to be looking at an important problem area and it=20 > seems to be > viable at least for the scenarios studied (TCP and UDP transport). In > reading this document, I wasn't really sure it works in cases where > these aren't the transports. I think about ICMP, for example, as well > as multicast. Perhaps its not in HIP's scope to look at these things, > but if that's the case then does it really make sense to=20 > re-tool the end > host implementations for just these protocols? Maybe it=20 > does, but this > issue doesn't seem to be discussed in the architecture document. >=20 > It may not be explicit enough in the architecture document, but HIP is intended for unicast upper layer protocols that can be protected by ESP, where TCP and UDP are cited as the most common examples. Now that I read the base draft, it is a little vague on this point, and perhaps can be clarified in Section 4.5. ICMP is an interesting case, because it may be that you really want to avoid a HIP encapsulation of such traffic (e.g., ping an interface, not a host). The HIP implementation and SPD should have enough granularity to allow for the right rules to be applied. In the OpenHIP implementation, we are able to control it to some degree-- if we say "ping " the stack will not use HIP but if we say "ping " or "ping " it will use HIP and ESP to encapsulate the ping. Multicast has been out of scope to date, but it is conceivable that a variation of HIP could be used as a phase 1 protocol supporting RFC 3547 secure multicast. There has also been work on integrating HIP with i3, which supports a multicast-like indirection; see <> (and Andrei Gurtov provided a patch to the OpenHIP implementation for this feature). Tom =20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec