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

["Ahmad Muhanna" <amuhanna at nortel.com>]

** Original message bounced because of the size of the message** Deleted
all previous responses from the message body.

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 

 


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