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

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Tue, 9 Oct 2001 13:22:41 +1000

> > 
> >      => You've mentioned this a few times now and  think it's
> >      misleading at best. Are you suggesting that if we all agreed
> >      today
> >      to go ahead with the Auth data suboption, then the MIPv6
> >      draft will be ready ? 
> >      Nothing else to solve for the security
> >      issues ? No key exchange problem (much bigger than what
> >      we're discussing now btw) ?
> 
> Auth Data suboption does not solve the key exchange problem. it
> solves the problem of how to protect the BU once the keys
> have been created between the MN and the CN. it is an alternative
> to using AH and ESP. 
> 
	=> Agreed.

> The MIPv6 draft talks about how to protect the BU. it does not
> talk about the key exchange problem. that is done in a bunch of
> drafts (BAKE, SUCV, PBK, Home Agent cookies...). so if we agree
> on using the suboption, MIPv6 draft can move ahead.
> 
	=> See below.

> Thats what I meant. and I did not intend to mislead anyone.
> its you and few others who are holding the MIPv6 draft to ransom
> by citing that it does not work with AH. So what? if it does not
> work with AH, lets move ahead. lets find an alternative solution.
> 
	=> Heh :) This is too much credit to give me or anyone else. 
	My understanding was that based on the IESG comments
	the draft could not go ahead without specifying the key
	exchange mechanism that can be used in the absence
	of IKE. So your comment about the draft going ahead
	without the key exchange mechanism doesn't seem to
	be inline with the IESG comments. I'd love to know if 
	this is a wrong interpretation of the IESG position. 
	This is why I think it's misleading to say that the BU
	protection is the only thing holding the draft back. 

	Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Oct 2001 10:10:33 -0700

hi Hesham,

comments below

> "Hesham Soliman (EPA)" wrote:
> 
>      >

IESG told us two things. ( I was there at the meeting with
the security ADs at the San Diego IETF last December ).

1. AH in its current form cannot be used for protecting the BU. 
Develop an alternative solution. 

2. Develop a Key distribution mechanism for MN and CN.

For the first one, the Auth Data suboption is the solution.
For the second one, we have a requirements draft and a lot of
competing proposals. We should be concentrating on this. and
NOT how we can modify things (disable piggybacking, get a 
new extension header) so that AH can be used for protecting
the BU.

The MIPv6 draft will not have the key distribution mechanism
embedded in it. It will just refer to another draft. It will 
only specify how the BU can be protected. So if we agree 
on the Auth Data suboption, we can conclude that the draft
is complete. and no further changes need to be made. (maybe
a few minor ones). thats what I meant by moving ahead.

and from you mail, you seem to say the key distribution 
mechanism is the main problem. great. thats what i wanted
to hear from you. hope, you would stop talking about how
AH can be used to protect the BU from now on.

Vijay

---

From: Michael Thomas <[email-masked]>
Date: Tue, 9 Oct 2001 10:24:37 -0700 (PDT)

> For the first one, the Auth Data suboption is the solution.

   It is _a_ solution, and it has not gained anything
   resembling rough consensus, and there are still many
   unanswered criticisms of it. There has also been much 
   discussion on how to make IPsec work untouched. It
   to is _a_ solution.

   While neither seem to make it to rough consensus, as
   far as I can tell, there's a lot more support for
   fixing the problems with MIP's use of IPsec.

	      Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Oct 2001 10:38:57 -0700

>    discussion on how to make IPsec work untouched. It

all right. thats a start. atleast you see that as a solution.
if its not good enough, lets work on improving it.

>    fixing the problems with MIP's use of IPsec.

well, IESG was very clear. they said 'develop an alternate
solution for AH'. I believe the IPSec WG wants to deprecate 
the use of AH. could be because of that. could be because
you need certain modifications (like either changing the
granularity of IPSec selectors or coming up with a new
extension header). 

anyway I disagree with you that there is more support for 
MIP's use of IPSec. its just a few!!

vijay

---

From: Michael Thomas <[email-masked]>
Date: Tue, 9 Oct 2001 10:49:32 -0700 (PDT)

Vijay Devarapalli writes:
 > solution for AH'. 

   That's not what I heard from Jeff. What I heard
   is that the way that the MIP WG is intending to
   use AH is not in line with the way that RFC
   2401 IPsec selectors behave. They did _not_ say
   to abandon any IPsec based approach.

 > I believe the IPSec WG wants to deprecate 
 > the use of AH.

   There's not consensus for this. Also: ESP
   could be used instead.

 > could be because of that. could be because

   You do _not_ need to change IPsec. All that is
   needed is a few relatively minor changes to 
   MIP. This has been discussed ad infinitum on
   this list.

 > MIP's use of IPSec. its just a few!!

   I count exactly you and _maybe_ Charlie.

	   Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Oct 2001 11:15:07 -0700

okay, let me try again.

>    to abandon any IPsec based approach.

nobody is throwing out IPSec. draft 15 does not exclude
the possibility of using AH for protecting the BUs. but
its good to have another solution in hand.

>    There's not consensus for this. 

what if there is a consensus to throw AH out tomorrow? I 
know there is such a discussion going on in the IPSec WG. 
we do all the work, figure out how to use AH and then 
somebody tells us a few months later "AH cannot be used. 
use something else". do you want to take the risk? how 
about having an alternate solution in hand? we dont want
somebody telling us again that MIPv6 is broken (even
though it never was).

> Also: ESP

this has been discussed a lot of times. There has been
MIP WG concensus for a long time now to use AH and not ESP.
ESP has not been found fit for protecting the BU. I do
not want to go into the details. check the archives.

>    MIP. This has been discussed ad infinitum on

the minor changes involve throwing out piggybacking (which
in my opinion is a nice feature). and getting a new extension
header. the BU as a destination option has been through a 
lot of interoperability events (we have been at atleast 3- 
2000 Conectathon, 2000 ETSI IPv6 bakeoff amd 2001 
Conectathon). lets not change it.

>    I count exactly you and _maybe_ Charlie.

again, both can exist. nobody wants to throw out AH. 

Vijay

---

From: "Jari T. Malinen" <[email-masked]>
Date: Tue, 09 Oct 2001 12:04:06 -0700

Vijay Devarapalli wrote:
> header.

Getting a new extension header is hardly a minor change. It needs
_every_ IPv6 forwarding engine to be changed, thus affecting the
ipv6 WG's scope. IMHO, people suggesting such a change should first
go to ipv6 WG to get their opinion on the issue. For the record,
I believe Francis bravely once already tried this - and, regrettably,
got rejected.

If, despite long discussion, there might be a lack of a credible
solution for AH, why not go ahead with an alternative? IMHO,
people interested in AH should work out the details (see above)
and come out with a separate description on how to solve the issue,
without stalling the base draft.

> >            Mike

-Jari

---

From: Michael Thomas <[email-masked]>
Date: Tue, 9 Oct 2001 12:55:48 -0700 (PDT)

Jari T. Malinen writes:
 > go to ipv6 WG to get their opinion on the issue. 

   Now wait a minute. I don't know about your
   forwarding engine, but ours don't route based
   on protocol number. And any flow classification
   engine which cannot deal with new IP protocols
   is broken and should be returned for full credit.

   Also: this could just as easily be done as a
   UDP packet on a well known port.

 > solution for AH []

   Nobody's shown that to be the case despite
   all the FUD.

		  Mike