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

Miika Komu <> Tue, 03 May 2016 11:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7080512D77B for <>; Tue, 3 May 2016 04:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2yvcVM0EKQVt for <>; Tue, 3 May 2016 04:59:55 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2031C12D779 for <>; Tue, 3 May 2016 04:59:54 -0700 (PDT)
X-AuditID: c1b4fb25-f79f26d00000327e-38-572892b9d517
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id DB.B7.12926.9B298275; Tue, 3 May 2016 13:59:53 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Tue, 3 May 2016 13:59:06 +0200
To: Tom Henderson <>
References: <>
From: Miika Komu <>
Organization: Ericsson AB
Message-ID: <>
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: <>
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-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

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.


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

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


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

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


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


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