 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
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 On Wed, 16 Jul 2008, McCann Peter-A001034 wrote:
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 ....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.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-----Original Message----- From: Vijay Devarapalli [mailto:vijay at wichorus.com] Sent: Tuesday, July 15, 2008 1:05 PM To: Muhanna, Ahmad (RICH1:2H10); Sri Gundavelli Cc: Hui Deng; Brian Haley; mip4 at ietf.org; Henrik Levkowetz Subject: RE: [Mip4] WGLC: draft-ietf-mip4-generic-notification-message-04.txt Hi Ahmad,-----Original Message----- From: Ahmad Muhanna [mailto:amuhanna at nortel.com] Sent: Tuesday, July 15, 2008 9:53 AM To: Sri Gundavelli Cc: Hui Deng; Brian Haley; Vijay Devarapalli; mip4 at ietf.org; Henrik Levkowetz Subject: RE: [Mip4] WGLC: draft-ietf-mip4-generic-notification-message-04.txt Hi Sri,draft-ietf-mip4-generic-notification-message-04.txt Hi Ahmad,Excellent, then please take a look at RFC3543 and try to use that 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.[Ahmad] Sure, But that is NOT TRUE. And I will leave it at that.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. VijayCheers!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 On Tue, 15 Jul 2008, Ahmad Muhanna wrote:Hi Sri, Please see inline. Regards, AhmadSubject: Re: [Mip4] WGLC: draft-ietf-mip4-generic-notification-message-04.txt inline ... On Tue, 15 Jul 2008, Ahmad Muhanna wrote: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.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: 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 thosemobility entities.[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 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] 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 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?Finally, on RFC 3344's Security Architecture, its all about a 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 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] Hopefully, you got what I meant by security architecture by now.Sri
-- 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/