Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 31 Jul 2001 10:52:48 -0500

I believe that piggybacking is very important and would prefer to keep the
existing proposal than get rid of it. You can always spend time later
developing something generic. The current proposal is on-scope and quite
pragmatic without giving anything up other than it just doesn't use IPSEC.

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Tuesday, July 31, 2001 9:32 AM
To: Jari Arkko
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [mobile-ip] Concern over
draft-team-mobileip-mipv6-sec-reqts-00.txt

Jari Arkko writes:
 > Of course, we must remember to keep separate the
 > packet protection and the key management problems.
 > The minutes from IETF #50 that Vijay referred to
 > discussed mostly the key management issues. It
 > seems very clear that there is working group consensus
 > on that BUs can't use IKE, KINK, PKI, AAA etc.

   Actually, I don't think there's consensus about
   _not_ using IKE etc. There is clear direction
   from the IESG that PKI/centralized keying cannot
   be the _only_ method of protecting BU's, especially
   for random MN/CN situations. Where you can use
   strong crypto (same administrative domain, say),
   it should be used in preference to a scheme based
   on a return routability test.

   One other nit with notes: IPsec (IKE/strong
   authentication, really) does protect against
   man in the middle attacks, something that a
   return routablity test based scheme would not
   be able to defend against.

 > But back to the BUs themselves. If it is not possible
 > to allocate a new next header value, the granularity
 > of standard IPsec policies isn't today sufficient (no
 > destination options looked). 

   I don't understand this: destination options are not
   supposed to be touched in the middle. Requiring
   all destination options to be protected -- not just
   BU's -- sounds like a *feature* to me. This requires
   no changes to IPsec.

 > Going further: if it is not possible to keep the BUs
 > in separate packets, then the above change to the
 > granularity of packets would be sufficient to send
 > even piggypacked BUs. In this case the IPsec policies
 > would state that packets from anywhere to us would
 > have to have protection if they contained a BU option.

   If you set up a selector which only selected
   based on IP addresses, you could piggyback
   with IPsec as it stands today. I'm not sure
   that piggybacking is really worth the grief
   that it's causing though.

	     Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2001 09:13:23 -0700 (PDT)

> pragmatic without giving anything up other than it just doesn't use  IPSEC.

   It's giving up standard key distribution which is
   always by far the hardest problem with crypto. I
   have a real problem with that.

	  Mike

 > <!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] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt</TITLE>
 > </HEAD>
 > <BODY>
 > 
 > <P><FONT SIZE=2>I believe that piggybacking is very important and would prefer to keep the existing proposal than get rid of it. You can always spend time later developing something generic. The current proposal is on-scope and quite pragmatic without giving anything up other than it just doesn't use IPSEC.</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: Tuesday, July 31, 2001 9:32 AM</FONT>
 > <BR><FONT SIZE=2>To: Jari Arkko</FONT>
 > <BR><FONT SIZE=2>Cc: [email-masked]; [email-masked];</FONT>
 > <BR><FONT SIZE=2>[email-masked]; [email-masked]</FONT>
 > <BR><FONT SIZE=2>Subject: Re: [mobile-ip] Concern over</FONT>
 > <BR><FONT SIZE=2>draft-team-mobileip-mipv6-sec-reqts-00.txt</FONT>
 > </P>
 > <BR>
 > 
 > <P><FONT SIZE=2>Jari Arkko writes:</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; Of course, we must remember to keep separate the</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; packet protection and the key management problems.</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; The minutes from IETF #50 that Vijay referred to</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; discussed mostly the key management issues. It</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; seems very clear that there is working group consensus</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; on that BUs can't use IKE, KINK, PKI, AAA etc.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp; Actually, I don't think there's consensus about</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; _not_ using IKE etc. There is clear direction</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; from the IESG that PKI/centralized keying cannot</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; be the _only_ method of protecting BU's, especially</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; for random MN/CN situations. Where you can use</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; strong crypto (same administrative domain, say),</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; it should be used in preference to a scheme based</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; on a return routability test.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp; One other nit with notes: IPsec (IKE/strong</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; authentication, really) does protect against</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; man in the middle attacks, something that a</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; return routablity test based scheme would not</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; be able to defend against.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&gt; But back to the BUs themselves. If it is not possible</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; to allocate a new next header value, the granularity</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; of standard IPsec policies isn't today sufficient (no</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; destination options looked). </FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp; I don't understand this: destination options are not</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; supposed to be touched in the middle. Requiring</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; all destination options to be protected -- not just</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; BU's -- sounds like a *feature* to me. This requires</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; no changes to IPsec.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&gt; Going further: if it is not possible to keep the BUs</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; in separate packets, then the above change to the</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; granularity of packets would be sufficient to send</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; even piggypacked BUs. In this case the IPsec policies</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; would state that packets from anywhere to us would</FONT>
 > <BR><FONT SIZE=2>&nbsp;&gt; have to have protection if they contained a BU option.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>&nbsp;&nbsp; If you set up a selector which only selected</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; based on IP addresses, you could piggyback</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; with IPsec as it stands today. I'm not sure</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; that piggybacking is really worth the grief</FONT>
 > <BR><FONT SIZE=2>&nbsp;&nbsp; that it's causing though.</FONT>
 > </P>
 > 
 > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; Mike</FONT>
 > </P>
 > 
 > </BODY>
 > </HTML>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2001 09:17:58 -0700 (PDT)

Glenn Morrow writes:
 > existing proposal than get rid of it.

   Piggybacking may not be as important as it seems. Layer
   2 concatenation of transmit frames -- a generally good
   feature with slow uplinks -- may mitigate the desire for
   piggybacking, and certainly plays better on the KISS 
   front.

		Mike