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

[Miika Komu <[e-mail]>]

Hi,

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.

...and?

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