Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Mon, 22 Oct 2001 15:30:57 +1000

Hello Rajeev and all, 

> > Koodli Rajeev (NRC/MtView) writes:
> 
> >  > This brings back the question of whether destination option must have
> >  > been specified in the first place because some weird link does not
> know
> >  > how to support it! What's the logic in saying IP cannot have
> >  > variable-sized packets because a link would have performance issues?
> >
> >    The current BU design is not modular. It claims
> >    that it did that because of bandwidth/latency
> >    gains. You have not presented a *single* MAC/PHY
> >    where that claim can be tested. Here you dodge
> >    my direct question yet again.
> >
> 
> Actually, I mentioned previously that the use of [rohc] over cellular is
> one
> reference for you. See http://www.ludd.luth.se/users/larsman/rocco and
> follow
> the references.
> Note: use of [rohc] would require support for variable packet sizes on the
> link (perhaps the same kind of link you are considering).
> 
	=> I'm not sure why the discussion has gone towards header
	compression, but anyway, the point I was raising was that 
	piggybacking can have negative effects on the MN/CN if they
	are attached to a tight channel. Obviously the channel is tight
	because it''s expensive so there is a very limited potential
	of reserving a "just in case" extra BW for piggybacking. 

	Now, I'm not saying ROHC can't handle it, all I was saying is 
	that this "larger" packet will likely take double the time 
	to be sent over the air since it may not fit into one radio
	frame. If it does, then the end to end delay will be significantly
	increased (the air link delays are -by far- the largest part
	of the e2e delay in a cellular environment) and it may be dropped. 
	ROHC is not reallt relevant here.

	So the result of the scenario above is a degradation in service. 
	Now we can argue for a long time about whether these links
	are "IP friendly" and whether we should design IP for 
	these interfaces, but the fact is this is what we have _today_. 

	Also BTW these systems are the ones deploying IPv6 first !
	So we just have to deal with the real case here and try to
	solve it. 

	Unfortunately, we can not assume that the problem can be solved
	at one end only. So what can we do ?

	1.  Keep piggybacking and just say to the designers of these
	     systems "tough luck". ? Doesn't look good for MIPv6.

		Pro: - The draft doesn't change
		con: - Adds another reason for not deploying MIPv6 in
cellular
	               systems. 
	             - The IPsec problem still stands

	2.  Remove piggybacking ?
	       
	    pros: - End of this thread (can't wait :))
	            - End of the IPsec problems. IPsec can be used
	            - MIPv6 becomes more "cellular friendly"

	     Con: whatever advantages people see for piggybacking 
	             (in Jari's draft) will disappear. 

	3.  Have some negotiation mechanism in MIPv6 between 
	     the MN/CN. I'm not sure how this would work yet
	     but I could imagine having something in the Home Address
	     option or the BU option to indicate whether piggybacking 
	     should be used or not. 
	     If we use the Home address option, we would need to 
	     account for the fact that it will not necessarily be secure. 
	     Meaning, it can be modified en route. 
	     
	     If we use the BU, we will still get some service degradation
	     for the first BU. 
	     Regardless of the chosen method for this option, this 
	     new "flag" or "indication" MUST be supported by all 
	     MNs and CNs to avoid any service degradation due to 
	     piggybacking. 

	I'd be more inclined to 2 or 3 .... Comments ?

	Hesham

---

From: Francis Dupont <[email-masked]>
Date: Mon, 22 Oct 2001 08:15:15 +0200

Here are my comment about the H.3 section of the first draft,
I resend them to the list taking advantage of some minutes in my office:
 - 6.8: Scenario H.3: the quote is not the best one (this quote is
   an implementation hint, the definition should be better but I agree
   there is no formal definition of the home address option in a general
   context. Someone should ask for it...)
 - same: same: "on nodes whose home addresses may be known": remove home,
   the attack works as soon as an address of the final target is known.
   This is a real problem and as you know the defense against is not easy.
 - same: Requirement H.3: SHOULD/MAY NOT -> SHOULD NOT/MAY NOT
   (the threat is important enough for careful wording).
 - same: same: I disagree with the requirement because as this is
   an ingress filtering defeat attack there can (should! or we'll be
   in deep trouble) be some defenses based on smart ingress filtering
   (for instance a clever access control can ask MNs to register their
    home addresses before accepting to forward packets with home address
    options on the firewall between the access network and the rest of
    the world). Something needs to be done because the trivial way to
    fix the issue on a firewall is just to drop any packet with HoA options
    and this is *not* what we want.)

Regards

[email-masked]

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 22 Oct 2001 16:46:33 -0700

Hello Hesham,

this is really the issue of carrying IPv6 over certain links.
Piggybacking happens to make use of destination option, that's all. So,
when you characterize not having piggybacking in MIPv6 as "cellular
friendly", you are inevitably referring to how to support destination
options in general. If these links are the first to carry IPv6, it
should be possible to support destination options in arbitrary packets,
don't you think ? [I realize home address option is a destination
option, BTW]. More generally, a link should be able to handle variable
packet sizes. Thus, removing piggybacking should not be an option.

I am in favor of option 1 you mention below. This is in line with
general IP protocol design. Any performance considerations could be
stated in the draft in some form.
For instance, we could state that "..if the BAck does not return after
transmitting a Binding Update BU_PIGGY_TIMES, the sending node must send
a BU without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is a
configurable parameter.

I am willing to live with option 3. As you suggest, in the home address
option, a flag might indicate the MN's intention to piggyback.
I however, don't know how the CN would be able to negate it unless it is
also using the home address option. In any case, if details cannot be
worked out, option 1 is my choice.

I have some more comments in-line below.

Regards,

-Rajeev

"Hesham Soliman (EPA)" wrote:

>      >  > been specified in the first place because some weird link
>      does not know
>      Actually, I mentioned previously that the use of [rohc] over
>      cellular is one
>      reference for you. See
>      http://www.ludd.luth.se/users/larsman/rocco and follow
>      the references.
Rajeev: Since we were discussing a "tight channel", it is likely that
header compression is needed on such links. Hence the discussion on HC.

>      ROHC is not reallt relevant here.
Rajeev: chances of a piggybacked packet being large enough that it
creates the problem you mention above is not an issue when you use HC.
In the non-IR states, you already have 40 bytes of gain due to IPv6
compression which is more than the size of a BU. If it is in the
IR state (only when you init or when there is irrepairable failure), the
compressor has to re-establish the context anyway. Thus, using HC on a
tight channel is not only conceivable but also easily handles
piggybacking.

>      So we just have to deal with the real case here and try to
Rajeev: this is a good reason to get it right in the first place! Don't
strike out piggybacking.

---

From: Greg Daley <[email-masked]>
Date: Tue, 23 Oct 2001 11:52:29 +1000

> a BU without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is a
[GD: chop to option 1]
> >                   - The IPsec problem still stands

	For Option 1 this could neatly restate the entire sent piggyback
	mechanism by saying that BU_PIGGY_TIMES is a Non-negative integer.

	Configuring BU_PIGGY_TIMES to 0 would mean:
	'do not wait for BAck timeouts, send a separate datagram'

	coupled with the mechanism: Only send a piggybacked BAck if
	a piggybacked Binding Update is received, it would guarantee
	compliance of BU and Back with a particular bandwidth constrained
	medium adjacent to the MN.

		Greg Daley

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Tue, 23 Oct 2001 09:44:48 -0400

At 11:52 AM 10/23/2001 +1000, Greg Daley wrote:

<snip>

>         medium adjacent to the MN.

Humm ... sounds like you are assuming a symmetrical link to the MN.

A lot of access technologies have a scarce bandwidth resource requiring
special treatment of real-time packets in only one direction (e.g., cable
access systems and some non-cellular wireless access).

>                 Greg Daley

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 23 Oct 2001 09:07:43 -0400

Hi Hesham,
  If you can work out the details I think that your point 2 certainly is
the right choice.
Keep up the good work.

Regards,

--
Behcet

---

From: Greg Daley <[email-masked]>
Date: Wed, 24 Oct 2001 09:47:16 +1000

GD: Hi Michael, Response is below.

> access systems and some non-cellular wireless access).

	Not strictly, but maybe I did not state myself explicitly...
	
	In order to not delay the (Possibly Critical) BU any longer than
	needs be, when the responding CN/HA does not have a-priori knowledge
	of the MN's Link conditions, if the BU packet arrives unpiggybacked,
	it is unsafe to assume that piggybacking will work.

	This is since the BU's may have been discarded/mangled/delayed 
	by their transit MN->HA/CN with Piggyback. For example this
unpiggybacked 
	BU may be the first datagram which reaches the CN/HA after
BU_PIGGY_TIMES.

	The role of the fall-back 'no piggybacking' is a mechanism which 
	most networks should be able to handle, at the expense of 
	additional datagram overhead and MAC access.  The Piggybacked 
	mechanism may be attempted if a Piggybacked BU is received, in order to 
	provide an optimal service.  

	If the BU is seen again though, it is possible that the return path 
	is misplacing the piggybacked BAcks...  This would mean sending 
	another datagram (possibly B_ACK_PIGGY_TIMES ;-) but another counter
for
	each Binding Cache Entry may be unnecessarily complicated..

	In the case where the CN prefers not to Piggyback (which may be because
	of configuration/knowledge about of the intervening network etc), this
is 
	possible.  The only requirement was not to send Unsolicited Piggyback
BU's.

	Just an idea which was triggered by Rajeev's

		Greg Daley

---

From: "Eng Soo Guan" <[email-masked]>
Date: Wed, 24 Oct 2001 10:04:13 +0800

Dear All,

I would like to know if any work has being done with regard to 'transiting'
to Mobile IPv6 with IPv4 Internet, especially with Mobile Node behing a NAT.

The closet drafts I find are "Mobile IPv4 Traversal Across NAT and VPN
Gateways" and "Mobility Support for IPv4 and IPv6 Interconnected Networks
based on Dual-Stack Model".

I read found the NGTRANS Shipworm draft attractive to be modified for MIPv6
in a IPv4 only network behind a NAT.

Warmest regards.

SG
Soo Guan, Eng
Centre for Wireless Communications, NUS
http://www.cwc.nus.edu.sg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~