Re: [Mip4] Summary of security issues (was RE: WGLC: draft-ietf-mip4-generic-notification-message-04.txt)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mip4] Summary of security issues (was RE: WGLC: draft-ietf-mip4-generic-notification-message-04.txt)
Hi Ahmad,
On 7/17/08 4:12 PM, "Ahmad Muhanna" <amuhanna at nortel.com> wrote:
>> Subject: Summary of security issues (was RE: [Mip4] WGLC:
>> draft-ietf-mip4-generic-notification-message-04.txt)
>>
>> 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.
>
> [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 impossFrom mip4-bounces at ietf.org Thu Jul 17 16:33:03 2008
Return-Path: <mip4-bounces at ietf.org>
X-Original-To: mip4-archive at optimus.ietf.org
Delivered-To: ietfarch-mip4-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 5041328C133;
Thu, 17 Jul 2008 16:33:03 -0700 (PDT)
X-Original-To: mip4 at core3.amsl.com
Delivered-To: mip4 at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 27D8328C141
for <mip4 at core3.amsl.com>; Thu, 17 Jul 2008 16:33:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.566
X-Spam-Level:
X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5
tests=[AWL=-1.034, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Q7LTPm+1jk59 for <mip4 at core3.amsl.com>;
Thu, 17 Jul 2008 16:32:59 -0700 (PDT)
Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms
[216.52.164.185])
by core3.amsl.com (Postfix) with ESMTP id ECC0728C125
for <mip4 at ietf.org>; Thu, 17 Jul 2008 16:32:58 -0700 (PDT)
Received: from 75.26.137.116 ([75.26.137.116]) by mse15be2.mse15.exchange.ms
([172.30.10.130]) via Exchange Front-End Server
owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange
Server HTTP-DAV ; Thu, 17 Jul 2008 23:33:30 +0000
User-Agent: Microsoft-Entourage/12.10.0.080409
Date: Thu, 17 Jul 2008 16:33:29 -0700
From: Vijay Devarapalli <vijay at wichorus.com>
To: Ahmad Muhanna <amuhanna at nortel.com>,
McCann Peter-A001034 <pete.mccann at motorola.com>
Message-ID: <C4A524D9.14B3%vijay at wichorus.com>
Thread-Topic: Summary of security issues (was RE: [Mip4] WGLC:
draft-ietf-mip4-generic-notification-message-04.txt)
Thread-Index: AcjmmX1GykQQ/DWyRnuE1z1dTAhS+wAAEaUQAALRCbAAAVu6YAAwVfoQAAsM8qAAH5sfAAACjnJwAAM04tAAC5/EMAAAUN5gAAIRXJ0=
In-Reply-To: <C5A96676FCD00745B64AE42D5FCC9B6E19803054 at zrc2hxm0.corp.nortel.com>
Mime-version: 1.0
Cc: Hui Deng <denghui02 at gmail.com>, mip4 at ietf.org,
Sri Gundavelli <sgundave at cisco.com>
Subject: Re: [Mip4] Summary of security issues (was RE: WGLC:
draft-ietf-mip4-generic-notification-message-04.txt)
X-BeenThere: mip4 at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mip4>,
<mailto:mip4-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mip4>
List-Post: <mailto:mip4 at ietf.org>
List-Help: <mailto:mip4-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mip4>,
<mailto:mip4-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mip4-bounces at ietf.org
Errors-To: mip4-bounces at ietf.org
Hi Ahmad,
On 7/17/08 4:12 PM, "Ahmad Muhanna" <amuhanna at nortel.com> wrote:
>> Subject: Summary of security issues (was RE: [Mip4] WGLC:
>> draft-ietf-mip4-generic-notification-message-04.txt)
>>
>> 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.
>
> [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 forible 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.
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.
>>
>> 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.
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.
>> 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.
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.
> 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.
The one major issue I see is about the replay protection mechanism. Yes, we
can call that "serious work". :)
Vijay
>
> Cheers and thanks for the very focused useful summary!
> I am sure a LOT of time will be saved because of it!
>
>
>>
>> Vijay
>>
>>> -----Original Message-----
>>> From: mip4-bounces at ietf.org [mailto:mip4-bounces at ietf.org]
>> On Behalf
>>> Of McCann Peter-A001034
>>> Sent: Thursday, July 17, 2008 10:11 AM
>>> To: Ahmad Muhanna
>>> Cc: mip4 at ietf.org
>>> Subject: Re: [Mip4] WGLC:
>>> draft-ietf-mip4-generic-notification-message-04.txt
>>>
>>> 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
>> 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.
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.
>>
>> 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.
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.
>> 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.
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.
> 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.
The one major issue I see is about the replay protection mechanism. Yes, we
can call that "serious work". :)
Vijay
>
> Cheers and thanks for the very focused useful summary!
> I am sure a LOT of time will be saved because of it!
>
>
>>
>> Vijay
>>
>>> -----Original Message-----
>>> From: mip4-bounces at ietf.org [mailto:mip4-bounces at ietf.org]
>> On Behalf
>>> Of McCann Peter-A001034
>>> Sent: Thursday, July 17, 2008 10:11 AM
>>> To: Ahmad Muhanna
>>> Cc: mip4 at ietf.org
>>> Subject: Re: [Mip4] WGLC:
>>> draft-ietf-mip4-generic-notification-message-04.txt
>>>
>>> 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
>> mechani 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 ism,
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: mip4-bounces at ietf.org [mailto:mip4-bounces at ietf.org] 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; mip4 at ietf.org; Henrik
>>>>>>> Levkowetz Subject: Re: [Mip4] WGLC:
>>>>>>> draft-ietf-mip4-generic-notification-message-04.txt
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Vijay
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> 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,
>>>>>>>>>>>> Ahmad
>>>>>>>>>>>>
>>>>>>>>>>>> Subject: 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 those
>>>>>>>>>>> mobility 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/
>>>
>>> --
>>> 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/
>>>
>>
--
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/
s 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
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: mip4-bounces at ietf.org [mailto:mip4-bounces at ietf.org] 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; mip4 at ietf.org; Henrik
>>>>>>> Levkowetz Subject: Re: [Mip4] WGLC:
>>>>>>> draft-ietf-mip4-generic-notification-message-04.txt
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Vijay
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> 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,
>>>>>>>>>>>> Ahmad
>>>>>>>>>>>>
>>>>>>>>>>>> Subject: 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 those
>>>>>>>>>>> mobility 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/
>>>
>>> --
>>> 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/
>>>
>>
--
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.
