Subject: [Hipsec] Review of draft-ietf-hip-mm-01

From: Christian Vogt <[email-masked]>
Date: Sun, 12 Jun 2005 18:00:02 +0200

Hi everybody,

reviewing draft-ietf-hip-mm-01, a couple of things came to my mind:

(1)  Address verification.  The draft mentiones in several places that a
correspondent host may omit address verification for a mobile or
multi-homed peer in case that peer is sufficiently trusted to provide
the right addresses.  I don't think trust eliminates the need for an
address check, however.  James Kempf brought this up on the Mobopts
mailing list [1].  If we omit the address check for "trusted" nodes,
those nodes could still be compromised by malware and start to redirect
packets.  In other words, a node redirecting packets to the wrong
address may not do this by intention; the perpetrator could be someone
else who brought that node under his control through a viral software.

Admittedly, the use of IPsec ESP would probably require a very
sophisticated virus/worm...

Anyway, I'd propose to make address verification a MUST in all cases.
Note that the verification won't delay communications since we are now
using Credit-Based Authorization (CBA).

I drafted possible modifications for the affected paragraphs and sent
them to the co-editors of draft-ietf-hip-mm-01 as part of my CBA-related
modifications.

(2)  Section 7.1 (Sending LOCATORs) and 7.2 (Handling received
LOCATORs):  There is mentioning of an "SPI field" inside the LOCATOR
parameter.  Is this a relict from draft-ietf-hip-mm-00?  There used to
be a SPI field in the REA parameter, but there is none in the LOCATOR
parameter.  As far as I understand, the SPI is now part of the Locator
field.

(3)  Section 7.1 (Sending LOCATORs).  Paragraph 8 says:

    "If there are multiple LOCATOR parameters leading to a packet size
    that exceeds the MTU, the host SHOULD send multiple packets, each
    smaller than the MTU.  In the case of R1 and I2, the additional
    packets should be UPDATE packets that are sent after the base
    exchange has been completed."

My concern is this:  Any locator not in the first packet will
(temporarily) be set to DEPRECATED status according to paragraph 5 of
this section.  Even when it shows up in a subsequent packet, it will
first go to UNVERIFIED status, and address verification will have to be
accomplished even if the locator was in ACTIVE status before the first
packet arrived.  So it seems that splitting the locator set over
multiple packets would be sub-optimal.

Would it be possible to change the semantics of the LOCATOR parameter
such that existing locators are not removed when they do not show up?
The readdressing host could explicitly remove a locator by advertising
it with a zero Locator Lifetime, e.g.

Regards,
- Christian

[1] http://www1.ietf.org/mail-archive/web/mip6/current/msg02936.html

--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

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

---

From: Teemu Koponen <[email-masked]>
Date: Mon, 13 Jun 2005 00:14:22 -0700

On Jun 12, 2005, at 9:00, Christian Vogt wrote:

Christian,

> address check, however.

Actually, I have been thinking the same issue of whether to do the 
address verification or not, but from a slightly different viewpoint. 
IMHO, there might be certain use cases where you would like to know for 
sure whether the remote peer is about to send an address verification 
or not.

One example, perhaps a bit artificial though, that comes to my mind is 
related to power management: a mobile device sends an UPDATE and begins 
to wait for an UPDATE with ACK. Now, if the device would know whether 
the peer is *not* about to respond with an address verification check, 
it could shutdown the transmitter components of its radio right after 
sending the UPDATE with new locator.

Teemu

--

---

From: Christian Vogt <[email-masked]>
Date: Mon, 13 Jun 2005 21:02:19 +0200

Hi Teemu,

yes, what you say definitely makes sense.

If we make address verification mandatory in all cases (*), which I
think we should, then hosts would not wait in vain for the challenge.
Would this solve your concern?

(*) The one and only exception would be a new primary locator advertised
as part of the R1 message.  We don't need to verify reachability of that
locator because, if the locator was false, then...

==> the I2 message would not reach the responder (because it's sent to
the new locator)
==> the responder could not create the DH secret
==> the responder could not compute the HMAC for the R2
==> the initiator would detect the fraud.

Since address verification is unnessary in this case, it shouldn't be
performed either because it could delay (or even confuse) the base exchange.

- Christian

Teemu Koponen wrote:
> sure whether the remote peer is about to send an address verification or
> not.
>

---

From: Teemu Koponen <[email-masked]>
Date: Mon, 13 Jun 2005 12:54:46 -0700

On Jun 13, 2005, at 12:02, Christian Vogt wrote:

Christian,

> Would this solve your concern?

Yes it certainly would, as my main concern was exactly the ambiguity.

Teemu

--