From nobody Mon May 2 23:32:04 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D046112D0A5 for ; Mon, 2 May 2016 23:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHV9BmW-7tlu for ; Mon, 2 May 2016 23:32:00 -0700 (PDT) Received: from mxout21.s.uw.edu (mxout21.s.uw.edu [140.142.32.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB5712B011 for ; Mon, 2 May 2016 23:32:00 -0700 (PDT) Received: from hymn01.u.washington.edu (hymn01.u.washington.edu [140.142.9.110]) by mxout21.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u436VAOE031114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 May 2016 23:31:10 -0700 Received: from hymn01.u.washington.edu (localhost [127.0.0.1]) by hymn01.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u436V9kV019860; Mon, 2 May 2016 23:31:09 -0700 Received: from localhost (Unknown UID 21258@localhost) by hymn01.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u436V9Is019854; Mon, 2 May 2016 23:31:09 -0700 X-Auth-Received: from [73.239.169.224] by hymn01.u.washington.edu via HTTP; Mon, 02 May 2016 23:31:09 PDT Date: Mon, 2 May 2016 23:31:09 -0700 (PDT) From: Tom Henderson To: Miika Komu Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.3.62115 X-PMX-Server: mxout21.s.uw.edu X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, DATE_TZ_NA 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_NOT_1 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __FRAUD_BADTHINGS 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __USER_AGENT 0' Archived-At: Cc: hip WG Subject: Re: [Hipsec] a review of ietf-hip-rfc5206-bis-10 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 06:32:03 -0000 Miika, below are some responses to the rest of your comments on this draft. > > 5.4. Verifying Address Reachability > > > > A host typically starts the address-verification procedure by sending > > a nonce to the new address. For example, when the host is changing > > its SPI and 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. > > (The copying is an implementation strategy) > > > However, if the host is not changing its SPI, > > it MAY still use the ECHO_REQUEST parameter in an UPDATE message sent > > to the new address. > > For what? To address both of your comments, how about changing this paragraph to read: A host typically starts the address-verification procedure by sending a nonce to the new address. A host MAY choose from different message exchanges or different nonce values so long as it establishes that the peer has received and replied to the nonce at the new address. For example, when the host is changing its SPI and sending an ESP_INFO to the peer, the NEW SPI value SHOULD be random and the random value MAY be copied into an ECHO_REQUEST sent in the rekeying UPDATE. However, if the host is not changing its SPI, it MAY still use the ECHO_REQUEST parameter for verification but with some other random value. A host MAY also use other message exchanges as confirmation of the address reachability. > > > 5.5. Changing the Preferred Locator > > > > [...] > > > > 3. If the peer host has not indicated a preference for any address, > > then the host picks one of the peer's ACTIVE addresses randomly > > or according to policy. This case may arise if, for example, > > local policy OK > > > 5.6. Credit-Based Authorization > > > > 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 > > mandatory or MUST? I suppose that we should use RFC2119 terminology (MUST). By the way, I propose to align Figure 9 better with the text; where it says to Drop Packet due to insufficient credit, I would like to have it say "Drop or Buffer Packet" in alignment with the preceding text. > > > 6. Security Considerations > > > > In Section 6.1 and Section 6.2, we assume that all users are using > > HIP. In Section 6.3 we consider the security ramifications when we > > have both HIP and non-HIP users. Security considerations for Credit- > > Based Authorization are discussed in [SIMPLE-CBA]. > > users -> hosts? Agree to change to 'hosts'. > > > 6.1. Impersonation Attacks > > > > An attacker wishing to impersonate another host will try to mislead > > its victim into directly communicating with them, or carry out a man- > > in-the-middle (MitM) attack between the victim and the victim's > > desired communication peer. Without mobility support, both attack > > types are possible only if the attacker resides on the routing path > > between its victim and the victim's desired communication peer, or if > > the attacker tricks its victim into initiating the connection over an > > incorrect routing path (e.g., by acting as a router or using spoofed > > DNS entries). > > Without HIP and its mobility support, ... OK to make that change > > By the way, I didn't get why the lack of mobility support can lead > MiTM attacks? I didn't read it that way; it seems to say that lack of mobility support limits the MITM attack potential to only on-path attacks (although it later says that HIP prevents even those types of attacks if the hosts authenticate one another). It later clarifies "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." > > > The HIP extensions defined in this specification change the situation > > in that they introduce an ability to redirect a connection (like > > IPv6), both before and after establishment. If no precautionary > > like in IPv6 (why is this an issue for IPv6, btw?) the reference is to Mobile IPv6; however, I think that we can safely delete the '(like IPv6)'. > > > measures are taken, an attacker could misuse the redirection feature > > to impersonate a victim's peer from any arbitrary location. The > > authentication and authorization mechanisms of the HIP base exchange > > [RFC7401] and the signatures in the UPDATE message prevent this > > attack. Furthermore, ownership of a HIP association is securely > > linked to a HIP HI/HIT. If an attacker somehow uses a bug in the > > implementation or weakness in some protocol to redirect a HIP > > what protocol? I do not know the reference to this (which protocol was in mind when this was written), so I suggest that we delete 'or weakness in some protocol'. > > > 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. However, once the opportunistic base > > ...once such an opportunistic... agreed > > > 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. UPDATE packets use HMAC and are signed. Even > > when an attacker can snoop packets to obtain the SPI and HIT/HI, they > > still cannot forge an UPDATE packet without knowledge of the secret > > keys. > > Also, replay attacks are impossible because the HMAC keys are and > nonces echo_requests are new. can you please restate the above sentence; I think that it may be missing an intended word? > > > 6.2.1. Flooding Attacks > > > > > > An effective DoS strategy is distributed denial of service (DDoS). > > Here, the attacker conventionally distributes some viral software to > > as many nodes as possible. Under the control of the attacker, the > > infected nodes, or "zombies", jointly send packets to the victim. > > With such an 'army', an attacker can take down even very high > > bandwidth networks/victims. > > zombies -> botnets agree, how about 'infected nodes (botnet) jointly send packets...' > > > With the ability to redirect connections, an attacker could realize a > > DDoS attack without having to distribute viral code. Here, the > > attacker initiates a large download from a server, and subsequently > > redirects this download to its victim. > > via HIP mobility UPDATE, right? Yes; I propose to change it to say: ".. and subsequently uses the HIP mobility mechanism to redirect this download to its victim." > > > 6.2.2. Memory/Computational-Exhaustion DoS Attacks > > > > We now consider whether or not the proposed extensions to HIP add any > > new DoS attacks (consideration of DoS attacks using the base HIP > > exchange and updates is discussed in [RFC7401]). A simple attack is > > to send many UPDATE packets containing many IP addresses that are not > > flagged as preferred. The attacker continues to send such packets > > until the number of IP addresses associated with the attacker's HI > > crashes the system. Therefore, there SHOULD be a limit to the number > > of IP addresses that can be associated with any HI. > > where there? I did not follow; can you restate? > > > 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. > > may or MAY? agree to use MAY > > > 6.3. Mixed Deployment Environment > > > > We now assume an environment with both HIP and non-HIP aware hosts. > > Four cases exist. > > > > 4. 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 the use of HIP address check information > > to influence non-HIP sessions. > > er... how? I think that the idea of this scenario was that an attacker may claim through HIP that it resided at a particular address, causing the host to possibly shift traffic (from other ongoing non-HIP sessions to that address) into the HIP SAs during the transient period when the address is being verified. Maybe it should say "a solution is to prevent the local redirection of sessions that were previously using an unverified address, but outside of the existing HIP context, into the HIP SAs until the address change can be verified." (note that I deleted the word 'simple' since I don't know how simple it will be) - Tom From nobody Tue May 3 05:00:01 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7080512D77B for ; Tue, 3 May 2016 04:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yvcVM0EKQVt for ; Tue, 3 May 2016 04:59:55 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2031C12D779 for ; Tue, 3 May 2016 04:59:54 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-38-572892b9d517 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id DB.B7.12926.9B298275; Tue, 3 May 2016 13:59:53 +0200 (CEST) Received: from [153.88.190.38] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.248.2; Tue, 3 May 2016 13:59:06 +0200 To: Tom Henderson References: From: Miika Komu Organization: Ericsson AB Message-ID: <5728928A.50109@ericsson.com> Date: Tue, 3 May 2016 14:59:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080106080703070603080709" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdWnfnJI1wg/6/ShZTF01mtph5/iCb A5PHkiU/mTxarscEMEVx2aSk5mSWpRbp2yVwZexr6mAq+NbIWPFg4TyWBsYXOV2MnBwSAiYS 2x/vYYewxSQu3FvP1sXIxSEkcIRRon31ThYIZxWjxKH9P5m6GDk4hAUsJe7vLAJpEBHQkbj0 YgsriC0k4CnRenEF2CBmARmJzR+ngsXZBLQkVt25zgxi8wtISmxo2M0MMoZXQFNi2rlAkDCL gIrEk1eHmUBsUYEIidXrroGV8woISpyc+YQFxOYU8JKYMXE6C8T4bkaJCY84QcYIAfVePBY8 gVFwFpKOWUiqIGxbiTtzdzND2NoSyxa+hrKtJWb8OsgGYStKTOl+yA5hm0q8PvqREcI2lli2 7i/bAkaOVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBMXJwy2/VHYyX3zgeYhTgYFTi4VVg 0wgXYk0sK67MPcSoAjTn0YbVFxilWPLy81KVRHgLJgKleVMSK6tSi/Lji0pzUosPMUpzsCiJ 8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MDIpf0v4Wpp0wNbXe5Eca7iR5n+JvntLtjbr+oYz n/7DJSryUyhmxVvR/yV3TIo1Lsx/fPkco5QAz46rd+Vc7i+5mG0mtSzJ/MfuO+6nFfWeeHlL Sv3ckO0Q0Xiz/WG1x4+e/bbh6zfM0Yr1fqyb1RfO4lL741GPhM5LCaOEH5Myf2052R3mrsRS nJFoqMVcVJwIAM71BR2ZAgAA Archived-At: Cc: hip WG Subject: Re: [Hipsec] a review of ietf-hip-rfc5206-bis-10 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 11:59:58 -0000 --------------ms080106080703070603080709 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Tom, On 05/03/2016 09:31 AM, Tom Henderson wrote: > Miika, below are some responses to the rest of your comments on this dr= aft. > >> > 5.4. Verifying Address Reachability >> > >> > A host typically starts the address-verification procedure by send= ing >> > a nonce to the new address. For example, when the host is changin= g >> > its SPI and sending an ESP_INFO to the peer, the NEW SPI value SHO= ULD >> > be random and the value MAY be copied into an ECHO_REQUEST sent in= >> > the rekeying UPDATE. >> >> (The copying is an implementation strategy) >> >> > However, if the host is not changing its SPI, >> > it MAY still use the ECHO_REQUEST parameter in an UPDATE message s= ent >> > to the new address. >> >> For what? > > To address both of your comments, how about changing this paragraph to = read: > > A host typically starts the address-verification procedure by sendi= ng > a nonce to the new address. A host MAY choose from different messa= ge > exchanges or different nonce values so long as it establishes that = the > peer has received and replied to the nonce at the new address. For= example, > when the host is changing > its SPI and sending an ESP_INFO to the peer, the NEW SPI value SHOU= LD > be random and the random value MAY be copied into an ECHO_REQUEST s= ent in > the rekeying UPDATE. However, if the host is not changing its SPI,= > it MAY still use the ECHO_REQUEST parameter for verification but wi= th some > other random value. A host MAY also use other message exchanges as= > confirmation of the address reachability. ok. >> > 5.5. Changing the Preferred Locator >> > >> > [...] >> > >> > 3. If the peer host has not indicated a preference for any addres= s, >> > then the host picks one of the peer's ACTIVE addresses randomly >> > or according to policy. This case may arise if, for example, >> >> local policy > > OK > >> >> > 5.6. Credit-Based Authorization >> > >> > 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 f= or >> > the CreditAgingFactor and CreditAgingInterval parameters in >> >> mandatory or MUST? > > I suppose that we should use RFC2119 terminology (MUST). > > By the way, I propose to align Figure 9 better with the text; where it = says > to Drop Packet due to insufficient credit, I would like to have it say > "Drop or Buffer Packet" in alignment with the preceding text. ok. >> > 6. Security Considerations >> > >> > In Section 6.1 and Section 6.2, we assume that all users are using= >> > HIP. In Section 6.3 we consider the security ramifications when w= e >> > have both HIP and non-HIP users. Security considerations for Cred= it- >> > Based Authorization are discussed in [SIMPLE-CBA]. >> >> users -> hosts? > > Agree to change to 'hosts'. > >> >> > 6.1. Impersonation Attacks >> > >> > An attacker wishing to impersonate another host will try to mislea= d >> > its victim into directly communicating with them, or carry out a m= an- >> > in-the-middle (MitM) attack between the victim and the victim's >> > desired communication peer. Without mobility support, both attack= >> > types are possible only if the attacker resides on the routing pat= h >> > between its victim and the victim's desired communication peer, or= if >> > the attacker tricks its victim into initiating the connection over= an >> > incorrect routing path (e.g., by acting as a router or using spoof= ed >> > DNS entries). >> >> Without HIP and its mobility support, ... > > OK to make that change > >> >> By the way, I didn't get why the lack of mobility support can lead >> MiTM attacks? > > I didn't read it that way; it seems to say that lack of mobility suppor= t > limits the MITM attack potential to only on-path attacks (although > it later says that HIP prevents even those types of attacks if the > hosts authenticate one another). Ok. (I would perhaps reverse the meaning of the sentence and state what=20 is possible with mobility support; it is always a bit difficult read=20 negated text) > It later clarifies > "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." Ok. >> > The HIP extensions defined in this specification change the situat= ion >> > in that they introduce an ability to redirect a connection (like >> > IPv6), both before and after establishment. If no precautionary >> >> like in IPv6 (why is this an issue for IPv6, btw?) > > the reference is to Mobile IPv6; however, I think that we can safely de= lete > the '(like IPv6)'. Ok. >> >> > measures are taken, an attacker could misuse the redirection featu= re >> > to impersonate a victim's peer from any arbitrary location. The >> > authentication and authorization mechanisms of the HIP base exchan= ge >> > [RFC7401] and the signatures in the UPDATE message prevent this >> > attack. Furthermore, ownership of a HIP association is securely >> > linked to a HIP HI/HIT. If an attacker somehow uses a bug in the >> > implementation or weakness in some protocol to redirect a HIP >> >> what protocol? > > I do not know the reference to this (which protocol was in mind when th= is > was written), so I suggest that we delete 'or weakness in some protocol= '. ok. >> >> > 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. However, once the opportunistic base >> >> ...once such an opportunistic... > > agreed > >> >> > exchange has taken place, even a MitM cannot steal the HIP connect= ion >> > 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. UPDATE packets use HMAC and are signed. Even >> > when an attacker can snoop packets to obtain the SPI and HIT/HI, t= hey >> > still cannot forge an UPDATE packet without knowledge of the secre= t >> > keys. >> >> Also, replay attacks are impossible because the HMAC keys are and >> nonces echo_requests are new. > > can you please restate the above sentence; I think that it may be missi= ng > an intended word? This text just talks just about forging. I would also state that replay=20 attacks are not possible due toe the same reasons as mentioned above. >> > 6.2.1. Flooding Attacks >> > >> > >> > An effective DoS strategy is distributed denial of service (DDoS).= >> > Here, the attacker conventionally distributes some viral software = to >> > as many nodes as possible. Under the control of the attacker, the= >> > infected nodes, or "zombies", jointly send packets to the victim. >> > With such an 'army', an attacker can take down even very high >> > bandwidth networks/victims. >> >> zombies -> botnets > > agree, how about 'infected nodes (botnet) jointly send packets...' Ok. (e.g. nodes in a botnet) >> > With the ability to redirect connections, an attacker could realiz= e a >> > DDoS attack without having to distribute viral code. Here, the >> > attacker initiates a large download from a server, and subsequentl= y >> > redirects this download to its victim. >> >> via HIP mobility UPDATE, right? > > Yes; I propose to change it to say: > > ".. and subsequently uses the HIP mobility mechanism to redirect this d= ownload > to its victim." Ok. >> >> > 6.2.2. Memory/Computational-Exhaustion DoS Attacks >> > >> > We now consider whether or not the proposed extensions to HIP add = any >> > new DoS attacks (consideration of DoS attacks using the base HIP >> > exchange and updates is discussed in [RFC7401]). A simple attack = is >> > to send many UPDATE packets containing many IP addresses that are = not >> > flagged as preferred. The attacker continues to send such packets= >> > until the number of IP addresses associated with the attacker's HI= >> > crashes the system. Therefore, there SHOULD be a limit to the num= ber >> > of IP addresses that can be associated with any HI. >> >> where there? > > I did not follow; can you restate? It says "there SHOULD be a limit". I am asking where, i.e., change=20 passive voice to active (e.g. a Host Association SHOULD have a limit). >> > A central server that has to deal with a large number of mobile >> > clients may consider increasing the SA lifetimes to try to slow do= wn >> > the rate of rekeying UPDATEs or increasing the cookie difficulty t= o >> > slow down the rate of attack-oriented connections. >> >> may or MAY? > > agree to use MAY ok >> >> > 6.3. Mixed Deployment Environment >> > >> > We now assume an environment with both HIP and non-HIP aware hosts= =2E >> > Four cases exist. >> > >> > 4. 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 the use of HIP address check information >> > to influence non-HIP sessions. >> >> er... how? > > I think that the idea of this scenario was that an attacker may > claim through HIP that it resided at a particular address, causing > the host to possibly shift traffic (from other ongoing non-HIP > sessions to that address) into the HIP SAs during the transient > period when the address is being verified. > > Maybe it should say "a solution is to prevent the local redirection > of sessions that were previously using an unverified address, > but outside of the existing HIP context, into the HIP SAs until > the address change can be verified." > > (note that I deleted the word 'simple' since I don't know how > simple it will be) Sounds better. --------------ms080106080703070603080709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNTAzMTE1OTA2 WjAvBgkqhkiG9w0BCQQxIgQguENlrXUMMxp6nxmk9f3fWnwZk7570kyfdnDVdD0fZjAwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAkRu4NnTuU 6C+/SmHQjsKRkhPjNIDmxZA76/wYwD9w6a3fQjOsPLJK5yGSw+OJD8YjgW4MlAeHhWyNaBhH ve+wwt0yJl6fKPC0NkyAmUFnKrnUHSf6CJgSQT3wBH39VRfKZLBR8tBZ3vbrgVyPB/GthSyp mB9xsk4OW6Or+yFhJhqxx1zyzVjOdD+4bjjrqgg8Xj7Pyo8UkRXoDLp/HR+BU9D/qF+fmZpf r92P4h578odrhnHH0VQcaidQsf2dukytm/0JvRdDAqKfrtUIm+BxRlDDTrrbHz7+eprJ5OFI 2W3Sl7zYbrHni+9JWsXvVCcW3HWcY0faE9F9gio//ae4AAAAAAAA --------------ms080106080703070603080709-- From nobody Thu May 5 22:48:27 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76EE112B015; Thu, 5 May 2016 22:48:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160506054826.26851.50165.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2016 22:48:26 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5206-bis-11.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 05:48:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Host Mobility with the Host Identity Protocol Authors : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-rfc5206-bis-11.txt Pages : 34 Date : 2016-05-05 Abstract: This document defines mobility extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR_SET" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR_SET parameter can also be used to support end-host multihoming, detailed procedures are out of scope for this document. This document obsoletes RFC 5206. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-rfc5206-bis-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5206-bis-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 5 23:00:12 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB1012D1E9 for ; Thu, 5 May 2016 23:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkBNR37ZBBDM for ; Thu, 5 May 2016 23:00:09 -0700 (PDT) Received: from mxout25.s.uw.edu (mxout25.s.uw.edu [140.142.234.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5873212D1A4 for ; Thu, 5 May 2016 23:00:09 -0700 (PDT) Received: from hymn02.u.washington.edu (hymn02.u.washington.edu [140.142.8.71]) by mxout25.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u465xojt028873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 May 2016 22:59:50 -0700 Received: from hymn02.u.washington.edu (localhost [127.0.0.1]) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u465xnEf009592; Thu, 5 May 2016 22:59:49 -0700 Received: from localhost (Unknown UID 18077@localhost) by hymn02.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u465xnEW009589; Thu, 5 May 2016 22:59:49 -0700 X-Auth-Received: from [73.239.169.224] by hymn02.u.washington.edu via HTTP; Thu, 05 May 2016 22:59:49 PDT Date: Thu, 5 May 2016 22:59:49 -0700 (PDT) From: Tom Henderson To: Gonzalo.Camarillo@ericsson.com Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.6.55116 X-PMX-Server: mxout25.s.uw.edu X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_800_899 0, DATE_TZ_NA 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_URI_TEXT 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_IN_BODY 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0' Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] WGLC: draft-ietf-hip-multihoming-08 and draft-ietf-hip-rfc5206-bis-10 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 06:00:11 -0000 On 04/15/2016 03:18 AM, Gonzalo Camarillo wrote: > Folks, > > I would like to start a WGLC on the following two drafts. This WGLC will > end on April 29th: > > https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ > https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ > > Thanks, > > Gonzalo > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec Gonzalo, the draft-ietf-hip-rfc5206-bis-11.txt version that I just published has handled all of Miika's WGLC comments (no other comments were received). We did not receive any WGLC comments on the multihoming draft. From my perspective, the open issues in the tracker that I had proposed to handle have all been handled, so we may now be ready for publication request on these documents. - Tom From nobody Fri May 6 00:05:50 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DFE12D12B for ; Fri, 6 May 2016 00:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GxyTboy9rpF for ; Fri, 6 May 2016 00:05:48 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCE312D0F2 for ; Fri, 6 May 2016 00:05:47 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-15-572c424939f0 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A0.CC.12516.9424C275; Fri, 6 May 2016 09:05:45 +0200 (CEST) Received: from [131.160.126.227] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.248.2; Fri, 6 May 2016 09:05:45 +0200 To: Tom Henderson References: From: Gonzalo Camarillo Message-ID: <572C4248.5080605@ericsson.com> Date: Fri, 6 May 2016 10:05:44 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM2J7uK6nk064wcETxhZTF01mtph5/iCb A5PHkiU/mTxarscEMEVx2aSk5mSWpRbp2yVwZUx5vZKl4Ax7xdYbc5gaGBexdTFyckgImEhc vr6OFcIWk7hwbz1QnItDSOAIo8SlifcYIZw1jBJnNn5jAakSFoiVON03FcwWEdCRuPRiC1i3 kICHxN6OnUBxDg5mAVGJ7bOqQMJsAhYSW27dByvnFdCW+D33OjuIzSKgIrHlfDcziC0qECPR +OAUE0SNoMTJmU/A6jkFPCWO/d8EVs8sYCBxZNEcVghbXmL72znMEGu1JZY/a2GZwCg4C0n7 LCQts5C0LGBkXsUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGKwHt/zW3cG4+rXjIUYBDkYl Ht4Fv7TDhVgTy4orcw8xSnAwK4nwTrDXCRfiTUmsrEotyo8vKs1JLT7EKM3BoiTO6/9SMVxI ID2xJDU7NbUgtQgmy8TBKdXAOIEn8/9zZ28VAbun14WTXouw3Pi//PjfR3OZbj4+/2DSDf8P j3tK695PPfRg5fpvJmIhQf08boL7i2z4r6z888Bgwu8rwpOnS3f7bdbwXXCMb46p027FviKv F9s4e589vHF1u/wkN7+6dMtnWVeWPzgoURkh/zqlzYtH3/9I4cd4JlGBP7rphkosxRmJhlrM RcWJAGUXfvhSAgAA Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] WGLC: draft-ietf-hip-multihoming-08 and draft-ietf-hip-rfc5206-bis-10 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 07:05:50 -0000 Thanks, Tom. Gonzalo On 06/05/2016 8:59 AM, Tom Henderson wrote: > On 04/15/2016 03:18 AM, Gonzalo Camarillo wrote: >> Folks, >> >> I would like to start a WGLC on the following two drafts. This WGLC will >> end on April 29th: >> >> https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ >> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ >> >> Thanks, >> >> Gonzalo >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec > > Gonzalo, the draft-ietf-hip-rfc5206-bis-11.txt version that I just published has handled all of Miika's WGLC comments (no other comments were received). We did not receive any WGLC comments on the multihoming draft. From my perspective, the open issues in the tracker that I had proposed to handle have all been handled, so we may now be ready for publication request on these documents. > > - Tom > > From nobody Mon May 9 01:32:19 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48DD12B078 for ; Mon, 9 May 2016 01:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PJzYDgheGK4 for ; Mon, 9 May 2016 01:32:15 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475DF12B023 for ; Mon, 9 May 2016 01:32:14 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-3d-57304b0c4167 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6E.00.27088.C0B40375; Mon, 9 May 2016 10:32:12 +0200 (CEST) Received: from [131.160.50.131] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.248.2; Mon, 9 May 2016 10:32:11 +0200 To: , References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> <5714D946.4070303@ericsson.com> From: Gonzalo Camarillo Message-ID: <57304B0B.6050804@ericsson.com> Date: Mon, 9 May 2016 11:32:11 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5714D946.4070303@ericsson.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM2K7ui6Pt0G4webtkhZTF01mtlg2ew6T RcO6z4wOzB5bn35h8dg9qYndY8mSn0wBzFFcNimpOZllqUX6dglcGXOfz2Ep+HWdseL45mVM DYyLVjF2MXJySAiYSPx5+BDKFpO4cG89G4gtJHCEUWLrO7EuRi4gezWjxK8f3SwgCWEBa4mp H26yg9giAsYSv5d/ZoQoamSUmN1/i7WLkYODWUBUYvusKpAaNgELiS237oP18gpoS8x78AXM ZhFQkWjquga2WFQgRqLxwSkmiBpBiZMzn4DVcAroSHQuawfbxSxgIHFk0RxWCFteYvvbOcwQ h2pLLH/WwjKBUXAWkvZZSFpmIWlZwMi8ilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwjA9u +W2wg/Hlc8dDjAIcjEo8vArv9cOFWBPLiitzDzFKcDArifC6ehiEC/GmJFZWpRblxxeV5qQW H2KU5mBREuf1f6kYLiSQnliSmp2aWpBaBJNl4uCUamD0yhT8V2mbUFLrkGlkcKBysmlY+pzl T9O//zzq2Jll+n131ZRdb6d9tNTlmvu2/7vTf/PDp1idaxr9p8U93m7nWfbsQBNbyZKQ57eX BlSF7LPvnOf99U3o/l87DfQ3epX93NheuWJ+13HBuUc4asxK5mXYNH6TO//g2KbWZp9O76d+ ++b4qhspsRRnJBpqMRcVJwIAE4oAT18CAAA= Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 08:32:18 -0000 Rene, Bob, when we agreed to add this draft to our charter it was based on your promise that you were going to be putting enough cycles into it. I assume that is still the case and you have allocated enough time to push this draft to completion, is that right? Please, let us know when you will be able to address Miika's comments below. Thanks, Gonzalo On 18/04/2016 3:55 PM, Gonzalo Camarillo wrote: > Rene, Bob, > > could you please have a look at Miika's comments below? > > Thanks, > > Gonzalo > > On 28/03/2016 11:05 PM, Miika Komu wrote: >> Hi, >> >>> 1.1. The HIP Diet EXchange (DEX) >> >>> Data packets start to flow after the 4th packet. The 3rd and 4th HIP >>> packets may carry data payload in the future. However, the details >>> of this may be defined later. >> >> Similarly as in RFC7401, data packets start to flow... >> >> (I guess you could also mention RFC6078 as another further work item) >> >>> An existing HIP association can be updated with the update mechanism >>> defined in [RFC7401]. Likewise, the association can be torn down >>> with the defined closing mechanism for HIPv2 if it is no longer >>> needed. HIP DEX thereby omits the HIP_SIGNATURE parameters of the >>> original HIPv2 specification. >> >> Why "thereby"? I don't see the connection. >> >>> HIP DEX does not have the option to encrypt the Host Identity of the >>> Initiator in the 3rd packet. The Responder's Host Identity also is >>> not protected. Thus, contrary to HIPv2, there is no attempt at >>> anonymity. >> >> The anonymous bit still exists, so I suggest changing the wording: >> >> there is no attempt at anonymity -> such Responder anonymity is not >> preserved in HIP DEX. >> >>> 2.1. Requirements Terminology >> >> In section 6.3, you are introduce also -> notation, which was >> not explained. >> >>> 2.3. Definitions >> >> I suggest to add also the definitions of both MAC and CMAC because they >> are used throughout the document. They are also used in this section. >> >>> 3.1. Host Identity Tag (HIT) >> >> Just thinking aloud... should a DEX HIT have a different context ID? >> Probably not. >> >>> 4.1. Creating a HIP Association >> >>> The HIP Diet EXchange serves to manage the establishment of state >>> between an Initiator and a Responder. The first packet, I1, >>> initiates the exchange, and the last three packets, R1, I2, and R2, >>> constitute an authenticated Diffie-Hellman [DH76] key exchange for >>> the Master Key SA generation. This Master Key SA is used by the >>> Initiator and the Responder to wrap secret keying material in the I2 >>> and R2 packets. Based on the exchanged keying material, the peers >>> then derive a Pair-wise Key SA if cryptographic keys are needed, >>> e.g., for ESP-based protection of user data. >> >> (Suggest replacing "user data" with e.g. "data plane" in the entire >> document since you're talking about machines (sensors) that may not >> have a user) >> >>> In the I2 packet, the Initiator MUST display the solution to the >>> received puzzle. Without a correct solution, the I2 packet is >>> discarded. The I2 also contains a key wrap parameter that carries a >>> secret keying material of the Initiator. This keying material is >>> only half the final session key. The packet is authenticated by the >>> sender (Initiator) via a MAC. >> >> ...half *of* the... >> >>> The R2 packet acknowledges the receipt of the I2 packet and completes >>> the handshake. The R2 contains a key wrap parameter that carries the >>> rest of the keying material of the Responder. The packet is >>> authenticated by the sender (Responder) via a MAC. >> >> key wrap parameter -> parameter with encrypted contents >> >>> 4.1.1. HIP Puzzle Mechanism >>> >>> The puzzle mechanism enables a Responder to immediately reject an I2 >>> packet if it does not contain a valid puzzle solution. To verify the >>> puzzle solution, the Responder only has to compute a single CMAC >>> operation. After a successful puzzle verification, the Responder can >>> securely create session-specific state and perform CPU-intensive >>> operations such as a Diffie-Hellman key generation. By varying the >>> difficulty of the puzzle, the Responder can frustrate CPU or memory >>> targeted DoS attacks. >> >> ...can frustrate *an Initiator*... >> >>> Conceptually, the puzzle mechanism in HIP DEX is the same as in >>> HIPv2. Hence, this document refers to Sections 4.1.1 and 4.1.2 in >>> [RFC7401] for more detailed information about the employed mechanism. >>> Notably, the only difference between the puzzle mechanism in HIP DEX >>> and HIPv2 is that HIP DEX uses CMAC instead of a hash function for >>> solving and verifying a puzzle. The implications of this change on >>> the puzzle implementation are discussed in Section 6.1. >> >> The other difference is mentioned in section 6.1: >> >> "The only exceptions are that HIP DEX does not use pre-computation of >> R1 packets and that RHASH is set to CMAC. As a result, the pre- >> computation step in in Section 6.3 of [RFC7401] is skipped in HIP DEX." >> >>> 4.1.2.1. HIP DEX Retransmission Mechanism >> >>> The potentially high processing time of an I2 packet at a (resource- >>> constrained) Responder may cause premature retransmissions if the >>> time required for I2 transmission and processing exceeds the RTT- >>> based retransmission timeout. Thus, the Initiator should also take >>> the processing time of the I2 packet at the Responder into account >>> for retransmission purposes. To this end, the Responder MAY notify >>> the Initiator about the anticipated delay once the puzzle solution >>> was successfully verified and if the remaining I2 packet processing >>> incurs a high processing delay. The Responder MAY therefore send a >>> NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator >>> before the Responder commences the ECDH operation. The NOTIFY packet >>> serves as an acknowledgement for the I2 packet and consists of a >>> NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT >>> (see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter >>> contains the anticipated remaining processing time for the I2 packet >>> in milliseconds as two-octet Notification Data. This processing time >>> can, e.g., be estimated by measuring the computation time of the ECDH >>> key derivation operation at Responder boot-up. After the I2 >>> processing has finished, the Responder sends the regular R2 packet. >> >> ( boot-up -> start-up procedures (it doesn't have to be a boot) ) >> >>> 4.1.2.3. Simplified HIP State Diagram >> >>> The following diagram shows the major state transitions. Transitions >>> based on received packets implicitly assume that the packets are >>> successfully authenticated or processed. >> >> Is the new NOTIFY illustrated also in the figure? >> >>> 5.2.1. DH_GROUP_LIST >>> >>> The DH_GROUP_LIST parameter contains the list of supported DH Group >>> IDs of a host. It is defined in Section 5.2.6 of [RFC7401]. With >>> HIP DEX, the DH Group IDs are restricted to: >>> >>> Group KDF Value >>> >>> NIST P-256 [RFC5903] CKDF 7 >>> NIST P-384 [RFC5903] CKDF 8 >>> NIST P-521 [RFC5903] CKDF 9 >>> SECP160R1 [SECG] CKDF 10 >>> Curve25519 [RFC7748] CKDF 11 >>> Curve448 [RFC7748] CKDF 12 >>> >>> The ECDH groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH >>> group 10 is covered in [SECG] and Appendix D of [RFC7401]. These >>> curves, when used with HIP MUST have a co-factor of 1. >> >> I suggest to change the "value" column title to "group id" or change the >> text >> as follows: "The ECDH groups with *values* 7 - 9..." >> >>> The ECDH groups 11 and 12 are defined in [RFC7748]. These curves >>> have cofactors of 8 and 4 (respectively). >> >> Same comment as previously. >> >>> 5.2.3. HOST_ID >>> >>> The HOST_ID parameter conveys the Host Identity (HI) along with >>> optional information about a host. It is defined in Section 5.2.9 of >>> [RFC7401]. >>> >>> HIP DEX uses the public portion of a host's static ECDH key-pair as >>> the HI. Correspondingly, HIP DEX limits the HI algorithms to the >>> following profile: >> >> I would add "*new* profile" since this is not part of RFC7401. >> >>> 5.2.4. HIT_SUITE_LIST >>> >>> The HIT_SUITE_LIST parameter contains a list of the supported HIT >>> suite IDs of the Responder. Based on the HIT_SUITE_LIST, the >>> Initiator can determine which source HIT Suite IDs are supported by >>> the Responder. The HIT_SUITE_LIST parameter is defined in >>> Section 5.2.10 of [RFC7401]. >> >>> The following HIT Suite IDs are defined for HIP DEX, and the >>> relationship between the four-bit ID value used in the OGA ID field >>> and the eight-bit encoding within the HIT_SUITE_LIST ID field is >>> clarified: >> >> ...the following *new* HIT Suite IDs... >> >> ...is clarified: -> ...is defined as follows: >> >>> Note that the HIP DEX HIT Suite ID allows the peers to distinguish a >>> HIP DEX handshake from a HIPv2 handshake. The Responder MUST respond >>> with a HIP DEX HIT suite ID when the HIT of the Initiator is a HIP >>> DEX HIT. >> >> The details are a bit unclear. Which packet are you talking about here? >> >> I mean the suite id is in R1 (and not in I1), so I guess you're >> referring that >> Responder must respond to I2 with an R2 that contains HIP DEX HITs? >> >> In general, I'd urge the authors to write a separate "Compatibility with >> HIP base exchange" section in the end of the document with the two >> (problematic) use cases: >> >> 1. Initiator=DEX, Responder=BEX >> 2. Initiator=BEX, Responder=DEX >> >> How what happens in each case? Can the Initiator still try to >> communicate (in case the Responder could potentially support both >> protocols) or should it just abort? When exactly each party knows and >> from which parameters both of the parties detect incompatibilities? >> Consider also the opportunistic mode. Bits and pieces of this >> discussion was scattered here and there, but it would useful to recap >> this is one single section due to compatibility issues with RFC7401. >> >>> 5.2.5. ENCRYPTED_KEY >>> >>> [...] >>> >>> The ENCRYPTED_KEY parameter encapsulates a random value that is later >>> used in the session key creation process (see Section 6.3). This >>> random value MUST have a length of at least 64 bit. The puzzle value >>> #I and the puzzle solution #J (see [RFC7401]) are used as the >>> initialization vector (IV) for the encryption process. To this end, >>> the IV is computed as FOLD(I | J, 128). The AES-CTR counter is a 16 >>> bit value that is initialized to zero with the first use. >> >> The initialization vector is a explicit, separate field in RFC7401. Why >> I and J >> are implicitly reused here? To save bits? >> >> The AES-CTR counter pops out a bit suddenly here. Perhaps you could >> "bridge" it to the text in a bit more smoother way. >> >>> Once this encryption process is completed, the "encrypted value" data >>> field is ready for inclusion in the Parameter. If necessary, >>> additional Padding for 8-byte alignment is then added according to >>> the rules of TLV Format in [RFC7401]. >> >> The key could be also included in ENCRYPTED parameter, which can >> accommodate multiple parameters... unless it is very important to >> keep the IV implicit. >> >>> 5.3. HIP Packets >>> >>> [...] >>> >>> In the future, an optional upper-layer payload MAY follow the HIP >>> header. The Next Header field in the header indicates if there is >>> additional data following the HIP header. >> >> RFC6078 is also future work. >> >>> 5.3.1. I1 - the HIP Initiator Packet >>> >>> [...] >>> >>> As a compression of the employed HIs, the Initiator's and the >>> Responder's HITs both determine the DH group ID that must be used in >>> order to successfully conclude the triggered handshake. HITs, >>> however, only include the OGA ID identifying a HIP DEX HIT. They do >>> not include information about the specific DH group ID of the >>> corresponding HI. [...] >> >> Something wrong here, the first sentence is contradicting with the >> second and third one. >> >>> 5.3.2. R1 - the HIP Responder Packet >>> >>> [...] >>> >>> The R1 packet generation counter is used to determine the currently >>> valid generation of puzzles. The value is increased periodically, >>> and it is RECOMMENDED that it is increased at least as often as >>> solutions to old puzzles are no longer accepted. >> >> Section 6.1 describes: "The only exceptions are that HIP DEX does not >> use pre-computation of R1 packets and that RHASH is set to CMAC. As a >> result, the pre- computation step in in Section 6.3 of [RFC7401] is >> skipped in HIP DEX. >> >> I guess R1 packet generation counters are still meaningful for the >> Initiator (despite Responder does not pre-generate R1s)? >> >>> [...] >>> >>> The HOST_ID parameter depends on the received DH_GROUP_LIST parameter >>> and the Responder HIT in the I1 packet. Specifically, if the I1 >>> contains a Responder HIT, the Responder verifies that this HIT >>> matches the required DH group based on the received DH_GROUP_LIST >>> parameter. >> >> "...included in the I1". Right? >> >>> 5.3.3. I2 - the Second HIP Initiator Packet >>> >>> [...] >>> >>> The HIP_CIPHER contains the single encryption transform selected by >>> the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY >>> parameters. The chosen cipher MUST correspond to one of the ciphers >>> offered by the Responder in the R1. All implementations MUST support >>> the AES-CTR transform [RFC3686]. >>> >>> [...] >>> >>> The TRANSPORT_FORMAT_LIST parameter contains the single transport >>> format type selected by the Initiator. The chosen type MUST >>> correspond to one of the types offered by the Responder in the R1 >>> packet. Currently, the only transport format defined is the ESP >>> transport format [RFC7402]. >> >> Should all of the cipher suites and transport formats still be echoed >> to the Responder for security reasons? See also my next comment. >> >>> 5.3.4. R2 - the Second HIP Responder Packet >>> >>> [...] >>> >>> The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, >>> and TRANSPORT_FORMAT_LIST parameters in the R2 packet. These >>> parameters MUST be the same as included in the R1 packet. The >>> parameter are re-included here because the R2 packet is MACed and >>> thus cannot be altered by an attacker. For verification purposes, >>> the Initiator re-evaluates the selected suites and compares the >>> results against the chosen ones. If the re-evaluated suites do not >>> match the chosen ones, the Initiator acts based on its local policy. >> >> Ok, so now the full list of parameters is included, so forget about my >> previous comment. >> >>> 6.1. Solving the Puzzle >>> >>> The procedures for solving and verifying a puzzle in HIP DEX are >>> strongly based on the corresponding procedures in HIPv2. The only >>> exceptions are that HIP DEX does not use pre-computation of R1 >>> packets and that RHASH is set to CMAC. As a result, the pre- >>> computation step in in Section 6.3 of [RFC7401] is skipped in HIP >>> DEX. >> >> in in -> in >> >>> 6.2.1. CMAC Calculation >>> >>> [...] >>> >>> >>> 5. Set Checksum and Header Length fields in the HIP header to >>> original values. Note that the Checksum and Length fields >>> contain incorrect values after this step. >> >> I guess also the values following HIP_MAC should be restored since >> they were wiped in the step 2. >> >>> 6.3. HIP DEX KEYMAT Generation >> >> (this section was a bit hard to understand) >> >>> The HIP DEX KEYMAT process is used to derive the keys for the Master >>> Key SA as well as for the Pair-wise Key SA. The keys for the Master >>> Key SA are based from the Diffie-Hellman derived key, Kij, produced >> >> from -> on >> >>> The keys of the Pair-wise Key SA are not directly used in the HIP DEX >>> handshake. [...] >> >> used -> exposed in plaintext? >> >>> Some payload protection mechanisms have their own >>> Key Derivation Function, and if so this mechanism SHOULD be used. >> >> this -> such >> >>> The HIP DEX KEYMAT process consists of two components, CKDF-Extract >>> and CKDF-Expand. The Extract function compresses a non-uniformly >>> distributed key, as is the output of a Diffie-Hellman key derivation, >> >> as is -> such as >> >> >>> The key derivation for the Master Key SA employs both the Extract and >>> Expand phases, whereas the Pair-wise Key SA MAY need both the Extract >>> and Expand phases if the key is longer than 128 bits. Otherwise, it >>> only requires the Expand phase. >> >> Suggest: >> >> The key derivation for the Master Key SA employs always both the >> Extract and Expand phases. The Pair-wise Key SA needs only the Extract >> phase when key is smaller or equal to 128 bits, but otherwise requires >> also the Expand phase. >> >>> The CKDF-Extract function is the following operation: >>> >>> CKDF-Extract(I, IKM, info) -> PRK >> >> What does the arrow operator signify? I thought that it produces PRK, >> but PRK is actually defined below. >> >>> where >>> >>> I Random #I from the PUZZLE parameter >>> IKM Input keying material, i.e., either the Diffie-Hellman >>> derived key or the concatenation of the random values >>> of the ENCRYPTED_KEY parameters in the same order as >>> the HITs with sort(HIT-I | HIT-R) >> >> So how to choose between the D-H key and ENCRYPTED_KEY? Use always the >> KEY if present, otherwise D-H? >> >>> info sort(HIT-I | HIT-R) | "CKDF-Extract" >> >> Is "CKDF-Extract" an octet string? >> >>> PRK a pseudorandom key (of RHASH_len/8 octets) >>> | denotes the concatenation >>> >>> The pseudorandom key PRK is calculated as follows: >>> >>> PRK = CMAC(I, IKM | info) >> >> Based on this, I don't really know how to extract key material (the >> arrow notation is confusing). >> >>> The CKDF-Expand function is the following operation: >>> >>> CKDF-Expand(PRK, info, L) -> OKM >> >> What does the arrow mean? >> >> Maybe name "info" as "info2" because it is different variable. >> >>> where >>> >>> PRK a pseudorandom key of at least RHASH_len/8 octets >>> (either the output from the extract step or the >>> concatenation of the random values of the >>> ENCRYPTED_KEY parameters in the same order as the >>> HITs with sort(HIT-I | HIT-R)) >> >> How to choose between the extract output vs encrypted key? >> >> Maybe you should rename this as "PRK2" in order to distinguish the >> variable from the Extract phase. >> >>> info sort(HIT-I | HIT-R) | "CKDF-Expand" >> >> Is "CKDF-Expand" an octet string? >> >>> L length of output keying material in octets >>> (<= 255*RHASH_len/8) >>> | denotes the concatenation >>> >>> The output keying material OKM is calculated as follows: >>> >>> N = ceil(L/RHASH_len/8) >>> T = T(1) | T(2) | T(3) | ... | T(N) >>> OKM = first L octets of T >>> >>> where >>> >>> T(0) = empty string (zero length) >>> T(1) = CMAC(PRK, T(0) | info | 0x01) >>> T(2) = CMAC(PRK, T(1) | info | 0x02) >>> T(3) = CMAC(PRK, T(2) | info | 0x03) >>> ... >> >> The Expand was a bit more clear, but still didn't understand how to get >> to the >> Expanded key material due the arrow notation. >> >>> (where the constant concatenated to the end of each T(n) is a >>> single octet.) >> >> Is there a max value? >> >>> The initial keys are drawn sequentially in the order that is >>> determined by the numeric comparison of the two HITs, with the >>> comparison method described in the previous paragraph. HOST_g >>> denotes the host with the greater HIT value, and HOST_l the host with >>> the lower HIT value. >> >> This is just for Master keys, right? >> >>> The number of bits drawn for a given algorithm is the "natural" size >>> of the keys. For the mandatory algorithms, the following sizes >>> apply: >>> >>> AES 128 or 256 bits >> >> I would clarify that this depends on the negotiated HIP_CIPHER. >> >>> 6.5. Processing Incoming I1 Packets >>> >>> 5. If the received Responder's HIT in the I1 packet is not NULL, the >>> Responder's in the R1 packet HIT MUST match the destination HIT >> >> ...the Responder's HIT in the R1 packet MUST match... >> >>> 6.6. Processing Incoming R1 Packets >>> >>> [...] >>> >>> 1. A system receiving an R1 MUST first check to see if it has sent >>> an I1 packet to the originator of the R1 packet (i.e., it has a >>> HIP association that is in state I1-SENT and that is associated >>> with the HITs in the R1). Unless the I1 packet was sent in >>> opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP >>> addresses in the received R1 packet SHOULD be ignored by the R1 >>> processing and, when looking up the right HIP association, the >> >> right -> correct >> >>> 8. The R1 packet may have the A-bit set - in this case, the system >>> MAY choose to refuse it by dropping the R1 packet and returning >>> to state UNASSOCIATED. The system SHOULD consider dropping the >>> R1 packet only if it used a NULL HIT in the I1 packet. >> >> I didn't understand the logic in the last sentence. >> >>> Note that step 4 from the original processing rules of HIPv2 >>> (signature verification) has been removed in the above processing >>> rules for HIP DEX. Moreover, step 7 of the HIPv2 processing rules >>> has been adapted to account for the fact that HIP DEX uses ECDH >>> public keys as HIs. >> >> Step 7 in the *original* processing rules, what is the ordinal in DEX? >> It is not 7. >> >>> 6.7. Processing Incoming I2 Packets >>> >>> [...] >>> >>> 5. If the system's state machine is in the I2-SENT state, the >>> system MUST make a comparison between its local and sender's >>> HITs (similarly as in Section 6.3). If the local HIT is smaller >>> than the sender's HIT, it should drop the I2 packet, use the >>> peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce >>> #I from the R1 packet received earlier, and get the local >>> Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J >>> from the I2 packet sent to the peer earlier. Otherwise, the >>> system should process the received I2 packet and drop any >>> previously derived Diffie-Hellman keying material Kij and >>> ENCRYPTED_KEY keying material it might have generated upon >>> sending the I2 packet previously. The peer Diffie-Hellman key, >>> ENCRYPTED_KEY, and the nonce #J are taken from the just arrived >>> I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY keying >>> material, and the nonce #I are the ones that were sent earlier >>> in the R1 packet. >> >> Please replace "sender" with "peer" (or remote host) in this section >> for more symmetric terminology. >> >> get -> obtain >> >>> 11. The implementation SHOULD also verify that the Initiator's HIT >>> in the I2 packet corresponds to the Host Identity sent in the I2 >>> packet. (Note: some middleboxes may not be able to make this >>> verification.) >> >> Why SHOULD? Why not MUST? I think we're talking about end-hosts here >> anyway. >> >>> Note that steps 11 (encrypted HOST_ID) and 15 (signature >>> verification) from the original processing rules of HIPv2 have been >>> removed in the above processing rules for HIP DEX. Moreover, step 10 >>> of the HIPv2 processing rules has been adapted to account for >>> optional extension of the retransmission mechanism. Step 16 has been >>> added to the processing rules. >> >> ...in this document. >> >>> 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets >> >>> UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP DEX >>> as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of [RFC7401]). >>> The only difference is the that the HIP_SIGNATURE is never present >>> and, therefore, is not required to be processed by the receiving >>> party. >> >> How does rekeying work with the extract and expand functions? >> >>> 6.11. Handling State Loss >> >>> Implementors MAY choose to use non-volatile, secure storage for HIP >>> states in order for them to survive a system reboot. If no secure >>> storage capabilities are available, the system SHOULD delete the >>> corresponding HIP state, including the keying material. If the >>> implementation does drop the state (as RECOMMENDED), it MUST also >>> drop the peer's R1 generation counter value, unless a local policy >>> explicitly defines that the value of that particular host is stored. >>> An implementation MUST NOT store a peer's R1 generation counters by >>> default, but storing R1 generation counter values, if done, MUST be >>> configured by explicit HITs. >> >> MUST NOT -> SHOULD? Otherwise the part after this is kinda void. >> >>> 7. HIP Policies >> >>> There are a number of variables that will influence the HIP exchanges >>> that each host must support. All HIP DEX implementations SHOULD >>> provide for an ACL of Initiator's HI to Responder's HI. This ACL >>> SHOULD also include preferred transform and local lifetimes. >>> Wildcards SHOULD also be supported for this ACL. >> >> Why ACLs are mandatory? >> >> ACL -> ACL consisting of >> >>> The value of #K used in the HIP R1 must be chosen with care. Values >>> of #K that are too high will exclude clients with weak CPUs because >>> these devices cannot solve the puzzle within a reasonable amount of >>> time. #K should only be raised if a Responder is under high load, >>> i.e., it cannot process all incoming HIP handshakes any more. If a >>> Responder is not under high load, #K SHOULD be 0. >> >>> 8. Security Considerations >> >>> o The HIP DEX HIT generation may present new attack opportunities. >> >> They cannot be used in ACLs. Maybe this could be mentioned. Can this >> be mitigated by always using full HIs? >> >> >> Some additional comments related to Appendix: >> >> I think you could reference the SLIMFIT extension from Rene Hummen in >> the appendix. And possibly mention the following related work >> extending DEX that was done in the context of Convince Celtic+ >> project: >> >> P. Porambage, A. Braeken, P. Kumar, A. Gurtov and M. Ylianttila, >> "Efficient Key Establishment for Constrained IoT Devices with >> Collaborative HIP-Based Approach," 2015 IEEE Global Communications >> Conference (GLOBECOM), San Diego, CA, 2015, pp. 1-6. doi: >> 10.1109/GLOCOM.2015.7417094 >> >> The work includes also benchmarks on energy consumption. >> >> P.S. My review can be credited to Convince Celtic+. >> >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From hummen.rwth@gmail.com Mon May 16 08:50:42 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0516128B44 for ; Mon, 16 May 2016 08:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlSZM1XOcnlE for ; Mon, 16 May 2016 08:50:32 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0BC12B074 for ; Mon, 16 May 2016 08:50:32 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id g133so165645579ywb.2 for ; Mon, 16 May 2016 08:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=DOlJngVcgk5ABszd0KzFbJnTF+xw3B9kSp6g2cPbWuc=; b=qLGPPAZBYRBg/X1DzEoRXyNBVGYe/g3o82gJV+7VikmN6QGuXa3GDmhrtNUuOBV824 J7PDtG3+qf7qfRC/j1dXXh+pxIospHs18Vf7A3LnRHVDNteubSDHBm5xTuwHWkZMRZxh IXYkAp2bF0jNNP6i4U1JOFIbw2sZdBOxRHZ4g8aHyxUhyHnyKqwfFiCJcmEfsxYsiHFl SxZlsPBweW5Fu9L3V1rzf1R/zkghqwzFvyym4g744U8eVLC+PiwLBQZV7vRegFFbkEqw UJ/w2PLDrWdzDOAl8sWfBfHIxb+LIL7A+Zy2K8ImEYvITx56y9NY82EL57Ej5JpZ4k6Z Ah1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=DOlJngVcgk5ABszd0KzFbJnTF+xw3B9kSp6g2cPbWuc=; b=eBCtCQ46KnHPs3vtVT5/GZqfWHVLVb1PR7N77FuT6Gmh6rLVuMgveHDAtoCaMNbHmQ X0sBdIOCJ0N4V9WqxhbmnFiCKE/mwGZKH0uFr3eRmHFhbwKNEZcFiGbZgrLU074ym+fs Yt4rCQmCS94qN5JbQf9gi9H7Ta+dTtKcuvTV4RvtxlGBuzJ9bJNirxDbRWc95eJQcx0E TAPlNk61Xt/3CWmB8zPpLqBST28xO61eOYcrDb8drBo+G1++nmqr20lwWjH+MWYmBuJK sRvxy7gNErEmueB7MmENE/J0KEHunzFan40OYbi2NKJQDtMUjeO+QvsuQI0z4dzc4xmP +APg== X-Gm-Message-State: AOPr4FX/R1UozffXtm4W8/P4gazhxOh8WMlcmvYErY4y7zEtB+kwi69L5WiL4z4sKgs9K3S5fPeYVVwnFdhHgA== MIME-Version: 1.0 X-Received: by 10.13.198.197 with SMTP id i188mr13959236ywd.207.1463413831423; Mon, 16 May 2016 08:50:31 -0700 (PDT) Sender: hummen.rwth@gmail.com Received: by 10.129.104.135 with HTTP; Mon, 16 May 2016 08:50:31 -0700 (PDT) In-Reply-To: <56F98E90.10601@ericsson.com> References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> Date: Mon, 16 May 2016 17:50:31 +0200 X-Google-Sender-Auth: CtktuQ5_XQMugaGX33iVgppNPnA Message-ID: From: =?UTF-8?B?UmVuw6kgSHVtbWVu?= To: Miika Komu Content-Type: multipart/alternative; boundary=001a114d6f7494ea1d0532f7954d Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 15:57:46 -0000 --001a114d6f7494ea1d0532f7954d Content-Type: text/plain; charset=UTF-8 Hi Miika, all, thanks for reviewing the draft! In this email I address the first part of your comments. I will send another email concerning the remaining comments by the end of the month latest. On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu wrote: > Hi, > > > 1.1. The HIP Diet EXchange (DEX) > > > Data packets start to flow after the 4th packet. The 3rd and 4th HIP > > packets may carry data payload in the future. However, the details > > of this may be defined later. > > Similarly as in RFC7401, data packets start to flow... > > (I guess you could also mention RFC6078 as another further work item) > Changed. I didn't include RFC6078 as it appears to rely on signatures. > > > An existing HIP association can be updated with the update mechanism > > defined in [RFC7401]. Likewise, the association can be torn down > > with the defined closing mechanism for HIPv2 if it is no longer > > needed. HIP DEX thereby omits the HIP_SIGNATURE parameters of the > > original HIPv2 specification. > > Why "thereby"? I don't see the connection. > Changed to "in doing so" > > > HIP DEX does not have the option to encrypt the Host Identity of the > > Initiator in the 3rd packet. The Responder's Host Identity also is > > not protected. Thus, contrary to HIPv2, there is no attempt at > > anonymity. > > The anonymous bit still exists, so I suggest changing the wording: > > there is no attempt at anonymity -> such Responder anonymity is not > preserved in HIP DEX. > > The statement refers to both Initiator and Responder. I changed the sentence as follows: "Thus, contrary to HIPv2, HIP DEX does not provide for end-point anonymity and any signaling that indicates such anonymity should be ignored." > > 2.1. Requirements Terminology > > In section 6.3, you are introduce also -> notation, which was > not explained. > I didn't think an explanation of this formal notation was necessary as it is also not further described, e.g., in RFC5869. What would you like me to write here? > > > 2.3. Definitions > > I suggest to add also the definitions of both MAC and CMAC because they > are used throughout the document. They are also used in this section. > > Thanks! We never really said what we meant by CMAC. I now added the following definition: " CMAC: The Cipher-based Message Authentication Code with the 128-bit Advanced Encryption Standard (AES) defined in RFC 4493 [RFC4493]." I addressed the comment about the MAC by noting the abbreviation on first use: "Still, note that CMAC is a message authentication code (MAC) ..." > > 3.1. Host Identity Tag (HIT) > > Just thinking aloud... should a DEX HIT have a different context ID? > Probably not. > We decided against this as HIP DEX is a variant of HIPv2 and as such should live in the same context. > > > 4.1. Creating a HIP Association > > > The HIP Diet EXchange serves to manage the establishment of state > > between an Initiator and a Responder. The first packet, I1, > > initiates the exchange, and the last three packets, R1, I2, and R2, > > constitute an authenticated Diffie-Hellman [DH76] key exchange for > > the Master Key SA generation. This Master Key SA is used by the > > Initiator and the Responder to wrap secret keying material in the I2 > > and R2 packets. Based on the exchanged keying material, the peers > > then derive a Pair-wise Key SA if cryptographic keys are needed, > > e.g., for ESP-based protection of user data. > > (Suggest replacing "user data" with e.g. "data plane" in the entire > document since you're talking about machines (sensors) that may not > have a user) > If you don't object, I would prefer to keep it the way it is right now in order stay in line with HIPv2. > > > In the I2 packet, the Initiator MUST display the solution to the > > received puzzle. Without a correct solution, the I2 packet is > > discarded. The I2 also contains a key wrap parameter that carries a > > secret keying material of the Initiator. This keying material is > > only half the final session key. The packet is authenticated by the > > sender (Initiator) via a MAC. > > ...half *of* the... > Fixed. > > > The R2 packet acknowledges the receipt of the I2 packet and completes > > the handshake. The R2 contains a key wrap parameter that carries the > > rest of the keying material of the Responder. The packet is > > authenticated by the sender (Responder) via a MAC. > > key wrap parameter -> parameter with encrypted contents > "Parameter with encrypted contents" is more generic than what key wrap parameter (encrypted parameter with secret keying material) indicates. I kept it as is. > > > 4.1.1. HIP Puzzle Mechanism > > > > The puzzle mechanism enables a Responder to immediately reject an I2 > > packet if it does not contain a valid puzzle solution. To verify the > > puzzle solution, the Responder only has to compute a single CMAC > > operation. After a successful puzzle verification, the Responder can > > securely create session-specific state and perform CPU-intensive > > operations such as a Diffie-Hellman key generation. By varying the > > difficulty of the puzzle, the Responder can frustrate CPU or memory > > targeted DoS attacks. > > ...can frustrate *an Initiator*... > I did not change the text as it is a straight copy/paste from RFC7401. Moreover, "Initiator" would indicate to me that the adversary must be a protocol-compliant entity. So, I would prefer keep this more general statement here. > > > Conceptually, the puzzle mechanism in HIP DEX is the same as in > > HIPv2. Hence, this document refers to Sections 4.1.1 and 4.1.2 in > > [RFC7401] for more detailed information about the employed mechanism. > > Notably, the only difference between the puzzle mechanism in HIP DEX > > and HIPv2 is that HIP DEX uses CMAC instead of a hash function for > > solving and verifying a puzzle. The implications of this change on > > the puzzle implementation are discussed in Section 6.1. > > The other difference is mentioned in section 6.1: > > "The only exceptions are that HIP DEX does not use pre-computation of > R1 packets and that RHASH is set to CMAC. As a result, the pre- > computation step in in Section 6.3 of [RFC7401] is skipped in HIP DEX." > True. I added the pre-computation bit here as well. > > > 4.1.2.1. HIP DEX Retransmission Mechanism > > > The potentially high processing time of an I2 packet at a (resource- > > constrained) Responder may cause premature retransmissions if the > > time required for I2 transmission and processing exceeds the RTT- > > based retransmission timeout. Thus, the Initiator should also take > > the processing time of the I2 packet at the Responder into account > > for retransmission purposes. To this end, the Responder MAY notify > > the Initiator about the anticipated delay once the puzzle solution > > was successfully verified and if the remaining I2 packet processing > > incurs a high processing delay. The Responder MAY therefore send a > > NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator > > before the Responder commences the ECDH operation. The NOTIFY packet > > serves as an acknowledgement for the I2 packet and consists of a > > NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT > > (see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter > > contains the anticipated remaining processing time for the I2 packet > > in milliseconds as two-octet Notification Data. This processing time > > can, e.g., be estimated by measuring the computation time of the ECDH > > key derivation operation at Responder boot-up. After the I2 > > processing has finished, the Responder sends the regular R2 packet. > > ( boot-up -> start-up procedures (it doesn't have to be a boot) ) > Changed. > > > 4.1.2.3. Simplified HIP State Diagram > > > The following diagram shows the major state transitions. Transitions > > based on received packets implicitly assume that the packets are > > successfully authenticated or processed. > > Is the new NOTIFY illustrated also in the figure? > Fixed. --001a114d6f7494ea1d0532f7954d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Miika, all,

thanks for = reviewing the draft!

In this email I address the f= irst part of your comments. I will send another email concerning the remain= ing comments by the end of the month latest.

On Mo= n, Mar 28, 2016 at 10:05 PM, Miika Komu <<= span>miika.komu@ericsson.com> wrote:
Hi,

> 1.1.=C2=A0 The HIP Diet EXchange (DEX)

> Data packets start to flow after the 4th packet.=C2=A0 The 3rd and 4th= HIP
> packets may carry data payload in the future.=C2=A0 However, the detai= ls
> of this may be defined later.

Similarly as in RFC7401, data packets start to flow...

(I guess you could also mention RFC6078 as another further work item)

Changed. I didn't include RFC6078 as it = appears to rely on signatures.
=C2=A0

> An existing HIP association can be updated with the update mechanism > defined in [RFC7401].=C2=A0 Likewise, the association can be torn down=
> with the defined closing mechanism for HIPv2 if it is no longer
> needed.=C2=A0 HIP DEX thereby omits the HIP_SIGNATURE parameters of th= e
> original HIPv2 specification.

Why "thereby"? I don't see the connection.

Changed to "in doing so"
=C2=A0
=

> HIP DEX does not have the option to encrypt the Host Identity of the > Initiator in the 3rd packet.=C2=A0 The Responder's Host Identity a= lso is
> not protected.=C2=A0 Thus, contrary to HIPv2, there is no attempt at > anonymity.

The anonymous bit still exists, so I suggest changing the wording:

there is no attempt at anonymity -> such Responder anonymity is not pres= erved in HIP DEX.


The statement refers to both Initiator= and Responder. I changed the sentence as follows:
"Thus, co= ntrary to HIPv2, HIP DEX does not provide for end-point anonymity and any s= ignaling that indicates such anonymity should be ignored."
= =C2=A0
> 2.1.=C2=A0 Requirements Terminology

In section 6.3, you are introduce also -> notation, which was
not explained.

I didn't think an ex= planation of this formal notation was necessary as it is also not further d= escribed, e.g., in RFC5869. What would you like me to write here?
=C2=A0

> 2.3.=C2=A0 Definitions

I suggest to add also the definitions of both MAC and CMAC because they
are used throughout the document. They are also used in this section.


Thanks! We never really said what we m= eant by CMAC. I now added the following definition:
= " =C2=A0 CMAC: =C2=A0The Cipher-based Message Authenticat= ion Code with the 128-bit
=C2=A0 =C2=A0 =C2=A0 Advanced Encryptio= n Standard (AES) defined in RFC 4493 [RFC4493]."

I addressed the comment about the MAC by noting the abbrev= iation on first use: "Still, note that CMAC is a message = authentication code (MAC) ..."
=C2=A0
> 3.1.=C2=A0 Host Identity Tag (HIT)

Just thinking aloud... should a DEX HIT have a different context ID?
Probably not.

We decided against this a= s HIP DEX is a variant of HIPv2 and as such should live in the same context= .=C2=A0
=C2=A0

> 4.1.=C2=A0 Creating a HIP Association

> The HIP Diet EXchange serves to manage the establishment of state
> between an Initiator and a Responder.=C2=A0 The first packet, I1,
> initiates the exchange, and the last three packets, R1, I2, and R2, > constitute an authenticated Diffie-Hellman [DH76] key exchange for
> the Master Key SA generation.=C2=A0 This Master Key SA is used by the<= br> > Initiator and the Responder to wrap secret keying material in the I2 > and R2 packets.=C2=A0 Based on the exchanged keying material, the peer= s
> then derive a Pair-wise Key SA if cryptographic keys are needed,
> e.g., for ESP-based protection of user data.

(Suggest replacing "user data" with e.g. "data plane" i= n the entire
document since you're talking about machines (sensors) that may not
have a user)

If you don't object, I= would prefer to keep it the way it is right now in order stay in line with= HIPv2.=C2=A0
=C2=A0

> In the I2 packet, the Initiator MUST display the solution to the
> received puzzle.=C2=A0 Without a correct solution, the I2 packet is > discarded.=C2=A0 The I2 also contains a key wrap parameter that carrie= s a
> secret keying material of the Initiator.=C2=A0 This keying material is=
> only half the final session key.=C2=A0 The packet is authenticated by = the
> sender (Initiator) via a MAC.

...half *of* the...

Fixed.
= =C2=A0

> The R2 packet acknowledges the receipt of the I2 packet and completes<= br> > the handshake.=C2=A0 The R2 contains a key wrap parameter that carries= the
> rest of the keying material of the Responder.=C2=A0 The packet is
> authenticated by the sender (Responder) via a MAC.

key wrap parameter -> parameter with encrypted contents
=

"Parameter with encrypted contents" is more g= eneric than what key wrap parameter (encrypted parameter with secret keying= material) indicates. I kept it as is.
=C2=A0

> 4.1.1.=C2=A0 HIP Puzzle Mechanism
>
> The puzzle mechanism enables a Responder to immediately reject an I2 > packet if it does not contain a valid puzzle solution.=C2=A0 To verify= the
> puzzle solution, the Responder only has to compute a single CMAC
> operation.=C2=A0 After a successful puzzle verification, the Responder= can
> securely create session-specific state and perform CPU-intensive
> operations such as a Diffie-Hellman key generation.=C2=A0 By varying t= he
> difficulty of the puzzle, the Responder can frustrate CPU or memory > targeted DoS attacks.

...can frustrate *an Initiator*...

I di= d not change the text as it is a straight copy/paste from RFC7401. Moreover= , "Initiator" would indicate to me that the adversary must be a p= rotocol-compliant entity. So, I would prefer keep this more general stateme= nt here.
=C2=A0

> Conceptually, the puzzle mechanism in HIP DEX is the same as in
> HIPv2.=C2=A0 Hence, this document refers to Sections 4.1.1 and 4.1.2 i= n
> [RFC7401] for more detailed information about the employed mechanism.<= br> > Notably, the only difference between the puzzle mechanism in HIP DEX > and HIPv2 is that HIP DEX uses CMAC instead of a hash function for
> solving and verifying a puzzle.=C2=A0 The implications of this change = on
> the puzzle implementation are discussed in Section 6.1.

The other difference is mentioned in section 6.1:

"The only exceptions are that HIP DEX does not use pre-computation of<= br> R1 packets and that RHASH is set to CMAC.=C2=A0 As a result, the pre-
computation step in in Section 6.3 of [RFC7401] is skipped in HIP DEX."= ;

True. I added the pre-co= mputation bit here as well.
=C2=A0

> 4.1.2.1.=C2=A0 HIP DEX Retransmission Mechanism

> The potentially high processing time of an I2 packet at a (resource- > constrained) Responder may cause premature retransmissions if the
> time required for I2 transmission and processing exceeds the RTT-
> based retransmission timeout.=C2=A0 Thus, the Initiator should also ta= ke
> the processing time of the I2 packet at the Responder into account
> for retransmission purposes.=C2=A0 To this end, the Responder MAY noti= fy
> the Initiator about the anticipated delay once the puzzle solution
> was successfully verified and if the remaining I2 packet processing > incurs a high processing delay.=C2=A0 The Responder MAY therefore send= a
> NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator
> before the Responder commences the ECDH operation.=C2=A0 The NOTIFY pa= cket
> serves as an acknowledgement for the I2 packet and consists of a
> NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT
> (see Section 5.2.19. in [RFC7401]).=C2=A0 The NOTIFICATION parameter > contains the anticipated remaining processing time for the I2 packet > in milliseconds as two-octet Notification Data.=C2=A0 This processing = time
> can, e.g., be estimated by measuring the computation time of the ECDH<= br> > key derivation operation at Responder boot-up.=C2=A0 After the I2
> processing has finished, the Responder sends the regular R2 packet.
( boot-up -> start-up procedures (it doesn't have to be a boot) )

Changed.
=C2=A0

> 4.1.2.3.=C2=A0 Simplified HIP State Diagram

> The following diagram shows the major state transitions.=C2=A0 Transit= ions
> based on received packets implicitly assume that the packets are
> successfully authenticated or processed.

Is the new NOTIFY illustrated also in the figure?

=
Fixed.

--001a114d6f7494ea1d0532f7954d-- From nobody Fri May 20 02:49:18 2016 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340BF12D79E for ; Fri, 20 May 2016 02:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTLa8hoE71uZ for ; Fri, 20 May 2016 02:49:15 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19BCB12D78D for ; Fri, 20 May 2016 02:49:13 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-b7-573edd9729ac Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F1.10.27088.79DDE375; Fri, 20 May 2016 11:49:11 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.248.2; Fri, 20 May 2016 11:48:58 +0200 To: =?UTF-8?Q?Ren=c3=a9_Hummen?= References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> From: Miika Komu Organization: Ericsson AB Message-ID: <573EDD8A.6050405@ericsson.com> Date: Fri, 20 May 2016 12:48:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040500080600030402080002" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbHdWHf6Xbtwg0nPFC2mLprMbPHu6HcW ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvj7a+9bAVtphVzNk5jbGCcYdTFyMkhIWAi ceHxQiYIW0ziwr31bF2MXBxCAkcYJf48us8E4axmlPg94QRYlbCAtcTUDzfZQWwRATuJJUce skIUrWCUWHrlG5DDwcEsICqxfVYVSA2bgJbEqjvXmUFsfgFJiQ0Nu8FsXgFtiXctKxlBbBYB VYmDh56DxUUFIiRmbf/BBFEjKHFy5hMWEJtTIFDi0ZPt7CC7mAW6GSVenj7ICLJLSEBF4uKx 4AmMgrOQtMxCVgaSYBYwk5i3+SEzhK0tsWzhayjbWmLGr4NsELaixJTuh+wQtqnE66MfoXqN JZat+8u2gJFjFaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZgrBzc8ttgB+PL546HGAU4GJV4 eBfk24ULsSaWFVfmHmJUAZrzaMPqC4xSLHn5ealKIrwqd4DSvCmJlVWpRfnxRaU5qcWHGKU5 WJTEef1fKoYLCaQnlqRmp6YWpBbBZJk4OKUaGGPZ5QIKXA1+Cuzby5E++1bDpcoyO/NJ5w7n 6tU/i7ib2XbQLCGhcxnzb72Vj+QC3mjsv9ImdstooVPJZflJftGh779Uq5st+uwcaO3go9lq f/Fqi6XBrpSNnw+x74zuPag8xeIK/8H4oJ0fvhX5xqpuYK39VJ+/94paeI/S4rsWX1JPrLa6 pMRSnJFoqMVcVJwIAJk9prOdAgAA Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 09:49:16 -0000 --------------ms040500080600030402080002 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On 05/16/2016 06:50 PM, Ren=C3=A9 Hummen wrote: > Hi Miika, all, > > thanks for reviewing the draft! my pleasure. I am ok with your changes, just a small note below. > > 2.1. Requirements Terminology > > In section 6.3, you are introduce also -> notation, which was > not explained. > > > I didn't think an explanation of this formal notation was necessary as > it is also not further described, e.g., in RFC5869. What would you like= > me to write here? I should probably read RFC5869 before I can understand how to implement=20 the key derivation for DEX. It was a bit difficult to follow what is the = input and especially what is the resulting output. The reference for RFC5869 is missing? --------------ms040500080600030402080002 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNTIwMDk0ODU4 WjAvBgkqhkiG9w0BCQQxIgQgPqfguaIqWBbfpHEWRxo8rm5rouEucyFymX7fnTodyG4wXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBmU56Qrv20 7TK2vr++5qTTRXlUwXl+8HGxGd19yXXwNnSjHobaVjqc1EZiDAc71Pl7TOLx82rc1TarPF29 +tPZCSlT1aMiFwjazUmOWsbg6wdejIo85AG0Kp895W4O/eW/QPWogGpuFFPb6zhVHutXQMQl SEK0vFU6qsOV/lhXQAFLU40Rij7Zl9OPF7XOh6YrAhKVhzWaI9nCsZW4QKHcyPMNutPo9Hcm 0+fRTCnhLT5G6x++kbdagAyZVBrl5rLQO/qqU7z3FJS9MBedxFBXAbRyuMI88kydkbY1d2LG f5dg+u1yakyDIJdM2cxQNyuK8sS18MRxq3l5dEPW4q8DAAAAAAAA --------------ms040500080600030402080002-- From nobody Tue May 31 22:34:07 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72AB712D98A; Tue, 31 May 2016 22:34:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160601053403.20280.69475.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 22:34:03 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5206-bis-12.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 05:34:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Host Mobility with the Host Identity Protocol Authors : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-rfc5206-bis-12.txt Pages : 33 Date : 2016-05-31 Abstract: This document defines mobility extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR_SET" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR_SET parameter can also be used to support end-host multihoming, detailed procedures are out of scope for this document. This document obsoletes RFC 5206. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-rfc5206-bis-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5206-bis-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 31 22:37:57 2016 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 462DE12B03C; Tue, 31 May 2016 22:37:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160601053755.20171.62025.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 22:37:55 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-multihoming-09.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 05:37:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Host Multihoming with the Host Identity Protocol Authors : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-multihoming-09.txt Pages : 21 Date : 2016-05-31 Abstract: This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-multihoming-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-multihoming-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/