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

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 29 Apr 2008 20:32:43 -0500

Hello All,

Please find the latest Binding Revocation for IPv6 Mobility draft at the
below link.
We highly value your review and comments!

Many Thanks in advance!

Best Regards,
Ahmad

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, April 29, 2008 8:30 PM
To: [email-masked]
Subject: I-D Action:draft-muhanna-mext-binding-revocation-00.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-00.txt
	Pages           : 32
	Date            : 2008-04-29

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-00.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: "Vijay Devarapallli" <[email-masked]>
Date: Wed, 30 Apr 2008 11:04:42 -0700

Hi Ahmad and others,

We previously had a discussion on this draft on the MIP6 mailing list
and it was agreed that the binding revocation message will be a
sub-type in the Generic Notification Message.
http://www.ietf.org/internet-drafts/draft-haley-mext-generic-notification-message-00.txt

We would need to modify the generic notification message to include a
new 'subtype' field. We had discussed this in the past and made no
progress. We can start with the following values

0 - Reserved, not used
1 - Notification message indicated by Mobility Options
2 - Binding Revocation Indication
3 - Binding Revocation Acknowledgement
4-255 reserved

The Generic Notification message draft is quite simple and shouldn't
take too long to standardize. It would be a good idea to use the
Generic Notification message as much as
possible when you have something to notify to either the mobile node
or the home agent. Otherwise we might end up with a proliferation of
notification messages using up a lot of mobility header message types.

Vijay

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Wed, 30 Apr 2008 11:44:02 -0700

Hi Ahmad,

One comment on the security considerations section.

   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.

The security association setup between the MN and the HA or between
the MAG and the LMA may not be usable for protecting the mobility
header message that carries the binding revocation. According to RFC
4877, if fine grain selectors are used, the following will be the SPD
entry on the MN.

       mobile node SPD-S:
         - IF local_address = home_address_1 &
              remote_address = home_agent_1 &
              proto = MH & local_mh_type = BU & remote_mh_type = BAck
           Then use SA ESP transport mode
           Initiate using IDi = user_1 to address home_agent_1

This can only protect the BU/BAck messages, not the new mobility
header message that carries the binding revocation messages.

So we might need some text in the security considerations section that
says you must negotiate selectors such that the new mobility header
message is also included along with the BU/BAck.

Or we can define new SPD entries in the binding revocation document
(or in the generic notification draft, if we re-use the generic
notification messages for binding revocation).

Vijay

---

From: Brian Haley <[email-masked]>
Date: Wed, 30 Apr 2008 14:48:02 -0400

Hi Vijay,

I've been talking with Ahmad and Sri about this off-line and we're 
trying to come to an agreement over some of the text in gen-notification 
to more easily support the revocation draft.  Hopefully an update will 
be agreeable to everyone, but I wouldn't necessarily hold-up the current 
revocation draft for it.  That's my thoughts at least.

-Brian

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 30 Apr 2008 14:46:10 -0500

Hi Vijay,

I agree. 
We will work offline on some clarification text which we can include in
the next revision.

Thanks!

Regards,
Ahmad

> From: Vijay Devarapallli [mailto:[email-masked]] 
> Sent: Wednesday, April 30, 2008 1:44 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: mext
> Subject: Re: [MEXT] FW: I-D 
> Action:draft-muhanna-mext-binding-revocation-00.txt
> 
> Hi Ahmad,
> 
> The security association setup between the MN and the HA or 
> between the MAG and the LMA may not be usable for protecting 
> the mobility header message that carries the binding 
> revocation. According to RFC 4877, if fine grain selectors 
> are used, the following will be the SPD entry on the MN.
> 
>        mobile node SPD-S:
> This can only protect the BU/BAck messages, not the new 
> mobility header message that carries the binding revocation messages.
> 
> So we might need some text in the security considerations 
> section that says you must negotiate selectors such that the 
> new mobility header message is also included along with the BU/BAck.
> 
> Or we can define new SPD entries in the binding revocation 
> document (or in the generic notification draft, if we re-use 
> the generic notification messages for binding revocation).
> 
> Vijay
> 
> >  Please find the latest Binding Revocation for IPv6 
> Mobility draft at 
> > the  below link.
> >         Filename        : 
> draft-muhanna-mext-binding-revocation-00.txt
> >         Pages           : 32
> >         Date            : 2008-04-29
> >
> >  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: Sri Gundavelli <[email-masked]>
Date: Wed, 30 Apr 2008 13:23:05 -0700 (PDT)

We need to specify the selectors for the MH type used for
Generic Notification Msg type. All sub-type extensions
that are using the Generic Notification Message will be
within this scope and are not required to deal with the
security semantics.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 30 Apr 2008 15:28:57 -0500

Hi Vijay,

Yes, we had a lot of discussion on this topic before and it seems that
different people have different understanding of what we have agreed
upon.

The main comment that people used at that time is NOT to use two new MH
types for revocation which is a scare resource.  Other opinions said
that revocation is a kind of notification. At that time and according to
what have been presented in Prague, Notification message was supposed to
communicate an opaque string where revocation is not as simple as an
opaque string of characters.

In my understanding the agreement was to create a new subtype header
that will be used as a container for different messages which may have
specific processing and functionality.

For example: 

1. when that subtype is set to 1 "using your example below", then it
define that the message to follow is "Generic Notification Message" and
the processing of that message will be defined in the Generic
Notification Message draft. I guess the Generic notification draft
currently define two more subtypes which you did not list. (Generic
Notification Response) and (Generic Notification Request)

2. In my understanding, when the subtype is set to 2/3 "using your
example", the message contained is BRI/BRA and should follow the
processing as per the Binding Revocation for IPv6 Mobility draft.

Having said all of the above, I am not sure what is missing. If we want
to go this route, then we need to define a "Generic Subtype Header" (or
call it whatever) in your example referred as subtype field and use it
as a container. The subtype value should define a specific message where
the processing is defined in a specific draft.

That is at my understanding of the agreement.

Regards,
Ahmad

> Sent: Wednesday, April 30, 2008 1:05 PM
> Cc: mext; Basavaraj Patil; Brian Haley; Sri Gundavelli
> We previously had a discussion on this draft on the MIP6 
> mailing list and it was agreed that the binding revocation 
> message will be a sub-type in the Generic Notification Message.
> We would need to modify the generic notification message to 
> include a new 'subtype' field. We had discussed this in the 
> past and made no progress. We can start with the following values
> 
> 0 - Reserved, not used
> The Generic Notification message draft is quite simple and 
> shouldn't take too long to standardize. It would be a good 
> idea to use the Generic Notification message as much as 
> possible when you have something to notify to either the 
> mobile node or the home agent. Otherwise we might end up with 
> a proliferation of notification messages using up a lot of 
> mobility header message types.
> 
> Vijay
>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 30 Apr 2008 13:30:30 -0700

I agree this would be a good approach.

BTW, you are suggesting defining the selectors as additional selectors
for the IPsec SA used for BU/BA, correct? I guess it would not be
acceptable to create a new child SA just for binding revocation
messages.

Cheers
Gerardo

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Sri Gundavelli
> Sent: Wednesday, April 30, 2008 1:23 PM
> To: Vijay Devarapallli
> Cc: mext
> Subject: Re: [MEXT] FW:
I-DAction:draft-muhanna-mext-binding-revocation-
> 00.txt
> >>  Please find the latest Binding Revocation for IPv6 Mobility draft
at
> the
> mobile
> >>  mobility entity which initiates the revocation procedure to
request
> its

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 30 Apr 2008 13:41:23 -0700 (PDT)

Hi Gerardo,

> acceptable to create a new child SA just for binding revocation

The messaging, security semantics and the basic transport aspects
for generic notification events are provided by the Generic
Notification draft. Revocation is another notification message. The
reason why its in a new draft, as it requires more focus and need to
specify the receiver action. It should not have deal with security
semantics, IMO. It just needs to refer to the format from Notification
draft, if the WG concensus is to use that format.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 30 Apr 2008 15:47:47 -0500

Gerardo,

That is not a big deal. The confusion is when we want to refer to every
message contained under that type MH as generic Notification message and
at the same time define a mechanism for that generic notification
message, which is defined by a specific subtype. That does not make any
sense.

Of course, that was the compromise, to define a new subtype field in
order to avoid using new MH types. 

There is no sense what so ever in calling all messages with all
different subtypes "generic notification message" while the
understanding of the scope of the generic notification message is as "an
opaque string of characters"

I do not believe that we have a big problem here but we need to specify
the scope precisely to avoid confusion.

Regards,
Ahmad

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Giaretta, Gerardo
> Sent: Wednesday, April 30, 2008 3:31 PM
> To: Sri Gundavelli; Vijay Devarapallli
> Cc: mext
> Subject: Re: [MEXT] FW: 
> I-DAction:draft-muhanna-mext-binding-revocation-00.txt
> 
> BTW, you are suggesting defining the selectors as additional 
> selectors for the IPsec SA used for BU/BA, correct? I guess 
> it would not be acceptable to create a new child SA just for 
> binding revocation messages.
> 
> Cheers
> Gerardo
> 
> > We need to specify the selectors for the MH type used for Generic 
> > Notification Msg type. All sub-type extensions that are using the 
> > Generic Notification Message will be within this scope and are not 
> > required to deal with the security semantics.
> > 
> > Sri
> > 
> > 
> > 
> > >   to exchange the corresponding MIPv6 or Proxy MIPv6 BU 
> and BA when
> the
> > >   session was established.
> > >
> > > On Tue, Apr 29, 2008 at 6:32 PM, Ahmad Muhanna 
> <[email-masked]>
> > wrote:
> > >> Hello All,
> > >>
> Mobility draft
> > >>  node's mobility session and associated resources.  
> These semantics
> are

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 30 Apr 2008 19:30:22 -0500

> 
> Hi Vijay,
> 
> I've been talking with Ahmad and Sri about this off-line and 
> we're trying to come to an agreement over some of the text in 
> gen-notification to more easily support the revocation draft. 
>  Hopefully an update will be agreeable to everyone, but I 
> wouldn't necessarily hold-up the current revocation draft for 
> it.  That's my thoughts at least.

[Ahmad]
Hi Brian,

I appreciate your opinion here. I believe it is inline with the original
scope of Generic Notification Message which as I said earlier, was
clearly presented in Prague IETF meeting as the following:
"communicating an opaque string of information". Actually, when I read
the latest Generic Notification draft I found several places in the
draft which emphasize the original nature and scope of this draft. Here
is some examples:

1. RFC 3775 [RFC3775] contains no provision for Mobile IPv6 entities,
   such as a home agent or mobile node, to send and receive asynchronous
   notification messages during a mobility session.

2. This document describes a generic notification message protocol that
   can be used by Mobile IPv6 entities for sending and receiving simple
   notification events. [Ahmad: I do not think revocation as described
in Binding Revocation for IPv6 Mobility fits under this scope]

3. The Generic Notification message is used by the home agent to notify
   the mobile node, or vice-versa, that there is an event that requires
   attention. [Ahmad: clearly in conflict with the Binding Revocation]

I respect your opinion and it seems to me that you probably wrote the
draft with that in mind. I agree, It makes sense to keep the revocation
separate from the Generic Notification Message. This way there is no
dependency on the Generic Notification message and there is no worry on
making sure that nothing in one draft restrict or limit the other draft
functionality. Finally, both can advance independently.

In my mind, if a simple functionality as the HA switch message qualify
to have a separate MH type why not Binding Revocation?

Regards,
Ahmad

> mailing list 
> include a 
> shouldn't 
> > Generic Notification message as much as possible when you have 
> > something to notify to either the mobile node or the home agent. 
> > Otherwise we might end up with a proliferation of notification 
> > messages using up a lot of mobility header message types.
> > 
> > Vijay
> > 
> <[email-masked]> wrote:
> >> Hello All,
> >>
> multiple 
> >> or all specified  binding cache entries.
> >>

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Wed, 30 Apr 2008 17:40:00 -0700

Hi Ahmad,

Having not been involved on all these discussions offline, its not
clear to me why this should be so complicated.

Generic notifications messages are just notification messages. Some
can be simple event indicators, some can be events like revoking a
binding. I am sure the text in the Generic Notification message draft
can be fixed to say "simple" or "complicated" events. :)

>  to have a separate MH type why not Binding Revocation?

Well, the Generic Notification Message draft was written much later.
IMO, it would have made sense to use the Generic Notification Message
for the HA switch message too, if it was available back then.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 30 Apr 2008 20:29:09 -0500

> Sent: Wednesday, April 30, 2008 7:40 PM
> Cc: Brian Haley; mext; Basavaraj Patil; Sri Gundavelli

[Ahmad]
Very good.
1. Some of them simple events and some complicated vents.
2. Some Asynchronous and synchronous.
3. Some can be sent HA==>> MN ONLY and some can be sent MN<<==>>HA.
4. some have mobility options only, some have specific fields only, some
have specific fields and mobility options,
5. Some is send and forget about it and some MUST be acknowledged with
retransmission.

What is Generic in all of this? 
How can we make sure that it is very generic and that there is no
conflict?

It is absolutely a noble cause to protect the MH type filed. I agree
with that. That is probably the only thing generic in all of what we
have here. Defining a Generic Mobility Subtype field/header that can be
used to define a Generic Notification message and associated mechanism,
a Binding Revocation messages and their mechanism, etc is a good thing.
However, we need to carefully lay down a very strong foundation for a
common work that can be referenced and easily expanded without
complication. Also, processing a Mobility Header with a Generic Mobility
subtype field/header is nothing but a MH processing which can be
captured in a half page. 

If we follow that, then the scope can be very specific and Revocation
for example can reference the Generic Mobility Subtype field/header
definition and processing in anywhere without fear of conflict or
contradiction. On the other hand, the Generic Notification draft can
continue to define a generic notification subtype which can be used to
send, for example, a simple event, asynchronous messages, HA<<==>>MN,
with or without mobility options, etc.

I believe this is the way to have a common solution in order to reduce
any possible conflict. I understand that some people fear that if that
kind of proposal adopted some work item merely become an IANA number
assignment. But, IMO, that is absolutely not true.

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 30 Apr 2008 21:14:26 -0700 (PDT)

> assignment. But, IMO, that is absolutely not true.

If that some people includes me, I will just say this.

I care the least if revocation uses a new MH Type or
the sub-type from Generic Message. Forget about the
fear part. However, couple of comments:

- Revocation message is *just* another notification message.
   It does not require semantics beyond a simple request/reply
   message format. It is not a protocol by itself. The value
   of the spec is in the use-cases and receiver action specifications.

- If there is a Notification message that is defined with the
   generic event properties in mind, we dont want to replicate
   that for every event. Let that generic behavior be specified
   in one place, including the security semantics. Keeping the
   messages to few MH types, will allow to define one set of
   selectors and even allow firewall admins to properly apply the
   required filters.

- At the end of the day, revocation message needs a message format.
   It does not diminish or increase the revocation draft value, if
   it uses its own MH type or a sub-type from Notification message.

Bottom line, Bryan or myself, care the least, if this uses a sub-type
from Notification draft or not. Do want you think is right, if the
WG and the chairs have no issue. I will leave this thread with this
note.

Thanks
Sri