Subject: RE: [mobile-ip] Piggybacking

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 13 Aug 2001 12:07:33 -0500

I believe I have already sufficiently answered Alper's implementation
complexity arguments on it. 

As for ICMP, I doubt anyone wants to hear my opinion at this time on the
security and/or privacy threats it has and how it should be changed
especially with the recent network hammering that is still happening;
nevertheless, I don't see the relationship of your argument.  

What is your goal in trying to get rid of the piggybacking:

1> rock the boat marketing
2> nuke MIPv6 down to MIPv4
3> use IPSEC and don't change IPSEC

I find it quite odd that you are bringing up the IKE++ thing especially when
you have been such an ardent Kerberos proponent. Please explain?

It seems to me that if you value IPSEC so much - change it to do the job.
People have even gone so far as to make some suggestions on how to do it.
There is nothing wrong with the BU piggybacking. It aint broke - don't fix
it or nuke it; although it may have been more appropriate to make it a
routing header, IMO.

 I'm a little pieved that I'm the one standing up for something I didn't
even suggest in the first place. 

Since we are all expressing our personal opinions today. I'll also add that
I believe the binding updates functions should be a MUST for ALL CNs - at
least then you will have some form of mobility "built in" IP. I'll make a
deal with you - you get this changed to a MUST and I might seriously
consider getting rid of piggybacking. 

That will stick mobility right down the 3GPP mobile vendors' "kinda - sort
of" IPv6 (without mobility) throat. This is such lovely "design by
committee" comprimise work - isn't it. These vendors claim they can't to MIP
but they propose huge SIP compression dictionaries - ahhhh right - talk to
the hand - I really need some big waders at this point.

In hindsite, perhaps the mobility should have been part of the IPng WG. I
suspect it would be done by now - no offense intended to the MIP WG chairs
or authors. It is just that the focus would likely have been greater as well
as the influence and communication on IPSEC.

I'll let you or others express their opinions. No more time for this stuff.
I'm hope this was an enjoyable read for many.

Glenn

------------------ Previous snip -------

   Fine. On 10bT ethernet the marginal gains in
   bandwidth efficiency are not worth the added
   complexity in the stack, both for normal IP
   processing as Alper pointed out, path MTU
   considerations, as well as the complexities 
   that arise from things that have to deal with
   5-tuple processing like IPsec and RSVP. If 
   you don't believe that, then why shouldn't
   we piggyback ICMP messages on TCP connections?

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 13 Aug 2001 10:45:01 -0700 (PDT)

> 3> use IPSEC and don't change IPSEC

3. I'm not convinced that IPsec is what was to
blame here. MIPv6 was trying to use it in a way
that wasn't really appropriate and there seems
to be pretty simple workarounds to use IPsec the
way it was intended to be used. Given that the
work arounds seems to mostly neutral depending
on your view of piggybacking, I'd much rather
not have to take on the task of either:

1) changing IPsec selectors
2) changing IKE and/or counting on something new

Piggybacking is the casualty; so be it. Nice
idea, but not worth the trouble.

 > you have been such an ardent Kerberos proponent. Please explain?

It's actually not contradictory. I think that IKE
with certificates has scaling problems in certain
though common cases; the cost of DH/RSA signatures
is considerable when you are talking about high
fanout servers/routers. Restart avalanches are a
large problem, with restart times measured in the
many, many minutes range.

That said, IKE is here, it works, and warts and
all is the only workable solution for peer keying
we have. Other keying schemes MAY eventually
replace IKE where something else is more
appropriate, but given the long and difficult
development cycle for IKE, it would be foolish to
not hedge bets to some degree by being able to
drop in what is at least known to work.

 > it or nuke it; although it may have been more appropriate to make it a

But there is something wrong with it: it breaks
the intended use of IPsec. Also: it's not even
clear that a routing update should be carried 
as an option which is normally handled by the
kernel. Indeed, if you don't have access to the
kernel, having BU's as a UDP or IP proto would
allow an external daemon to camp on the port
and add the necessary routing updates which is
almost certainly infeasible as a DO.

		    Mike