Re: a review of ietf-hip-rfc5206-bis-10

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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec