RE: [Hipsec] some comments for mm-03

["Henderson, Thomas R" <[e-mail]>]

Here is the response to the last batch of initial comments:
 

> -----Original Message-----
> From: Miika Komu [mailto:[e-mail]] 
> Sent: Wednesday, April 05, 2006 12:34 AM
> To: [e-mail]
> Subject: Re: [Hipsec] some comments for mm-03
> 
> My last comments, from section six:
> 
> > 6.  Security Considerations
> >
> > If no precautionary measures are taken, an attacker could 
> misuse this
> > feature to impersonate a victim's peer from any arbitrary location.
> 
> s/this/the redirection/

OK

> 
> > If an attacker somehow uses a bug in the implementation or 
> weakness in
> > some protocol to redirect a HIP connection, the original owner can
> > always reclaim their connection (they can always prove 
> ownership of the
> > private key associated with their public HI).
> 
> How is this possible if the private key is compromised?

As pekka suggested, this case is out of scope.

> 
> > 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, but once the base exchange has taken 
> place even a
> > MitM cannot steal an opportunistic HIP connection 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.
> 
> This was mostly a readibility comment. I suggest changing the text as
> follows:
> 
> MitM attacks are always possible when the attacker is present 
> during the
> initial HIP base exchange and the hosts do not authenticate 
> each other's
> identities. However, once the opportunistic base 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.
> 

OK

> > 6.2.  Denial of Service attacks
> 
> > This threat is mitigated through reachability checks and 
> credit-based
> > authorization.
> 
> This threat is mitigated through reachability checks and credit-based
> authorization strategies.

I think Christian would object to this additional word because it may
suggest that alternate CBA strategies are equivalent, so I will leave it
out.

> 
> > As a result, the combination of a reachability check and 
> credit-based
> > authorization makes a HIP redirection-based flooding attack 
> as effective
> > and applicable as a normal, direct flooding attack in which 
> the attacker
> > itself sends the flooding traffic to the victim.
> 
> As a result, the combination of a reachability check and credit-based
> authorization degrades a HIP redirection-based flooding attack to the
> level of a direct flooding attack in which the attacker 
> itself sends the
> flooding traffic to the victim.

s/degrades/lowers
otherwise, I'm OK with the change

> 
> > First, when a reachability packet is received, this nonce 
> packet MUST be
> > ignored if the HIT is not one that is currently active.
> 
> First, when a reachability packet is received, the nonce in the packet
> MUST be ignored if the HIT is not one that is currently active.
> 
> What does a currently active HIT mean? You probably mean address...

No, I think it pertains to the case when multiple HITs are on a host-- I
have tried to clarify this.

> 
> > Second, if the attacker is a MitM asnd can capture this nonce packet
> > then it can respond to it, in which case it is possible for 
> an attacker
> > to redirect the connection.
> 
> How?

I think it would require the ECHO_REQUEST/RESPONSE to be outside the
signature, and for another HIP packet to be available to be replayed.  I
think that is unlikely scenario in this case.

But reading this has raised an interesting question in my mind.
Currently, there is no requirement for the nonce to be signed.  The base
spec and this spec do not specify whether ECHO_REQUEST is inside or
outside the signature.  Should it be one way or the other?

I think that the last paragraph in Section 6.2.1 can be safely deleted.

> 
> > 6.2.2.  Memory/Computational exhaustion DoS attacks
> 
> Suggest adding some text that central servers may have to deal with
> multiple mobile clients that change their location rapidly. This may
> burn too many CPU cycles of the server, and in such a case, 
> the server may
> want to e.g. increase its SA lifetimes or increase cookie 
> difficulty to
> slow down acceptance of new connections.

How about:
"         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."

> 
> > 6.3.  Mixed deployment environment
> 
> s/user/host/ in this section?
> s/their/its/ in this section
> 
> I did not get the purpose of this section. If you user A uses 
> IPsec, user
> B does not get anything meaninful even though the IPsec data 
> is redirected
> from A to B.
> 
> > ..connection with and then attempts to use a IPv6 change of address
> > request to steal the HIP user's connection.
> 
> ..connection with and then attempts to change its IPv6 
> address to steal
> the HIP user's connection.

s/IPv6/IP/; otherwise OK

Also, I changed the last case a little bit as follows:
           " 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
               use of HIP address check information to influence non-HIP
sessions."

> 
> > 4. ..
> 
> What is a session here? TCP session?

upper layer session-- TCP or otherwise
> 
> 
> -- 
> Miika Komu              [e-mail]          http://www.iki.fi/miika/
> 
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/hipsec
> 

_______________________________________________
Hipsec mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hipsec