[Hipsec] a review of ietf-hip-rfc5206-bis-10

Miika Komu <miika.komu@ericsson.com> Sun, 17 April 2016 20:27 UTC

Return-Path: <miika.komu@ericsson.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6C41012D806 for <hipsec@ietfa.amsl.com>; Sun, 17 Apr 2016 13:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TUiJOkL1pLy6 for <hipsec@ietfa.amsl.com>; Sun, 17 Apr 2016 13:27:19 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8E912D771 for <hipsec@ietf.org>; Sun, 17 Apr 2016 13:27:18 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-c1-5713f1a49bec
Received: from ESESSHC002.ericsson.se (Unknown_Domain []) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C7.85.12926.4A1F3175; Sun, 17 Apr 2016 22:27:16 +0200 (CEST)
Received: from [] ( by smtp.internal.ericsson.com ( with Microsoft SMTP Server id; Sun, 17 Apr 2016 22:26:40 +0200
To: hip WG <hipsec@ietf.org>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <5713F17F.1060405@ericsson.com>
Date: Sun, 17 Apr 2016 23:26:39 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020506060408060302040805"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvje6Sj8LhBusb9CymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLMH57EWrO5krPi/aAFjA+PNki5GTg4JAROJ5taJ7BC2mMSF e+vZuhi5OIQEjjJKPDhxhx3CWc0ocXPxdhaQKhEBGYkNm16wgthsAloSq+5cZwaxhQV0JP5P WsYEYvMLSEpsaNgNFucV0JY4snQvI4jNIqAqcezMLjYQW1QgQuLJ3JOMEDWCEidnPmEBWcYs 0M0oMWH9H6DNHECbVSQuHguewMg3C0nZLGRlIAlmATOJeZsfMkPY2hLLFr6Gsq0lZvw6yAZh K0pM6X4IVW8q8froR0YI21hi2bq/bAsYOVYxihanFiflphsZ66UWZSYXF+fn6eWllmxiBAb0 wS2/VXcwXn7jeIhRgINRiYdX4Z1QuBBrYllxZe4hRhWgOY82rL7AKMWSl5+XqiTC+/O1cLgQ b0piZVVqUX58UWlOavEhRmkOFiVx3uzIf2FCAumJJanZqakFqUUwWSYOTqkGxpL+xB3XzOYm fk09oz8/k5tHO+Ok8+k3+kf6clar53Ck3Vntt2S2/VIWRvNLGuHJ1kejl55ZcmRym22XQ9Hm nxuMPRzW75kkN7cwttq5JEAw+Xljz+S/u/76VORNdJmTsXNVuwZ7c0Dl6alJDyfOimks9lzr HXzi1ucnLManvrRHn5dkmXL+lxJLcUaioRZzUXEiABwvRzBwAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/0bKkmDFWyTnhtK8w2UoAh8JATG0>
Subject: [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: Sun, 17 Apr 2016 20:27:21 -0000


I read through ietf-hip-rfc5206-bis-10, and it is in pretty good shape. 
Below are a few nits.

 > 3.1.  Operating Environment
 > [...]
 > Consider next a mobility event, in which a host moves to another IP
 > address.  Two things must occur in this case.  First, the peer must
 > be notified of the address change using a HIP UPDATE message.
 > Second, each host must change its local bindings at the HIP sublayer
 > (new IP addresses).  It may be that both the SPIs and IP addresses
 > are changed simultaneously in a single UPDATE; the protocol described
 > herein supports this.  However, elements of procedure to recover from

I think simultaneous mobility is covered as already mentioned in the intro?

 > 3.2.3.  Mobility messaging through rendezvous server
 > 3.  A host receiving an UPDATE packet MUST be prepared to process the
 > FROM and RVS_HMAC parameters, and MUST include a VIA_RVS
 > parameter in the UPDATE reply that contains the ACK of the UPDATE
 > SEQ.

(I would add that the return routability test should be invoked to the
end-host's addresses rather than the ones in VIA_RVS)

 > 4.  This scenario requires that hosts using rendezvous servers also
 > take steps to update their current address bindings with their
 > rendezvous server upon a mobility event.
 > [I-D.ietf-hip-rfc5204-bis] does not specify how to update the
 > rendezvous server with a client host's new address.
 > [I-D.ietf-hip-rfc5203-bis] Section 3.2 describes how a host may
 > send a REG_REQUEST in either an I2 packet (if there is no active
 > association) or an UPDATE packet (if such association exists).

(Maybe this should have been actually step 0)

 > The procedures described in [I-D.ietf-hip-rfc5203-bis] for
 > sending a REG_REQUEST and REG_RESPONSE to the rendezvous server
 > apply also to this mobility scenario.

This was a bit vague, how?

 > 3.2.4.  Network Renumbering
 > It is expected that IPv6 networks will be renumbered much more often
 > than most IPv4 networks.  From an end-host point of view, network
 > renumbering is similar to mobility.


 > 3.3.  Other Considerations
 > 3.3.1.  Address Verification
 > When a HIP host receives a set of locators from another HIP host in a
 > LOCATOR_SET, it does not necessarily know whether the other host is
 > actually reachable at the claimed addresses.  In fact, a malicious
 > peer host may be intentionally giving bogus addresses in order to
 > cause a packet flood towards the target addresses [RFC4225].
 > Therefore, the HIP host must first check that the peer is reachable
 > at the new address.
 > An additional potential benefit of performing address verification is
 > to allow middleboxes in the network along the new path to obtain the
 > peer host's inbound SPI.
 > Address verification is implemented by the challenger sending some
 > piece of unguessable information to the new address, and waiting for
 > some acknowledgment from the Responder that indicates reception of
 > the information at the new address.  This may include the exchange of
 > a nonce, or the generation of a new SPI and observation of data
 > arriving on the new SPI.

I suggest would move the second paragraph after the third one.

 > 3.3.2.  Credit-Based Authorization
 > On this basis, rather than eliminating malicious packet redirection
 > in the first place, Credit-Based Authorization prevents
 > amplifications.  This is accomplished by limiting the data a host can
 > send to an unverified address of a peer by the data recently received
 > from that peer.  Redirection-based flooding attacks thus become less
 > attractive than, for example, pure direct flooding, where the
 > attacker itself sends bogus packets to the victim.

Reference section 5.6?

 > 4.3.  UPDATE Packet with Included LOCATOR_SET
 > A number of combinations of parameters in an UPDATE packet are
 > possible (e.g., see Section 3.2).  In this document, procedures are
 > defined only for the case in which one LOCATOR_SET and one ESP_INFO
 > parameter is used in any HIP packet.  Furthermore, the LOCATOR_SET
 > SHOULD list all of the locators that are active on the HIP
 > association (including those on SAs not covered by the ESP_INFO
 > parameter).

What do you mean by "including those on SAs..."?

 > Any UPDATE packet that includes a LOCATOR_SET parameter
 > SHOULD include both an HMAC and a HIP_SIGNATURE parameter.

Please add a paragraph break here.

 > The UPDATE MAY also include a HOST_ID parameter (which may be useful for
 > middleboxes inspecting the HIP messages for the first time).  If the
 > UPDATE includes the HOST_ID parameter, the receiving host MUST verify
 > that the HOST_ID corresponds to the HOST_ID that was used to
 > establish the HIP association, and the HIP_SIGNATURE must verify with
 > the public key assodiated with this HOST_ID parameter.

assodiated -> associated

Please add a paragraph break here.

 > The relationship between the announced Locators and any ESP_INFO
 > parameters present in the packet is defined in Section 5.2.  This
 > draft does not support any elements of procedure for sending more
 > than one LOCATOR_SET or ESP_INFO parameter in a single UPDATE.

draft -> document

 > 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?

 > 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

 > 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?

 > 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?

 > 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, ...

By the way, I didn't get why the lack of mobility support can lead
MiTM attacks?

 > 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?)

 > 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?

 > 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...

 > 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.

 > 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

 > 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?

 > 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?

 > 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?

 > 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?