Subject: RE: [mobile-ip] Piggybacking

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 13 Aug 2001 15:01:35 -0500

Well I couldn't resist one last comment - Gosh  - why doesn't RSVP use
IPSEC?

Apparently IPSEC isn't to blame for this either?  

I think we should force RSVP to use IPSEC based upon your logic. Hey - I
guess we'll have to get rid of the router alert to get RSVP to work. Routing
headers are O.K. though. Yeah - each router knows based upon the destination
address in the routing header where to directly send the packet hop by hop
or over tunnels - that's the ticket.

RSVP would be too complex with the router alert in conjunction with IPSEC
based upon your logic? RSVP needs to rely on IKE for distribution - it has
to or the sky will fall out. I guess we can't use RSVP at all ever because
it doesn't use IKE and IPSEC. I guess there is something inherently wrong
with RSVP - it breaks IPSEC. We wouldn't be leveraging our bets if all
routers and hosts which employ RSVP didn't use IKE for key distribution.

Though these arguments above are quite ludicrous, it does hopefully point
out the injustice in your reasoning. 

As I recall authors of MIP did have designs on IPSEC to handle the exact
point we are discussing now and apparently their arguments for its
definitition didn't make it in probably because wireless devices were a
twinkle in most peoples' (wirehead) eyes at the time or they simply didn't
understand the intent; nevertheless, here we are today. So blame is probably
disputable.

RSVP didn't use IPSEC because it wasn't designed to deal with that
particular network service. To force IPSEC on MIP or take things away from
it so it can use IPSEC would be pathetic. TLS/HTTPs don't use IPSEC. I don't
see people standing up and yelling about that and the service seems to work
just fine. It seems that IKE can be used in conjunction with TLS too -
right? MIP could use IKE++ for key distribution without IPSEC. These are
disjunct issues.

As for the routing updates being handled by the kernal, I personally feel
that per node routing updates belong in purpose built machines (routers)
designed to handle the lookups of fairly large cached routing tables at the
edge - not hosts. But that is an entirely different topic. I think when we
finally get into more optimization issues in conjunction with other network
based services such as multicast, VPNs, anycast, privacy and security
threats, people will eventually change their tune. I suspect a few highly
publicized civil cases involving the victims of stalkers or assassins will
provide the impetus.

The original BBNers seemed to take this purpose built machine thought into
account. Perhaps I'm old school on this but I guess time will tell. The fact
that there is no IPv6 checksum certainly eliminates a great deal of concern
about the bundling of options and their removal before delivery to the upper
layers or end-hosts irrespective of whether they contained routing
information or not.

:)

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Monday, August 13, 2001 12:45 PM
To: [email-masked]
Subject: RE: [mobile-ip] Piggybacking

Glenn Morrow writes:
 > 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

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.

 > 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'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 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.

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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 13 Aug 2001 18:33:40 -0700 (PDT)

I'm not really sure what this outburst is about,
but it doesn't seem to have much to do with the
merits of piggybacking so I'll bow out.

	  Mike

Glenn Morrow writes:
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 > <HTML>
 > <HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
 > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
 > <TITLE>RE: [mobile-ip] Piggybacking</TITLE>
 > </HEAD>
 > <BODY>
 > 
 > <P><FONT SIZE=2>Well I couldn't resist one last comment - Gosh&nbsp; - why doesn't RSVP use IPSEC?</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Apparently IPSEC isn't to blame for this either?&nbsp; </FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>I think we should force RSVP to use IPSEC based upon your logic. Hey - I guess we'll have to get rid of the router alert to get RSVP to work. Routing headers are O.K. though. Yeah - each router knows based upon the destination address in the routing header where to directly send the packet hop by hop or over tunnels - that's the ticket.</FONT></P>
 > 
 > <P><FONT SIZE=2>RSVP would be too complex with the router alert in conjunction with IPSEC based upon your logic? RSVP needs to rely on IKE for distribution - it has to or the sky will fall out. I guess we can't use RSVP at all ever because it doesn't use IKE and IPSEC. I guess there is something inherently wrong with RSVP - it breaks IPSEC. We wouldn't be leveraging our bets if all routers and hosts which employ RSVP didn't use IKE for key distribution.</FONT></P>
 > 
 > <P><FONT SIZE=2>Though these arguments above are quite ludicrous, it does hopefully point out the injustice in your reasoning. </FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>As I recall authors of MIP did have designs on IPSEC to handle the exact point we are discussing now and apparently their arguments for its definitition didn't make it in probably because wireless devices were a twinkle in most peoples' (wirehead) eyes at the time or they simply didn't understand the intent; nevertheless, here we are today. So blame is probably disputable.</FONT></P>
 > <BR>
 > 
 > <P><FONT SIZE=2>RSVP didn't use IPSEC because it wasn't designed to deal with that particular network service. To force IPSEC on MIP or take things away from it so it can use IPSEC would be pathetic. TLS/HTTPs don't use IPSEC. I don't see people standing up and yelling about that and the service seems to work just fine. It seems that IKE can be used in conjunction with TLS too - right? MIP could use IKE++ for key distribution without IPSEC. These are disjunct issues.</FONT></P>
 > 
 > <P><FONT SIZE=2>As for the routing updates being handled by the kernal, I personally feel that per node routing updates belong in purpose built machines (routers) designed to handle the lookups of fairly large cached routing tables at the edge - not hosts. But that is an entirely different topic. I think when we finally get into more optimization issues in conjunction with other network based services such as multicast, VPNs, anycast, privacy and security threats, people will eventually change their tune. I suspect a few highly publicized civil cases involving the victims of stalkers or assassins will provide the impetus.</FONT></P>
 > 
 > <P><FONT SIZE=2>The original BBNers seemed to take this purpose built machine thought into account. Perhaps I'm old school on this but I guess time will tell. The fact that there is no IPv6 checksum certainly eliminates a great deal of concern about the bundling of options and their removal before delivery to the upper layers or end-hosts irrespective of whether they contained routing information or not.</FONT></P>
 > 
 > <P><FONT SIZE=2>:)</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>-----Original Message-----</FONT>
 > <BR><FONT SIZE=2>From: Michael Thomas [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
 > <BR><FONT SIZE=2>Sent: Monday, August 13, 2001 12:45 PM</FONT>
 > <BR><FONT SIZE=2>To: [email-masked]</FONT>
 > <BR><FONT SIZE=2>Subject: RE: [mobile-ip] Piggybacking</FONT>
 > </P>
 > <BR>
 > 
 > <P><FONT SIZE=2>Glenn Morrow writes:</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; What is your goal in trying to get rid of the piggybacking:</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; </FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; 1&gt; rock the boat marketing</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; 2&gt; nuke MIPv6 down to MIPv4</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; 3&gt; use IPSEC and don't change IPSEC</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>3. I'm not convinced that IPsec is what was to</FONT>
 > <BR><FONT SIZE=2>blame here. MIPv6 was trying to use it in a way</FONT>
 > <BR><FONT SIZE=2>that wasn't really appropriate and there seems</FONT>
 > <BR><FONT SIZE=2>to be pretty simple workarounds to use IPsec the</FONT>
 > <BR><FONT SIZE=2>way it was intended to be used. Given that the</FONT>
 > <BR><FONT SIZE=2>work arounds seems to mostly neutral depending</FONT>
 > <BR><FONT SIZE=2>on your view of piggybacking, I'd much rather</FONT>
 > <BR><FONT SIZE=2>not have to take on the task of either:</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>1) changing IPsec selectors</FONT>
 > <BR><FONT SIZE=2>2) changing IKE and/or counting on something new</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Piggybacking is the casualty; so be it. Nice</FONT>
 > <BR><FONT SIZE=2>idea, but not worth the trouble.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&gt; I find it quite odd that you are bringing up the IKE++ thing especially when</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; you have been such an ardent Kerberos proponent. Please explain?</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>It's actually not contradictory. I think that IKE</FONT>
 > <BR><FONT SIZE=2>with certificates has scaling problems in certain</FONT>
 > <BR><FONT SIZE=2>though common cases; the cost of DH/RSA signatures</FONT>
 > <BR><FONT SIZE=2>is considerable when you are talking about high</FONT>
 > <BR><FONT SIZE=2>fanout servers/routers. Restart avalanches are a</FONT>
 > <BR><FONT SIZE=2>large problem, with restart times measured in the</FONT>
 > <BR><FONT SIZE=2>many, many minutes range.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>That said, IKE is here, it works, and warts and</FONT>
 > <BR><FONT SIZE=2>all is the only workable solution for peer keying</FONT>
 > <BR><FONT SIZE=2>we have. Other keying schemes MAY eventually</FONT>
 > <BR><FONT SIZE=2>replace IKE where something else is more</FONT>
 > <BR><FONT SIZE=2>appropriate, but given the long and difficult</FONT>
 > <BR><FONT SIZE=2>development cycle for IKE, it would be foolish to</FONT>
 > <BR><FONT SIZE=2>not hedge bets to some degree by being able to</FONT>
 > <BR><FONT SIZE=2>drop in what is at least known to work.</FONT>
 > </P>
 > <BR>
 > 
 > <P><FONT SIZE=2>&nbsp;&gt; It seems to me that if you value IPSEC so much - change it to do the job.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; People have even gone so far as to make some suggestions on how to do it.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; There is nothing wrong with the BU piggybacking. It aint broke - don't fix</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; it or nuke it; although it may have been more appropriate to make it a</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; routing header, IMO.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>But there is something wrong with it: it breaks</FONT>
 > <BR><FONT SIZE=2>the intended use of IPsec. Also: it's not even</FONT>
 > <BR><FONT SIZE=2>clear that a routing update should be carried </FONT>
 > <BR><FONT SIZE=2>as an option which is normally handled by the</FONT>
 > <BR><FONT SIZE=2>kernel. Indeed, if you don't have access to the</FONT>
 > <BR><FONT SIZE=2>kernel, having BU's as a UDP or IP proto would</FONT>
 > <BR><FONT SIZE=2>allow an external daemon to camp on the port</FONT>
 > <BR><FONT SIZE=2>and add the necessary routing updates which is</FONT>
 > <BR><FONT SIZE=2>almost certainly infeasible as a DO.</FONT>
 > </P>
 > <BR>
 > 
 > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>&nbsp;&nbsp;&nbsp; Mike</FONT>
 > </P>
 > 
 > </BODY>
 > </HTML>