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

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 13 Jun 2005 13:12:43 -0700

> -----Original Message-----
> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Sunday, June 12, 2005 9:00 AM
> To: Henderson, Thomas R; Pekka Nikander; Gregory Perkins; 
> Jari Arkko; [email-masked]
> Cc: [email-masked]; Ahrenholz, Jeffrey M
> Subject: Review of draft-ietf-hip-mm-01
> 
> 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).

Disclaimer:  I was one who originally pushed for making address check a
MAY instead of a MUST, to save transmissions and latency in certain
(wireless) environments.

However, I think your security rationale may trump this (and as you
mention, CBA solves the latency issue).  There is an additional
consideration that may bias towards always sending the address check--
if one wants HIP-aware middleboxes to be able to learn SPI/identity
bindings, there needs to be a packet in each direction.  So I would
agree with your proposal now-- make address verification prior to
address use a MUST for hosts that have received an UPDATE (but, as
presently specified, do not require the peer host to enforce this MUST
condition).

> (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.
> 

Yes, the text in this section has fallen inconsistent with the LOCATOR
format.

> (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.

It may be worse than this if the subsequent packets deprecate the
locators of the all previous packets.  

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

I do not recall the entire history of this issue, but if I recall
correctly, both variants (explicit and implicit removal) have been
supported at different times during the history of this draft.
Presently, it is implicit removal (removed if locator is not present in
the UPDATE).  

One argument in favor of the status quo might be that, if the common
case is single-interface mobility, the implicit removal avoids having to
explicitly deprecate the old locator.  

I think that the "large packet" issue might be better handled via IP
fragmentation-- although it seems an unlikely scenario for IPv6 in
particular.

Tom

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

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 15 Jun 2005 08:55:50 +0300

> locators of the all previous packets.

I don't think anyone has thought about that before; at least
the problem didn't occur to me nor had I heard about it before.

IIRC, the original reason for the behaviour was to make the
method to work also if UPDATEs are lost.  That is, the idea
was that each address update would include complete information,
making them idempotent.  However, as UPDATEs are now acked
there is less reason for this, though still some.

> Presently, it is implicit removal (removed if locator is not present in

IIRC, we originally had the interface identifiers there,
grouping IP addresses by logical interfaces, where the
logical interfaces were basically whatever groups the
sender decided to have.  These were later removed.

> explicitly deprecate the old locator.

Does this imply that in the case of multi-interface mobility
we perhaps should reconsider interface IDs?

> fragmentation-- although it seems an unlikely scenario for IPv6 in

Agreed.

--Pekka