Subject: Re: [Mip4] WGLC: draft-ietf-mip4-generic-notification-message-04.txt

From: "Hui Deng" <[email-masked]>
Date: Thu, 3 Jul 2008 13:53:57 +0800

Hello, all

Thanks Yingzhe's comments.

We have resolved all issues related to it and
updated the draft based on the last call.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip4-generic-notification-message-05.txt
Many thanks

-Hui
--
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 8 Jul 2008 18:40:54 -0500

Hello all,
Probably the following comments are a little late but it is better than
never. 
IMO, this draft needs to address these questions before sent to the
IESG.

Please see comments below:

+++++++++++++

4.  Generic Notification Message and Considerations

   This section describes in detail the generic notification message,
   generic notification acknowledgement message, and some considerations
   related to the handling of these messages in the mobile node, foreign
   agent and home agent.

4.1.  Generic Notification Message

   A generic notification message is sent by a mobility agent to inform
   another mobility agent, or a mobile node, of MIP-related information.

[Ahmad]
What is the definition of MIP-related information. A more detailed
description is better.

   These messages must use the same IP and UDP headers as any previous
   Registration Request or Reply message to the same entity.  The
   generic notification message is defined as follows:

   IP Fields:

     Source Address         Sender's address.

     Destination Address    Receiver's address.

   UDP Fields:

     Source Port            variable.

     Destination Port       Same as the last Registration Reply/Request
                            message.

   The UDP header is followed by the Mobile IP fields shown below:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   Subtype     |      MD       |A|  Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Home Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Home Agent Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Care-of Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                       Identification                          +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Extensions...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

   Identification

      A 64-bit number, constructed by the sender, used for matching
      Generic Notification with Generic Notification Acknowledgement,
      and for protecting against replay attacks of notification
      messages.  See Sections 5.4 and 5.7 of [RFC3344].

[Ahmad]
According to RFC3344, timestamp is mandatory but nonce is optional. Does
that mean that we MUST make sure that this draft , at least, MUST work
for timestamp. 

   Extensions

      The fixed portion of the Generic Notification Message is followed
      by one or more extensions which may be used with this message, and
      by one or more authentication extensions (as defined in Section
      3.5 of [RFC3344]).  See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344]
      for information on the relative order in which different
      extensions, when present, must be placed in a Generic Notification
      Message.

[Ahmad]
we are barely referring to RFC3344 here but the proposed model is
different than the one in RFC3344.
For example: section 3.5 again talks about FA-HA and MN-FA AE being
OPTIONAL. What is the relation to this document?
IS that optional too? Is there any scenario that it is mandatory for
this draft?

BTW: What the authorization-enabling extension has to do with the
generic notification message. I understand that with respect to Mobile
IPv4 protocol but what is the relation here? May be we can refer to it
as MN-HA AE.

4.2.  Generic Notification Acknowledgment Message

   A generic notification acknowledgement message is sent by mobility
   agents or mobile nodes to indicate the successful receipt of a
   generic notification message.

   The UDP header is followed by the Mobile IP fields shown below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Subtype     |      MD       |    Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Home Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Home Agent Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Care-of Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Identification                          +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Extensions...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Identification

      A 64-bit number used for matching Generic Notification with
      Generic Notification Acknowledgement, and for protecting against
      replay attacks of generic notification messages.  

[Ahmad]
How is that done?

      The value is
      based on the Identification field from the Generic Notification
      message from the sender, and on the style of replay protection
      used in the security context between the receiver and sender
      (defined by the mobility security association between them, and
      SPI value in the authorization-enabling extension).  See Sections
      5.4 and 5.7 of [RFC3344].

[Ahmad]
Are we assuming that the security association here is dynamically
allocated or statically configured. It will be good to elaborate more on
this one. Because RFC3344 does not clearly specify this one. On the
other hand, does the replay protection mechanism for Generic message has
anything to do with the one for Mobile IPv4.?

   Extensions

      The fixed portion of the generic notification acknowledgement
      message is followed by one or more of the Extensions listed in
      Section 3.5 of [RFC3344].  See Sections 3.6.1.3 and 3.7.2.2 of
      [RFC3344] for information on the relative order in which different
      extensions, when present, MUST be placed in a Generic Notification

[Ahmad]
Same comments as above.

      message.

4.3.  Mobile Node Consideration

   It is possible that the mobile node MAY receive a generic
   notification message from a foreign agent or home agent.  Both in the
   case of FA-CoA and Co-located CoA, the mobile node MAY reply with a
   Generic Notification Acknowledgement message based on the "A" flag in
   the notification message.

4.3.1.  Receiving Generic Notification Messages

   When the mobile node is using FA-CoA and receives a Notification
   message, if the "MD" value is 0, it means that the notification
   message came from the home agent.  If the "MD" value is 4, the
   notification came from the foreign agent.

   If this notification message came from a foreign agent and the mobile
   node accepts the foreign agent's generic notification message, it
   will process the notification extension according to the specific
   rules for that extension.

   After that, the mobile node MAY reply with
   a Generic Notification Acknowledgement message back to the foreign
   agent.  If the "A" flag is set in the notification message, then the
   mobile node MUST send the acknowledgement.

[Ahmad]
Okay, what extensions the MN need to include. 
How it is going to handle replay protection. Is that mentioned any where
in RFC3344, for example?
If that is captured in another section, we need to reference that
section here.

   If this notification message came from the home agent, relayed by the
   foreign agent, or is a Co-located CoA, the Mobile-Home Authentication
   extension MUST be checked and the mobile node MUST check the
   Authenticator value in the Extension.  

[Ahmad]
Okay, but what about the case when receiving the message from the FA.
Which extension the MN MUST validate? What kind of replay protection it
will validate and how?

   If no Mobile-Home
   Authentication Extension is found, or if more than one Mobile-Home
   Authentication Extension is found, or if the Authenticator is
   invalid, the mobile node MUST silently discard the Notification
   message.  If the mobile node accepts the home agent's generic
   notification message, it will process it according to the specific
   rules for that extension.  After that, the mobile node MAY reply with
   a Generic Notification Acknowledgement message back to the home agent
   based on the "A" flag in the notification message.

4.3.2.  Sending Generic Notification Acknowledgement Message

   Both in the case of a Co-located CoA and FA-CoA, the mobile node MAY
   reply with a Generic Notification Acknowledgement Message based on
   the "A" flag in the notification message as follows:

   If the notification message was initiated from the foreign agent to
   the mobile node ("MD" value is set to 4), the ordering of the
   extension is: any non-authentication Extensions used only by the
   foreign agent, 
[Ahmad]

Is there any other extension that will be used by any other entity other
than the FA? Why do we need to say "used only by the FA"

   followed by The Mobile-Foreign Authentication
   extension defined in section 3.5.3 of [RFC3344].

[Ahmad]
I do not see any normative text here? Is including the MN-FA AE optional
or mandatory?
How the MN will address replay protection in this case, for example in
the timestamp which is the mandatory method in RFC3344?

   In the case of a FA-CoA, the source address is the mobile node's
   address, the destination address is the foreign agent's address.

   If the notification message was initiated from the home agent to the
   mobile node ("MD" value is set to 0) and in the case of Co-located
   CoA, the ordering of the extension is: any non-authentication
   Extensions used only by the home agent, followed by the Mobile-Home
   Authentication extension defined in section 3.5.2 of [RFC3344]

   In the case of a FA-CoA, the source address is the mobile node's CoA
   address and the destination address is the home agent's address ("MD"
   value is set to 2), the ordering of the extension is: any non-
   authentication Extensions used only by the home agent, followed by
   the Mobile-Home Authentication Extension defined in section 3.5.2. of
   [RFC3344], followed by any non-authentication Extensions used only by
   the foreign agent, followed by The Mobile-Foreign Authentication
   extension defined in section 3.5.3 of [RFC3344].

[Ahmad]
This is missing the normative part and what needs to be done. Why the MN
needs to include the MN-FA AE in this case or we are just listing the
order of the extensions here?

4.4.  Foreign Agent Consideration

   The foreign agent cannot only relay generic notification message from
   the home agent and mobile node, but it can also initiate a generic
   notification message to the mobile node or home agent, but only when
   there is a binding for the mobile node.

[Ahmad]
May be some rewording is needed.

4.4.1.  Receiving Generic Notification Message

   If the foreign agent receives a notification message, and the "MD"
   value is set to 0, it means that the home agent is asking the foreign
   agent to relay the message to the mobile node.  Otherwise, it means
   that the target of the notification is the foreign agent.

[Ahmad]
What otherwise, mean here? May be we need to specifically mention the
Message Direction.
Do we need to specify how the FA needs to handle this case. I mean what
actions where to store the message ID. Does it need to maintain
something in order to match the Generic Ack from the MN which is coming
back soon from the MN?

   If the "MD" value is set to 1, the Foreign-Home Authentication
   extension MUST be checked, and the foreign agent MUST check the
   Authenticator value in the Extension.  If no Foreign-Home
   Authentication Extension is found, or if more than one Foreign-Home
   Authentication Extension is found, or if the Authenticator is
   invalid, the foreign agent MUST silently discard the Notification
   message.  If foreign agent accepts the home agent's generic
   notification message, it will process it based on the specific rules
   for that extension.  

[Ahmad]
Before accepting the message what else the FA needs to check before
accepting this message. For example, is the FA going to check the
message ID? And how?

   The foreign agent MAY then reply with a Generic
   Notification Acknowledgement message back to the home agent based on
   the "A" flag in the notification message.

   If the "MD" value is set to 0, the Foreign-Home Authentication
   extension MUST be checked, and the foreign agent MUST check the

[Ahmad]
I do not understand this. If the MD is set to 0, it means that the
message is destined to the MN. Are we mandating that FA-HA AE for this
scenario? Although, I assume that the message is protected using MN-HA
AE. NO?

   Authenticator value in the Extension.  If no Foreign-Home
   Authentication Extension is found, or if more than one Foreign-Home
   Authentication Extension is found, or if the Authenticator is
   invalid, the foreign agent MUST silently discard the Notification
   message.  If foreign agent accepts the home agent's generic
   notification message, it MUST relay the Generic Notification to the
   mobile node's home address as specified in the Home Address field of
   the Generic Notification.  

[Ahmad]
Ok. Fine. What "accept" in the above sentence means here?
We need to specify what that exactly means.

   The foreign agent MUST NOT modify any of
   the fields beginning with the fixed portion of the Generic
   Notification message through and including the Mobile-Home
   Authentication Extension or other authentication extension supplied
   by the home agent as an authorization-enabling extension for the
   mobile node.  Furthermore, the foreign agent MUST process and remove
   any Extensions following the Mobile-Home Authentication Extension and
   MAY append any of its own non-authentication Extensions of relevance
   to the mobile node, if applicable, and MUST append the Mobile-Foreign
   Authentication Extension, if the foreign agent shares a mobility
   security association with the Mobile Node.

[Ahmad]
The above is confusing. Probably needs to be reworded.

4.4.2.  Sending Generic Notification Acknowledgement Messages

   The foreign agent may need to either relay a Generic Notification
   Acknowledgment message between the mobile node and the home agent or
   send one as a response to a notification message that was sent to
   it.  In both cases, the Generic Notification Acknowledgement Message
   is defined as follows:

   The source address is the foreign agent address, the destination
   address is home agent address.

   If the foreign agent is only relaying this message to the home agent,
   the foreign agent it MUST NOT modify any of the fields beginning with
   the fixed portion of the Generic Notification Acknowledgement through
   and including the Mobile-Home Authentication Extension 

   or other
   authentication extension supplied by the home agent as an
   authorization-enabling extension for the mobile node.  

[Ahmad]
This message is sent by the FA to the HA. No? what are the extensions
supplied by the HA?

   Furthermore,
   the foreign agent MUST process and remove any Extensions following
   the Mobile-Home Authentication Extension and MAY append any of its
   own non-authentication Extensions of relevance to the home agent, if
   applicable.  It MUST also append the Foreign-Home Authentication
   Extension, if the foreign agent shares a mobility security
   association with the home agent.

[Ahmad]
This is really confusing.
When the FA receives a Generic Message from the HA, it MUST check the
FA-HA AE, which means that the FA-HA SA is mandatory. However, when
sending the Generic Acknowledgement, the FA MUST include the FA-HA AE
ONLY if it shares a FA-HA SA with the HA? I am not sure how does this
make sense?

   If the notification message is from the home agent to the foreign
   agent then the "MD" value is set to 1 and the ordering of the
   extension is: any non-authentication Extensions used only by the home
   agent, followed by The Foreign-Home Authentication extension defined
   in section 3.5.4 of [RFC3344].

[Ahmad]
What does the above paragraph mean?

4.4.3.  Sending Generic Notification Messages

   If the foreign agent is initiating a notification to the mobile node
   using the generic notification message, it MAY also notify the home
   agent as well.

   In the message to the mobile node, the source address is the foreign
   agent address, the destination address is the mobile node's address,
   the "MD" value is set to 4, and the ordering of the extension is: the
   notification extension, followed by any non-authentication Extensions
   used only by the mobile node, followed by The Mobile-Foreign
   Authentication extension defined in section 3.5.3 of [RFC3344].
   Computing Authentication Extension Value is the same as section 3.5.1
   of [RFC3344] except the payload is the notification other than
   registration.

   In the message to the home agent, the source address is the foreign
   agent's address, the destination address is the home agent's address
   (the "MD" value is set to 5), and the ordering of the extension is:
   notification extension, followed by any non-authentication Extensions
   used only by the home agent, followed by The Foreign-Home
   Authentication extension defined in section 3.5.4 of [RFC3344].
   Computing Authentication Extension Value is the same as section 3.5.1
   of [RFC3344] except the payload is the notification other than
   registration.

[Ahmad]
Is there a certain sequence that is needed here?
Does the FA have the option to send these messages at any time, for
example?
Is there a need for synchronization between the MN and tits HA?

4.4.4.  Receiving Generic Notification Acknowledgement Messages

   In the case of a FA-CoA, if the foreign agent receives this message,
   and the "MD" value is set to 3, it means that the notification
   acknowledgement message came from the mobile node, otherwise it came
   from the home agent.

   If the "MD" value is set to 1, and the foreign agent accepted this
   message, 

[Ahmad]
Here it seems acceptance comes before checking the FA-HA AE; Is that
correct?

   the Foreign-Home Authentication extension MUST be checked,
   and the home agent MUST check the Authenticator value in the
   Extension.  

[Ahmad]
Do you mean here the FA?

   If no Foreign-Home Authentication Extension is found, or
   if more than one Foreign-Home Authentication Extension is found, or
   if the Authenticator is invalid, the foreign agent MUST silently
   discard the Notification Acknowledgement message.  
   
   If the foreign
   agent accepted this message, the home agent MAY also process it based
   on the notification event.

[Ahmad]
What does this mean?

   If the "MD" value is set to 3, and the foreign agent accepted this
   message, the Mobile-Foreign Authentication extension MUST be checked,
   and the foreign agent MUST check the Authenticator value in the
   Extension.  If no Mobile-Foreign Authentication Extension is found,
   or if more than one Mobile-Foreign Authentication Extension is found,
   or if the Authenticator is invalid, the foreign agent MUST silently
   discard the Notification Acknowledgement message.  If the foreign
   agent accepted this message, the foreign agent MAY also process it
   based on the notification event.

[Ahmad]
Again, acceptance of the message comes before checking the FA-HA AE?

   In the case of a FA-CoA and if the "MD" value is set to 2, if the
   foreign agent received this message, the Mobile-Foreign
   Authentication extension MUST be checked, and the foreign agent MUST
   check the Authenticator value in the Extension.  If no Mobile-Foreign
   Authentication Extension is found, or if more than one Mobile-Foreign
   Authentication Extension is found, or if the Authenticator is
   invalid, the foreign agent MUST silently discard the Notification
   Acknowledgement message.  

[Ahmad]
Ok. Again, it is Interesting, If MD value is set to 2, the message is
sent by the MN to the HA. The original Mobile IPv4 makes MN-FA AE
optional since signaling is between the MN and its HA, however, MIP4
Generic notification message here mandates the MN-FA SA for signaling
between the MN and its HA. Is that right?
Also, is there any mapping between the request and the ack messages?

   If foreign agent accepted the mobile node's
   Generic Notification Acknowledgement message, it MUST relay this
   message to the home agent.  The foreign agent MUST NOT modify any of
   the fields beginning with the fixed portion of the Generic
   Notification Acknowledgement message through and including the
   Mobile-Home Authentication Extension or other authentication
   extension supplied by the home agent as an authorization-enabling
   extension for the mobile node.  Furthermore, the foreign agent MUST
   process and remove any Extensions following the Mobile-Home
   Authentication Extension and MAY append any of its own non-
   authentication Extensions of relevance to the home agent, if
   applicable, and MUST append the Foreign-Home Authentication
   Extension, if the foreign agent shares a mobility security
   association with the home agent.

4.5.  Home Agent Consideration

   The Home agent MAY initiate a generic notification message to both
   the mobile node and foreign agent, and it also MAY receive a generic
   notification acknowledgement message from both the foreign agent and
   mobile node.  The home agent also MAY receive a generic notification
   message from the foreign agent, but only when there is a binding for
   a mobile node.  If the home agent receives a notification message
   from a foreign agent and there is no corresponding mobile node
   registration, the home agent should drop the notification message.

4.5.1.  Sending Generic Notification Messages

   In the case of a FA-CoA, the home agent may either send a
   notification message to notify the foreign agent, or have the foreign
   agent relay the notification message to the mobile node if the mobile
   node needs to be notified.

   If the message is from the home agent to the foreign agent, the
   source address is the home agent's address, and the destination
   address is the foreign agent's address

   If the foreign agent is working only as a relay agent, the "MD" value
   is set to 0, and the ordering of the extension is: the notification
   extension, followed by any non-authentication extension expected to
   be used by mobile node, followed by Mobile-Home Authentication
   Extension defined in section 3.5.2. of [RFC3344], followed by any
   non-authentication Extensions used only by the foreign agent,
   followed by The Foreign-Home Authentication extension defined in
   section 3.5.4 of [RFC3344].  Computing Authentication Extension Value
   is the same as section 3.5.1 of [RFC3344].

[Ahmad]
Also are we mandating FA-HA AE when the HA sends a notification message
to the MN through the FA?

   If the foreign agent is the target of this notification message, then
   the "MD" value is set to 1, and the ordering of the extension is: the
   notification extension, followed by any non-authentication Extensions
   used only by the foreign agent, followed by The Foreign-Home
   Authentication extension defined in section 3.5.4 of [RFC3344].
   Computing Authentication Extension Value is the same as section 3.5.1
   of [RFC3344].

[Ahmad]
Talks about ordering of the extensions. This message is destined to the
FA, i.e. from the HA to the FA. What about replay protection here? Is it
mentioned any where else?

   In the case of a Co-located CoA, the home agent MAY send a
   notification message directly to the mobile node if it needs to be
   notified.  The "MD" value is set to 0, and the ordering of the
   extension is: the notification extension, followed by any non-
   authentication extension expected to be used by mobile node, followed
   by Mobile-Home Authentication Extension defined in section 3.5.2. of
   [RFC3344].

4.5.2.  Receiving Generic Notification Acknowledgement Messages

   In the case of a FA-CoA, if the home agent receives this message, and
   the "MD" value is set to 2, it means that the notification
   acknowledgement message came from mobile node, otherwise it came from
   the foreign agent.

[Ahmad]
Again. It is better to indicate the MD rather than otherwise.

   If the "MD" value is set to 5, and the home agent accepted this
   message, the home agent MAY also process it based on the notification
   event.  The Foreign-Home Authentication extension MUST be checked,
   and the home agent MUST check the Authenticator value in the
   Extension.  If no Foreign-Home Authentication Extension is found, or
   if more than one Foreign-Home Authentication Extension is found, or
   if the Authenticator is invalid, the home agent MUST silently discard
   the Notification Acknowledgement message.

   If the "MD" value is set to 2, and the home agent accepted this
   message, the Mobile-Home Authentication extension MUST be checked,
   and the home agent MUST check the Authenticator value in the
   Extension.  

[Ahmad]
Acceptance precedes MN-HA AE checking?

   If no Mobile-Home Authentication Extension is found, or
   if more than one Mobile-Home Authentication Extension is found, or if
   the Authenticator is invalid, the home agent MUST silently discard
   the Notification Acknowledgement message.  If the home agent accepted
   this message, the home agent MAY also process it based on the
   notification event.

   In the case of a Co-located CoA, if the home agent received this
   message, the Mobile-Home Authentication extension MUST be checked,
   and the home agent MUST check the Authenticator value in the
   Extension.  If no Mobile-Home Authentication Extension is found, or
   if more than one Mobile-Home Authentication Extension is found, or if
   the Authenticator is invalid, the home agent MUST silently discard
   the Notification Acknowledgement message.

4.5.3.  Receiving Generic Notification Messages

   The home agent MAY receive a generic notification message sent from
   the foreign agent.  When the home agent receives this message, the
   Foreign-Home Authentication extension MUST be checked, and the home
   agent MUST check the Authenticator value in the Extension.  If no
   Foreign-Home Authentication Extension is found, or if more than one
   Foreign-Home Authentication Extension is found, or if the
   Authenticator is invalid, the home agent MUST silently discard the
   Notification message.  

[Ahmad]
This Generic message could come from the Mobile Node and it seems that
this draft mandate the use of the FA-HA AE even in the cases when the
message is sent from the MN to the HA and covered by the MN-HA AE? Why?
Why the Generic Notification Message has stronger security requirement
than Mobile IPv4 signaling? in this respect.

   If home agent accepts the foreign agent's
   generic notification message, it will process it based on the
   notification extension.  Furthermore, the home agent MAY reply with a
   Generic Notification Acknowledgement message back to the foreign
   agent based on the "A" flag in the notification message.

4.5.4.  Sending Generic Notification Acknowledgement Messages

   If the generic notification message came from the foreign agent only,
   the home agent MAY reply with a generic notification acknowledgement
   message to the foreign agent based on the "A" flag in the
   notification message.  If the "A" flag is set in the notification
   message, then the home agent MUST send a Notification Acknowledgement
   message.  The message is as follows: The source address is home
   agent's address, the destination address is the foreign agent's
   address, the "MD" value is set to 1.  The ordering of the extension
   is: any non-authentication Extensions used only by the foreign agent,
   followed by The Foreign-Home Authentication extension defined in
   section 3.5.4 of [RFC3344].

[Ahmad]
What about sending Generic Notification Ack with MD is set to 0?

5.  Usage Example

   There are several applications that could use this generic
   notification message. for example, during handover between CDMA 2000
   1x EV-DO and Wireless LAN, the PPP resource of CDMA side have to be
   removed on the foreign agent (PDSN) to avoid over-charging
   subscribers.  Other applications such as registration revocation,

[Ahmad]
[RFC3543] Mobile IPv4 revocation does this functionality in a well
defined standard. 
Why do we need another mechanism for this one?

   home agent switch over, NEMO prefix changes, service or billing
   related events, load balancing where the home agent wants to move
   some of the registered mobile nodes to other home agents, service
   termination due to end of prepaid time, and service interruption due
   to system maintenance.

   Here we give a example of using revocation extension and describe
   some possible event which could use the generic string extension
   [RFC3344] 

[Ahmad]
I do not understand the reference to RFC3344 in the above sentence.

   based on this notification mechanism also.  There is also
   the possibility that this notification message could carry many
   extensions at once.  A new VSE extension could be defined to support
   this notification message.

5.1.  Revocation Extension

   If one agent wants to notify another agent about registration
   revocation [RFC3543], it could easily be carried by a generic
   notification message and generic notification acknowledgement by
   specifying the exact "Subtype" in the two messages.

[Ahmad]
First of all, I do not see why we need to have two mechanisms to address
the same problem.
Secondly, Are you saying that you are proposing a simpler approach and
procedure for achieving Mobile IPv4 Revocation by merely including the
revocation extension in Generic Notification request/Ack?
If that the case, it would be good to give us an idea how.

5.2.  Generic String Extension

   In some case, the home agent or foreign agent needs to notify the
   mobile node about service termination due to the end of prepaid time,
   or service interruption due to system maintenance.  This information
   could be defined based on a string [RFC4917]which is recognized by
   the mobile node easily.  An example would be "Maintenance Stopping",
   "Prepaid Expire".  These string MUST be strictly defined so they
   could be easily understood by all of the network entities.  "Subtype"
   number would need to be decided by the working group.

7.  Security Considerations

   This specification operates in the security constraints and
   requirements of [RFC3344].  
[Ahmad]
What does this mean?

   It extends the operations of mobile node,
   home agent and foreign agent defined in [RFC3344] to notify each
   other about some events.  The Generic Notification message defined in
   the specification could carry information that modifies the mobility
   bindings.  Therefore the message MUST be integrity protected.  Replay
   protection MUST also be guaranteed.

[Ahmad]
Good. How is this achieved in this document?

   RFC 3344 provides replay protection only for registration requests
   sent by the mobile node.  There is no mechanism for replay protection
   for messages initiated by a Foreign Agent.  
[Ahmad]
Okay, then how this is addressed in this document?

   The 64-bit Identification
   field specified in this document for the Generic Notification message
   is used to provide replay protection for the notification messages
   initiated by the Foreign Agent.

[Ahmad]
How this is achieved?
Can you refer me to the section number or any where in the draft?

Regards, 
Ahmad  

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hui Deng
	Sent: Thursday, July 03, 2008 12:54 AM
	To: [email-masked]
	Subject: Re: [Mip4] WGLC:
draft-ietf-mip4-generic-notification-message-04.txt

	Hello, all

	 
	
http://www.ietf.org/internet-drafts/draft-ietf-mip4-generic-notification
-message-05.txt
	
	Many thanks
	 
	-Hui

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 15 Jul 2008 01:45:07 -0500

I tried my best to give you detailed comments hoping that would be easier for you to follow, but that seems not to work well. Let me here try to provide you and all of involved parties with some detailed high level comments, hoping that would help in understanding the proper scope of what you are trying to propose here, I may add while seems to me that you are taking this task lightly:)

RFC3344 Security Architecture:
==========================

1. Fundamentally, RFC3344 introduced an end-to-end signaling protocol between the Mobile Node (MN) and ITS home agent (HA).
2. The FA is a passive mobility entity which participates in relaying the MIP4 RRQ to the HA or the RRP to the MN.
3. This means that fundamentally, RFC3344 needs to address security architecture based on the above two criteria, which means if RFC3344 only address the security between the MN and the HA ALONE, that still should be enough. ACTUALLY that is what RFC3344 mandates and anything else is OPTIONAL.

Hope this is clear.

NOW: let me come to your attempt to propose a new "What so called Generic Notification Message" signaling.

1. In your proposal, you are proposing an end-to-end signaling between the following nodes:
1.1. MN-HA and HA-MN, this the only scenario that is relevant to RFC3344.
1.2. MN-FA and FA-MN, this scenario is NOT addressed in RFC3344 and THUS it is new with new security architecture and requirement that you MUST clearly identify and address. Although, it may sound as if RFC3344 is addressing this case but it is NOT.
1.3. FA-HA and HA-FA, this scenario is NOT addressed in RFC3344 and THUS it is new with new security architecture and requirement that you MUST clearly identify and address. The more relevant document in here is RFC3543.

In order for this "Generic Notification Message" to work, YOU MUST have the security architecture to address the following main items:

No. I. MN-FA-MN Secure Signaling:
============================

1. A security architecture that address all applicable security threats for this end-to-end signaling, for example saying that the Identification field is used for replay protection does not mean anything. You need to clearly articulate how replay protection mechanism is used in each case. How you security architecture address Man-in-the-middle attack, etc.
2. You MUST remember that the MN MAY have no pre-existing relationship with the visited foreign network.
3. You MUST remember that since RFC3344 does not propose an end-to-end signaling between the MN and the FA as part of MIP4 signaling, RFC3344 did not have to address the following question: "How a MN visiting a foreign network with NO pre-existing relationship is able to establish a secure signaling with the FA" That is why MN-FA AE is OPTIONAL in RFC3344 and is NOT required to establish a MIP4 session. However, in your case, YOU MUST address it and make a case, how this visiting MN all of a sudden have a security association with the visited network. You can NOT just ignore it as if nothing happened!

I am sorry, I tend to write long emails which cause some people to get lost sometimes, but I hope that I did not loose you thus far, let us continue.

No. II. FA-HA-FA Secure Signaling: (Almost similar to MN-FA-MN)
============================

1. A security architecture that address all applicable security threats for an end-to-end signaling between the FA and the HA.  For example, in RFC3344 the HA is always receiving RRQ but sending RRP, different messages, do you see the difference. Instead of you looking into RFC3344, you SHOULD look into RFC3543, Registration Revocation in Mobile IPv4, Security architecture. It is more relevant.
2. You MUST remember that the FA and the HA MAY belong to different operators and there has to be some assumption of how these two nodes establish their security association. Please remember, All operators that I am aware of HATE statically configured shared secret keys. Please keep that in mind. Although, statically configured shared key MAY just a distant MAY  be possible between the MN and its HA, but unlikely between the FA and the HA across different domains.
3. You MUST also remember that since RFC3344 does not propose an end-to-end signaling between the FA and the HA as part of MIP4 signaling, RFC3344 did not have to mandate the use of FA-HA AE nor address how it could be established.

The fact that RFC3344 did not talk about these questions and did not address how these SA could be established IS NOT an excuse for you not to worry about it. What you are proposing and what RFC3344 proposes are mainly two different things.

NO. III. Relation to Binding Revocation:
===============================
I still do not understand what you tried to say about Registration Revocation, However, I want you to answer the following questions:
1. Are we in MIP4 wg in the business of proposing more than one solution for the same problem space, YES or NO.
2. Is your solution more reliable and easier to deploy than the protocol already specified in RFC3543.

May be if you answer these questions first, then we will move to the more technical ones.

FINALLY, please remember that a Mobile IPv4 deployment based on RFC3344 does not require MN-FA SA nor FA-HA SA, while for the same operator to deploy a "Generic Notification Message" signaling to service the Mobility session that was established without a MN-FA SA nor a FA-HA SA, all of a sudden needs to have those SA in place. Why is that acceptable to you? Does that make sense?

I am not saying the answer is "it does not make sense", what I am saying is that you have to make a valid case/story for everything that you are proposing.

Regards, 
Ahmad 

	From: Hui Deng [mailto:[email-masked]] 
	Sent: Monday, July 14, 2008 1:23 AM
	To: Muhanna, Ahmad (RICH1:2H10)
	Cc: [email-masked]; Henrik Levkowetz; Vijay Devarapalli; Sri Gundavelli; Brian Haley
	Subject: Re: [Mip4] WGLC: draft-ietf-mip4-generic-notification-message-04.txt

	Hello all,

	Probably the following comments are a little late but it is better than
	never.
	IMO, this draft needs to address these questions before sent to the
	IESG.
	==> thanks for your kind detail review, sorry for my late reply.
	your comments has been detailed reply inline below started with "==>
	I have updated the draft based on your comments,
	Please help to read 06 version.
	 
	thanks again.
	 
	-Hui

	+++++++++++++

	[Ahmad]
	What is the definition of MIP-related information. A more detailed
	description is better.
	==> of MIP-related information such as vendor specific extensions, generic string notification or binding revocation.

	  IP Fields:

	  UDP Fields:

	    Source Port            variable.

	      0                   1                   2                   3

	  Identification

	[Ahmad]
	According to RFC3344, timestamp is mandatory but nonce is optional. Does
	that mean that we MUST make sure that this draft , at least, MUST work
	for timestamp.
	==>How about like this
	"Here is the same as Sections 5.4 and 5.7 of <xref target="RFC3344"/>. 
	Timestamps is mandatory and nonces is optional."

	  Extensions

	[Ahmad]
	we are barely referring to RFC3344 here but the proposed model is
	different than the one in RFC3344.
	For example: section 3.5 again talks about FA-HA and MN-FA AE being
	OPTIONAL. What is the relation to this document?
	IS that optional too? Is there any scenario that it is mandatory for
	this draft?
	==> Good suggestion, how about like this
	              "The fixed portion of the Generic Notification Message is followed
	               by one or more extensions which may be used with this message, and
	               by one or more authentication extensions (as defined in Section
	               3.5 of [RFC3344]. This document mandate the MN-HA AE when this message
	               is sent between the mobile node and the home agent, others are optional.
	               This document also mandate the MN-FA AE when this message is sent between
	               the mobile node and the foreign agent, others are optional. This document
	               mandate the FA-HA AE when this message is sent between the foreign agent 
	               and the home agent, others are optional. This could be judged based on "MD" value.).
	               See Sections 3.6.1.3 and 3.7.2.2 of <xref target="RFC3344"/> 
	               for information on the relative order in which different
	               extensions, when present, must be placed in a Generic Notification
	               Message."

	BTW: What the authorization-enabling extension has to do with the
	generic notification message. I understand that with respect to Mobile
	IPv4 protocol but what is the relation here? May be we can refer to it
	as MN-HA AE.
	==> It really depends on which entity talks with which entity,
	for MN talks with FA, MN-FA AE will be refered to. I made a clarification 
	in the above text.

	   0                   1                   2                   3

	  Identification

	[Ahmad]
	How is that done?
	==> you could refer to Section 5.7 of the RFC 3344. Here is the same mechanism.

	     The value is

	[Ahmad]
	Are we assuming that the security association here is dynamically
	allocated or statically configured. It will be good to elaborate more on
	this one. Because RFC3344 does not clearly specify this one. On the
	other hand, does the replay protection mechanism for Generic message has
	anything to do with the one for Mobile IPv4.?
	==> This document only describe how to use SA, regarding whether it is
	dynamically or statically configured, will be out of the scope of this document.
	If RFC 3344 also need clarification, then it may also need a seperated document.

	  Extensions

	[Ahmad]
	Same comments as above.
	==>revise to
	              "The fixed portion of the Generic Notification Message is followed
	               by one or more extensions which may be used with this message, and
	               by one or more authentication extensions (as defined in Section
	               3.5 of [RFC3344]. This document mandate the MN-HA AE when this message
	               is sent between the mobile node and the home agent, others are optional.
	               This document also mandate the MN-FA AE when this message is sent between
	               the mobile node and the foreign agent, others are optional. This document
	               mandate the FA-HA AE when this message is sent between the foreign agent 
	               and the home agent, others are optional. This could be judged based on "MD" value.).
	               See Sections 3.6.1.3 and 3.7.2.2 of <xref target="RFC3344"/> 
	               for information on the relative order in which different
	               extensions, when present, must be placed in a Generic Notification
	               Message."
	               
	     message.

	[Ahmad]
	Okay, what extensions the MN need to include.
	How it is going to handle replay protection. Is that mentioned any where
	in RFC3344, for example?
	If that is captured in another section, we need to reference that
	section here.
	==> Below section already explained what kind of extensions MN should include
	please help to read it. 

	[Ahmad]
	Okay, but what about the case when receiving the message from the FA.
	Which extension the MN MUST validate? What kind of replay protection it
	will validate and how?
	==> It already says based on the specific rule, ok, I will append one
	clause in the above section like
	"The MN MUST check for the presence of an authorization-enabling extension, 
	and perform the indicated authentication.  Exactly one authorization-enabling
	extension MUST be present in the Registration Request, if this message 
	came from a foreign agent, MN-FA AE MUST be present, if this message came 
	from a foreign agent, MN-HA AE MUST be present.

	  If no Mobile-Home

	Is there any other extension that will be used by any other entity other
	than the FA? Why do we need to say "used only by the FA"
	==> There could be other extension or self defined extension used by FA.
	Because this message only go to FA, so it says "used only by the FA"

	[Ahmad]
	I do not see any normative text here? Is including the MN-FA AE optional
	or mandatory?
	How the MN will address replay protection in this case, for example in
	the timestamp which is the mandatory method in RFC3344?
	==>As described in appended part of previous section, MN-FA AE will be mandatory
	in this case.

	[Ahmad]
	This is missing the normative part and what needs to be done. Why the MN
	needs to include the MN-FA AE in this case or we are just listing the
	order of the extensions here?
	==> Here is just the listing order of the extension, previous appended part
	already said that MN-HA AE will be mandatory.

	[Ahmad]
	May be some rewording is needed.
	==> thanks, rewored
	  "The foreign agent can not only relay generic notification message from
	  the home agent and mobile node, but it can also initiate a generic
	  notification message to the mobile node or home agent, and it will depends
	  on whether there is a binding for the mobile node."

	[Ahmad]
	What otherwise, mean here? May be we need to specifically mention the
	Message Direction.
	Do we need to specify how the FA needs to handle this case. I mean what
	actions where to store the message ID. Does it need to maintain
	something in order to match the Generic Ack from the MN which is coming
	back soon from the MN?
	==> There are only two cases, to make you more clear, 
	I could reword to 
	"If the "MD" value is set to 1, it means
	that the target of the notification is the foreign agent."

	[Ahmad]
	Before accepting the message what else the FA needs to check before
	accepting this message. For example, is the FA going to check the
	message ID? And how?
	==> I thought that "check" already explained ID will be checked.
	to make you more understandable, I could refer to 
	"  If the "MD" value is set to 1, the Foreign-Home Authentication
	  extension MUST be checked, and the foreign agent MUST check the
	  Authenticator value in the Extension which is the same as the
	  section 3.7.3.1 of RFC 3344."

	[Ahmad]
	I do not understand this. If the MD is set to 0, it means that the
	message is destined to the MN. Are we mandating that FA-HA AE for this
	scenario? Although, I assume that the message is protected using MN-HA
	AE. NO?
	==> Thanks, good catch, you are correct, reword to
	          "If the "MD" value is set to 0,  the foreign agent MUST
	          check the FA-HA AE and Authenticator value in the Extension if the Foreign-Home
	          Authentication extension is presented. if more than one Foreign-Home
	          Authentication Extension is found, or if the Authenticator is
	          invalid, the foreign agent MUST silently discard the Notification
	          message. If the foreign agent validates the home agent's generic
	          notification message, "

	[Ahmad]
	Ok. Fine. What "accept" in the above sentence means here?
	We need to specify what that exactly means.
	==> changed to " validates"

	[Ahmad]
	The above is confusing. Probably needs to be reworded.
	==> reword
	         "Furthermore, the foreign agent MUST process and remove any Extensions following
	          the Mobile-Home Authentication Extension, and MAY append any of its own
	          non-authentication Extensions of relevance to the mobile node if
	          applicable, and MUST append the Mobile-Foreign Authentication
	          Extension, if the foreign agent shares a mobility security
	          association with the Mobile Node. "

	  or other

	[Ahmad]
	This message is sent by the FA to the HA. No? what are the extensions
	supplied by the HA?
	==> No, this message is relayed to HA, sent originally by MN.

	  Furthermore,

	[Ahmad]
	This is really confusing.
	When the FA receives a Generic Message from the HA, it MUST check the
	FA-HA AE, which means that the FA-HA SA is mandatory. However, when
	sending the Generic Acknowledgement, the FA MUST include the FA-HA AE
	ONLY if it shares a FA-HA SA with the HA? I am not sure how does this
	make sense?
	==> You may need re-read this part, it is only relayed by FA, 
	other than FA reply to HA which is described in the next paragraph.

	[Ahmad]
	What does the above paragraph mean?
	==> This paragraph means MD=1 case, if you could help to read it again.

	[Ahmad]
	Is there a certain sequence that is needed here?
	Does the FA have the option to send these messages at any time, for
	example?
	Is there a need for synchronization between the MN and tits HA?
	==> Yes, FA could send these messages any time, which confused you 
	from the beginning. 

	[Ahmad]
	Here it seems acceptance comes before checking the FA-HA AE; Is that
	correct?
	==> this clause has been removed.

	[Ahmad]
	Do you mean here the FA?
	==> thanks, you are correct, revised

	  If the foreign

	[Ahmad]
	What does this mean?
	==> same mistake like above, revise to "the foreign agent MAY"

	[Ahmad]
	==> removed.

	[Ahmad]
	Ok. Again, it is Interesting, If MD value is set to 2, the message is
	sent by the MN to the HA. The original Mobile IPv4 makes MN-FA AE
	optional since signaling is between the MN and its HA, however, MIP4
	Generic notification message here mandates the MN-FA SA for signaling
	between the MN and its HA. Is that right?
	Also, is there any mapping between the request and the ack messages?
	==> As previous appended part, it is optional, revised to
	"If the "MD" value is set to 3, if the Mobile-Foreign Authentication extension
	 is presented, it MUST be checked,"
	mapping could be done by "identification" field.

	[Ahmad]
	Also are we mandating FA-HA AE when the HA sends a notification message
	to the MN through the FA?
	==>we don't mandate it as previous appended part explained

	[Ahmad]
	Talks about ordering of the extensions. This message is destined to the
	FA, i.e. from the HA to the FA. What about replay protection here? Is it
	mentioned any where else?
	==>"Identification" field is always used for replay protection.

	[Ahmad]
	==> thanks, revised

	[Ahmad]
	==> thanks, removed.

	[Ahmad]
	==> Revised in the previous part.and this part has been revised accordingly.

	[Ahmad]
	==> thanks, appended

	5.  Usage Example

	[Ahmad]
	[RFC3543] Mobile IPv4 revocation does this functionality in a well
	defined standard.
	Why do we need another mechanism for this one?
	==>  revocation mechanism doesn't specify the case FA send to HA?

	[Ahmad]
	==〉thanks, revised

	[Ahmad]
	First of all, I do not see why we need to have two mechanisms to address
	the same problem.
	Secondly, Are you saying that you are proposing a simpler approach and
	procedure for achieving Mobile IPv4 Revocation by merely including the
	revocation extension in Generic Notification request/Ack?
	If that the case, it would be good to give us an idea how.
	==> firstly, as explained early, binding revocation message could be sent
	from FA to HA.
	secondly, I see no confusion here, we just need specify subtype for revocation.
	Home Address,Foreign Domain Address, and Home Domain Address already defined
	in generic notifcation message. For my understanding,
	Revocation Identifier is not necessary because Notifcation/Notification Ack
	already specify identification field which could be used directly for 
	protection of anti-play attack. Hope this explaination could remove your concern.

	  This specification operates in the security constraints and
	  requirements of [RFC3344].
	[Ahmad]
	What does this mean?
	==>I could elaborate to make it more clear.
	"This specification operates in the security constraints and
	  requirements of [RFC3344]. It require that when this message is transmitted
	  between the mobile node and the home agent, MN-HA AE is mandatory, when this
	  message is transmitted between the mobile node and the foreign agent, MN-FA AE
	  is mandatory, when this message is transmitted between the foreign agent and
	  the home agent, FA-HA AE is mandatory."

	[Ahmad]
	Good. How is this achieved in this document?
	==> Identification field inside the message could be used.

	==> Clarified

	[Ahmad]
	How this is achieved?
	Can you refer me to the section number or any where in the draft?
	==> section 4.1 and 4.2 of this document
	the end