Re: [Mip4] WGLC: draft-ietf-mip4-generic-notification-message-04.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mip4] WGLC: draft-ietf-mip4-generic-notification-message-04.txt
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:denghui02 at gmail.com]
Sent: Monday, July 14, 2008 1:23 AM
To: Muhanna, Ahmad (RICH1:2H10)
Cc: mip4 at ietf.org; 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
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.
==> of MIP-related information such as vendor specific extensions, generic string notification or binding revocation.
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.
==>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
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?
==> 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.
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?
==> you could refer to Section 5.7 of the RFC 3344. Here is the same mechanism.
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.?
==> 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
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.
==>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.
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.
==> Below section already explained what kind of extensions MN should include
please help to read it.
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?
==> 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
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"
==> 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"
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?
==>As described in appended part of previous section, MN-FA AE will be mandatory
in this case.
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?
==> Here is just the listing order of the extension, previous appended part
already said that MN-HA AE will be mandatory.
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.
==> 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."
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?
==> 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."
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?
==> 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."
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?
==> 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, "
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.
==> changed to " validates"
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.
==> 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. "
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?
==> No, this message is relayed to HA, sent originally by MN.
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?
==> 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.
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?
==> This paragraph means MD=1 case, if you could help to read it again.
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?
==> Yes, FA could send these messages any time, which confused you
from the beginning.
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?
==> this clause has been removed.
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?
==> thanks, you are correct, revised
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?
==> same mistake like above, revise to "the foreign agent MAY"
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?
==> removed.
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?
==> 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.
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?
==>we don't mandate it as previous appended part explained
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?
==>"Identification" field is always used for replay protection.
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.
==> thanks, revised
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?
==> thanks, removed.
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.
==> Revised in the previous part.and this part has been revised accordingly.
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?
==> thanks, appended
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?
==> revocation mechanism doesn't specify the case FA send to HA?
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.
==〉thanks, revised
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.
==> 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.
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?
==>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."
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?
==> Identification field inside the message could be used.
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?
==> Clarified
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?
==> section 4.1 and 4.2 of this document
the end
--
Mip4 mailing list: Mip4 at ietf.org
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/
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
