Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt

From: [email-masked] (Mika Kousa)
Date: Wed Feb 18 08:15:01 2004

It seems that mm-01 has the same issue which I was thinking about when I
was implementing mm-00: how does a host tell its peer that "remove all my
addresses belonging to the Interface ID x immediately ?". This might be
needed e.g. when you plug out a PCMCIA network card and the kernel notices
this event, so it needs to inform the peer not to use anymore the card's
addresses (assuming that the HIP implementation uses direct
ifindex->Interface ID mapping). Simply by relying on (potentially very
long) address timeouts might cause problems on the given example case when
the peer tries to send data to old addresses.

Is this a relevant issue or a non-issue ?

In mm-00 I was experimenting with my own idea of "REA_INFO with no
addresses". When the peer received this kind of REA_INFO, it just deleted
every peer address which were associated with the Interface ID in given
REA_INFO parameter and did not send any AC packets.

---

From: [email-masked] (Pekka Nikander)
Date: Wed Feb 18 13:17:01 2004

> Is this a relevant issue or a non-issue ?

I don't know, I have to check.  But I don't have time before Seoul,
sorry.

Other than that, it has been brought to my attention via
private communications that certain aspects of mm-01 either
cannot be implemented or are very cumbersome to implement.
I haven't had time to consider this, either, but I'll try
to find time for these kinds of issues while in Seoul.
In any case, my current assumption is that the RR mechanism,
which is currently based on NES, may need big changes for -02.
I'd like to get more feedback, especially from those who either
have or have tried to implement it.

--Pekka

---

From: [email-masked] (Michael Richardson)
Date: Wed Feb 18 13:38:02 2004

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Mika" == Mika Kousa <[email-masked]> writes:
    Mika> "remove all my addresses belonging to the Interface ID x
    Mika> immediately ?". This might be needed e.g. when you plug out a
    Mika> PCMCIA network card and the kernel notices this event, so it needs
    Mika> to inform the peer not to use anymore the card's addresses
    Mika> (assuming that the HIP implementation uses direct
    Mika> ifindex-> Interface ID mapping). Simply by relying on (potentially
    Mika> very long) address timeouts might cause problems on the given
    Mika> example case when the peer tries to send data to old addresses.

  I'm not really up-to-speed on HIP-MM (yet).
  But, since I think it supports multiple Interface IDs, isn't the problem
of an address going away like this equivalent to one path becoming very slow?

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: [email-masked] (Andrew McGregor)
Date: Thu Feb 19 21:28:51 2004

> Is this a relevant issue or a non-issue ?

It's relevant, but shouldn't the peer notice ICMP messages (Host 
Unreachable or whatever) and correct fairly quickly anyway?

> REA_INFO parameter and did not send any AC packets.

This sounds like a pretty good solution, and is how I was planning on doing 
it.

Andrew

--------
Andrew McGregor
Director, Scientific Advisor
IndraNet Technologies Ltd
http://www.indranet.co.nz/
Office: +64 3 3656485
Mobile: +64 21 898856