Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 13 Oct 2010 16:19:52 -0700

I can review the document (in a week or two).

Vijay

On 9/23/10 12:30 PM, Laganier, Julien wrote:
> Folks,
>
> The chairs have received a request from the authors of http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec  that their draft be adopted as one of the WG deliverables for our "alternative security mechanisms" work item.
>
> Before we go ahead with this, the chairs would like to solicit at least three thorough review of the document to ensure that the has an adequate understanding of the proposal and its implications.
>
> Please support the WG process by volunteering as a reviewer.
>
> --julien&  marcelo
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 14 Oct 2010 07:50:02 +0200

great, thanks!

El 14/10/10 1:19, Vijay Devarapalli escribió:
>> The chairs have received a request from the authors of 
>> http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec  that 
>> their draft be adopted as one of the WG deliverables for our 
>> "alternative security mechanisms" work item.
>>
>> Before we go ahead with this, the chairs would like to solicit at 
>> least three thorough review of the document to ensure that the has an 
>> adequate understanding of the proposal and its implications.
>>

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 14 Oct 2010 08:41:51 -0700

Marcelo/Julien:

Clarifying question ?

Given that, this (Alternative Security Mechanisms for MIPv6) is now a
chartered work item under experimental category, wondering about the future
and the relation of the candidate solution with two existing security
mechanisms, before we spin one more.

We have IPsec, a normative standard, Authentication Option, an informative
standard, and hopefully a perfect new solution as an experimental standard.

So, what is the evolution plan, if we love this new experimental standard
and MIP deployments get adopted and phase out GTP in 3GPP, will this get
promoted to be an informational standard or a normative standard ? :)
 
Secondly, for Auth-Opt to be considered an alternative security mechanism,
since that is some what black listed with that famous IESG note, will it be
a demotion or a promotion to get that under this Experimental standard, from
informational standard with a red dot. :)

Just curious, we will surely have excellent interoperability between
vendors. Its better to put few forward looking statements around this work,
else it will confuse the hell out of every one.

Sri

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 14 Oct 2010 10:04:13 -0700

Sri,

> Clarifying question ?

Sure.
 
> chartered work item under experimental category, wondering about the
> future and the relation of the candidate solution with two existing security

To be exact: we do not spin one more, we are spinning more experimental mechanisms, to experiment with security model alternatives. There might be one more, two more, etc. It all depends on what the WG think is worth experimenting with.
 
> We have IPsec, a normative standard, Authentication Option, an
> informative standard, and hopefully a perfect new solution as an experimental
> standard.

To be exact: RFC 4285 (Authentication option) does not specify an Internet standard of any kind.

> So, what is the evolution plan, if we love this new experimental
> standard and MIP deployments get adopted and phase out GTP in 3GPP, will this
> get promoted to be an informational standard or a normative standard ? :)

Any new experimental RFC that the WG publish will define an Experimental Protocol for the Internet community.  It will not specify an Internet standard of any kind.

As a result of the experiment, if one of the proposals is considered successful we might consider progressing it on the standard track.
 
> Secondly, for Auth-Opt to be considered an alternative security
> mechanism, since that is some what black listed with that famous IESG note, will
> it be a demotion or a promotion to get that under this Experimental standard,
> from informational standard with a red dot. :)

Since neither experimental RFCs not informational RFC defines Internet standard or any kind, there does not seem to be a huge difference. However from my perspective the experimental status highlights that an experiment is ongoing and thus that at some point the results can be evaluated by the community.
 
> vendors. Its better to put few forward looking statements around this
> work, else it will confuse the hell out of every one.

Standard wise there is no reason for anyone to be confused. IPsec remains the standard track, mandatory to implement security mechanism that guarantees interoperability.

--julien

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 14 Oct 2010 19:58:12 +0200

I agree with all Julien stated.
Just one more comment.

I personally would be interested to understand for each new proposed 
solution, what would be the interoperability plan with the current 
solutions. I mean, it could be as simple as: " we assume that all nodes 
in the network implement the new solution", but maybe there is something 
more into it (e.g. the HA will support multiple security mechanisms, and 
the MNs will support only one).
I think it would be worth doing the exercise.

Regards, marcelo

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 15 Oct 2010 11:43:27 -0700 (PDT)

Hi Marcelo,
  
  From SDO point of view, I think that WiMAX already adopted RFC 4285 
(Authentication option) and
3GPP is happy with IPSec. 

This new experimental security mechanism is looking for a place to go. I hope it 
does find one.

Regards,

Behcet

----- Original Message ----
> From: marcelo bagnulo braun <[email-masked]>
> To: "Laganier, Julien" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; Jari Arkko <[email-masked]>
> Sent: Thu, October 14, 2010 12:58:12 PM
> Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec
> 
> > To be exact: we do not spin one more, we are spinning more  experimental 
>mechanisms, to experiment with security model alternatives. There  might be one 
>more, two more, etc. It all depends on what the WG think is worth  experimenting 
>with.
> >
> > Any new experimental RFC that the  WG publish will define an Experimental 
>Protocol for the Internet  community.  It will not specify an Internet standard 
>of any  kind.
> >
> > As a result of the experiment, if one of the proposals is  considered 
>successful we might consider progressing it on the standard  track.
> >
> > Since neither experimental RFCs not  informational RFC defines Internet 
>standard or any kind, there does not seem to  be a huge difference. However from 
>my perspective the experimental status  highlights that an experiment is ongoing 
>and thus that at some point the results  can be evaluated by the community.
> >
> > Standard wise there is no reason for  anyone to be confused. IPsec remains 
>the standard track, mandatory to implement  security mechanism that guarantees 
>interoperability.
> >
> >  --julien
> >
>

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 20 Oct 2010 15:38:38 +0300

Sri,

> mechanism,

Good point.

When a vendor, operator, or SDO look at the picture, if they don't want to
use IPsec, what would it mean if one alternative is informational (with some
IESG note) and one or more others are experimental? How would the
experimental vs informational status play into it?

> work,

I think so too.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 20 Oct 2010 15:50:47 +0300

RFC 4285
IESG Note

   This RFC is not a candidate for any level of Internet Standard.  RFC
   3775 and 3776 define Mobile IPv6 and its security mechanism.  This
   document presents an alternate security mechanism for Mobile IPv6
   used in 3GPP2 networks.

   The security properties of this mechanism have not been reviewed in
   the IETF.  Conducting this review proved difficult because the
   standards-track security mechanism for Mobile IPv6 is tightly
   integrated into the protocol; extensions to Mobile IPv6 and the core
   documents make assumptions about the properties of the security model
   without explicitly stating what assumptions are being made.  There is
   no documented service model.  

What is a "service model"? 

   Thus it is difficult to replace the
   security mechanism and see if the current protocol and future
   extensions meet appropriate security requirements both under the
   original and new security mechanisms.  If a service model for Mobile
   IPv6 security is ever formally defined and reviewed, a mechanism
   similar to this one could be produced and fully reviewed.

I'd guess we need to overcome this "service model" barrier even for the
other experimental RFCs for them to ever become a standard.