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

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 1 May 2008 09:10:42 -0500

> 
> 
> 
> On Wed, 30 Apr 2008, Ahmad Muhanna wrote:
> 
> >
> > 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.
> >
> 
> 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. 

[Ahmad]
My bad choice of word. Meant to say "think".

> 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.

[Ahmad]
If this is the scope of Notification message, then almost every protocol
is nothing but a notification message, which , in general, may be true.
For example: MIPv6 BU message is nothing but a notification message from
the MN to the HA expressing its intent to register a care-of address.
Consequently, the HA send a BA to acknowledge the notification, and so
on ...

However, the differentiator here is the scope of the Generic
Notification Message that was presented in Prague IETF meeting and
documented in the meeting minutes. Which was "an opaque string of
information" 

Having that scope in mind, then Binding Revocation for IPv6 Mobility
does not fit within this scope. It much more.

> 
> - 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.

[Ahmad]
I do not think anyone disagree with this. The devil in the details. For
example, looking at the latest Generic Notification Message draft, I see
the following related to the processing of Generic Notification
Messages:

<<<<<<========>>>>>>>
5. Sending Generic Notification Messages

   When sending a Generic Notification message, the sending node
   constructs the packet as it would any other Mobility Header, except:

     o The MH Type field MUST be set to (TBD).

   The Generic Notification Request message MUST use the home agent to
   mobile node IPsec ESP authentication SA for integrity protection.

6. Receiving Generic Notification Messages

   Upon receiving a Generic Notification message, the Mobility Header
   MUST be verified as specified in [RFC3775], specifically:

     o The Checksum, MH type, Payload Proto and Header Len fields MUST
        meet the requirements of Section 9.2 of [RFC3775].

     o The packet MUST be covered by the home agent to mobile node
        IPsec ESP authentication SA for integrity protection.

   If the packet is dropped due to the above tests, the receiving node
   MUST follow the processing rules as Section 9.2 of [RFC3775].  For
   example, it MUST send a Binding Error message with the Status field
   set to 2 (unrecognized MH Type value) if it does not support the
   message type.

     o If the Generic Notification message is valid according to the
        tests above, then it is processed according to the rules
        specific to the Sub-Type specified in the header.

<<<<<<========>>>>>>>

I may be missing something, but can some one tells me what is new in
here?

My point is: the common thing here is the interest to protect the MH
type field by introducing a Generic MH Subtype field which can be used
to define different messages with different processes. As I said before.
The processing of the Generic MH Subtype message in nothing but the
processing of a MH. On the other hand, one of the subtypes value of that
Generic MH Subtype is reserved for a Generic Notification Message
defined in the Generic Notification Message draft, another 2 values
reserved for BRI and BRA which can be defined in Binding Revocation
draft.

What is the problem in this proposal and why there is some resistance
not to accept that?

> 
> - 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.

[Ahmad]
At the end of the day, we need to come to a framework and a proposal
that works and generic enough to avoid conflict and at the same time can
be expanded if necessary.

Let me try this proposal and see if that make sense:

1. define a Frame Work for Generic MH Subtype message. In order to avoid
conflict and have a clear mechanism for other defined messages to
reference this work, it could be addressed in a couple of pages draft.

2. Generic Notification message draft reserve as many as needed subtypes
and define their messages and appropriate mechanism. e.g. sending a
notification message that not necessarily require reply and can be
formatted as an opaque string of information, etc.

3. Binding Revocation reference the Frame work draft and reserve two
subtypes for BRI and BRA and define the respected mechanism.

Could we live with such proposal? 

> 
> 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.

[Ahmad]
Hi Sri,
I respect this! 

Hopefully we can use this approach after we thoroughly discuss the issue
to give the chairs enough material to make a decision.

Cheers!

> Thanks
> Sri
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Mohamed Khalil" <[email-masked]>
Date: Fri, 2 May 2008 12:37:53 -0500

Hi All,
> that works and generic enough to avoid conflict and at the same time 
> can be expanded if necessary.
> 
> 1. define a Frame Work for Generic MH Subtype message. In order to
> avoid conflict and have a clear mechanism for other defined messages 
> to reference this work, it could be addressed in a couple of pages 
> draft.
> 
> 2. Generic Notification message draft reserve as many as needed
> subtypes and define their messages and appropriate mechanism. e.g. 
> sending a notification message that not necessarily require reply and 
> can be formatted as an opaque string of information, etc.
> 
[MK]
I think we have put more time than necessary discussing this issue.
There has been an agreement before that the semantics for Binding
Revocation is absolutely different than "Send it and forget about it"
Notification message and that was the reason for coming with the subtype
proposal.

As was pointed out earlier by many people on this list before, there is
a 3GPP dependency on the Binding Revocation and we need to move this
forward. 

I support this proposal, and let us go forward!

Cheers!

==================================================This is the
END=================================
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext