Subject: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Jul 2008 08:53:28 -0500

Hello Folks,

We updated the Binding Revocation draft according to the mext wg ml
consensus by using the Mobile IPv6 Generic Signaling Message (MGSM)
framework. Since the MGSM draft is still being revised, we referenced
the MGSM draft in all related sections of the Binding Revocation draft.
We probably will be able to optimize the draft a little more in order to
eliminate any duplication in some sections as soon as the new MGSM draft
revision becomes available.

The only other change introduced in this revision is that we referenced
the DSMIP6 draft and made it optional for the HA to include the IPv4
home address in the BRI.

With the aggressive schedule and 3GPP dependency on this draft, we
appreciate your review, comment, and feedback.

Thanks in advance!

Regards,
Ahmad

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, July 11, 2008 8:45 AM
To: [email-masked]
Subject: I-D Action:draft-muhanna-mext-binding-revocation-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Binding Revocation for IPv6 Mobility
	Author(s)       : A. Muhanna, et al.
	Filename        : draft-muhanna-mext-binding-revocation-02.txt
	Pages           : 32
	Date            : 2008-07-11

This document defines the revocation semantics for terminating a mobile
node's mobility session and associated resources.  These semantics are
generic enough and can be used by mobility entities in the case of
Client Mobile IPv6 and its extensions.  This mechanism allows the
mobility entity which initiates the revocation procedure to request its
corresponding one to terminate either one, multiple or all specified
binding cache entries.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-muhanna-mext-binding-revocatio
n-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Frank Xia <[email-masked]>
Date: Fri, 11 Jul 2008 09:23:16 -0500

Hi Ahmad

IMHO, this document can't be directly used by
WiMAX and 3GPP2 in which IPsec SA is not mandatory.

3GPP2/WiMAX adopted RFC4285, and corresponding documents,
such as Diameter, RADIUS, now are explicitely supporting RFC4285.

We discussed before.

BR
Frank

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: <[email-masked]>
Sent: Friday, July 11, 2008 8:53 AM
Subject: [MEXT] FW: I-D Action:draft-muhanna-mext-binding-revocation-02.txt

Hello Folks,

Thanks in advance!

Regards,
Ahmad

-----Original Message-----

--------------------------------------------------------------------------------

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Jul 2008 10:12:32 -0500

Hi Frank,

I do not think there is a conflict here.

In the case of WiMAX and 3GPP2, I assume that there will be no IPsec SA
between the HA and the MN, for example. Therefore, there will be no SPD
to worry about. Although the BRI/BRA uses the MGSM which has a MH type
that support IPsec (if IPsec is used), but that is not applicable to the
case you mentioned then there is no problem.

Does that make sense? 

Regards,
Ahmad

> From: Frank Xia [mailto:[email-masked]] 
> Sent: Friday, July 11, 2008 9:23 AM
> To: Muhanna, Ahmad (RICH1:2H10); [email-masked]
> Subject: Re: [MEXT] FW: I-D 
> Action:draft-muhanna-mext-binding-revocation-02.txt
> 
> Hi Ahmad
> 
> IMHO, this document can't be directly used by WiMAX and 3GPP2 
> in which IPsec SA is not mandatory.
> 
> Subject: [MEXT] FW: I-D 
> Action:draft-muhanna-mext-binding-revocation-02.txt
> 
> 
> 
> Hello Folks,
>

---

From: Frank Xia <[email-masked]>
Date: Fri, 11 Jul 2008 10:18:07 -0500

Hi Ahmad

How to secure the signaling between HA and MN
if there is no IPsec?

BR
Frank

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Frank Xia" <[email-masked]>; <[email-masked]>
Sent: Friday, July 11, 2008 10:12 AM
Subject: RE: [MEXT] FW: I-D 

Hi Frank,

Does that make sense?

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Jul 2008 10:20:52 -0500

Hi Frank,

I guess you need to answer that question. Right?
I assume that what you mentioned about 3GPP2 and WiMAX is accurate.
i.e., 
"by WiMAX and 3GPP2 in which IPsec SA is not mandatory."

Regards,
Ahmad

> Sent: Friday, July 11, 2008 10:18 AM
> How to secure the signaling between HA and MN if there is no IPsec?
> 
> BR
> Frank
> 
> In the case of WiMAX and 3GPP2, I assume that there will be 
> no IPsec SA between the HA and the MN, for example. 
> Therefore, there will be no SPD to worry about. Although the 
> BRI/BRA uses the MGSM which has a MH type that support IPsec 
> (if IPsec is used), but that is not applicable to the case 
> you mentioned then there is no problem.
> 
> Does that make sense?
> 
> Regards,
> Ahmad
> 
> 
> > IMHO, this document can't be directly used by WiMAX and 
> 3GPP2 in which 
> > IPsec SA is not mandatory.
> >
> > 3GPP2/WiMAX adopted RFC4285, and corresponding documents, such as 
> > Diameter, RADIUS, now are explicitely supporting RFC4285.
> >
> > We discussed before.
> >
> > BR
> > Frank
> >
> >
> > We probably will be able to optimize the draft a little 
> more in order 
> > to eliminate any duplication in some sections as soon as 
> the new MGSM 
> > draft revision becomes available.
> >
> > The only other change introduced in this revision is that we 
> > referenced the DSMIP6 draft and made it optional for the HA 
> to include 
> > the IPv4 home address in the BRI.
> >
> > This document defines the revocation semantics for terminating a 
> > mobile node's mobility session and associated resources.  These 
> > semantics are generic enough and can be used by mobility 
> entities in 
> > the case of Client Mobile IPv6 and its extensions.  This mechanism 
> > allows the mobility entity which initiates the revocation 
> procedure to 
> > request its corresponding one to terminate either one, 
> multiple or all 
> > specified binding cache entries.
> >

---

From: Frank Xia <[email-masked]>
Date: Fri, 11 Jul 2008 10:26:13 -0500

Hi Ahmad

I copy the security consideration from you draft.

It says "The protocol described here uses the same security association
   between the MN and the HA or the MAG and the LMA that has been used
   to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the
   session was established.  This SPD of this IPsec SA MUST allow the MH
   type for the MGSM."

How to secure signalling if there is no IPsec?

I can't find the answer.

BR
Frank

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Frank Xia" <[email-masked]>; <[email-masked]>
Sent: Friday, July 11, 2008 10:20 AM
Subject: RE: [MEXT] FW: I-D 

Hi Frank,

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Jul 2008 10:32:41 -0500

Thanks Frank for pointing that, I believe the text should have been as
follows:

  "The protocol described here uses the same security association
   between the MN and the HA or the MAG and the LMA that has been used
   to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the
   session was established.  If IPsec is used, the SPD of this IPsec SA 
   MUST allow the MH type for the MGSM."

We will fix it and if there is other nits like this will, we will take
care of it. Does that address your concern?

Basically, the Binding Revocation messages should use the same security
association that was used during the establishment of the session that
being revoked.

Regards,
Ahmad

> Sent: Friday, July 11, 2008 10:26 AM
> no IPsec 
> > SA between the HA and the MN, for example.
> > Therefore, there will be no SPD to worry about. Although 
> the BRI/BRA 
> > uses the MGSM which has a MH type that support IPsec (if IPsec is 
> > used), but that is not applicable to the case you mentioned 
> then there 
> > is no problem.
> >
> > Does that make sense?
> >
> > Regards,
> > Ahmad
> >
> >

---

From: Frank Xia <[email-masked]>
Date: Fri, 11 Jul 2008 10:37:21 -0500

Hi Ahmad

Please add more information about "If IPsec is not used ...",
IMO, it is not necessary limited to "If IPsec is used".

BR
Frank

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Frank Xia" <[email-masked]>; <[email-masked]>
Sent: Friday, July 11, 2008 10:32 AM
Subject: RE: [MEXT] FW: I-D 

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Jul 2008 10:46:30 -0500

Hi Frank,

The following text captures all different mechanisms that are used or
can be used to establish a security association between the MN and the
HA or the MAG and the LMA.

  "The protocol described here uses the same security association
   between the MN and the HA or the MAG and the LMA that has been used
   to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the
   session was established."

I personally believe that it captures and cover all cases including the
case you mentioned.

Regards,
Ahmad

> Sent: Friday, July 11, 2008 10:37 AM
> We will fix it and if there is other nits like this will, we 
> will take care of it. Does that address your concern?
> 
> Basically, the Binding Revocation messages should use the 
> same security association that was used during the 
> establishment of the session that being revoked.
> 
> Regards,
> Ahmad
> 
> 
> >    to exchange the corresponding MIPv6 or Proxy MIPv6 BU 
> and BA when 
> > the
> >    session was established.  This SPD of this IPsec SA MUST 
> allow the 
> > MH
> >    type for the MGSM."
> >
> > > > the MGSM draft in all related sections of the Binding 
> Revocation 
> > > > draft.

---

From: Frank Xia <[email-masked]>
Date: Fri, 11 Jul 2008 11:06:16 -0500

Hi Ahmad

Firstly, why do you only mention "If IPsec is used" ?

Secondly, there are different security mechanism between RFC3776/4877
and RFC4285.  As to the latter, there is not separated SA establishment
and maitanance machanism (such as IKE), and each packet should
authenticate itselft.

IMO, your original text is only about IPsec case,  and your later
text only highlights IPsec case.

Could you give me an explicit answer?
How to secure the signaling between HA and MN if there is no IPsec?

Please don't ask me because I am not the author of draft.
Of course, I am willing to answer the question if you add me as an co-author 
:-)

BR
Frank

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Frank Xia" <[email-masked]>; <[email-masked]>
Sent: Friday, July 11, 2008 10:46 AM
Subject: RE: [MEXT] FW: I-D 

Hi Frank,

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Jul 2008 12:49:22 -0500

Thanks Frank!

This is becoming a very interesting discussion:-)
Let me try one more time. Please see inline.

Regards,
Ahmad

> Firstly, why do you only mention "If IPsec is used" ?

Ok, since as per the consensus of the mext ml, the BRI and BRA use the
Mobile IPv6 Generic Signaling Message (MGSM) framework, I believe what
we need to do here: is to reference that draft and only document the
exceptions.

What about the following:?

"
   The protocol described here uses the same security architecture and 
   requirement of the Mobile IPv6 Generic Signaling Message framework as
   defined in [ID-MGSM]. 

   However, in the case when the MAG sends a BRI message with the G bit 
   is set, the LMA must verify that the MAG is authorized to use
Per-Peer 
   Global Revocation.
"

Therefore, there is no exception and IPsec is not treated differently
than any other security mechanisms.

> and RFC4285.  

> As to the latter, there is not separated SA establishment

[Ahmad]
With the proposed text above, I guess this becomes a different
discussion. We actually can take that offline.
But I am just curious, what do you mean by the following:? 

1. there is not separated SA establishment and maitanance machanism
(such as IKE), and 
2. each packet should authenticate itselft.

> How to secure the signaling between HA and MN if there is no IPsec?

[Ahmad]
I hope that this has been addressed, please see above.

> > > > > Subject: I-D

---

From: Frank Xia <[email-masked]>
Date: Fri, 11 Jul 2008 12:57:20 -0500

Hi Ahmad

My question is very simple, why could you answer this directly?

OK, I would like to reword my question.

How to secure BRI/BRA messages when there is not IPsec SA between
HA and MN?

BR
Frank

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Frank Xia" <[email-masked]>; <[email-masked]>
Sent: Friday, July 11, 2008 12:49 PM
Subject: RE: [MEXT] FW: I-D 

Thanks Frank!

Regards,
Ahmad

"

[Ahmad]

[Ahmad]

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Jul 2008 13:12:20 -0500

Hi Frank,

The Binding Revocation draft does not define any new security mechanism,

I am not trying to escape from answering your question. What I am saying
here is that the Binding Revocation does not specify a new security
mechanism. It only defines a generic Revocation mechanism that can be
used by different mobility entities as captured in the draft. 

What else you want me to say?

If you have a security mechanism that can be used for securing BU/BA
exchange, it should be good enough to secure BRI/BRA. If you want me to
spell out the word "RFC4285", that is fine, you should be able to use
that security association too. On top of all of this, as I said earlier
and based on the mext ml consensus, BRI and BRA use the MGSM framework
and the security mechanism that is defined there.

Regards,
Ahmad

> Sent: Friday, July 11, 2008 12:57 PM
> How to secure BRI/BRA messages when there is not IPsec SA 
> between HA and MN?
> 
> BR
> Frank
> 
> This is becoming a very interesting discussion:-) Let me try 
> one more time. Please see inline.
> 
> Regards,
> Ahmad
> 
> 
> Ok, since as per the consensus of the mext ml, the BRI and 
> BRA use the Mobile IPv6 Generic Signaling Message (MGSM) 
> framework, I believe what we need to do here: is to reference 
> that draft and only document the exceptions.
> 
>    is set, the LMA must verify that the MAG is authorized to 
> use Per-Peer
>    Global Revocation.
> "
> 
> Therefore, there is no exception and IPsec is not treated 
> differently than any other security mechanisms.
> 
> >
> > As to the latter, there is not separated SA establishment and 
> > maitanance machanism (such as IKE), and each packet should 
> > authenticate itselft.
> 
> [Ahmad]
> With the proposed text above, I guess this becomes a 
> different discussion. We actually can take that offline.
> 1. there is not separated SA establishment and maitanance 
> machanism (such as IKE), and 2. each packet should 
> authenticate itselft.
> 
> >
> > IMO, your original text is only about IPsec case,  and your 
> later text 
> > only highlights IPsec case.
> >
> > I personally believe that it captures and cover all cases including 
> > the case you mentioned.
> >
> >
> > Regards,
> > Ahmad
> >
> >
> > > Please add more information about "If IPsec is not used 
> ...", IMO, 
> > > it is not necessary limited to "If IPsec is used".
> > >
> > > BR
> > > Frank
> > >
> > >    session was established.  If IPsec is used, the SPD of 
> this IPsec 
> > > SA
> > > We will fix it and if there is other nits like this will, we will 
> > > take care of it. Does that address your concern?
> > >
> > > Basically, the Binding Revocation messages should use the same 
> > > security association that was used during the 
> establishment of the 
> > > > > > Filename        : 
> draft-muhanna-mext-binding-revocation-02.txt
> > > > > > Pages           : 32
> > > > > > Date            : 2008-07-11
> > > > > >

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 11 Jul 2008 11:35:42 -0700

Frank,
 
This drafts focus is on the revocation semantics. Your comments on transport or
security has to be on the generic notification draft. Brian updated the draft and any
comments on that will help and can be fixed there. 
 
If you have specific comments on the revocation mechanism, on those details,
it can be fixed in this draft. How the message is delivered or the transport semantics
are all provided by the other other draft. This is another notification message. We can
discuss 4285 applicability on that draft as well.  
 
Thanks
Sri

________________________________

From: [email-masked] on behalf of Ahmad Muhanna
Sent: Fri 7/11/2008 11:12 AM
To: Frank Xia; [email-masked]
Subject: Re: [MEXT] FW: I-DAction:draft-muhanna-mext-binding-revocation-02.txt

Hi Frank,

Regards,
Ahmad

---

From: Frank Xia <[email-masked]>
Date: Fri, 11 Jul 2008 14:01:58 -0500

Hi Ahmad

IMHO, you are trying to escape from answering my very simple question. :-)

If you want to offload your security consideration to the MGSM draft,
you should contact the authors of the draft, and make sure that
they will deal with the issue.

Here are some specific question.
1)which authentication options should be include in BRI/BRA?
  MN-HA or MN-AAA?
2) If authentication fails,  is any new status to be defined in BRA ?
          0  success.
          1  partial success.
          2  Binding Does NOT Exist.
          3  Global Revocation NOT Authorized.
          4  CAN NOT Identify Binding.
BR
Frank

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Frank Xia" <[email-masked]>; <[email-masked]>
Sent: Friday, July 11, 2008 1:12 PM
Subject: RE: [MEXT] FW: I-D 

Hi Frank,

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Jul 2008 16:05:34 -0500

Hi Frank,

Please see inline.

Regards,
Ahmad

> Sent: Friday, July 11, 2008 2:02 PM
[Ahmad]
Okay; I am not sure what to say here. Please see more below.
> 
> If you want to offload your security consideration to the 
> MGSM draft, you should contact the authors of the draft, and 
> make sure that they will deal with the issue.

[Ahmad]
There is nothing to offload to the Mobile IPv6 Generic Signaling Message
(MGSM) framework draft. That draft does not specify any new security
mechanism either. It is nothing other than saying that the new MH needs
to be added to the SPD in case of IPsec and the same security
association used for the mobility binding establishment signaling
(BU/BA) will be used to secure the MGSM messages.

> 1)which authentication options should be include in BRI/BRA?

[Ahmad]
This needs to be addressed separately. Or probably you can start a
separate thread for that and get feedback from the list.

>           4  CAN NOT Identify Binding.

[Ahmad]
The problem is not in a new status code, it is to have No. 1 resolved.
IMO.

> I am not trying to escape from answering your question. What 
> I am saying here is that the Binding Revocation does not 
> specify a new security mechanism. It only defines a generic 
> Revocation mechanism that can be used by different mobility 
> entities as captured in the draft.
> 
> If you have a security mechanism that can be used for 
> securing BU/BA exchange, it should be good enough to secure 
> BRI/BRA. If you want me to spell out the word "RFC4285", that 
> is fine, you should be able to use that security association 
> too. On top of all of this, as I said earlier and based on 
> the mext ml consensus, BRI and BRA use the MGSM framework and 
> the security mechanism that is defined there.
> 
> 
> Regards,
> Ahmad
> 
> 
> between HA 
> > and MN?
> > This is becoming a very interesting discussion:-) Let me 
> try one more 
> > time. Please see inline.
> >
> > Regards,
> > Ahmad
> >
> >
> BRA use the 
> >    requirement of the Mobile IPv6 Generic Signaling Message 
> framework 
> > as
> >    defined in [ID-MGSM].
> >
> > (such as IKE), and 2. each packet should authenticate itselft.
> >
> > >
> > > Of course, I am willing to answer the question if you add 
> me as an 
> > > co-author
> > > :-)
> > >
> > > BR
> > > Frank
> > >

---

From: Frank Xia <[email-masked]>
Date: Fri, 11 Jul 2008 16:40:17 -0500

Hi Ahmad

Upon your request, I initials this thread.

1) How are BRI/BRA messages secured  when 
there is not IPsec SA between HA  and MN?

2)If authentication options defined in RFC4285 
are used, which  option should be used? 
MN-HA or MN-AAA?

3)If BRI processing failure is  because of 
 failed authentication, how does the MN inform HA?

BR
Frank

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Jul 2008 17:19:57 -0500

Hi Frank,

It was a comment on that topic rather than a request, but that is fine:)

Please note that I changed the subject by removing the word "draft"
because this discussion is supposed to be generic on the applicability
of Auth protocol to secure Binding Revocation signaling not the current
Binding Revocation draft. The reason as I said before, the mext wg
consensus was to use MGSM framework for BRI and BRA.

Therefore, if the discussion is on the draft, then the discussion should
be focused on the need to secure MGSM signaling using the authentication
protocol.

Regards,
Ahmad

> Sent: Friday, July 11, 2008 4:40 PM
> Subject: Authentication option support in Binding Revocation draft
> 
> Hi Ahmad
> 
> 1) How are BRI/BRA messages secured  when there is not IPsec 
> SA between HA  and MN?
> 
> 2)If authentication options defined in RFC4285 are used, 
> which  option should be used? 
> MN-HA or MN-AAA?
> 
> 3)If BRI processing failure is  because of  failed 
> authentication, how does the MN inform HA?
> 
> BR
> Frank
> 
> 
>

---

From: Frank Xia <[email-masked]>
Date: Fri, 11 Jul 2008 17:32:51 -0500

Hi Ahmad

All the questions are explicit to the draft.
I encourage you to face the questions directly.

If  authentication options are required to add
in the BRI/BRA message, IMO, this is not related to
MGSM draft.

I will feel confortable only after I have an 
satisfactory answer.  

BR
Frank

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Frank Xia" <[email-masked]>; <[email-masked]>
Sent: Friday, July 11, 2008 5:19 PM
Subject: Authentication option support in Binding Revocation

Hi Frank,

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Jul 2008 17:36:24 -0500

Hi Frank,

I usually do not like to yield issues to the chairs that quickly, but it
seems that the chairs need to take care of this.  It is not me who
decides on this, it is the consensus of the group.

Cheers!

Regards,
Ahmad

> Sent: Friday, July 11, 2008 5:33 PM
> Subject: Re: Authentication option support in Binding Revocation
> 
> Hi Ahmad
> 
> If  authentication options are required to add in the BRI/BRA 
> message, IMO, this is not related to MGSM draft.
> 
> I will feel confortable only after I have an satisfactory answer.  
> 
> BR
> Frank
> 
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 11 Jul 2008 21:03:04 -0400

Hello Frank, Ahmad, 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ahmad Muhanna
> Sent: Friday, July 11, 2008 8:33 AM
> Subject: Re: [MEXT] FW: 
> I-DAction:draft-muhanna-mext-binding-revocation-02.txt
> 
> 
> this IPsec SA 

I think this text is sufficient. There is nothing that needs to be said
about RFC 4285 in the binding revocation document.

Vijay

> same security
> > allow the MH

---

From: "Frank Xia" <[email-masked]>
Date: Fri, 11 Jul 2008 21:28:56 -0500

Hi Vijay

We have jumped to the thread
"Authentication option support in Binding Revocation".

Anyway,  this is not about how to word the text, but
how to enable secured BRI/BRA in 3GPP2/WiMAX
environment.

If you like, you can try to answer my listed question
in that thread.

BR
Frank

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Ahmad Muhanna" <[email-masked]>; "Frank Xia" 
<[email-masked]>; <[email-masked]>
Sent: Friday, July 11, 2008 8:03 PM
Subject: RE: [MEXT] FW: 
I-DAction:draft-muhanna-mext-binding-revocation-02.txt

Hello Frank, Ahmad,

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 11 Jul 2008 20:00:40 -0700 (PDT)

Hi Frank,

Comments inline ..

> 1) How are BRI/BRA messages secured  when there is not IPsec SA between 
HA
> and MN?

If its CMIP, the messages can be protected using 4285.

If its PMIP, currently 4285 is not defined for PMIP. But, I assume
some one will extend this to be used in PMIP, if required. Alper ?

> 2)If authentication options defined in RFC4285 are used, which  option
> should be used? MN-HA or MN-AAA?
>

If there is a shared key between the mobile node and the home agent,
MN-HA Authentication option can be used.

If there is a shared key between the mobile node and the AAA,
MN-AAA authentication option can be used.

But you bring a good point, these options are defined to be carried
in BU/BA. We need to allow these options to be carried in Generic
Notification messages.

> 3)If BRI processing failure is  because of  failed authentication, how
> does the MN inform HA?
>

Revocation message is a particular type of event carried in a GNM message.
If the message fails authentication, the draft should deal with it
properly. We need to address this issue in GNM. This is not specific
to revocation.

Lastly, you are challenging both the drafts and this is good. We will
fix this and ensure the Generic Notification message can properly
address these issues. Lets discuss in Dublin IETF.

Regards
Sri

On Fri, 11 Jul 2008, Frank Xia wrote:

> ----- Original Message ----- From: "Ahmad Muhanna" <[email-masked]>
>>  From: Frank Xia [mailto:[email-masked]] Sent: Friday, July 11,
>>  2008 4:40 PM
>>  1) How are BRI/BRA messages secured  when there is not IPsec SA between HA
>>  and MN?
>>
>>  2)If authentication options defined in RFC4285 are used, which  option
>>  should be used? MN-HA or MN-AAA?
>>
>>  3)If BRI processing failure is  because of  failed authentication, how
>>  does the MN inform HA?
>>
>>  BR
>>  Frank
>>
>>
>> 
>
>

---

From: "Frank Xia" <[email-masked]>
Date: Fri, 11 Jul 2008 22:25:41 -0500

Hi Sri

I like the straight reply, and it is fine with me.

Please see some other inline  comments.

BR
Frank

----- Original Message ----- 
From: "Sri Gundavelli" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "Ahmad Muhanna" <[email-masked]>; <[email-masked]>
Sent: Friday, July 11, 2008 10:00 PM
Subject: Re: [MEXT] Authentication option support in Binding Revocation

> in BU/BA. We need to allow these options to be carried in Generic
Frank=>Yes. We should extend the semantics of these options, and
let it be used in these cases.
> properly. We need to address this issue in GNM. This is not specific
Frank=>Sure . Just I said before, some new status codes
should be defined except the following in Revocation draft:
          0  success.
          1  partial success.
          2  Binding Does NOT Exist.
          3  Global Revocation NOT Authorized.
          4  CAN NOT Identify Binding.
> address these issues. Lets discuss in Dublin IETF.
Frank=>Thank you!

>> I will feel confortable only after I have an satisfactory answer. BR
>> Frank
>>
>>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Sat, 12 Jul 2008 00:17:08 -0400

> how to enable secured BRI/BRA in 3GPP2/WiMAX

Just use the MN-HA authentication option. However, WiMAX or 3GPP2 would
have to specify how to calculate the "Authentication Data" in the MN-HA
authentication option for the Generic Signaling Message. RFC 4285 only
specifies how the MN-HA authentication option is used for the Binding
Update and Binding Ack messages. 

Note that this is still not relevant to the Binding Revocation messages.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Sat, 12 Jul 2008 00:24:03 -0400

I hadn't seen Sri's response....

> Behalf Of Sri Gundavelli
> Sent: Friday, July 11, 2008 8:01 PM
> To: Frank Xia
> Cc: [email-masked]

> in BU/BA. We need to allow these options to be carried in Generic

Specifying the use of MN-HA authentication option with the Generic
Signaling Message sounds good to me. I doubt if the MN-AAA
authentication option will ever be used with the Generic Signaling
Message, though.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 11 Jul 2008 21:29:13 -0700 (PDT)

> authentication option will ever be used with the Generic Signaling

Vijay,

I think we can redefine these options (one or both) as valid options
to be carried in Generic Notification messages. We can add few lines
on this validity. Brian ?

We can address Frank's issues in this draft and revocation or other
clients dont have to deal with this.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 12 Jul 2008 07:05:05 -0500

Hi Vijay,

> > If there is a shared key between the mobile node and the 
> AAA, MN-AAA 
> > authentication option can be used.
> > 
> > But you bring a good point, these options are defined to be 
> carried in 
> > BU/BA. We need to allow these options to be carried in Generic 
> > Notification messages.
> 
> Specifying the use of MN-HA authentication option with the 
> Generic Signaling Message sounds good to me. I doubt if the 
> MN-AAA authentication option will ever be used with the 
> Generic Signaling Message, though.

[Ahmad]
I agree. 
If auth protocol to be used to authenticate the MIP6 Generic Signaling
Message, then it has to be the MN-HA AE in the case of Client MIP6.
MN-AAA AE is used during the initial registration to help in
bootstrapping MN-HA SA if it is needed. After the MIP6 session is
established, it is assumed that MN-HA SA has been established.
Therefore, MN-AAA AE has no value in this scenario. Not only that, but
it does not make sense either.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 12 Jul 2008 07:19:47 -0500

Just to add one point to my earlier reply.

My understanding that Mobile IPv6 Generic Signaling Message (MGSM) and
Binding Revocation are proposed as standard track document. Therefore,
before we start talking about adding Auth protocol support to MGSM and
consequently Binding Revocation, we need to do something about RFC4285.
This RFC is still an Informational one and my understanding a standard
track doc can not reference an Informational one.

Any one knows what is the latest on RFC4285? Raj or Kuntal?

Regards,
Ahmad 

> Behalf Of Muhanna, Ahmad (RICH1:2H10)
> Sent: Saturday, July 12, 2008 7:05 AM
> To: Vijay Devarapalli; Sri Gundavelli; Frank Xia
> Cc: [email-masked]
> > home agent,
> If auth protocol to be used to authenticate the MIP6 Generic 
> Signaling Message, then it has to be the MN-HA AE in the case 
> of Client MIP6.
> bootstrapping MN-HA SA if it is needed. After the MIP6 
> session is established, it is assumed that MN-HA SA has been 
> established.
> Therefore, MN-AAA AE has no value in this scenario. Not only 
> that, but it does not make sense either.
> 
> 
> > 
> > Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Sat, 12 Jul 2008 12:59:10 -0400

> track doc can not reference an Informational one.

It doesn't matter. The Generic Signaling Message just needs to describe
how to calculate the authentication data if the MN-HA authentication
option is used. RFC 4285 would be an Informational reference, since it
is not required for someone to use the Generic Signaling Message.

Vijay

---

From: "Hui Deng" <[email-masked]>
Date: Sun, 13 Jul 2008 07:52:58 +0800

Hello all

I saw lots of options and SA may be used, anybody can help to let me
know how does mobile node know how it should work in CMIP or PMIP?

Secondly, I also don't know how to prevent anti-replay happen,

Lastly, how could IKEv1 or IKEv2 work for this.

Many thanks

-Hui

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 14 Jul 2008 07:41:13 -0500

Hi Ahmad,

RFC4285bis status currently shows as expired.
The authors need to resubmit a revised version of the I-D. This I-D will be
progressed as part of the MIP6 charter.

-Raj

---

From: Brian Haley <[email-masked]>
Date: Mon, 14 Jul 2008 10:43:10 -0400

Hi Sri,

> clients dont have to deal with this.

This seems fine with me.  Maybe someone can propose some text?  :)

-Brian

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 14 Jul 2008 11:11:20 -0500

Hi Vijay,

I guess, It is not that simple:) One more thing to add here is that the
whole discussion here is concentrated on supporting the Auth protocol
for Client MIP6 BCE. Otherwise, IMO, things is more complicated.

MGSM is based on the security architecture of RFC3775. In the case of
PMIPv6 it is based on PMIPv6 base draft. On the other hand, let us not
forget that RFC4285 also, defines a replay protection mechanism for
Client MIP6 BU/BA. 
IMO, the options here are as follows:

1. Either MGSM need to have a normative reference to RFC4285, or
2. MGSM need to define all the details of a new security architecture
which cover all security threats including replay protection, etc. 

Looking at the current options, I believe that any attempt to have MGSM
support auth protocol in the current timeframe is nothing but more delay
to the completion of Binding Revocation. Additionally, the mext wg
consensus call on Binding Revocation to use MGSM was based on the fact
that MGSM and Binding Revocation use the same security architecture as
in RFC3775 and PMIPv6 base draft which in itself is based on RFC3775. 

IMO, We need to specify the MGSM based on RFC3775 and PMIPv6 base draft
without excluding the support for Auth protocol which can be added in
the future based on the consensus of the wg.

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Saturday, July 12, 2008 11:59 AM
> To: Muhanna, Ahmad (RICH1:2H10); Sri Gundavelli; Frank Xia
> Cc: [email-masked]; Basavaraj Patil; Chowdhury, Kuntal
> Subject: RE: [MEXT] Authentication option support in Binding 
> Revocation
> 
> It doesn't matter. The Generic Signaling Message just needs 
> to describe how to calculate the authentication data if the 
> MN-HA authentication option is used. RFC 4285 would be an 
> Informational reference, since it is not required for someone 
> to use the Generic Signaling Message.
> 
> Vijay
> 
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of Muhanna, Ahmad (RICH1:2H10)
> > > Signaling Message, then it has to be the MN-HA AE in the case of 
> > > Client MIP6.
> > > Therefore, MN-AAA AE has no value in this scenario. Not 
> only that, 
> > > but it does not make sense either.
> > > 
> > > 
> > > > 
> > > > Vijay

---

From: Julien Laganier <[email-masked]>
Date: Mon, 14 Jul 2008 18:56:36 +0200

Hello Frank, and other interesting parties,

<WG chait hat on>

> there is not IPsec SA between HA  and MN?

MIPv6 uses IPsec and IKE as a security mechanism, thus how the BRI/BRA 
messages are secured when there is no IPsec SA between HA and MN is 
out-of scope for this WG. 

> are used, which  option should be used?

This is out-of scope for this WG as well.

>  failed authentication, how does the MN inform HA?

When standard security mechanisms are used to protect MIPv6 signalling 
traffic it is my understanding that failed authentication is 
appropriately handled by IKE and IPsec.

--julien

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 14 Jul 2008 13:55:53 -0400

Hello Ahmad,

You are unnecessarily complicating things. Let me try to clarify again.

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Monday, July 14, 2008 9:11 AM
> MGSM is based on the security architecture of RFC3775. 

Generic signaling message just defines a new mobility header message (or
two in fact) for signaling between mobility entities. The mobility
entities include, the mobile node, MAG or the LMA. There is no such
thing as "based on the security architecture of RFC 3775".

> In the case of

The same timestamp-based replay protection can be used here too. Nothing
new needs to be specified.

> 1. Either MGSM need to have a normative reference to RFC4285, or

I don't think you understand what a normative reference means. A
normative reference is used when the mechanism described in a particular
document cannot be implemented or understood without first understanding
or implementing another mechanism in another draft. The Generic
Signaling Message does not require RFC 4285 to be used. So 4285 would
not be a normative reference. 

> to the completion of Binding Revocation. 

Of course not. You only need to specify how to calculate the MAG. I
don't think anything more is needed.

> Additionally, the mext wg

Can you point me to that? You are assuming a lot of stuff in the above
sentence. 

> the future based on the consensus of the wg.

The fact is there are systems that use RFC 4285. If these networks want
to use the generic signaling messages, it obviously makes no sense
saying IPsec/IKEv2 must be used.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 14 Jul 2008 14:03:51 -0400

Hi Julien,

> Hello Frank, and other interesting parties,

I wish you had left the WG chair hat off for this email. 

> This is out-of scope for this WG as well.

I disagree. RFC 4285 is a valid alternative to the use of IKE/IPsec for
securing Binding Update and Binding Ack messages. Some of the SDOs have
adopted this over the use of IKE/IPsec. If the systems that belong to
these SDOs want to use the Generic Signaling Message, we should not
require them to use IKEv2/IPsec. They obviously would want to use the
same MN-HA key and the MN-HA authentication option for the Generic
Signaling Messages too. 

Vijay

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 14 Jul 2008 21:02:39 +0200

Hi Vijay,

speaking as a chair as well
below...

> same MN-HA key and the MN-HA authentication option for the Generic
we have very clear guidance on this

see the MEXT charter:

The group employs IPsec and IKE as a security mechanism. The group
shall refrain, however, from making generic extensions to these
protocols. Any proposed extension must be reviewed by the INT and SEC
ADs before it can be accepted as a part of a work item.

any work in using other security mechanisms need to be approved by SEC 
and INT ADs

Regards, marcelo

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 14 Jul 2008 15:12:58 -0400

Hi Marcelo,

> ADs before it can be accepted as a part of a work item.

The last sentence says any extensions to IKEv2 and IPsec should be
reviewed by the INT and SEC ADs before being adopted as WG items.

> and INT Ads

The charter does not say this. Perhaps I am missing something.

Vijay

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 14 Jul 2008 21:21:14 +0200

> The charter does not say this. Perhaps I am missing something.

The very first sentence reads:

        The group employs IPsec and IKE as a security mechanism.

To me that means that whatever mechanism we define must work with IPSec IKE security and that it is out of the scope to do work on security based on other mechanism.

This means to me, that if we define an extension, we need to secure it using IPSec/IKE and that security based on other approaches is out of the scope and needs to be explicitly reviewed by INT and SEC ADs.

That is our reading of the charter. We may ask for guidance from INT and SEC ADs if people think that we are reading it wrong, no problem with that. 

regards, marcelo

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 14 Jul 2008 14:21:50 -0500

Hello Vijay,
Please see inline.

Regards,
Ahmad 

> You are unnecessarily complicating things. Let me try to 
[Ahmad]
I hope you are right:)

> > I guess, It is not that simple:) One more thing to add here is that 
> > the whole discussion here is concentrated on supporting the Auth 
> > protocol for Client MIP6 BCE. Otherwise, IMO, things is more 
> > complicated.
> > 
> Generic signaling message just defines a new mobility header 
> message (or two in fact) for signaling between mobility 
> entities. The mobility entities include, the mobile node, MAG 
> or the LMA. There is no such thing as "based on the security 
> architecture of RFC 3775".

[Ahmad]
What do you mean by there is not such thing?

What I meant to say here is "the choice of IPsec based on IKE is a
security architecture decision". Because, it addresses all the security
concerns that are needed to secure the MIP6 signaling between the MN and
the HA, for example:

1. IPsec with IKE is known to address replay protection.
2. IPsec is known to provide confidentiality.
3. IPsec is known to provide integrity protection.
4. IKE is used to dynamically derive the IPsec SA that is needed to
secure the MIP6 signaling.
5. IKE has a mechanism to update the IPsec SA dynamically based on the
SA lifetime,
6. etc.

Not only that but there are two RFCs (3776 & 4877) that have been
developed to allow/explain IPsec/IKE address the specific need of MIP6
signaling. If that is not an architectural decision, I am not sure what
it is?

However, we can continue discussing this offlist, if needed.

> The same timestamp-based replay protection can be used here 
> too. Nothing new needs to be specified.
> 
> I don't think you understand what a normative reference 
> means. A normative reference is used when the mechanism 
> described in a particular document cannot be implemented or 
> understood without first understanding or implementing 
> another mechanism in another draft. The Generic Signaling 
> Message does not require RFC 4285 to be used. So 4285 would 

[Ahmad]
Okay, Thanks!:)
May be I am missing something here, but does not your definition
contradict your above comment about the time-stamp based replay
protection, where you said it can be used.? Also, In order to support
IPsec, either a proper IPsec reference is made or a short cut to
RFC3775. Therefore, if Auth protocol is to be used, we either reference
a document which introduced this protocol or redefine it, which what I
was trying to say.
 
> > Looking at the current options, I believe that any attempt to have 
> > MGSM support auth protocol in the current timeframe is nothing but 
> > more delay to the completion of Binding Revocation.
> 
> Of course not. You only need to specify how to calculate the 
> MAG. I don't think anything more is needed.

[Ahmad]
I assume you meant to say the MAC. 
Okay, but what is needed is a secure mechanism that address all security
concerns and threats. We can call it whatever appropriate. IMO, that is
not a trivial thing. 

> Can you point me to that? You are assuming a lot of stuff in 
> the above sentence.

[Ahmad]
No I did not assume anything, but the consensus call was based on all
the discussion that took place on the mailing list and based on the
content of these drafts. What I meant, we never talked about the support
of Auth protocol before now.
Also, neither one of the documents ever referenced in any normative or
informative manner RFC4285 or Auth protocol.
 
> 
> > IMO, We need to specify the MGSM based on RFC3775 and PMIPv6 base 
> > draft without excluding the support for Auth protocol which can be 
> > added in the future based on the consensus of the wg.
> 
> The fact is there are systems that use RFC 4285. If these 
> networks want to use the generic signaling messages, it 
> obviously makes no sense saying IPsec/IKEv2 must be used.

[Ahmad]
That is why I said the following:
"without excluding the support for Auth protocol which can be 
added in the future based on the consensus of the wg."

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 14 Jul 2008 14:31:12 -0500

> same MN-HA key and the MN-HA authentication option for the Generic

I agree with Vijay here. RFC4285 (or the bis version) is a valid option for
securing the signaling.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 14 Jul 2008 14:57:12 -0500

Marcelo,

IPsec/IKEv2 is the default mechanism for securing MIP6 signaling. However
the use of RF4285 based security is allowed within certain boundaries. So it
is a valid method within the scope of the MIP6 protocol and one that is
actually specified as the default mode for MIP6 operation (eg. 3GPP2 and
WiMAX). 
Any extensions to IPsec/IKEv2 itself would need consideration by the
Security AD. Or changing the default security model for MIP6 would require
the SEC and INT AD views.
But in the current thread I do not see that as an issue.

-Raj

On 7/14/08 2:21 PM, "Marcelo Bagnulo" <[email-masked]> wrote:

> To me that means that whatever mechanism we define must work with IPSec IKE
> security and that it is out of the scope to do work on security based on other
> mechanism.
> 
> This means to me, that if we define an extension, we need to secure it using
> IPSec/IKE and that security based on other approaches is out of the scope and
> needs to be explicitly reviewed by INT and SEC ADs.
> 
> 
> That is our reading of the charter. We may ask for guidance from INT and SEC
> ADs if people think that we are reading it wrong, no problem with that.
> 
> 
> regards, marcelo
> 
>> Vijay
>> 
>>   
>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Mon, 14 Jul 2008 13:04:07 -0700

Hi all,

I think the question is: do we really need to support RFC4285 for this?
Where is that requirement coming from?

I think there is a lot of time pressure for these drafts and it would be
good to complete them without extending the support for rfc4285 which is
still an Informational RFC as mentioned by Ahmad.

Assuming there is some interest, I think a separate draft for the usage
of authentication protocol with MGSM and BRI should be written.

Gerardo

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Vijay Devarapalli
> Sent: Saturday, July 12, 2008 9:59 AM
> To: Ahmad Muhanna; Sri Gundavelli; Frank Xia
> Cc: Basavaraj Patil; [email-masked]

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 14 Jul 2008 16:15:06 -0400

marcelo bagnulo braun wrote:
>>> protocols. Any proposed extension must be reviewed by the INT and
>>> SEC ADs before it can be accepted as a part of a work item.
>>> 
>> 
> To me that means that whatever mechanism we define must work
> with IPSec IKE security and that it is out of the scope to do
> work on security based on other mechanism.

I completely disagree. I wish I had paid more attention to that text when we were re-chartering. 4285bis was supposed to be in-scope.

> This means to me, that if we define an extension, we need to
> secure it using IPSec/IKE and that security based on other
> approaches is out of the scope and needs to be explicitly reviewed by
> INT and SEC ADs. 

The way the text is written currently, it does not say that. I read it as - any extensions to IKEv2 and IPsec must be referred to the SEC and INT Ads before getting adopted. 

> That is our reading of the charter. We may ask for guidance
> from INT and SEC ADs if people think that we are reading it wrong, no
> problem with that. 

I think we should ask them then.

Vijay

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 14 Jul 2008 22:18:07 +0200

Hi Raj,

My understanding is that any extension we define in mext will be secured 
using IPSec IKE unless explicilty chartered to do otherwise. Moreover, 
RFC4285 is an informational document, which makes thing complex if we 
want that a std track extension depend on it. finally, i guess that when 
we are chartered to work on a particular exentsion this does not 
includes defining how it should work with any other informational extension.

Regards, marcelo

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 14 Jul 2008 16:19:05 -0400

Giaretta, Gerardo wrote:
> Hi all,
> 
> I think the question is: do we really need to support RFC4285 for
> this? Where is that requirement coming from?

RFC 4285 would not be a requirement for the generic signaling message.
That is clear. If 4285 is being used for protecting BU/Back messages,
then what we do? That was the question Frank had asked. So we need to
answer that question in the draft. 

> I think there is a lot of time pressure for these drafts and it would
> be good to complete them without extending the support for rfc4285
> which is still an Informational RFC as mentioned by Ahmad.

I am sure we can get these two documents completed pretty soon, even
with the description of the use of the MN-HA authentication option.
Don't worry. :)

> Assuming there is some interest, I think a separate draft for the
> usage of authentication protocol with MGSM and BRI should be written.

I don't think a separate draft is necessary for this.

Vijay

>> Of Vijay Devarapalli Sent: Saturday, July 12, 2008 9:59 AM
>>> My understanding that Mobile IPv6 Generic Signaling Message (MGSM)
>>> and Binding Revocation are proposed as standard track document.
>>> Therefore, before we start talking about adding Auth protocol
>>> support to MGSM and consequently Binding Revocation, we need to do
>>> something 
>>> about RFC4285.
>>> This RFC is still an Informational one and my understanding a
>>> standard track doc can not reference an Informational one.
>> 
>> It doesn't matter. The Generic Signaling Message just needs to
>> describe how to calculate the authentication data if the MN-HA
>> authentication option is used. RFC 4285 would be an Informational
>> reference, since it is not required for someone to use the Generic
>> Signaling Message. 
>> 
>> Vijay
>> 
>>>>>> If there is a shared key between the mobile node and the home
>>>>>> agent, MN-HA Authentication option can be used.
>>>>>> 
>>>>>> carried in BU/BA. We need to allow these options to be carried
>>>>>> in Generic Notification messages.
>>>>> 
>>>> Client MIP6. MN-AAA AE is used during the initial registration to
>>>> help in bootstrapping MN-HA SA if it is needed. After the MIP6
>>>> established. Therefore, MN-AAA AE has no value in this scenario.
>>>> Not only that, but it does not make sense either.
>>>> 
>>>> 
>>>>> 
>>>>> Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 14 Jul 2008 15:26:01 -0500

Hi Marcelo,

Agree with your view... And as I said, IPSec/IKE(v2) is the default security
protocol for MIP6. 

RFC4285 was published originally as an Informational RFC. However I think
that was a mistake (IMO) and hopefully 4285bis would be progressed as a
standards track RFC.

The MIP6 protocol has been incorporated in the 3GPP2 and WiMAX networks
architectures with RFC4285 as the default security mechanism. Hence it
makese sense to address how the new extension would be utilized in such
deployment scenarios.

-Raj

---

From: Frank Xia <[email-masked]>
Date: Mon, 14 Jul 2008 15:27:17 -0500

Hello Gerardo

Please see my inline comments.

BR
Frank

----- Original Message ----- 
From: "Giaretta, Gerardo" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>; "Ahmad Muhanna" 
<[email-masked]>; "Sri Gundavelli" <[email-masked]>; "Frank Xia" 
<[email-masked]>
Cc: "Basavaraj Patil" <[email-masked]>; <[email-masked]>
Sent: Monday, July 14, 2008 3:04 PM
Subject: RE: [MEXT] Authentication option support in Binding Revocation

Hi all,

I think the question is: do we really need to support RFC4285 for this?
Where is that requirement coming from?
Frank=>You can refer to 
http://tools.ietf.org/id/draft-ietf-mip6-whyauthdataoption-06.txt.

I think there is a lot of time pressure for these drafts and it would be
good to complete them without extending the support for rfc4285 which is
still an Informational RFC as mentioned by Ahmad.
Frank=>I don't know what is the really problem when referring to rfc4285.
However, I do know some practices that  intended standard tracks
refering to the informational document, RFC4285.
http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt
http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt

Frank=>Sounds good.

Gerardo

Of
> > My understanding that Mobile IPv6 Generic Signaling Message (MGSM)
and
> > This RFC is still an Informational one and my understanding a
standard
> It doesn't matter. The Generic Signaling Message just needs to
describe

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 14 Jul 2008 22:32:40 +0200

> I think we should ask them then.
we will do that

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 14 Jul 2008 22:50:10 +0200

> I don't think a separate draft is necessary for this.
probably it is cause 4285 is an informational rfc and we probably want 
that the binding revocation to a std track. If this is so, we need to 
avoid the downward ref

So either we do the binding revocation an informational document, or 
either we do some trick to deal with the downard ref or we split the 
binding revocation in two, one for IPSec (std track) and another for 
4285 (informational)

I think the last one would be best

Regards, marcelo

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 14 Jul 2008 15:54:28 -0500

Hi Marcelo,

> or we split the binding revocation in two, one for IPSec 
> (std track) and another for
> 4285 (informational)
> 

[Ahmad]
I agree. That should work.

> >>>> something about RFC4285.
> >>>>>> MN-AAA authentication option will ever be used with 
> the Generic 
> >>>>>> Signaling Message, though.
> >>>>>>             
> >>>>> [Ahmad]
> >>>>> I agree.

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Mon, 14 Jul 2008 14:00:17 -0700

As mentioned in my previous email, I agree that if there is some
interest in that work, a separate draft is a better option

Thanks
Gerardo

> Sent: Monday, July 14, 2008 1:54 PM
> To: marcelo bagnulo braun; Vijay Devarapalli
> Cc: Giaretta, Gerardo; Sri Gundavelli; Frank Xia; [email-masked];
Basavaraj
> Patil
Revocation
> > >>>>>>> If there is a shared key between the mobile node and the
home
> > >>>>>>> If there is a shared key between the mobile node and the
AAA,

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 15 Jul 2008 00:06:13 +0300

Folks, we should stop ignoring RFC 4285, as it is already being used in
wireless architectures. Its informational RFC status, or some people's
dislike, or missing an acknowledgement in the charter do not make this
protocol non-existent.  Unless IETF wants to wipe it off, IETF needs to
accommodate it.

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 14 Jul 2008 17:11:15 -0400

Hi Marcelo,

> I think the last one would be best

The new text in the Generic Signaling Message draft would say

  If the MN-HA authentication option {RFC4285] was used to protect 
  the Binding Update and Binding Acknowledgement messages, then the 
  same can be used also to protect the Generic Signaling Message. The
  "Authentication Data" field in the MN-HA authentication option must
  be calculate as follows, when used with the Generic Signaling 
  Message.

     <describe how to calculate the MAC here>

  When the MN-HA authentication option is used to protect the Generic
  Signaling Message, timestamp-based replay protection as described in
  [RFC4285] must be used for preventing replay attacks.

Do we need to add anything more? Why would this require a normative reference to RFC 4285? IKEv2/IPsec would still be the default mechanism, of course.

The Binding Revocation draft does not have to say anything about RFC 4285.

Vijay

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 14 Jul 2008 23:55:12 +0200

> Do we need to add anything more? Why would this require a normative reference to RFC 4285? IKEv2/IPsec would still be the default mechanism, of course.
according to RFC4677

        8.4.2. Normative References in Standards

   A normative reference is a reference to a document that
   must be followed in order to implement the standard.  A non-normative
   reference (sometimes called an "informative reference") is one that
   is helpful to an implementor but is not needed.

I guess that if we add the text you mention above, we would certainly 
need rfc4285 for implemeting the generic message, right?
Hence, it would be normative reference

Regards, marcelo

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 14 Jul 2008 18:12:57 -0400

marcelo bagnulo braun wrote:
>>> probably it is cause 4285 is an informational rfc and we probably
>>> want that the binding revocation to a std track. If this is so, we
>>> need to avoid the downward ref 
>>> 
>>> binding revocation in two, one for IPSec (std track) and another
>>> for 4285 (informational) 
>>> 
>>   Signaling Message, timestamp-based replay protection as described
>>   in [RFC4285] must be used for preventing replay attacks.
>> 
>> Do we need to add anything more? Why would this require a
> normative reference to RFC 4285? IKEv2/IPsec would still be
> the default mechanism, of course.
>> 
> according to RFC4677
> 
> 
>    must be followed in order to implement the standard.  A
>    non-normative reference (sometimes called an "informative
>    reference") is one that is helpful to an implementor but is not
> needed. 
> 
> 

I don't think so. One can implement the Generic Signaling Message protected with IKEv2/IPsec without implementing anything from RFC 4285. The entire paragraph starts with, "If the MN-HA authentication option was used....". Under these circumstances, I would say RFC 4285 becomes an Informational reference.

Vijay

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 15 Jul 2008 00:43:28 +0200

> I don't think so. One can implement the Generic Signaling Message protected with IKEv2/IPsec without implementing anything from RFC 4285. The entire paragraph starts with, "If the MN-HA authenticat…

mmmm...

if you read the description of a non normative reference, right below, 
it says that the refernece is helpful for the implementor but not 
needed. I think that in this case, if someone wnat to implement the 
solution using rfc4285 is more than usefu, but is actually needed. so i 
don't see this as being a non normative reference.

I mean, if we do this, 4285 would be certainly needed (more than just 
useful) if you want to use 4285 securiyt and would be completely 
irrelevant for an implementor that wants to use IPSec.

So, i may not get this right, but i understand that a reference is 
normative if you need it to implement some part of the spec, which seems 
to be the case here. (in my experience, when you have two alternative 
mechanisms that you can use in a spec, both are normative, not the other 
way round, but certianly i hadn't had this level of deep disucssion in 
this before, so may need more queries to figure it out)

regards, marcelo

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 Jul 2008 09:32:51 +0200

Hi Vijay,

> I wish you had left the WG chair hat off for this email.

You might well wish so...

I on the other hand believe I am in my role of WG chair when I try to 
ensure the MEXT WG follows the charter that was approved by the 
community.

> I disagree. RFC 4285 is a valid alternative to the use of IKE/IPsec
> for securing Binding Update and Binding Ack messages. Some of the
> SDOs have adopted this over the use of IKE/IPsec. If the systems that
> belong to these SDOs want to use the Generic Signaling Message, we
> should not require them to use IKEv2/IPsec. They obviously would want
> to use the same MN-HA key and the MN-HA authentication option for the
> Generic Signaling Messages too.

I am not saying that within some SDOs RFC 4285 isn't a valid 
alternative. 

But this is the IETF MEXT WG, and we've been chartered by the community 
to use IKE/IPsec as a security mechanism. The standard track MIPv6 
specification mandates (thus require) to use IPsec/IKE as a security 
mechanism -- and this is orthogonal to the existence of an alternative 
security mechanism documented in the informational track RFC 4285. 

In a similar fashion, the standard track MGSM will mandates (thus 
require) to use IPsec/IKE as a security mechanism.

Now anybody is free to document alternative mechanisms to secure MGSM, 
e.g., based on RFC 4285. Such a document can then be published as RFC 
as a result of either 1) the document being AD sponsored, or 2) the WG 
being rechartered to consider RFC 4285 as an alternative security 
mechanism to IKE/IPsec.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 Jul 2008 10:51:10 +0200

Hi Vijay,

<chair hat on>

> reviewed by the INT and SEC ADs before being adopted as WG items.

Right.

> > any work in using other security mechanisms need to be
> > approved by SEC and INT Ads
>

Agree the charter does not say this.

The charter quite clearly states "The group employs IPsec and IKE as a 
security mechanism". Thus this WG should currently limit itself to 
specifying use of IPsec and IKE as a security mechanism.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 Jul 2008 10:53:09 +0200

Raj,

On Monday 14 July 2008, Basavaraj Patil wrote:
> > SDOs have adopted this over the use of IKE/IPsec. If the systems
> > that belong to these SDOs want to use the Generic Signaling
> > Message, we should not require them to use IKEv2/IPsec. They
> > obviously would want to use the same MN-HA key and the MN-HA
> > authentication option for the Generic Signaling Messages too.
>
> I agree with Vijay here. RFC4285 (or the bis version) is a valid
> option for securing the signaling.

Nobody said that 4285 is not a valid option to secure the signaling in 
some contexts such as the SDOs who've been cited in the discussion.

The point is, under our current charter, the MEXT WG uses IPsec and IKE.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 Jul 2008 10:59:39 +0200

Vijay,

On Monday 14 July 2008, Vijay Devarapalli wrote:
> I completely disagree. I wish I had paid more attention to that text
> when we were re-chartering. 

You can.

> 4285bis was supposed to be in-scope. 

But it's not.

> > approaches is out of the scope and needs to be explicitly reviewed
> > by INT and SEC ADs.
>
> The way the text is written currently, it does not say that. I read
> it as - any extensions to IKEv2 and IPsec must be referred to the SEC
> and INT Ads before getting adopted.

It reads as: IPsec/IKE is the security mechanism, extensions to 
IPsec/IKE must be reviewed by INT and SEC ADs before being adopted.

Thus we are not chartered to specify use of RFC4285 as a security 
mechanism to secure MGSM.

> > from INT and SEC ADs if people think that we are reading it wrong,
> > no problem with that.
>

I'm unsure what to ask...

Do you want us to confirm with our AD that our charter saying "The group 
employs IPsec and IKE as a security mechanism" implies that 4285 is 
out-of-scope of our charter?

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 15 Jul 2008 11:05:04 +0200

Alper,

This WG has a charter and should follow it. MEXT is currently NOT 
chartered to use other security mechanisms than IPsec/IKE, thus an 
RFC4285 based security mechanism for MGSM is out-of-scope.

If there's a real need to develop an RFC4285 based security mechanism 
for MGSM, I encourage the interested parties to first document one in 
an Internet Draft, and then get the draft AD sponsored, or a 
corresponding work item added to the MEXT charter.

--julien

On Monday 14 July 2008, Alper Yegin wrote:
> Folks, we should stop ignoring RFC 4285, as it is already being used
> in wireless architectures. Its informational RFC status, or some
> people's dislike, or missing an acknowledgement in the charter do not
> make this protocol non-existent.  Unless IETF wants to wipe it off,
> IETF needs to accommodate it.
>

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 15 Jul 2008 14:27:04 +0300

Julien,

I acknowledge that I should have reacted to the charter text when it came
up. 
Unless someone has a solid reason why IETF should ignore its own work and
furthermore other SDOs' adoption of its own work, I cannot see a reason
against working towards allowing use of RFC 4285 (and rechartering in
parallel if people want to have a strictly followed charter).

Alper 

> From: julien laganier [mailto:[email-masked]] On Behalf Of
> Julien Laganier
> Sent: Tuesday, July 15, 2008 12:05 PM
> To: [email-masked]
> Cc: Alper Yegin
> draft

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 15 Jul 2008 13:53:46 +0200

> parallel if people want to have a strictly followed charter).

that is what it is not ok

we are following the charter
if we want to work on something, we open the recharter discussion and we 
get WG consensu that we want to change the charter (and that among the 
many different changes we want to make to the charter, a particular 
subset is the most relevant)

and then we start the work

Regards, marcelo

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 15 Jul 2008 17:05:39 +0300

Marcelo,

I certainly respect the WG and the chairs if they want to strictly follow
the charter. Even though several WGs in IETF utilize some leg room in going
beyond the charter in a healthy and constructive way, I cannot expect every
WG do the same as we cannot define a fine rule around this flexibility. For
that I'd not even encourage we do that.

But I'd suggest the work and discussions be accommodated to reflect the
industry situation (use of RFC 4285), and

Initiate discussion for a micro-surgery on the charter. Bundling this change
with any other would be a sure recipe for unnecessary delay.

Alper

> From: marcelo bagnulo braun [mailto:[email-masked]]
> Sent: Tuesday, July 15, 2008 2:54 PM
> To: Alper Yegin
> Cc: 'Julien Laganier'; [email-masked]

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 15 Jul 2008 16:17:27 +0200

Alper,

My point is the following one:
- the charter was approved by consensus and review by the IAB and IESG.
- it is our work to make sure that it is honoured (not in the exact word 
but in spirit, resulting in some flexibility)
- in this particular case, there is a very clear note in the charter, 
which clearly seems to me that we were provided some strict guidance 
w.r.t. to this particular issue, so that is why we are being more 
careful (and more rigid, if you wish) that what we would normally be 
with other matters.

Hopefully we will clarify this soon and we can have a clear way on how 
to move forward.

Regards, marcelo

Alper Yegin escribió:
>>> I acknowledge that I should have reacted to the charter text when it
>>>       
>> came
>>     
>>> up.
>>> Unless someone has a solid reason why IETF should ignore its own work
>>>       
>> and
>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 15 Jul 2008 08:52:42 -0700

Hi Julien,

> out-of-scope of our charter?

I was always under the impression that 4285bis will be taken up by the MEXT
WG after the MIP6 WG shut down. 4285bis is a bug fix and it should be
standardized ASAP. Frankly, I did not equate the sentence in the charter
that says "The group employs IPsec and IKE as a security mechanism." with
4285bis being out of scope during the re-chartering process. I wish I had
paid more attention to this back then.

I do want to check with Jari to see if thought 4285bis was out of scope too.
>From what I remember, he wanted the bug fix done too.

I suggest we modify the charter to explicitly add a sentence on maintaining
4285-based mechanisms. We should also explicitly say "maintenance" so that
we don't add new features like bootstrapping for RFC 4285, for which there
was no consensus.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 15 Jul 2008 08:59:12 -0700

Hi Marcelo,

> careful (and more rigid, if you wish) that what we would normally be

I don't think this is so clear. If the charter had said "4285-based
mechanisms are out-of scope", then yes. We never discussed whether 4285
should be out-of scope during the re-chartering process. FWIW, I had always
assumed 4285-bis would be taken up by the MEXT WG.
 
> Hopefully we will clarify this soon and we can have a clear way on how

As I said in another email, my suggestion would be to explicitly add
maintenance of 4285 to the charter.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 15 Jul 2008 11:04:28 -0500

Hi Vijay,

I agree that 4285bis should be published since it is a bug fix.
Additionally, I do think that the WG should request the IESG to publish it
as a proposed standard and not an Informational only RFC.

4285bis will be progressed either as a remnant of the MIP6 WG or potentially
by the MEXT WG. Jari will need to elaborate on the plan.

-Raj

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 15 Jul 2008 13:15:03 -0700

Hello Marcelo,

marcelo bagnulo braun wrote:
>> amarcelo bagnulo braun wrote:
>>
>>  

That much makes sense to me.

>>> any work in using other security mechanisms need to be

I also do not think the charter was intended to say that.  Or, perhaps
worse, if it really was intended to say that, it somehow escaped the
notice of a lot of people, somewhat like congressional earmarks are
done.
 
> To me that means that whatever mechanism we define must work with 
> IPSec IKE security and that it is out of the scope to do work on 
> security based on other mechanism.

I think it is very possible to read the sentence in a way that
is not at all so exclusionary.
>
> This means to me, that if we define an extension, we need to secure it 
> using IPSec/IKE and that security based on other approaches is out of 
> the scope and needs to be explicitly reviewed by INT and SEC ADs.
>
>
> That is our reading of the charter. We may ask for guidance from INT 
> and SEC ADs if people think that we are reading it wrong, no problem 
> with that.

Well, the proper people to ask are the people in the
working group, who thought they knew what they
were agreeing to but now seem to be surprised.

As a side note, I think that the history of mip6 was to
some extent a long battle against restrictions imposed by
implementations of IPsec, as well as poor granularity for
selectors for security associations.  This is really bad for
me since I was the first person to originally campaign to
use IPsec for MIPv6 even though it was not standardized
yet at that time.  I now regret that.  I still remember
the insistence that IPsec-protected packets with mobility
headers could not have payload.  Even if IPsec were
improved, I doubt anyone has the energy to reopen
the discussion.  It was very long and bruising, like
many, many other discussions with IPsec.  IPsec
was not architected with the goal in mind to support
mobile IP in any form, it seems to me.

As a point of comparison, up until now I do not think that
anyone has exposed security problems with the MN-HA
authentication extension for MIPv4, except insofar as it
originally specified MD5.  It is simple, easy to understand
and implement, and effective.  Why not make use of the
lessons we have learned from that?

Bottom line for me: use IPsec when it offers advantages,
use what else we know works when IPsec gets in the way.

Regards,
Charlie P.

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 15 Jul 2008 14:00:54 -0700

Hi all,

I agree with the WG chairs here. The charter is clear and the fact that
there are no milestones related to rfc4285, besides the RFC on the
motivations why that was defined, should be a clear indication of what
the WG is chartered for.

In my view, MEXT should work only on IPsec/IKEv2 based solution. This is
so far the only solution which is standard in IETF and we should not try
to revisit this every three months. And the fact that 3GPP and 3GPP2
have now adopted RFC4877 as the security mechanism shows that the
motivations why rfc4285 was defined are no longer valid.

Concerning the specific issue, I think the Binding Revocation draft
should cover only the IPsec based solution. This is particularly
important due to the strict timeline from 3GPP (and this draft is in the
official 3GPP-IETF dependency list). 
If people are interested in a 4285-based solution, they are free to
write a new draft and ask for a rechartering discussion to include it in
the milestone. 

Gerardo

Of
> Charles E. Perkins
> Sent: Tuesday, July 15, 2008 1:15 PM
> To: marcelo bagnulo braun
> Cc: [email-masked]
SEC

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 15 Jul 2008 16:19:05 -0500

Hi Gerardo,

When I last checked with the 3GPP2 TSG-X chair (Avi Lior) about the use of
Authentication protocol (RFC4285) with MIP6, I was told that 3GPP2 relies on
RFC4285 as the basis for MIP6 signaling security. Maybe things have changed
since March, 08.
Additionally RFC4285 is also the default security method for MIP6 in WiMAX
Rel 1 as well. 
Hence I believe that RFC4285 is a valid security solution for MIP6
deployments and cannot be simply ignored by the MEXT WG.
I do tend to agree with Charlies sentiment that IPsec/IKEv2 in certain
scenarios is an overkill for MIP6 security.

Experience shows that large scale deployment of MIP4 using authentication
akin to RFC4285 has worked well. So I don't see why MEXT should close the
doors to anything but IPsec/IKEv2. The relevance of MIP6 itself (IMO)
diminishes with this overarching dependence on IPsec/IKEv2 as the only
security mechanism.

-Raj