Subject: [Hipsec] Comments on draft-nikander-hip-mm

From: [email-masked] (Henderson, Thomas R)
Date: Fri Apr 16 20:45:01 2004

> -----Original Message-----
> From: Jonathan Wood [mailto:[email-masked]]
> Sent: Friday, April 16, 2004 3:17 PM
> To: [email-masked]
> Subject: [Hipsec] Comments on draft-nikander-hip-mm
>=20
>=20
>=20
> I have some comments about the current design for the
> mm draft (draft-nikander-hip-mm-0*). These comments are
> mostly high-level and apply to both version 00 and 01.
>=20
> Use of SAs in MM
> ----------------
> I'm not very comfortable with the use of new/multiple SAs
> to handle new addresses. It is a pretty heavy weight and
> complex way to add a new address, and getting IPSec policy
> management to select the right SA based on the ultimate IP
> address selected would be pretty tricky (and require lots
> of hacking :).
>=20
>  From reading back over the archives, it appears that
> the primary motivation for this approach is to handle
> the case of packets sent on different links with
> different latencies falling outside the ESP replay
> window.
>=20
> However, if you have a decent RTT estimate for each
> path to the peer, it should be possible to adjust the
> replay window according to your link conditions. (More
> on RTT estimation later). If this is the case, is there
> still a need to create a new SA for each new address
> put in use?

In the new draft I just sent around, it is explicitly=20
stated that the main reason a host may want new SAs is
due to replay window.  However, it also says that it is
up to the host whether to generate new SAs upon a readdress
event-- i.e., REA is decoupled from NES in the proposed
draft.

>=20
> Address States
> --------------
> Currently the drafts specify that a host maintain
> address state on each peer address (active, unverified,
> deprecated), and one of the addresses is preferred.
>=20
> I think that there are some problems with this approach.
> A host really only cares about active addresses -
> if it wants to switch to a new address in the case of
> path failure, it wants the backup to already be active
> so there is no delay in failing over. If it wants to
> send some packets on one path and other packets on
> another path, it also wants both paths to be active and
> verified. Keeping track of unverified and deprecated
> addresses seems to be a waste of resources.
>=20
> So perhaps dropping the unverified and deprecated states
> might be a better approach. All addresses are verified
> for return routability (if policy dictates) upon receipt.

It seems like you are really only arguing for dispensing
with DEPRECATED.  DEPRECATED state seems implicitly to
me to be an implementation option-- maybe it should be
an explict MAY?  I think Pekka introduced this address=20
state- he may have more to say about it.   =20

>=20
> The other mechanism that probably needs to be in place
> for this to work is some sort of periodic probe to verify
> that the path is still alive. This probe can also be used
> to estimate RTTs for each path, which can then be used to
> set the ESP replay window. The path RTTs can also be fed
> to transport protocols.
>=20
> For a mature example on how to do this sort of thing, see
> SCTP (rfc2960) and its heartbeat mechanism.

This could perhaps be accomplished via existing mechanisms,
using a naked UPDATE packet. =20

"A host MAY periodically probe the reachability of an=20
address using an UPDATE packet.  A host MAY use packet
exchanges on a particular address to estimate the path
RTT, which could be used to set the ESP replay window
or fed to transport protocols."  ??

>=20
> 3-Way Exchange Reliability
> --------------------------
> Adding a new address involves a protocol exchange
> conceptually like this (RR =3D return routability check):
>=20
>=20
> Initator       Responder
>          REA
>    -------------->
>    RR Request/Ack
>    <--------------
>       RR Reply
>    --------------->
>=20
> Currently the RR request doubles as an ack for the REA.
> Presumably the REA will be retransmitted if no RR
> request is received after some time (via the UPDATE
> protocol in draft version 01). However, there is no such
> mechanism in place to ensure the the RR reply gets
> best effort delivery (whether it be data or a HIP TLV).
> If it gets lost, the address verification is left in limbo.
> I think we need something more reliable. Two (not terribly
> attractive) possibilities are having the responder retransmit
> the RR request, or going with a 4-way exchange with the
> initiator retransmitting the RR reply if necessary.
> [ Does this also apply to the UPDATE exchange in the base
>    protocol? ]

See the new draft.  I think there are a couple of ways that
REA could occur, depending on the circumstances:

1.=20
   REA in NOTIFY
----------------->
                   (recipient does nothing-- trusted host)

2.
   REA in UPDATE
----------------->
  UPDATE (reply)
<----------------  (recipient does nothing but reply (ack) the REA

3. =20
  REA in NOTIFY
---------------->
  UPDATE  =20
<---------------  (recipient wants a RR check on the address)
  UPDATE (reply)
---------------->

4.  REA in NOTIFY
---------------->
  UPDATE (NES)
<---------------  (recipient wants a RR check and a new SA)
  UPDATE (reply)
---------------->

5.  REA in UPDATE
----------------->
   UPDATE (reply)
<----------------- (recipient must ack first UPDATE before sending own =
RR check/NES)
   UPDATE (NES)
<-----------------
   UPDATE (reply)
----------------->

(at least, that is what I was hoping for in the proposed
new draft-- to have this flexibility). =20

>=20
> A Security Consideration
> ------------------------
> Currently the drafts with allow a peer to add an
> unlimited number of addresses to an assocation. This could
> open a window to an attack where a host attempts to
> exhaust its peer's memory resources by adding lots of
> addresses. HIP implementations should allow administrators
> to place limits on the number of peer addresses added.
> However, when the limit is reached, will we need some
> protocol mechanism to inform the peer that the address
> addition has been rejected?
>=20

This could be in the new NOTIFY mechanism.

> CGA Addresses?
> --------------
> Just curious:
> If a peer's address is a CGA and can be verified against
> the peer's public key, can we skip RR?
>=20

I'm not following-- any REA can be verified against the
peer's public key via the signature? =20

Tom

---

From: [email-masked] (Jonathan Wood)
Date: Tue Apr 20 13:05:06 2004

On Apr 16, 2004, at 6:33 PM, Henderson, Thomas R wrote:

<...>

> In the new draft I just sent around, it is explicitly

OK, I think this is better.

<...>

> an explict MAY?

This sounds like a better way to handle it.

<...>

> 1.

What happens if the NOTIFY packet is lost?

>    REA in UPDATE

OK.

> 3.
>   UPDATE

OK - the UPDATE will be retransmitted if no reply comes back, right?

> 4.  REA in NOTIFY

Same as 3.

>
> 5.  REA in UPDATE
> ----------------->
>    UPDATE (reply)
> <----------------- (recipient must ack first UPDATE before sending own 
> RR check/NES)
>    UPDATE (NES)
> <-----------------
>    UPDATE (reply)
> ----------------->
>
> new draft-- to have this flexibility).
>
>>
>> A Security Consideration
>> ------------------------

Yes, I need to review the upcoming NOTIFY text.