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

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

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.

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.
> >
> >
> >>From mip4-bounces at ietf.org  Tue Jul 15 09:53:10 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 4087F3A6B14;
	Tue, 15 Jul 2008 09:53:10 -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 6679428C149
	for <mip4 at core3.amsl.com>; Tue, 15 Jul 2008 09:53:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.588
X-Spam-Level: 
X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, 
	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 MyuO1Yr0e8ol for <mip4 at core3.amsl.com>;
	Tue, 15 Jul 2008 09:53:08 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56])
	by core3.amsl.com (Postfix) with ESMTP id D1FB13A6AFD
	for <mip4 at ietf.org>; Tue, 15 Jul 2008 09:53:07 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com
	[47.103.123.71])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	m6FGrOF03124; Tue, 15 Jul 2008 16:53:24 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 15 Jul 2008 11:53:15 -0500
Message-ID: <C5A96676FCD00745B64AE42D5FCC9B6E19716CAC at zrc2hxm0.corp.nortel.com>
In-Reply-To: <Pine.GSO.4.63.0807150927340.22813 at irp-view13.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Mip4] WGLC: draft-ietf-mip4-generic-notification-message-04.txt
thread-index: AcjmmX1GykQQ/DWyRnuE1z1dTAhS+wAAEaUQ
References: <C5A96676FCD00745B64AE42D5FCC9B6E196C63AC at zrc2hxm0.corp.nortel.com>
	<Pine.GSO.4.63.0807150720490.29061 at irp-view13.cisco.com>
	<C5A96676FCD00745B64AE42D5FCC9B6E196C69A0 at zrc2hxm0.corp.nortel.com>
	<Pine.GSO.4.63.0807150927340.22813 at irp-view13.cisco.com>
From: "Ahmad Muhanna" <amuhanna at nortel.com>
To: "Sri Gundavelli" <sgundave at cisco.com>
Cc: Hui Deng <denghui02 at gmail.com>, Brian Haley <brian.haley at hp.com>,
	mip4 at ietf.org, Vijay Devarapalli <vijay at wichorus.com>,
	Henrik Levkowetz <henrik at levkowetz.com>
Subject: Re: [Mip4] 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 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.

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


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/