Subject: RE: [mobile-ip] question on protecting MN - HA communication

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 9 Oct 2002 19:52:07 +0200

=> That's not clear, do you mean that you can remove
the first condition (tunnel i/f) and keep this as it 
is? I don't think so, because the destination cannot
be left to "any". Note that this check is done
_before_ the packet is tunnelled to the HA.

  > 
  > by using tunnel interface as one of the selectors we can 
  > have a packet on the wire which looks like the following
  > 
  >    IPv6 header (source = care-of address, destination = home agent)
  >    ESP header
  >    IPv6 header (source = home address, destination = 
  > correspondent node)
  >    Mobility Header
  >       Home Test Init
  > 
  > otherwise the packet would be
  > 
  >    IPv6 header (source = care-of address, destination = home agent)
  >    Dst Opts Hdr
  >       HAO
  >    ESP header
  >    IPv6 header (source = home address, destination = 
  > correspondent node)
  >    Mobility Header
  >       Home Test Init
  > 
  > notice the home address option (24 bytes). this 24 bytes 
  > overhead is removed by making the tunnel interface as one of 
  > the selectors and by changing the gateway address (towards the 
  > MN) whenever the MN moves and changes its CoA. the gateway
  > addresses for the ESP tunnel are MN's CoA and HA's address.

=> Understood, but given the rarity of this message
compared to normal traffic and the unnecessary assumptions
that it makes, I'm not too sure that it's worth it.

  > 
  > > I can understand this as a reason (only reason?).
  > > I'm curious because this route information might
  > > not be available at this stage of processing the
  > > outgoing packet.
  > 
  > this is listed as an open issue currently. we are working on 
  > 01 version of this draft, which lists this under implementation
  > considerations with some more info.

=> ok, good.

Thanks,
Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 09 Oct 2002 11:18:32 -0700

> _before_ the packet is tunnelled to the HA.

ah! I think you are right.

> that it makes, I'm not too sure that it's worth it.

the only assumption here is the existense of this API. and 
in the draft, we are not leaving it as an assumption. we are 
requiring it. almost always, the SA database exists in the 
kernel. so, it shouldnt be difficult to have this API.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 09 Oct 2002 11:28:07 -0700

> that it makes, I'm not too sure that it's worth it.

I forgot something. the same procedure is followed for
IPsec protected reverse tunneled payload traffic (sec 7.3.4).
in that case, it wont be a rarity anymore.

Vijay