Subject: [Hipsec] Destination address usage in UPDATE packet processing

From: [email-masked] (Henderson, Thomas R)
Date: Sun Dec 12 18:07:01 2004

> -----Original Message-----
> From: Mika Kousa [mailto:[email-masked]]
> Sent: Friday, December 10, 2004 7:45 AM
> To: [email-masked]
> Subject: [Hipsec] Destination address usage in UPDATE packet=20
> processing
>=20
>=20
> Section 8.11 "Processing UPDATE packets" of the base draft does not=20
> explicitly tell whether the destination address of the reply=20
> UPDATE packet=20
> must be the same as the source address of the received initial UPDATE=20
> packet.
>=20
> When I was doing some mobility draft tests, sometimes the=20
> UPDATE packet=20
> was lost because it went to a non-existing address (the case when I=20
> removed one network card and inserted an other card). This=20
> was due to the=20
> assumption I made based on the base draft, that the reply=20
> UPDATE is to be=20
> always sent to the source address of the initial UPDATE address.

Were you sending the UPDATE before you removed the network card?  I
would assume that if you removed one network card and inserted another,
the UPDATE would originate from the new address.

>=20
> Should the draft explicitly mention that destination address=20
> of the reply=20
> UPDATE packet must be the source address of the received=20
> initial UPDATE=20
> packet ? This requirement should not break the base draft case=20
> functionality for static hosts and it seems to work well with mobile=20
> hosts.

In general, that would seem to work well for transparent middleboxes.
However, I wonder whether it should be a MUST, since that might
constrain implementation (depending on how HIP is implemented and the
socket model, it is not always easy to tell what the IP address was
of the incoming packet).

Tom

---

From: [email-masked] (Mika Kousa)
Date: Wed Dec 15 06:56:01 2004

On Sun, 12 Dec 2004, Henderson, Thomas R wrote:

-> > -----Original Message-----
-> > From: Mika Kousa [mailto:[email-masked]]
-> > Sent: Friday, December 10, 2004 7:45 AM
-> > To: [email-masked]
-> > Subject: [Hipsec] Destination address usage in UPDATE packet 
-> > processing
-> > 
-> > 
-> > Section 8.11 "Processing UPDATE packets" of the base draft does not 
-> > explicitly tell whether the destination address of the reply 
-> > UPDATE packet 
-> > must be the same as the source address of the received initial UPDATE 
-> > packet.
-> > 
-> > When I was doing some mobility draft tests, sometimes the 
-> > UPDATE packet 
-> > was lost because it went to a non-existing address (the case when I 
-> > removed one network card and inserted an other card). This 
-> > was due to the 
-> > assumption I made based on the base draft, that the reply 
-> > UPDATE is to be 
-> > always sent to the source address of the initial UPDATE address.
-> 
-> Were you sending the UPDATE before you removed the network card?  I
-> would assume that if you removed one network card and inserted another,
-> the UPDATE would originate from the new address.

The scenario was:

An internal network interface was running. HIP association was set up 
using that interface. The network interface was disabled. UPDATE could not 
be sent, because there was no available network connectivity. A moment 
later another external network interface card was inserted, and when this 
card got addresses, UPDATE was sent.

The host which received the UPDATE packet followed the design principle 
"when sending HIP control packets to the peer, use verified addresses 
only". At this time this host knew only the address used during the base 
exchange. However, that address belongs to the interface which is down, so 
the packet was sent to non-existent address, and the readdressing failed.

If the draft would have said that reply is sent to the source address of 
the initial address and not to a verified address, there would not have 
been any problems.

-> > Should the draft explicitly mention that destination address 
-> > of the reply 
-> > UPDATE packet must be the source address of the received 
-> > initial UPDATE 
-> > packet ? This requirement should not break the base draft case 
-> > functionality for static hosts and it seems to work well with mobile 
-> > hosts.
-> 
-> In general, that would seem to work well for transparent middleboxes.
-> However, I wonder whether it should be a MUST, since that might
-> constrain implementation (depending on how HIP is implemented and the
-> socket model, it is not always easy to tell what the IP address was
-> of the incoming packet).

Then how about some level of recommendation ?

Would sending of same UPDATEs to multiple addresses (both to a verified 
address and to the source of the initial packet) be a better approach ? If 
the UPDATE IDs are the same, the later packet is just dropped if both 
packets are received.

---

From: [email-masked] (Pekka Nikander)
Date: Wed Dec 15 11:14:01 2004

> ...

draft-ietf-hip-mm-00.txt, Section 5.1, bullet 2, last sentence:

> The UPDATE messages sent from the peer back to the
> mobile are sent to the newly advertised address.

Then there is some text about reachability test in Section 4.2.

But maybe those are not enough?  If so, what would be your suggestion?
Concrete text/diff, please.

--Pekka

---

From: [email-masked] (Mika Kousa)
Date: Wed Dec 15 11:52:01 2004

On Wed, 15 Dec 2004, Pekka Nikander wrote:

-> > If the draft would have said that reply is sent to the source address of
-> > the initial address and not to a verified address, there would not have
-> > been any problems.
-> > 
-> > ...
-> > 
-> > Then how about some level of recommendation ?
-> 
-> draft-ietf-hip-mm-00.txt, Section 5.1, bullet 2, last sentence:
-> 
-> > The UPDATE messages sent from the peer back to the
-> > mobile are sent to the newly advertised address.
-> 
-> Then there is some text about reachability test in Section 4.2.

Ah, I was just reading the base draft, not the mm draft. I guess that 
adding the same sentence as above would not hurt the base draft either.

-> But maybe those are not enough?  If so, what would be your suggestion?
-> Concrete text/diff, please.

Based on my current knowledge on this issue, I think it is sufficient most 
of the time.

However, I haven't thought about the destination address selection in the 
situations when there are more than one address in the REA parameter (and 
possibly no address flagged as the preferred address), or there are 
multiple REA parameters.

---

From: [email-masked] (Pekka Nikander)
Date: Wed Dec 15 12:37:01 2004

> adding the same sentence as above would not hurt the base draft either.

Well, the base spec does not cover mobility or multi-homing situations.
The assumption is, more or less, that you just don't change your
addresses while the HIP association is active.  Should there be an
explicit caveat emptor about that somewhere?

However, the situation is likely to get even more complicated when
we really start to consider the cases where the signalling packets
(UPDATE) and data packets (ESP) may take different paths, as in the
case of Hi3.  But I would not like to complicate the current specs
with that, but wait for some experimentation and research results
before jumping into that rat hole.

> possibly no address flagged as the preferred address), or there are

Ok.  It you come up with something, it would be nice to include some
text, if needed.

--Pekka