Subject: [netlmm] Tim's DISCUSS and discussions thereof

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 7 Apr 2008 23:15:34 -0700

Attached. 

Subject: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6
From: "Tim Polk" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Wed, 26 Mar 2008 08:33:49 -0700

Discuss:
Section 4, Proxy Mobile IPv6 Security, provides some guidelines for the application of
IPsec, but lacks the specificity in several aspects to ensure interoperability. Specifically:

(1) Section 4 specifies that IKEv2 SHOULD be used to setup security associations between
the MAG and LMA, but to my reading IKEv2 is not mandatory to implement.
(2) Section 4 permits the MAG and LMA to use any of the authentication options
specified in IKEv2 for authentication, which is reinforced in section 4.1 which notes
that the peer authentication mechanisms in the PAD examples (shared secrets,
certificates, or EAP) are not exhaustive.  No authentication mechanism is mandatory
to implement.

Did the wg consider specifying IKEv2 as mandatory to implement?  What about 
specifying a mandatory to implement authentication mechanism?  If this was
considered and rejected, I would like to understand why mandatory to implement
mechanisms are not required/desirable.

Comment:
The security considerations provide a nice description of how the Proxy Mobile IPv6 protocol
defends itself against most of the threats listed in RFC 4382, but does not address threats
from the Internet (Section 4 of RFC 4382).  For completeness, please note how the Proxy Mobile
IPv6 protocol does (or does not) defend against these threats.

Subject: RE: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6
From: "Narayanan, Vidya" <[email-masked]>
To: "Tim Polk" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Wed, 26 Mar 2008 09:14:15 -0700

Tim,
Thanks for the review.  Please see some notes below.  

> -----Original Message-----
> From: Tim Polk [mailto:[email-masked]] 
> Sent: Wednesday, March 26, 2008 8:34 AM
> To: [email-masked]
> Cc: [email-masked]; 
> [email-masked]
> Subject: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6 
> 
> Discuss:
> Section 4, Proxy Mobile IPv6 Security, provides some 
> guidelines for the application of IPsec, but lacks the 
> specificity in several aspects to ensure interoperability. 
> Specifically:
> 
> (1) Section 4 specifies that IKEv2 SHOULD be used to setup 
> security associations between the MAG and LMA, but to my 
> reading IKEv2 is not mandatory to implement.

I don't believe that we are asking IKEv2 to be a mandatory to implement
thing for IPsec setup at the IETF yet (the last time we had this
discussion with Sam, we weren't; has that changed?).  That said, I do
agree that we need a mandatory to implement dynamic key management
mechanism.  Given that both the MAG and LMA are infrastructure entities
so to say, it is entirely possible that set up an SA based on some other
operator provided credentials from a backend server, such as AAA.   The
issue then obviously is that we don't have an IETF mechanism of
bootstrapping an IPsec SA from AAA or anything other than IKE/IKEv2 for
that matter.  

From an IETF perspective, it may be better to say that the MAG and LMA
MUST support and SHOULD use IKEv2 to set up the SAs.  Would that satisfy
your concern? 

> (2) Section 4 permits the MAG and LMA to use any of the 
> authentication options specified in IKEv2 for authentication, 
> which is reinforced in section 4.1 which notes that the peer 
> authentication mechanisms in the PAD examples (shared 
> secrets, certificates, or EAP) are not exhaustive.  No 
> authentication mechanism is mandatory to implement.
> 
> Did the wg consider specifying IKEv2 as mandatory to 
> implement?  What about specifying a mandatory to implement 
> authentication mechanism?  If this was considered and 
> rejected, I would like to understand why mandatory to 
> implement mechanisms are not required/desirable.
> 

This was not discussed in the WG.  I hate to admit, but, we did not
spend a significant amount of time debating the security aspects here.
The discussion was more about the fact that channel security is required
and that IPsec seems like the best fit for it.  Perhaps the authors can
comment what some implementations are doing from their knowledge (I
understand that there are implementations already) and we can go from
there. 

> Comment:
> The security considerations provide a nice description of how 
> the Proxy Mobile IPv6 protocol defends itself against most of 
> the threats listed in RFC 4382, but does not address threats 
> from the Internet (Section 4 of RFC 4382).  For completeness, 
> please note how the Proxy Mobile
> IPv6 protocol does (or does not) defend against these threats.

I think you meant RFC4832.  Section 4 primarily talks about DoS attack
feasibilities on entities using or providing NETLMM services, much in
the same way as any host or router using IP in the internet.  I don't
know if it really adds much value to say that - obviously, there is
nothing that can be done about that.  Perhaps one could argue that if
you used tunnel mode IPsec to an internal IP address between the MAG and
LMA, the external, globally routable IP address can be hidden from
eavesdroppers.  However, I really think that level of mitigation is
unnecessary and does not buy a whole lot, given that the MAG and LMA are
already infrastructure entities and an attacker must invest significant
resources already to obtain the globally routable addresses of those
entities.  

If you think it adds value, we can add a couple of sentences to reflect
the above in the security considerations section.  Please let us know
what you think. 

Thanks,
Vidya

Subject: Re: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6
From: "Vijay Devarapalli" <[email-masked]>
To: "Tim Polk" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 26 Mar 2008 11:38:12 -0700

Hi Tim,

Tim Polk wrote:
> Discuss:
> Section 4, Proxy Mobile IPv6 Security, provides some guidelines for the application of
> IPsec, but lacks the specificity in several aspects to ensure interoperability. Specifically:
> 
> (1) Section 4 specifies that IKEv2 SHOULD be used to setup security associations between
> the MAG and LMA, but to my reading IKEv2 is not mandatory to implement.

I don't think we should require the MAG and the LMA to implement IKEv2.
There could be any number of mechanisms available within a network
(both the MAG and the LMA are nodes inside the PMIPv6 domain), to setup
IPsec security associations between the MAG and the LMA.

> (2) Section 4 permits the MAG and LMA to use any of the authentication options
> specified in IKEv2 for authentication, which is reinforced in section 4.1 which notes
> that the peer authentication mechanisms in the PAD examples (shared secrets,
> certificates, or EAP) are not exhaustive.  No authentication mechanism is mandatory
> to implement.
> 
> Did the wg consider specifying IKEv2 as mandatory to implement?  What about 
> specifying a mandatory to implement authentication mechanism?  If this was
> considered and rejected, I would like to understand why mandatory to implement
> mechanisms are not required/desirable.

This was discussed among the authors, before the draft had become a
WG document. Again, my comment would be similar to the other comment
I made for the issue you raised about security between access routers
for 4068bis. The MAG and the LMA, being nodes inside a network, can
use any of the authentication mechanisms, shared secrets, PKI, etc..
to authenticate each other. Mandating shared secrets would mean
configuring the LMA with a number of shared secrets (one per MAG).
This is not convenient. We can't mandate PKI either.

We could add some text saying the MAGs and the LMA in a PMIPv6 domain
MUST be configured with the authentication mechanism they should be
using. Would this be sufficient?

Vijay

Subject: RE: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6
From: "Sri Gundavelli" <[email-masked]>
To: "Tim Polk" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Thu, 27 Mar 2008 21:06:48 -0700

Hi Tim,

Thanks for the review. Please see inline ..

Sri

> -----Original Message-----
> From: Tim Polk [mailto:[email-masked]] 
> Sent: Wednesday, March 26, 2008 8:34 AM
> To: [email-masked]
> Cc: [email-masked]; 
> [email-masked]
> Subject: DISCUSS and COMMENT: draft-ietf-netlmm-proxymip6 
> 
> Discuss:
> Section 4, Proxy Mobile IPv6 Security, provides some 
> guidelines for the application of
> IPsec, but lacks the specificity in several aspects to ensure 
> interoperability. Specifically:
> 
> (1) Section 4 specifies that IKEv2 SHOULD be used to setup 
> security associations between
> the MAG and LMA, but to my reading IKEv2 is not mandatory to 
> implement.

Yes. We require IPsec as mandatory to implement. For
key management we recommend the use of IKEv2, however we do
not mandate on implementation or on use.

> (2) Section 4 permits the MAG and LMA to use any of the 
> authentication options
> specified in IKEv2 for authentication, which is reinforced in 
> section 4.1 which notes
> that the peer authentication mechanisms in the PAD examples 
> (shared secrets,
> certificates, or EAP) are not exhaustive.  No authentication 
> mechanism is mandatory
> to implement.
> 
> Did the wg consider specifying IKEv2 as mandatory to 
> implement?  What about 
> specifying a mandatory to implement authentication mechanism? 
>  If this was
> considered and rejected, I would like to understand why 
> mandatory to implement
> mechanisms are not required/desirable.
> 

This protocol for network-based mobility is based on Mobile
IPv6 protocol and all signaling and security semantics are
based of that protocol. Mobile IPv6 does not mandate on the
use of IKEv1 or IKEv2 for key management and the same security
model is applied here.

Also, given the applicability scope of this protocol, we may
not be able to mandate the use or implementation of IKEv2. The
SDO architectures where this protocol will be applied will
generally have their own key management functions. However,
IKEv2 is recommended for key management.

> Comment:
> The security considerations provide a nice description of how 
> the Proxy Mobile IPv6 protocol
> defends itself against most of the threats listed in RFC 
> 4382, but does not address threats
> from the Internet (Section 4 of RFC 4382).  For completeness, 
> please note how the Proxy Mobile
> IPv6 protocol does (or does not) defend against these threats.
> 

We probably did not add text related to this threat, as it is
a very common threat and the impact is just the same for Proxy
Mobile IPv6 entities as in for a fixed network. Also, I think
I did have some text on this earlier and based on some review
feedback, I took it out as the threat is not really standing
out and the text in 4832 pretty much states that.

A DOS attack by flooding packets to a prefix assigned to a mobile
node, will result in the LMA and the serving MAG ending up
processing those packets, just as any on-path router processing
those packets. This protocol does not defend itself against such
attacks and this vulnerability is not unique to Proxy Mobile IPv6
protocol.

A DOS attack on the LMA or MAG is again a very common attack on
like any other network services and is not unique to Proxy Mobile
IPv6 protocol entities. This protocol does not defend itself
against such attacks.

Thanks for the review.

Regards
Sri

_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm