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

["Vijay Devarapalli" <vijay at wichorus.com>]

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/