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

[Tom Henderson <[e-mail]>]

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