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

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

** 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: [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: Sri Gundavelli <[email-masked]>
Date: Tue, 15 Jul 2008 07:53:56 -0700 (PDT)

inline ...

> clearly identify and address. The more relevant document in here is

I do not understand the logic here, or your ideas on 3344 Security 
Architecture. Couple of points:

HA, FA and MN are the mobility entities. The protocol defines
security mechanism to secure messages at each hop.

- Between FA and MN, in the form of MFAE and there also 4721.
- Between FA and HA in the form of FHAE
- Betweem MN and HA in the form of MHAE

Some of these extensions in some scenarios may be optional, it
does not imply, there cannot be signaling between those mobility
entities.

FA is not a passive node as you put it. Its not a on-path router
or a random node in the network. Its is a mobility agent. When
a mobile node's registration sent through a FA is accepted, the
state that is created on the HA and FA have relationship. Each
of those agents should be able to signal the other agent with
respect to those states. An example is Revocation signaling
which is allowed between all mobility agents. As long as there
is mechanism to secure signaling between those mobility agents
and as long as the signaling is w..r.t the state associated with
the same set of mobile nodes, it is perfectly valid to allow
signaling between those agents. FHAE may be optional on a
message secured by mobile node, it does not mean we cannot
mandate the use of FHAE when a signaling message originates from
HA to FA or vicerversa.

Finally, on RFC 3344's Security Architecture, its all about a
configured security association between any two mobility agents. As
long as there is a SA configured, it is sufficient to secure the
signaling messages between those two agents. If the protocol did
not mandate the use of that security in some paths and for some
signaling, it does not mean that it cannot be enabled for some
other signaling, such as Generic Notification and this does not mean
it requires a new security architecture.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 15 Jul 2008 10:54:21 -0500

Hi Sri,

Please see inline.

Regards,
Ahmad

> Subject: Re: [Mip4] WGLC: 
> draft-ietf-mip4-generic-notification-message-04.txt 
> 
> inline ... 
> 
> > 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.
> >
> 
> I do not understand the logic here, or your ideas on 3344 
> Security Architecture. 

[Ahmad]
Okay. That is still fine. I do not blame you.
But understanding the security architecture or requirement or you may
call it whatever, e.g., addressing all security threats to make sure
that we have a secure signaling protocol or anything similar.

> Couple of points:
[Ahmad]

May be the valid question here is the following. 
>From security prospective or security architecture, What are these
extensions are used for? 
When we understand that, then we can go deeper into further details.
> 
> FA is not a passive node as you put it. 

[Ahmad]
A quick visit to RFC3344, section 3.7. would help.

Here is what it says:

"3.7. Foreign Agent Considerations

   The foreign agent plays a mostly passive role in Mobile IP
   registration. 
"

But beside that point, from security prospective, there is a big
difference between the following two cases:

1. End-to-End signaling. Not only that but your protocol allows each End
to send the same message to the other end.
2. Let me say, a pass through mobility agent which makes sure that the
RRQ is a good one and then relay it to the destined node, i.e, other
end.

In the first case, we must make sure that the security architecture
proposed for securing this protocol addresses all security threats. In
the latter one, we could be more flexible, that is basically why MN-FA
AE is OPTIONAL in RFC3344. On the other hand, MN-FA addresses only one
security threat, what about the others?

> Its not a on-path router
> respect to those states. 

[Ahmad]
I agree with your explanation above and I never said anything that
contradicts it.

> An example is Revocation signaling
> which is allowed between all mobility agents. 

[Ahmad]
Excellent, then please take a look at RFC3543 and try to use that
security architecture in your case if it is applicable. But you are
right, RFC3543 did a good job to address all of these security threats.

> As long as there

[Ahmad]
As I said, answering the first question about the role of FA-HA AE would
help in here. Without understanding the role of this extension we will
always propose a handicapped signaling protocol that I doubt will be
acceptable as an IETF standard. On the other hand, RFC3543 mandates
FA-HA for any FACoA Mobile IPv4 registration which indicate the support
of Registration Revocation. This is on the top of mandating FA-HA AE or
similar mechanism to secure the Revocation messages. Please check that
RFC for further details.

BTW: since we are at Binding Revocation and this draft claims that
Revocation can merely be supported by adding an extension with some
information. Can some one tell me how the FA and HA would communicate
their support for this functionality? Or it is assumed that all entities
should support it as soon as it is released?

> configured security association between any two mobility agents. 

[Ahmad]
That is NOT TRUE.
As I said only configuration between the MN and ITS HA could be argued
that way. Why?
Because it is assumed that the HA and the MN belong to a specific
operator and can configure these two entities with the same security
parameters. Not to mention that is also NOT accepted by operators and
would like to have a dynamic mechanism for that. On the other hand, I
would like you to show me how that configuration would work in the case
of the MN visiting a foreign Network, i.e., an FA.

> As

[Ahmad]
Hopefully, you got what I meant by security architecture by now.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 15 Jul 2008 09:40:22 -0700 (PDT)

Hi Ahmad,

> security architecture in your case if it is applicable.

RFC3543 did not define a new security architecture. In that protocol
use and a issue related to replay attack and the solution there by,
did not create a new security architecture for Mobile IP. There are
no two security architectures, one from 3344 and one from 3543.

The semantics provided by 3344 with respect securing signaling
messages in all the 3 paths is sufficient for Generic Notification.
In this usage of MIP signaling and using those provided security
semantics from 3344, leads to some new security vulnerabilities,
we have to identify those attacks and document them. AFAIK, beyond
requiring SA between the mobility entities and requring that the
signaling message when sent with regards to mobility session has
to have some state w.r.t that mobility session on both those nodes,
beyond and above, nothing else is required.

If all you are saying, is to add some text to security
considerations about some vulnerability that you know off and in
the context Notfication draft, let us know and we can add text
related to that issue. That's all to it.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 15 Jul 2008 11:53:15 -0500

Hi Sri,

> RFC3543 did not define a new security architecture. In that 
> protocol use and a issue related to replay attack and the 
> solution there by, did not create a new security architecture 
> for Mobile IP. 
> There are no two security architectures, one 
> from 3344 and one from 3543.
> 
> The semantics provided by 3344 with respect securing 
> signaling messages in all the 3 paths is sufficient for 
> Generic Notification.

[Ahmad]
Sure, But that is NOT TRUE. And I will leave it at that.

Cheers!

> In this usage of MIP signaling and using those provided 
> security semantics from 3344, leads to some new security 
> vulnerabilities, we have to identify those attacks and 
> document them. AFAIK, beyond requiring SA between the 
> mobility entities and requring that the signaling message 
> when sent with regards to mobility session has to have some 
> state w.r.t that mobility session on both those nodes, beyond 
> and above, nothing else is required.
> 
> considerations about some vulnerability that you know off and 
> in the context Notfication draft, let us know and we can add 
> text related to that issue. That's all to it.
> 
> Thanks
> Sri
> 
> 
> 
> 
> 
> 
> 
> >> Architecture.
> >> Some of these extensions in some scenarios may be 
> optional, it does 
> >> not imply, there cannot be signaling between those 
> mobility entities.
> > [Ahmad]
> >

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 15 Jul 2008 14:05:26 -0400

Hi Ahmad, 

> -----Original Message-----
> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Tuesday, July 15, 2008 9:53 AM
> To: Sri Gundavelli
> Cc: Hui Deng; Brian Haley; Vijay Devarapalli; [email-masked]; 
> Henrik Levkowetz
> Subject: RE: [Mip4] WGLC: 

RFC 3543 does not define a new security architecture. It just uses
whatever is provided in RFC 3344. So I am not sure what you are trying
to say here. 

Vijay

> But you are

---

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

Hi Vijay,

I am not sure if you followed all of the discussion thus far, but just
in case, my comment below is in response to the statement that preceded
it and not related to RFC3543:) I actually do not know how that came
into the discussion ....

> Sure, But that is NOT TRUE. And I will leave it at that.

Anyhow, I am not sure why we need to be bugged down to RFC3543 security,
but just to clarify my suggestion that the use of RFC3543 to secure
end-to-end signaling between the FA and the HA is more relevant than
RFC3344 in response to a comment made by Sri, I would like to say the
following:

1. RFC3543 mandates the use of FA-HA AE during FACoA Mobile IPv4
registration which include an indication for revocation support. (The
use of FA-HA AE is similar to RFC3344)

1.1. As a subset of the above, RFC3543 securely allow the negotiation of
revocation between the FA and HA.

2. It also mandates, of course, FA-HA AE for revocation messages. (The
use of FA-HA AE is similar to RFC3344)

3. RFC3543 proposes a very specific replay protection mechanism that is
different than the simple one in RFC3344. Both are based on timestamp,
However, the timestamp replay protection as in RFC3344 addresses
signaling between the MN and HA and that is not sufficient in the case
of FA and HA. 

4. It requires a specific indication in the revocation messages to
prevent man-in-the-middle reflection attack. (Specific to RFC3543)

5. As an alternative to FA-HA AE, it also allows the use of IPsec.
(Specific to RFC3543)

Finally, as I said earlier couple of times, if you still do not like my
term "Security architecture", you can call security requirements, ways
to address all security threats, etc.:)

Cheers!

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, July 15, 2008 1:05 PM
> To: Muhanna, Ahmad (RICH1:2H10); Sri Gundavelli
> Cc: Hui Deng; Brian Haley; [email-masked]; Henrik Levkowetz
> > Cc: Hui Deng; Brian Haley; Vijay Devarapalli; [email-masked]; Henrik 
> > Levkowetz
> > > did not create a new security architecture for Mobile IP.
> > > There are no two security architectures, one from 3344 
> and one from 
> > > 3543.
> > > 
> RFC 3543 does not define a new security architecture. It just 
> uses whatever is provided in RFC 3344. So I am not sure what 
> you are trying to say here. 
> 
> Vijay
> 
> > 
> > Cheers!
> > 
> > > semantics from 3344, leads to some new security 
> vulnerabilities, we 
> > > have to identify those attacks and document them. AFAIK, beyond 
> > > signaling message when sent with regards to mobility 
> session has to 
> > > have some state w.r.t that mobility session on both those nodes, 
> > > considerations about some vulnerability that you know off 
> and in the 
> > > context Notfication draft, let us know and we can add 
> text related 
> > > >> or a random node in the network. Its is a mobility 
> agent. When a 
> > > >> mobile node's registration sent through a FA is accepted, the 
> > > >> state that is created on the HA and FA have 
> relationship. Each of 
> > > >> those agents should be able to signal the other agent with 
> > > >> respect to those states.
> > > >
> > > > [Ahmad]
> > > >> An example is Revocation signaling which is allowed 
> between all 
> > > >> mobility agents.
> > > >
> > > > [Ahmad]
> > > >> signaling between those agents. FHAE may be optional 
> on a message 
> > > >> secured by mobile node, it does not mean we cannot mandate the 
> > > >> use of FHAE when a signaling message originates from 
> HA to FA or 
> > > >> vicerversa.
> > > >
> > > > [Ahmad]

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 16 Jul 2008 15:09:38 -0400

Ahamd makes some good points.  The Identification field used in
RFC3543 is set to a 32-bit timestamp, not a 64-bit value as in
basic Mobile IP.  The timestamp is a secure replay protection
mechanism only because an initial timestamp is sent in the
original Registration Request that negotiates support for
Revocation, which is itself protected by the vanilla replay
protection from RFC3344.  Note that the original, RFC3344
replay protection has a built-in mechanism to re-sync through
the use of a Rejection message with an error code; such support
is lacking in both RFC3543 and the present generic notification
document.

3344 doesn't specify how replay protection is achieved between
FA and HA when they communicate directly in the absence of a
Registration Request from a mobile node.  I think it is inadequate
to just depict an Identification field and say "same as RFC3344"
without also specifying a Generic Notification Rejection message
or something similar that can re-synchronize the clocks (or really,
that allows one node to calculate the proper offeset between the
clocks so that it can adjust its Identification fields appropriately).
Personally I'd prefer a re-sync mechanism to the initialization
approach because it would be robust against arbitrary clock drift
between the two nodes.

I also note that there seems to be some missing text in Section 4.2
of the generic notifications draft under the description of the
Identification 
field; the text there seems to be a copy of the Extensions description
of 
Section 4.1.

-Pete

Ahmad Muhanna wrote:
> Hi Vijay,
> 
> I am not sure if you followed all of the discussion thus far, but
> just in case, my comment below is in response to the statement that
> preceded it and not related to RFC3543:) I actually do not know how
> that came into the discussion ....   
> 
> Anyhow, I am not sure why we need to be bugged down to RFC3543
> security, but just to clarify my suggestion that the use of RFC3543
> to secure end-to-end signaling between the FA and the HA is more
> relevant than   
> 1.1. As a subset of the above, RFC3543 securely allow the negotiation
> of revocation between the FA and HA. 
> 
> 2. It also mandates, of course, FA-HA AE for revocation messages.
> (The use of FA-HA AE is similar to RFC3344) 
> 
> 3. RFC3543 proposes a very specific replay protection mechanism that
> is different than the simple one in RFC3344. Both are based on
> timestamp, However, the timestamp replay protection as in RFC3344
> addresses signaling between the MN and HA and that is not sufficient
> in the case of FA and HA.    
> 
> Finally, as I said earlier couple of times, if you still do not like
> my term "Security architecture", you can call security requirements,
> ways to address all security threats, etc.:)  
> 
> Cheers!
> 
> 
> Regards,
> Ahmad
> 
> 
>>> Levkowetz Subject: RE: [Mip4] WGLC:
>>>> protocol use and a issue related to replay attack and the solution
>>>> there by, did not create a new security architecture for Mobile IP.
>>>> There are no two security architectures, one from 3344 and one
>>>> from 3543. 
>>>> 
>> whatever is provided in RFC 3344. So I am not sure what you are
>> trying to say here. 
>> 
>> Vijay
>> 
>>> 
>>> Cheers!
>>> 
>>>> semantics from 3344, leads to some new security vulnerabilities, we
>>>> signaling message when sent with regards to mobility session has to
>>>>>>> 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. 
>>>>>>> 
>>>>>> 
>>>>> But understanding the security architecture or requirement or you
>>>>> may call it whatever, e.g., addressing all security threats to
>>>>> make sure that we have a secure signaling protocol or anything
>>>>> similar. 
>>>>> 
>>>>>> Couple of points:
>>>>>> 
>>>>>> 
>>>>>> does not imply, there cannot be signaling between those
>>>> mobility entities.
>>>>> [Ahmad]
>>>>> 
>>>>> From security prospective or security architecture, What are
>>>>> these extensions are used for? When we understand that, then we
>>>>> can go deeper into further details. 
>>>>>> 
>>>>> registration. "
>>>>> 1. End-to-End signaling. Not only that but your protocol allows
>>>>> each End to send the same message to the other end.
>>>>> 2. Let me say, a pass through mobility agent which makes sure
>>>>> that the RRQ is a good one and then relay it to the destined
>>>>> node, i.e, other end. 
>>>>> 
>>>>> In the first case, we must make sure that the security
>>>>> architecture proposed for securing this protocol addresses all
>>>>> security threats. In the latter one, we could be more flexible,
>>>>> that is basically why MN-FA AE is OPTIONAL in RFC3344. On the
>>>>> other hand, MN-FA addresses only one security threat, what about
>>>>> the others? 
>>>>> 
>>>>> 
>>>>>> Its not a on-path router
>>>>>> or a random node in the network. Its is a mobility agent. When a
>>>>>> state that is created on the HA and FA have relationship. Each of
>>>>> I agree with your explanation above and I never said anything
>>>>> that contradicts it. 
>>>>> 
>>>>> 
>>>>>> An example is Revocation signaling which is allowed between all
>>>>>> mobility agents.
>>>>> 
>>>>> [Ahmad]
>>>>> security architecture in your case if it is applicable. But you
>>>>> are right, RFC3543 did a good job to address all of these
>>>>> security threats. 
>>>>> 
>>>>>> As long as there
>>>>>> signaling between those agents. FHAE may be optional on a message
>>>>>> use of FHAE when a signaling message originates from HA to FA or
>>>>>> vicerversa.
>>>>> 
>>>>> [Ahmad]
>>>>> As I said, answering the first question about the role of FA-HA
>>>>> AE would help in here. Without understanding the role of this
>>>>> extension we will always propose a handicapped signaling protocol
>>>>> that I doubt will be acceptable as an IETF standard. On the other
>>>>> hand, RFC3543 mandates FA-HA for any FACoA Mobile IPv4
>>>>> registration which indicate the support of Registration
>>>>> Revocation. This is on the top of mandating FA-HA AE or similar
>>>>> mechanism to secure the Revocation messages. Please check that
>>>>> RFC for further details.  
>>>>> 
>>>>> Revocation can merely be supported by adding an extension with
>>>>> some information. Can some one tell me how the FA and HA would
>>>>> communicate their support for this functionality? Or it is
>>>>> assumed that all entities should support it as soon as it is
>>>>> released? 
>>>>> 
>>>>>> 
>>>>> As I said only configuration between the MN and ITS HA could be
>>>>> argued that way. Why? Because it is assumed that the HA and the
>>>>> MN belong to a specific operator and can configure these two
>>>>> entities with the same security parameters. Not to mention that
>>>>> is also NOT accepted by operators and would like to have a
>>>>> dynamic mechanism for that. On the other hand, I would like you
>>>>> to show me how that configuration would work in the case of the
>>>>> MN visiting a foreign Network, i.e., an FA. 
>>>>> 
>>>>>> As
>>>>>> other signaling, such as Generic Notification and this does not
>>>>>> mean it requires a new security architecture.
>>>>> 
>>>>> [Ahmad]

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 16 Jul 2008 13:02:45 -0700 (PDT)

Hi Pete,

Thanks for your comments. Couple of points:

1.) The Generic Notification draft uses a 64-bit identification field,
just as in 3344 and not a 32-bit filed. This is not tied to 3543
mechanism or formats.

2.) When calculating the authenticators, or adding any form of
extensions, we have to consider the approaches as identical to
3344, except where there is deviation, such as the resync
considerations when FA originates the message, it will have
additional considerations as in MN.

There are some textual clarifications needed for the resync case
and related to this. We will fix it. Fundamentally, the security
model or nothing else has to change, as the original email
claimed. We need to fix some text, we will do that.

Thanks
Sri

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 17 Jul 2008 13:11:29 -0400

Hi, Ahmad,

Ahmad Muhanna wrote:
>> 
>> Ahmad Muhanna wrote:
>>> Hello Pete,
>>> Good points, Hope you have sometime for my comments:)
>>> 
>>> It has been a very long time since we participated with others to
>>> help developing the replay protection mechanism for Registration
>>> Revocation. However, as you said and I am sure you still remember,
>>> there was a very good reason for that mechanism.
>>> 
>>> BTW: with respect to your preference of using a re-sync mechanism,
>>> which somewhat similar to the MN-HA replay protection, I remember
>>> that mechanism was discredited because it did not solve the whole
>>> problem:) IMO, A MN is a single client where its session is served
>>> always by the same HA.
>> 
>> Nothing prevents an MN from having multiple Mobile IP registrations
>> with different HAs.
> 
> [Ahmad]
> True. However, the MN is the initiator of the RRQ and establishing
> the session. In the case of GNM, we are sending a message which
> relates to a session that has been established between the MN and its
> HA where the FA was a pass-through, i.e. passive agent.   

Right - but we could use the same mechanisms to protect the GNM
from replay attacks as we do the RRQ, assuming we have a suitable
Identifier synchronization mechanism.

>> 
>>> Additionally, part of the reply protection of RFC3344 (which is not
>>> spelled out very well) is the timestamp of the last successful RRQ
>>> which is maintained in the MN binding at the HA. That piece does not
>>> exist in the case of GNM and that why Revocation tried to make that
>>> link. I have not looked at RFC3344 for sometime and I could be wrong
>>> but that what I recall.
>> 
>> Yes, the HA maintains that number so that it can properly order RRQs.
>> 
>>> As I said, it has been a long time:), but the following is what I
>>> still remember:
>>> 
>>> 1. Let us assume the clock of the FA went bad and backward for any
>>> reason, Any old message from the HA, within that range, can easily
>>> be replayed and the FA will accept it, i.e. that message could be
>>> replayed.
>> 
>> I think it is a security requirement that the node receiving messages
>> keeps its clock within a reasonable offset to real-time.
> [Ahmad]
> Hmmm... Does that mean we were wrong to eliminate this during
> Revocation replay protection discussion? 

I don't remember all the details, but we might have been concerned
about the extra round-trips of a synchronization mechanism.  In
retrospect,
it seems like the mechanism described in the Revocation extension may
not be robust to clock drift.

> One more thing, where this requirement is captured? and what do you
> mean by real-time here? 

The node enforcing replay protection needs to know that the message it
is checking was generated recently.  This is the time window discussed
in 3344.  Obviously, if someone can manipulate the clock being used
then replays become possible again.  

By "reasonable offset to real-time" I don't mean that we need to run
tight synchronization mechanisms like NTP.  In fact, I think the
requirement
is much looser and really just requires that the node's time be
monotonically
increasing and not jumping around arbitrarily.

>> If an adversary can take control of this clock it
>> is a security breach
> [Ahmad]
> That is good.
> However, a security breach at one node must not negatively impact
> other 
> nodes in the network. Do not you agree?

Well, the recipient of a message is responsible for enforcing
anti-replay protection.  If that node is breached then we open
ourselves up to attack.

>> and yes bad things can happen.
> 
> [Ahmad]
> Sure, that is why we need to have a mechanism that works for all
> cases. 
> No?

Are there particular failure cases that you have in mind?

>>> 2. Let us assume that a pool of HAs has several cards or even
>>> several different boxes with different clocks while all of them are
>>> reachable at the same HA IP address, How the FA will re-synch with
>>> such scenario? I mean the FA could re-synch the first time with HA1
>>> but the first GNM message the FA will send could be for a session
>>> on HA3, for example, and it will fail. The problem here could be
>>> that there is no reliable mechanism for FA-HA re-synchronization
>>> which may eventually cause a lot of error cases if MIP4 GNM is used
>>> frequently. 
>> 
>> I think the re-sync procedure shouldn't change the actual
>> value of the MN's internal clock.  Rather, it should produce
>> an offset between the MN's clock and that particular HA's
>> clock which is maintained along with the other parameters of
>> the security association.
>> This offset would be used to calculate the proper timestamp
>> to put in the next RRQ.  So, the MN could maintain multiple
>> different offsets with multiple different HAs.  Granted, this
>> is not spelled out very clearly in 3344 but I think this is
>> what most implementations do.
> 
> [Ahmad]
> I agree that is understood and I would assume that all current
> implementation does the same thing.
> However, It is not clear to me how that is related to the case of GNM
> when it handles a Client MIPv4 session that was established between
> the 
> MN and the HA. Could you elaborate?

I'm using the MN-HA replay protection as an example; we could use
the same mechanism in GNM to protect messages between other parties.
 
>> 
>>> 3. We also, if I recall correctly, discussed the issue of mandating
>>> NTP server on FA's and HA's, however, that was a strong requirement
>>> first and second how to impose that across different operators and
>>> domains. Since it is very common to have the FA and the HA belong
>>> to different domains, as in roaming scenarios.
>> 
>> Right, I don't think NTP should be a requirement.
>> 
>>> BTW: That concerning the case between the FA and HA; what do you
>>> think of the case between the FA and the MN?
>>> 
>>> 1. How replay protection would work, i.e. what mechanism to be use.
>> 
>> I think we can use a timestamp with a rejection message for
>> re-sync, just as with MN-HA.
>> 
>>> 2. Is this feature going to mandate RFC3957 or similar mechanism to
>>> allow MN-FA SA establishment?
>> 
>> Yes, it does require a security association.  3957 would be a
>> good way to establish it but I don't think this document
>> needs to specify how it comes into existence.  3344 is the same way.
> 
> [Ahmad]
> I am not sure what do you mean by "needs to specify how it comes into
> existence"?
> On the other hand, 3344 does not mandate MN-FA SA for completing MIP4
> signaling.
> IMO, if it was a requirement, 3344 would have indicated how that would
> be established, not necessarily reinvent the wheel but at least
> reference something if there was one.

If you want to send an authenticated and replay protected message
from one party to another, there needs to be a security association
in place.  This SA includes keys, time offsets, authentication
algorithm, and replay protection mechanism.  I think that the
notification draft should assume that an SA exists without specifying
new SA establishment protocols - those seem out of scope. 

-Pete

>> 
>>> Take care and hope to see you in Dublin.
>> 
>> Yes, see you there.
> 
> [Ahmad]
> Sure.
> 
>> 
>> -Pete
>> 
>>> Regards,
>>> Ahmad
>>> 
>>> 
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of McCann Peter-A001034 Sent: Wednesday, July 16, 2008 2:10
>>>> PM To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Sri
>>>> Gundavelli Cc: Hui Deng; Brian Haley; [email-masked]; Henrik
>>>> Levkowetz Subject: Re: [Mip4] WGLC:
>>>> mechanism only because an initial timestamp is sent in the original
>>>> Registration Request that negotiates support for Revocation, which
>>>> is itself protected by the vanilla replay protection from RFC3344.
>>>> Note that the original, RFC3344 replay protection has a built-in
>>>> mechanism to re-sync through the use of a Rejection message with an
>>>> error code; such support is lacking in both RFC3543 and the present
>>>> generic notification document.
>>>> 
>>>> 3344 doesn't specify how replay protection is achieved between FA
>>>> and HA when they communicate directly in the absence of a
>>>> without also specifying a Generic Notification Rejection message or
>>>> something similar that can re-synchronize the clocks (or really,
>>>> clocks so that it can adjust its Identification fields
>>>> appropriately). Personally I'd prefer a re-sync mechanism to the
>>>> initialization approach because it would be robust against
>>>> arbitrary clock drift between the two nodes. 
>>>> 
>>>> Identification field; the text there seems to be a copy of the
>>>> Extensions description of Section 4.1.
>>>> 
>>>> -Pete
>>>> 
>>>> 
>>>> Ahmad Muhanna wrote:
>>>>> Hi Vijay,
>>>>> 
>>>>> just in case, my comment below is in response to the statement
>>>>> that preceded it and not related to RFC3543:) I actually do not
>>>>> know how that came into the discussion ....
>>>>> 
>>>>> security, but just to clarify my suggestion that the use of
>>>>> RFC3543 to secure end-to-end signaling between the FA and the HA
>>>>> is more relevant than RFC3344 in response to a comment made by
>>>>> Sri, I would like to say the following: 
>>>>> 
>>>>> registration which include an indication for revocation support.
>>>>> 1.1. As a subset of the above, RFC3543 securely allow the
>>>>> negotiation of revocation between the FA and HA.
>>>>> 
>>>>> 3. RFC3543 proposes a very specific replay protection mechanism
>>>>> that is different than the simple one in RFC3344. Both are based
>>>>> on timestamp, However, the timestamp replay protection as in
>>>>> RFC3344 addresses signaling between the MN and HA and that is not
>>>>> sufficient in the case of FA and HA. 
>>>>> 
>>>>> 5. As an alternative to FA-HA AE, it also allows the use of
>>>>> IPsec. (Specific to RFC3543) 
>>>>> 
>>>>> 
>>>>> Finally, as I said earlier couple of times, if you still do not
>>>>> like my term "Security architecture", you can call security
>>>>> requirements, ways to address all security threats, etc.:)
>>>>> 
>>>>> Cheers!
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> Ahmad
>>>>> 
>>>>> 
>>>>>>> Henrik Levkowetz Subject: RE: [Mip4] WGLC:
>>>>>>>>> Excellent, then please take a look at RFC3543 and try to use
>>>>>>>>> that security architecture in your case if it is applicable.
>>>>>>>> 
>>>>>>>> for Mobile IP. There are no two security architectures, one
>>>>>> uses whatever is provided in RFC 3344. So I am not sure what you
>>>>>> are trying to say here. 
>>>>>> 
>>>>>> Vijay
>>>>>> 
>>>>>>> 
>>>>>>> Cheers!
>>>>>>> 
>>>>>>>> document them. AFAIK, beyond requiring SA between the mobility
>>>>>>>> entities and requring that the signaling message when sent
>>>>>>>> with regards to mobility session has to have some state w.r.t
>>>>>>>> that mobility session on both those nodes, beyond and above,
>>>>>>>> nothing else is required. 
>>>>>>>> 
>>>>>>>>>>> 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.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> But understanding the security architecture or requirement or
>>>>>>>>> you may call it whatever, e.g., addressing all security
>>>>>>>>> threats to make sure that we have a secure signaling protocol
>>>>>>>>> or anything similar. 
>>>>>>>>> 
>>>>>>>>>> Couple of points:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Some of these extensions in some scenarios may be optional,
>>>>>>>>>> it does not imply, there cannot be signaling between those
>>>>>>>> mobility entities.
>>>>>>>>> [Ahmad]
>>>>>>>>> 
>>>>>>>>> these extensions are used for? When we understand that, then
>>>>>>>>> we can go deeper into further details.
>>>>>>>>>> 
>>>>>>>>> But beside that point, from security prospective, there is a
>>>>>>>>> big difference between the following two cases:
>>>>>>>>> 
>>>>>>>>> 1. End-to-End signaling. Not only that but your protocol
>>>>>>>>> allows each End to send the same message to the other end.
>>>>>>>>> security threats. In the latter one, we could be more
>>>>>>>>> flexible, that is basically why MN-FA AE is OPTIONAL in
>>>>>>>>> RFC3344. On the other hand, MN-FA addresses only one security
>>>>>>>>> threat, what about the others? 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Its not a on-path router
>>>>>>>>>> or a random node in the network. Its is a mobility agent.
>>>>>>>>>> When a mobile node's registration sent through a FA is
>>>>>>>>>> accepted, the state that is created on the HA and FA have
>>>>>>>>>> relationship. Each of those agents should be able to signal
>>>>>>>>>> the other agent with respect to those states.
>>>>>>>>> 
>>>>>>>>> [Ahmad]
>>>>>>>>>> An example is Revocation signaling which is allowed between
>>>>>>>>>> all mobility agents.
>>>>>>>>> 
>>>>>>>>> [Ahmad]
>>>>>>>>> Excellent, then please take a look at RFC3543 and try to use
>>>>>>>>> that security architecture in your case if it is applicable.
>>>>>>>>> But you are right, RFC3543 did a good job to address all of
>>>>>>>>> these security threats. 
>>>>>>>>> 
>>>>>>>>>> As long as there
>>>>>>>>>> is mechanism to secure signaling between those mobility
>>>>>>>>>> agents and as long as the signaling is w..r.t the state
>>>>>>>>>> associated with the same set of mobile nodes, it is
>>>>>>>>>> perfectly valid to allow signaling between those agents.
>>>>>>>>>> FHAE may be optional on a message secured by mobile node, it
>>>>>>>>>> does not mean we cannot mandate the use of FHAE when a
>>>>>>>>>> signaling message originates from HA to FA or vicerversa.
>>>>>>>>> 
>>>>>>>>> [Ahmad]
>>>>>>>>> As I said, answering the first question about the role of
>>>>>>>>> FA-HA AE would help in here. Without understanding the role
>>>>>>>>> of this extension we will always propose a handicapped
>>>>>>>>> signaling protocol that I doubt will be acceptable as an IETF
>>>>>>>>> standard. On the other hand, RFC3543 mandates FA-HA for any
>>>>>>>>> FACoA Mobile IPv4 registration which indicate the support of
>>>>>>>>> Registration Revocation. This is on the top of mandating
>>>>>>>>> FA-HA AE or similar mechanism to secure the Revocation
>>>>>>>>> messages. Please check that RFC for further details. 
>>>>>>>>> 
>>>>>>>>> BTW: since we are at Binding Revocation and this draft claims
>>>>>>>>> that Revocation can merely be supported by adding an extension
>>>>>>>>> with some information. Can some one tell me how the FA and HA
>>>>>>>>> would communicate their support for this functionality? Or it
>>>>>>>>> is assumed that all entities should support it as soon as it
>>>>>>>>> is released? 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> As I said only configuration between the MN and ITS HA could
>>>>>>>>> be argued that way. Why? Because it is assumed that the HA
>>>>>>>>> and the MN belong to a specific operator and can configure
>>>>>>>>> these two entities with the same security parameters. Not to
>>>>>>>>> mention that is also NOT accepted by operators and would like
>>>>>>>>> to have a dynamic mechanism for that. On the other hand, I
>>>>>>>>> would like you to show me how that configuration would work
>>>>>>>>> in the case of the MN visiting a foreign Network, i.e., an FA.
>>>>>>>>> 
>>>>>>>>>> As
>>>>>>>>>> long as there is a SA configured, it is sufficient to secure
>>>>>>>>>> the signaling messages between those two agents. If the
>>>>>>>>>> protocol did not mandate the use of that security in some
>>>>>>>>>> paths and for some signaling, it does not mean that it
>>>>>>>>>> cannot be enabled for some other signaling, such as Generic
>>>>>>>>>> Notification and this does not mean it requires a new
>>>>>>>>>> security architecture. 
>>>>>>>>> 
>>>>>>>>> [Ahmad]

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 17 Jul 2008 18:33:19 -0400

Hi Ahmad, Pete,

Let me try and summarize the discussion so far.

Security association setup between the MN and the FA and between the FA
and the HA is out-of scope for the generic notification draft. It is
sufficient to assume that the security associations already exist. 

The generic notification draft should say that the MN-FA authentication
extension is mandatory in case the notification is between the MN and
the FA. Similarly it should say the FA-HA authentication extension is
mandatory in case the notification is between the FA and the HA. I have
a question here though. What if the notification message is of the type
that does not require any integrity protection? Some sort of an "FYI"
message. Should we still say the authentication extensions are
mandatory?

We need a replay protection mechanism for the generic notification
message. The current one based on the use of Identification field is not
sufficient. We should probably first modify the Identification field to
use "Timestamps" only. Not clear if nonces are useful at all. Then we
need a mechanism to sync the clocks with an error message.

Did I miss anything?

Vijay

> Behalf Of McCann Peter-A001034
> Sent: Thursday, July 17, 2008 10:11 AM
> To: Ahmad Muhanna
> Cc: [email-masked]
> signaling
> >>>>     Web interface: 
> https://www.ietf.org/mailman/listinfo/mip4

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 17 Jul 2008 18:12:36 -0500

Thanks Vijay this is very good!
I was planning to reply back to Pete but this is a good summary that
could help close all issues.

Please see some comments inline.

Regards,
Ahmad

> Subject: Summary of security issues (was RE: [Mip4] WGLC: 
> draft-ietf-mip4-generic-notification-message-04.txt)
> 
> Hi Ahmad, Pete,
> 
> Security association setup between the MN and the FA and 
> between the FA and the HA is out-of scope for the generic 
> notification draft. 

[Ahmad]
I am not looking for redefining anything, but if we are proposing a
protocol that mandate MN-FA SA, for example, we need to reference an
IETF doc, may be an SDO mechanism if that possible, etc. I believe
RFC3957 is there and it is an IETF standard that can be referenced. On
the other hand, if there is no such draft to address this, then we need
to have a plan to have it.

> It is sufficient to assume that the 
> security associations already exist.

[Ahmad]
I actually would like to see a reference to a doc which at least
describe one mechanism. I mean there has to be a default mechanism. The
default for MN-HA is "statically configured". What about MN-FA SA, or
FA-HA could they be statically configured.? I am sure the answer is
almost impossible for MN-FA and yes but extremely not convenient for
FA-HA. Then we need to have a default one. RFC3344 does not reference
anything because these two SA are optional and not mandatory to deploy
Mobile IPv4 as per RFC3344.
 
> 
> The generic notification draft should say that the MN-FA 
> authentication extension is mandatory in case the 
> notification is between the MN and the FA. 

[Ahmad]
Sure this is good.

> Similarly it 
> should say the FA-HA authentication extension is mandatory in 
> case the notification is between the FA and the HA. 

[Ahmad]
Agreed.

> I have a 
> question here though. What if the notification message is of 
> the type that does not require any integrity protection? Some 
> sort of an "FYI"
> message. Should we still say the authentication extensions 
> are mandatory?

[Ahmad]
I do not think it needs to be protected. 
However, care needs to be taken for replay protection of this case and
DoS attack. I assume that this kind of message does not require a
response. But still you do not want to exhaust resources. I think these
concerns need to be carefully addressed.

> 
> We need a replay protection mechanism for the generic 
> notification message. 
[Ahmad]
Yes.

> The current one based on the use of 
> Identification field is not sufficient. 

[Ahmad]
I am not sure what to say here. The final one could end up using the
Identification field and something else. But what I would say, the
current RFC3344 replay protection mechanism is not sufficient to handle
MN-FA and FA-HA replay protection.

As a matter of fact, one of the points that I forgot to point to Pete is
that even if we mandate RFC3957, we still have a problem with the replay
protection between the MN and the FA. Because RFC3957 assumes that
replay protection mode is negotiable between the MN and the HA ONLY. In
other words, how in the world the FA would know that the MN uses
timestamp or something else.

> We should probably 
> first modify the Identification field to use "Timestamps" 
> only. Not clear if nonces are useful at all. Then we need a 
> mechanism to sync the clocks with an error message.

[Ahmad]
Sure, we need a clear and secure replay protection mechanism for MN-FA
and FA-HA. Not necessarily to be the same mechanism but if it is the
same, rock-n-roll!

[Ahmad]
>From security prospective, I believe all things should have been
covered. 
You never know something else could pops up but I do not have anything
else in mind.

I still have one comment that no one answer. I believe the chairs and
our AD could have an answer for this. If MIP4 wg have a protocol for
Registration Revocation, why we are clearly suggesting a new protocol
which duplicate the same thing? As I asked before, are we in the
business of defining more than one protocol for the same problem space?
IF the answer is Yes, then be my guest; if the answer is NO, the draft
needs to remove any reference to the use of Registration Revocation.

Bottom line Vijay,
Let us put all non sense aside, this draft needs serious work. I am just
being frank and honest here.
First time I read the draft, I could not believe that it has already
passed wg Last Call.
I am sure the authors and the wg will be able to get it in a very good
shape.

Cheers and thanks for the very focused useful summary! 
I am sure a LOT of time will be saved because of it!

> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of McCann Peter-A001034
> > Right - but we could use the same mechanisms to protect the 
> GNM from 
> > replay attacks as we do the RRQ, assuming we have a suitable 
> > retrospect, it seems like the mechanism described in the Revocation 
> > extension may not be robust to clock drift.
> > 
> > requirement is much looser and really just requires that the node's 
> > time be monotonically increasing and not jumping around arbitrarily.
> > 
> > >> If an adversary can take control of this clock it is a security 
> > >> breach
> > > [Ahmad]
> > > That is good.
> > > other nodes in the network. Do not you agree?
> > 
> > >> I think the re-sync procedure shouldn't change the 
> actual value of 
> > >> the MN's internal clock.  Rather, it should produce an offset 
> > >> between the MN's clock and that particular HA's clock which is 
> > >> maintained along with the other parameters of the security 
> > >> association.
> > >> This offset would be used to calculate the proper 
> timestamp to put 
> > >> in the next RRQ.  So, the MN could maintain multiple different 
> > >> offsets with multiple different HAs.  Granted, this is 
> not spelled 
> > >> out very clearly in 3344 but I think this is what most 
> > >> implementations do.
> > > 
> > > [Ahmad]
> > > the MN and the HA. Could you elaborate?
> > 
> > I'm using the MN-HA replay protection as an example; we 
> could use the 
> > same mechanism in GNM to protect messages between other parties.
> >  
> > >> 
> > >> Yes, it does require a security association.  3957 would 
> be a good 
> > >> way to establish it but I don't think this document needs to 
> > >> specify how it comes into existence.  3344 is the
> > same way.
> > > 
> > > [Ahmad]
> > If you want to send an authenticated and replay protected 
> message from 
> > one party to another, there needs to be a security association in 
> > place.  This SA includes keys, time offsets, authentication 
> algorithm, 
> > and replay protection mechanism.  I think that the 
> notification draft 
> > should assume that an SA exists without specifying new SA 
> > establishment protocols - those seem out of scope.
> > 
> > -Pete
> > 
> > >> 
> > >>>>>>>>> Hopefully, you got what I meant by security 
> architecture by 
> > >>>>>>>>> now.
> > >>>>>>>>> 
> > >>>>>>>>>> 
> > >>>>>>>>>> Sri
> > >>>> 
> > >>>> --
> > >>>> Charter page: 
> http://www.ietf.org/html.charters/mip4-charter.html
> >      Charter page: 
> http://www.ietf.org/html.charters/mip4-charter.html

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Jul 2008 16:33:29 -0700

Hi Ahmad,

> Mobile IPv4 as per RFC3344.

I don't think the generic notification draft needs to talk about security
association setup at all. We could add some text that says security
association setup between the MN and the FA and between the FA and HA is out
of scope.
 
> concerns need to be carefully addressed.

Replay protection is a separate issue. I am talking about scenarios when no
integrity protection is required. In that case, the authentication
extensions would not be used. The authentication extensions will be used
only if integrity protection is required for the notification messages.
 
> timestamp or something else.

This is not about punting to RFC 3344, 3543 or to 3957. I don't think we
should do that. The replay protection mechanism in the generic notification
draft will be self-contained.

> I am sure the authors and the wg will be able to get it in a very good

The one major issue I see is about the replay protection mechanism. Yes, we
can call that "serious work". :)

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 17 Jul 2008 18:44:35 -0500

Hi Vijay, 

> between the 
> >> FA and the HA is out-of scope for the generic notification draft.
> > 
> > [Ahmad]
> > the other hand, if there is no such draft to address this, then we 
> > need to have a plan to have it.
> > 
> > describe one mechanism. I mean there has to be a default mechanism. 
> > The default for MN-HA is "statically configured". What 
> about MN-FA SA, 
> > or FA-HA could they be statically configured.? I am sure 
> the answer is 
> I don't think the generic notification draft needs to talk 
> about security association setup at all. We could add some 
> text that says security association setup between the MN and 
> the FA and between the FA and HA is out of scope.

[Ahmad]
Sure, if it is only me who feels that way, then I am with the wg
consensus. 

> >> authentication extension is mandatory in case the notification is 
> >> between the MN and the FA.
> > 
> > [Ahmad]
> > Sure this is good.
> > 
> >> Similarly it
> >> should say the FA-HA authentication extension is mandatory in case 
> >> the notification is between the FA and the HA.
> > 
> > [Ahmad]
> > Agreed.
> > 
> >> I have a
> >> question here though. What if the notification message is 
> of the type 
> > response. But still you do not want to exhaust resources. I think 
> > these concerns need to be carefully addressed.
> 
> Replay protection is a separate issue. I am talking about 
> scenarios when no integrity protection is required. In that 
> case, the authentication extensions would not be used. The 
> authentication extensions will be used only if integrity 
> protection is required for the notification messages.

[Ahmad]
Okay, but if you allow this scenario, then anyone can send any message
to the other node. What I am saying we need to be very careful to make
sure that we have analyzed all threats and there is enough text for the
implementers not to be a victim of one of these attacks. 

The more you emphasize it, the more I got scared:)

> >> message.
> > current RFC3344 replay protection mechanism is not sufficient to 
> > handle MN-FA and FA-HA replay protection.
> > 
> > As a matter of fact, one of the points that I forgot to 
> point to Pete 
> > is that even if we mandate RFC3957, we still have a problem 
> with the 
> > replay protection between the MN and the FA. Because 
> RFC3957 assumes 
> > that replay protection mode is negotiable between the MN and the HA 
> > ONLY. In other words, how in the world the FA would know 
> that the MN 
> > uses timestamp or something else.
> 
> This is not about punting to RFC 3344, 3543 or to 3957. I 
> don't think we should do that. The replay protection 
> mechanism in the generic notification draft will be self-contained.

[Ahmad]
Agreed 100%.

> 
> > Bottom line Vijay,
> > Let us put all non sense aside, this draft needs serious work. I am 
> > just being frank and honest here.
> The one major issue I see is about the replay protection 
> mechanism. Yes, we can call that "serious work". :)

[Ahmad]
Sorry! did not mean to under estimate the hard work that was put in this
draft.

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 28 Jul 2008 03:53:54 -0700

Hi folks.  I think this draft needs more review.  Some comments on
version 06.

1) Sect. 3.2.

It's confusing to show "notificaton" from AAA to FA.  Maybe the arrow
can be named "trigger" since the notification message is from FA to MN
and to HA?

2) Sect. 3 usage scenarios clarificaton.  Can MN send notification to
FA?  MN to HA via FA or direct?

3) Sect. 4.1. Reference RFC 3115 for VSE and RFC 4917 for generic
string.  Not clear how binding revocation is applied in GNM?

   A generic notification message is sent by a mobility agent to inform
   another mobility agent, or a mobile node, of MIP-related information
   such as vendor specific extensions, generic string notification or
   binding revocation.

3b) Sect. 4.1. The IP destination address should be "Same as the last
Registration Reply/Request message received".  Also, shouldn't the
source IP address and port be same as the last registration message?
This would support NAT traversal and ensure same security association
used for GNM/GNA and RRQ/RRP.

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

4) Sect. 4.1. What is the Binding Revocation extension?  RFC 3543
specifies Revocation Support Extension to indicate MN or FA supports
revocation function.  But this extension does not provide notification
or revocation. 

      3 Information carried in Binding Revocation extension

5) Typo "foreing" -> "foreign":

      5 -- Message sent by the foreing agent to the home agent

6) Using nonce method requires much more operational description (e.g.
HA does not have nonce value with MN after registration).  Replay
protection using timestamp should be covered in a section for clarity.
For example, FA -> MN GNM security is not covered by RFC 3344.

   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.  Here is the same as Sections 5.4 and 5.7 of [RFC3344].
      Timestamps is mandatory and nonces is optional.
 
7) Sect. 4.2. Why is the GNA's source UDP port not copied from the GNM?
NAT traversal issue (when NAT between FA and HA) if not copied.

   UDP Fields:

     Source Port            variable.

8) Sect. 4.2.  Why values 2 and 3 are not described?  As noted before,
I'm not clear about value 3.

      The value 0 is reserved and should not be used.  The value 1
      indicates that the actual information is carried in vendor
      specific extensions.  Other values are reserved for future
      extensions.

9) Sect. 4.2. Is MD needed in GNA?  GNA is in response to GNM so MD
should be known.  Also, not sure if HA and CoA address fields needed in
GNA?

10) Sect. 4.2. The description does not cover Identification field.  

   Identification

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

11) Sect. 4.2. There are 3 defined cases: VSE, generic string, and
revocation extension.  VSE is handled by each vendor.  I assume that
generic string handling is based on RFC 4917.  Revocation is unclear.

If the mobile node accepts the home agent's generic
   notification message, it will process it according to the specific
   rules for that extension. 

12) Sect. 4.3.2. source address should be MN's HoA in the case of
FA-CoA.  Destination address should be FA.

   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),

13) Sect. 4.4.1. FHAE is optional for GNM from HA to MN via FA, right?

   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. 

14) Sect 4.4.3.  How does FA know the timestamp of the HA to send GNM?
Does FA have to glean the Identification field in the RRP?  Need
clarification here.  Also, if FA maintains some timestamp value for each
HA, and vice versa, that needs to be added to FA and HA considerations.

15) 4.5. Since RFC 4917 was intended for MN to receive a message from
the network, it's unclear what HA or FA will do when generic string is
received?

16) 4.5.  Shouldn't HA acknowledge the receipt of the GNM in this case?

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.

17) 4.5.2.  Should specify that HA sends GNM with A bit set when GNA is
not received.  Or this can be generically covered.

18) sects. 5 and 5.1.  The example for revoking the CDMA session can be
handled by revocation message (RFC 3543).  This adds to the confusion
when revocation message vs. GMN should be used.  May be good to clarify
that point.

19) 5.1. Typo "notificaiton".  There are other typos that can be checked
later.

20) 5.2. Not clear how this is different from revocation message with
generic message string extension?

21) Agree with Pete on the timestamp sync issue.  That means some use of
code 133 in GNA.  Should there be some Code field in GNA to confirm
positive or negative operation after receiving GNM?

22) NAI extension should be covered in draft.  Home Address is not
typically sufficient to identify the MN.

Kent