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 Vijay,
> 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 woFrom mip4-bounces at ietf.org Thu Jul 17 16:44:36 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 3C54B3A6869;
Thu, 17 Jul 2008 16:44:36 -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 E6A7F3A67B6
for <mip4 at core3.amsl.com>; Thu, 17 Jul 2008 16:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.589
X-Spam-Level:
X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 r67n9bWqtkFv for <mip4 at core3.amsl.com>;
Thu, 17 Jul 2008 16:44:32 -0700 (PDT)
Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57])
by core3.amsl.com (Postfix) with ESMTP id B73ED3A68D9
for <mip4 at ietf.org>; Thu, 17 Jul 2008 16:44:31 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
[47.103.123.71])
by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
m6HNiv410811; Thu, 17 Jul 2008 23:44:58 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 17 Jul 2008 18:44:35 -0500
Message-ID: <C5A96676FCD00745B64AE42D5FCC9B6E198030B6 at zrc2hxm0.corp.nortel.com>
In-Reply-To: <C4A524D9.14B3%vijay at wichorus.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Mip4] Summary of security issues (was RE: WGLC:
draft-ietf-mip4-generic-notification-message-04.txt)
Thread-Index: AcjmmX1GykQQ/DWyRnuE1z1dTAhS+wAAEaUQAALRCbAAAVu6YAAwVfoQAAsM8qAAH5sfAAACjnJwAAM04tAAC5/EMAAAUN5gAAIRXJ0AAAouoA==
References: <C5A96676FCD00745B64AE42D5FCC9B6E19803054 at zrc2hxm0.corp.nortel.com>
<C4A524D9.14B3%vijay at wichorus.com>
From: "Ahmad Muhanna" <amuhanna at nortel.com>
To: "Vijay Devarapalli" <vijay at wichorus.com>,
"McCann Peter-A001034" <pete.mccann at motorola.com>
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 Vijay,
> 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 likeuld 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.
>
> 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.
>
> >>
> >> 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.
[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:)
>
> >> 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.
[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.
> > 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". :)
[Ahmad]
Sorry! did not mean to under estimate the hard work that was put in this
draft.
>
> 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
> >> 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 me 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.
>
> 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.
>
> >>
> >> 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.
[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:)
>
> >> 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.
[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.
> > 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". :)
[Ahmad]
Sorry! did not meachanisms 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
> >>>> signalin to under estimate the hard work that was put in this
draft.
>
> 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
> >> 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 mechanismsng.
> >>>> 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 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.
> >>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
> >>>> 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 >>>>>>>>> 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 Mmy 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
> >>>>>>>>>>obile 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.
> >>> 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>>>>>>>>>> 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/
>
--
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/
> >>>>>>>>>>>> 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/
>
--
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.
