Re: [Hipsec] a review of ietf-hip-rfc5206-bis-10
Miika Komu <miika.komu@ericsson.com> Tue, 03 May 2016 11:59 UTC
Return-Path: <miika.komu@ericsson.com>
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 <hipsec@ietfa.amsl.com>; 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 <hipsec@ietfa.amsl.com>; 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 <hipsec@ietf.org>; 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 <tomhend@u.washington.edu>
References: <alpine.LRH.2.01.1605022331090.18246@hymn01.u.washington.edu>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <5728928A.50109@ericsson.com>
Date: Tue, 03 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: <alpine.LRH.2.01.1605022331090.18246@hymn01.u.washington.edu>
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: <http://mailarchive.ietf.org/arch/msg/hipsec/vLzinPavPM-sJaqJrWFMRgAuIhc>
Cc: hip WG <hipsec@ietf.org>
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." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 May 2016 11:59:58 -0000
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 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. ok. >> > 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. 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 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). Ok. (I would perhaps reverse the meaning of the sentence and state what is possible with mobility support; it is always a bit difficult read 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 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)'. Ok. >> >> > 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'. 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 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? This text just talks just about forging. I would also state that replay 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 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." 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 number >> > 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 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 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 ok >> >> > 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) Sounds better.
- [Hipsec] a review of ietf-hip-rfc5206-bis-10 Miika Komu
- Re: [Hipsec] a review of ietf-hip-rfc5206-bis-10 Tom Henderson
- Re: [Hipsec] a review of ietf-hip-rfc5206-bis-10 Miika Komu
- Re: [Hipsec] a review of ietf-hip-rfc5206-bis-10 Tom Henderson
- Re: [Hipsec] a review of ietf-hip-rfc5206-bis-10 Miika Komu