Subject: RE: [netlmm] Issue: Auth Option support

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 6 Sep 2007 13:07:08 -0700

I want some comments on this issue raised by Alper.

Also, if I interpret Sec 5.1 [3775], the IPSec is being
mandated, only the use of IPsec ESP is optional. 

--------
5.1.  Binding Updates to Home Agents

   The mobile node and the home agent MUST use an IPsec security
   association to protect the integrity and authenticity of the Binding
   Updates and Acknowledgements.  Both the mobile nodes and the home
   agents MUST support and SHOULD use the Encapsulating Security Payload
   (ESP) [6] header in transport mode and MUST use a non-NULL payload
   authentication algorithm to provide data origin authentication,
   connectionless integrity and optional anti-replay protection.  Note
   that Authentication Header (AH) [5] is also possible but for brevity
   not discussed in this specification.
-------

I'm confused, should the draft say 

"Both LMA and MAG MUST implement IPsec" and
"all the signaling messages SHOULD be protected using IPSec".

Will this ok, when reviewed by the security folks ?

or mandate IPsec for this specification and let other draft
relax this in the presence of an alternative approach ?

Please comment.

Sri

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Tuesday, August 07, 2007 1:41 AM
> To: 'Sri Gundavelli'; [email-masked]
> Subject: RE: [netlmm] Issue: Auth Option support
> 
> > The issue was related to the use of MUST clause in specifying
> > the IPSec requirement for Proxy Mobile IPv6 protocol. Alper
> > was suggesting that we relax that requirement and potentially
> > leave a room for Auth Option support in future.
> 
> Actually, I didn't mean it specifically for Auth Option. It 
> can be anything.
> Given that the security is handled by a separate protocol, 
> why lock it down
> to "IPsec", when some other protocol (Auth Option being one 
> example) cannot
> be used.
> 
> > But, as most people agreed and as supported by Jari, this can
> 
> My understanding was the opposite, especially about Jari's statement.
> 
> > always be changed in future when the support for new security
> > mechanisms such as Auth Option are defined for Proxy Mobile IPv6
> > and that specific document can always modify this requirement.
> > So, no changes will be made to the document on this issue.
> 
> What if Auth Option is good enough as written?
> What if a document in another SDO defines the alternative security
> mechanism?
> 
> For the type of interop we are seeking in IETF, "MUST 
> implement" is good
> enough. "MUST use" is not necessary.
> 
> Alper
> 
> 
> 
> 
> 
> > 
> > 
> > Regards
> > Sri
> > 
> > _______________________________________________
> > netlmm mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/netlmm

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2007 00:05:18 +0200

Sri, IMHO, I have several comments on the authopt original support, and 
I've already posted on the mip6 list, not much follow up yet.  authopt 
draft is currently incompletely specified (eg what happens to Binding 
Error authentication?).

Basically, I would like to not see authopt being a mandatory 
authentication mechanism for P-MIPv6.  At least not yet - it should 
evolve more.

I would personally say that IPsec support for LMA and MAG is understood 
ok for the moment and could be suggested as a default for the P-MIPv6 spec.

(I perfectly understand the deployments need and use AAA, and AAA is
  performant and should be integrated with MIP6 and P-MIP6 - but it's not
  yet clear how).

IMHO,

Alex

>> enough. "MUST use" is not necessary.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 7 Sep 2007 01:38:08 +0300

Hi Alex, Sri,

- The highlight of my suggestion is not to mandate auth option, but to
simply relax the current language that states "must use IPsec". 

- Auth option is an example of another security mechanism that we shall not
prevent from being used.

- "default" does not mean much. We shall speak in terms of "must/should/may
implement", and "must/should/may use."

- Leaving that to other specs, and the "must use IPsec" language in RFC 3775
despite RFC4285 do not make sense to me.

My recommendation is to state "should implement IPsec, may use IPsec" in the
PMIP6 spec.

Alper

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Friday, September 07, 2007 1:05 AM
> To: Sri Gundavelli
> Cc: 'Alper Yegin'; [email-masked]
> Subject: Re: [netlmm] Issue: Auth Option support
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2007 11:03:01 +0200

Alper Yegin wrote:
> Hi Alex, Sri,
> 
> - The highlight of my suggestion is not to mandate auth option, but
> to simply relax the current language that states "must use IPsec".
> 
> - Auth option is an example of another security mechanism that we
> shall not prevent from being used.

Auth option is now little appropriate for recommendation to
implementation of a MIP6 stack.  As I said already, authopt is silent
about other MIP6 messages than BU/BAck.  And one surely doesn't want
BU/BAck auth'ed with authopt and BErr with IPsec.

It will probably evolve more than its current state.

When would you like to discuss technically authopt document?  BEfore we
recommend it in PMIP or after?

> - "default" does not mean much. We shall speak in terms of
> "must/should/may implement", and "must/should/may use."

I agree, it's more understandable.

> - Leaving that to other specs, and the "must use IPsec" language in
> RFC 3775 despite RFC4285 do not make sense to me.

Sorry, it does make a lot of sense to me.  3775 is stds track.  Authopt
is informational.  The new authopt-bis draft is apparently intended as
informational as well, correct me if I'm wrong.  It's normal for a stds
track document to recommend another stds track document and be silent
about the informationals.

> My recommendation is to state "should implement IPsec, may use IPsec"
> in the PMIP6 spec.

Should and should is ok with me by now (not should and may).

Alex

---

From: Julien Laganier <[email-masked]>
Date: Fri, 7 Sep 2007 14:29:19 +0200

Hi Sri,

> relax this in the presence of an alternative approach ?

Somehow, "MUST implement" and "SHOULD use" together seems a bit 
tautologic. 

To me "SHOULD use" is sufficient since it covers both of the two 
possibles cases:

- deployment follows the SHOULD recommendation, it uses IPsec to protect 
PMIPv6, in which case it supports it, since it's using it :), or

- deployment ignores the SHOULD recommendation, does not uses IPSec, in 
which case it is useless to implement it since it's not used...

I'd prefer having "MUST protect integrity of signalling messages, and 
SHOULD use IPsec ESP to protect integrity of those messages". We might 
also add "MAY use IPsec AH".

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2007 14:52:36 +0200

> also add "MAY use IPsec AH".

I'm not sure what you mean...

Do you mean to use ESP to offer authentication (integrity protection)? 
I'd suggest to make AH a should, for this purpose, not ESP.

Or do you mean to use ESP to offer confidentiality (encrypted packets)? 
  In this case, ESP is the only possibility to do confindentiality, 
because authopt doesn't; so not sure why needing to debate the use of 
ESP for confidentiality, it is pretty clear.

Also, when you say to protect integrity of signalling messages, which of 
those do you assume?  authopt only does bu/back, it doesn't do other 
mip6 signalling.  So I think you only assume integrity of bu/back, right?

Alex

---

From: Julien Laganier <[email-masked]>
Date: Fri, 7 Sep 2007 15:15:51 +0200

On Friday 07 September 2007, Alexandru Petrescu wrote:
> > - deployment follows the SHOULD recommendation, it uses IPsec to
> > protect PMIPv6, in which case it supports it, since it's using it
> > :), or
> >
> > - deployment ignores the SHOULD recommendation, does not uses
> > IPSec, in which case it is useless to implement it since it's not
> > used...
> >
> > I'd prefer having "MUST protect integrity of signalling messages,
> > and SHOULD use IPsec ESP to protect integrity of those messages".
> > We might also add "MAY use IPsec AH".
>
> Do you mean to use ESP to offer authentication (integrity
> protection)? I'd suggest to make AH a should, for this purpose, not
> ESP.

For an IPsec implementation ESP is MUST and AH is a MAY, therefore I 
meant exactly what I said: ESP for integrity protection. For the 
reference, this is an excerpt from Section 3.2 of RFC4301:

                        IPsec implementations MUST support ESP and MAY
   support AH. (Support for AH has been downgraded to MAY because
   experience has shown that there are very few contexts in which ESP
   cannot provide the requisite security services.  Note that ESP can be
   used to provide only integrity, without confidentiality, making it
   comparable to AH in most contexts.)

> Or do you mean to use ESP to offer confidentiality (encrypted

No I don't mean that. I don't see confidentiality protection as a 
requirement for PMIPv6 security.

> In this case, ESP is the only possibility to do 
> confindentiality, because authopt doesn't; so not sure why needing to
> debate the use of ESP for confidentiality, it is pretty clear.
>
> Also, when you say to protect integrity of signalling messages, which
> of those do you assume?  authopt only does bu/back, it doesn't do
> other mip6 signalling.  So I think you only assume integrity of
> bu/back, right?

I mean protection of PMIPv6 messages, i.e. defined/used by the PMIPv6 
specification. Seems that's limited to pBU/pBAck, right?

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Sep 2007 15:28:43 +0200

>    comparable to AH in most contexts.)

Ok, I was not aware of that paragraph.

I was thinking AH protection was enough but it seems it is not 
necessary, and that ESP is necessary.

> requirement for PMIPv6 security.

Err...

> specification. Seems that's limited to pBU/pBAck, right?

Right... that's what the PMIPv6 spec says.  It is strange we struggle 
with timestamp/seqno issues whose main goal is to make it more reliable 
and at the same time we ignore Binding Error, Binding Refresh Request.

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 7 Sep 2007 10:10:12 -0700

Hi Julien,

> From: julien laganier [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: Friday, September 07, 2007 5:29 AM
> To: [email-masked]
> Cc: Sri Gundavelli; 'Alper Yegin'
> IPSec, in 

I agree. I'm not against allowing other approaches. I'm only concerned,
if we can leave the draft saying, "MUST protect integrity of signalling
messages", with out specifying IPsec or some other approach. If that
will pass the security review. We may have to state that IPsec MUST be
used or some other approach, say Auth-Option MUST be used. Not sure, if
we can leave this blank.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 7 Sep 2007 12:26:54 -0700

All,
On this topic, I believe we must have a mandatory to implement mechanism
specified for standards track publication.  We can leave the use at
"RECOMMENDED" or "SHOULD", but, we need a "MUST" on what the LMA and MAG
need to implement.  

I had run this by the security directorate at the Chicago meeting and my
understanding is that as long as we have "MUST implement IPsec" and
"SHOULD use IPsec", it would be fine.  

In other words, the SHOULD vs. MUST that we want to place on using IPsec
can be discussed, but, the "MUST" on implementation is non-negotiable.  

This is inline with my understanding on what we need to state for a
complete specification.  Given that channel security of signaling
messages is mandatory, unless we have at least one common denominator
that the MAG and LMA implementors will implement, we cannot ensure
interoperability.  If they support multiple common mechanisms and chose
to use something other than IPsec, that's fine - hence, the "SHOULD" on
usage. 

Hope that helps. 

Thanks,
Vidya

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Friday, September 07, 2007 10:10 AM
> To: 'Julien Laganier'; [email-masked]
> Behalf Of 
> > Julien Laganier
> > > "Both LMA and MAG MUST implement IPsec" and "all the signaling 
> > > messages SHOULD be protected using IPSec".
> > >
> > > or mandate IPsec for this specification and let other draft relax 
> > > this in the presence of an alternative approach ?
> > >
> > > Please comment.
> > 
> > protect PMIPv6, in which case it supports it, since it's 
> using it :), 
> > or
> > 
> > - deployment ignores the SHOULD recommendation, does not 
> uses IPSec, 
> > in which case it is useless to implement it since it's not used...
> > 
> I agree. I'm not against allowing other approaches. I'm only 
> concerned, if we can leave the draft saying, "MUST protect 
> integrity of signalling messages", with out specifying IPsec 
> or some other approach. If that will pass the security 
> review. We may have to state that IPsec MUST be used or some 
> other approach, say Auth-Option MUST be used. Not sure, if we 
> can leave this blank.
> 
> Sri
> 
>

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 07 Sep 2007 16:11:33 -0500

Hi Sri,

I do believe we need to specify a default security mechanism for the MAG/LMA
signaling messages. And for this purpose, IPsec is a good choice.
So IMO it is required that we state "Proxy MIP6 signaling messages between
the MAG and LMA MUST be secured by the use of an IPsec SA between the two
entities".

I think this does not limit the ability to adopt alternative security
solutions in the future.

-Raj

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 7 Sep 2007 14:42:25 -0700

Raj,

This is my view as well. Now, this will conflict with
"MUST implement and SHOULD use of IPsec". To be consistent,
it has to be "MUST implement and MUST use". Then Alper wont
like this...

Sri

> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Friday, September 07, 2007 2:12 PM
> To: Sri Gundavelli; 'Julien Laganier'; [email-masked]

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 07 Sep 2007 16:55:41 -0500

To ensure there is interoperability between multiple implementations, there
needs to be a default security mechanism and that would be IPsec. What
specific method is used in a certain deployment is not mandated by the spec.

So I think we can just leave it as a MUST for IPsec as the default security
solution without saying MUST use.

-Raj

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 7 Sep 2007 18:01:32 -0400

I agree. MUST implement is fine. MUST use is too much, IMO.

-Kuntal

> Sent: Friday, September 07, 2007 4:56 PM

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 09 Sep 2007 19:47:08 -0700

Sri,

I agree with "SHOULD" for using IPsec and "MUST" for supporting IPsec on 
the MAG and the LMA.

If thats the consensus, we need to modify a few sentences in the draft.

In section 4, replace

>    The signaling messages, Proxy Binding Update and Proxy Binding
>    Acknowledgement, exchanged between the mobile access gateway and the
>    local mobility anchor MUST be protected using IPsec [RFC-4301] and
>    using the established security association between them.  The
>    security association of the specific mobile node for which the
>    signaling message is initiated is not required for protecting these
>    messages.

with

    The signaling messages, Proxy Binding Update and Proxy Binding
    Acknowledgement, exchanged between the mobile access gateway and the
    local mobility anchor MUST be protected using security associations
    established between them. The security association of the specific
    mobile node for which the signaling message is initiated is not
    required for protecting these messages.

We need the MUST above since we have to say that the proxy BU and proxy 
BAck must be protected, irrespective of whether IPsec or some other 
mechanism is used.

Add one sentence that says

    The mobile access gateway and the local mobility anchor MUST
    implement IPsec for protecting the Proxy Mobile IPv6 signaling
    messages [RFC-4301].

The paragraph that comes after already uses "SHOULD" for using ESP.

>    IPsec ESP [RFC-4303] in transport mode with mandatory integrity
>    protection SHOULD be used for protecting the signaling messages.
>    Confidentiality protection of these messages is not required.

Hope that is sufficient.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 9 Sep 2007 20:13:29 -0700

Vijay/Raj,

I agree. Will make these changes.

Sri

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Sunday, September 09, 2007 7:47 PM
> To: Sri Gundavelli; 'Alper Yegin'
> Cc: [email-masked]

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 10 Sep 2007 11:19:49 +0300

For interop "SHOULD implement and use", or even "SHOULD use" (like Julien
explained) is fine. "SHOULD" means "you better know what you are doing if
you don't follow", and that's exactly the case. 

If both ends are using some other mechanism and they know what each other
supports, they should not have to worry about (and implement) the mechanism
in the base spec. This is what SHOULD is for.

Alper

> From: Narayanan, Vidya [mailto:[email-masked]]
> Sent: Friday, September 07, 2007 10:27 PM
> To: Sri Gundavelli; Julien Laganier; [email-masked]

---

From: Julien Laganier <[email-masked]>
Date: Mon, 10 Sep 2007 11:28:08 +0200

Hi Vijay,

One comment below,

On Monday 10 September 2007, Vijay Devarapalli wrote:
> Sri,
>
> I agree with "SHOULD" for using IPsec and "MUST" for supporting IPsec
> on the MAG and the LMA.
>
> >    Acknowledgement, exchanged between the mobile access gateway and
> > the local mobility anchor MUST be protected using IPsec [RFC-4301]
> > and using the established security association between them.  The
>     Acknowledgement, exchanged between the mobile access gateway and
> the local mobility anchor MUST be protected using security
> associations established between them. The security association of
> the specific mobile node for which the signaling message is initiated
> is not required for protecting these messages.
>
> We need the MUST above since we have to say that the proxy BU and
> proxy BAck must be protected, irrespective of whether IPsec or some
> other mechanism is used.

I understand you want to say that integrity and data origin 
authentication are MUST's. I'm thus suggesting a minor change to your 
text above (rest is fine with me):

      The Proxy Binding Update and Proxy Binding Acknowledgement
      signaling messages exchanged between the MAG and LMA MUST be
      protected using end-to-end security association(s) offering
      integrity and data origin authentication. A security association
      with the mobile node for which the signaling message is issued is
      not required for protection of these messages.

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 10 Sep 2007 07:56:31 -0500

Hope this is never too late.

My understanding is that for any implementation to claim compliancy to
any RFC, that implementation MUST implement all "MUST" and "SHOULD".
Having said that, I am not sure why we need this distinction of "MUST
implement IPsec" and "SHOULD use IPsec", that is exactly the meaning of
"SHOULD use IPsec".

Regards,
Ahmad

> Sent: Friday, September 07, 2007 2:27 PM
> On this topic, I believe we must have a mandatory to 
> implement mechanism specified for standards track 
> publication.  We can leave the use at "RECOMMENDED" or 
> "SHOULD", but, we need a "MUST" on what the LMA and MAG need 
> to implement.  
> 
> I had run this by the security directorate at the Chicago 
> meeting and my understanding is that as long as we have "MUST 
> implement IPsec" and "SHOULD use IPsec", it would be fine.  
> 
> In other words, the SHOULD vs. MUST that we want to place on 
> using IPsec can be discussed, but, the "MUST" on 
> implementation is non-negotiable.  
> 
> This is inline with my understanding on what we need to state 
> for a complete specification.  Given that channel security of 
> signaling messages is mandatory, unless we have at least one 
> common denominator that the MAG and LMA implementors will 
> implement, we cannot ensure interoperability.  If they 
> support multiple common mechanisms and chose to use something 
> other than IPsec, that's fine - hence, the "SHOULD" on usage. 
> 
> Hope that helps. 
> 
> Thanks,
> Vidya
> 
> integrity 
> > of signalling messages", with out specifying IPsec or some other 
> > approach. If that will pass the security review. We may 
> have to state 
> > that IPsec MUST be used or some other approach, say 
> Auth-Option MUST 
> > be used. Not sure, if we can leave this blank.
> > 
> > Sri
> > 
> >

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 10 Sep 2007 09:27:40 -0500

> I agree with "SHOULD" for using IPsec and "MUST" for 
> supporting IPsec on the MAG and the LMA.
> 
> We need the MUST above since we have to say that the proxy BU 
> and proxy BAck must be protected, irrespective of whether 
> IPsec or some other mechanism is used.

[Ahmad]
Hi Vijay,

As far as I remember, the whole security concept of using a per-Node SA
for PMIPv6 was based on the use of IPsec. Although, I see why you
proposed the text but I still see a problem here. For example, the above
text allows the use of an authentication option similar to FA-HA AE to
secure the P-BU/P-BA. 

Now, since allowing a per-Node SA to be used in PMIPv6 was based on the
use of IPsec, I believe we clearly need to keep that as part of the spec
text.

What about the following slight modification to what you just proposed:

    The signaling messages, Proxy Binding Update and Proxy Binding
    Acknowledgement, exchanged between the mobile access gateway and the
    local mobility anchor MUST be protected using a security association
    established between them. If IPsec is used, the security association

    of the specific mobile node for which the signaling message is
initiated 
    is not required for protecting these messages.

Thanks,
Ahmad

> relax this 
> > in the presence of an alternative approach ?
> > 
> > Please comment.
> > 
> > 
> > Sri
> > 
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> > 
> >>> The issue was related to the use of MUST clause in specifying the 
> >>> IPSec requirement for Proxy Mobile IPv6 protocol. Alper was 
> >>> suggesting that we relax that requirement and potentially leave a 
> >>> room for Auth Option support in future.
> >> Actually, I didn't mean it specifically for Auth Option. It can be 
> >> anything.
> why lock 
> >> it down to "IPsec", when some other protocol (Auth Option being one
> >> example) cannot
> >> be used.
> >>
> >>> mechanisms such as Auth Option are defined for Proxy 
> Mobile IPv6 and 
> >>> that specific document can always modify this requirement.
> implement" is 
> >> good enough. "MUST use" is not necessary.
> >>
> >> Alper
> >>
> >>
> >>
> >>
> >>
> >>>
> >>> Regards
> >>> Sri
> >>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 10 Sep 2007 08:00:42 -0700

>       not required for protection of these messages.

Sounds good to me.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 10 Sep 2007 08:02:59 -0700

Ahmad,

I don't believe the security model of using just one security 
association between the MAG and the LMA for protecting the proxy BU and 
Proxy BAck changes irrespective of whether IPsec or RFC 4285 is used. So 
  I don't agree with the suggested change.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 10 Sep 2007 08:17:10 -0700

Alper,

When we need to ensure interoperability, we use "MUST" and not "SHOULD".

Vijay

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Mon, 10 Sep 2007 19:44:28 +0200

Hi,

I am slowly catching up with NETLMM and I acknowledge that in some aspects (e.g. security model) I'm definitely late

I understand from this email that, in this group it has already been decided to go for a per-node security model
I followed the discussion about the security model in a PMIP solution in a given forum (Wimax) some years ago, and then it was considered that a per-node security model was was not sufficient
The main argument I remember is the threat of the MAG being compromised and indiscriminately allocating resources from the LMA
This is especially worrisome when the the MAG and the LMA belong to 2 different administrative domains
Has this problem been addressed in this group?

Thanks

federico

-----Message d'origine-----
De : Vijay Devarapalli [mailto:[email-masked]] 
Envoyé : lundi 10 septembre 2007 17:03
À : Ahmad Muhanna
Cc : [email-masked]
Objet : Re: [netlmm] Issue: Auth Option support

Ahmad,

I don't believe the security model of using just one security association between the MAG and the LMA for protecting the proxy BU and Proxy BAck changes irrespective of whether IPsec or RFC 4285 is used. So
  I don't agree with the suggested change.

Vijay

Ahmad Muhanna wrote:
>> the
> As far as I remember, the whole security concept of using a per-Node 
> SA for PMIPv6 was based on the use of IPsec. Although, I see why you 
> proposed the text but I still see a problem here. For example, the 
> above text allows the use of an authentication option similar to FA-HA 
> AE to secure the P-BU/P-BA.
> 
> Now, since allowing a per-Node SA to be used in PMIPv6 was based on 
> the use of IPsec, I believe we clearly need to keep that as part of 
> the spec text.
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 10 Sep 2007 13:08:12 -0500

Hi Federico,

The issue of using a per-Node SA has been discussed long time ago and reached consensus. This thread is not about the use of Per-Node vs. Per-MN SA. It is about relaxing the mandate of the use IPsec to "MUST implement" and SHOULD use"
That is it.

I Hope this address your concern.

Regards,
Ahmad

> From: DE JUAN HUARTE FEDERICO 
> [mailto:[email-masked]] 
> Sent: Monday, September 10, 2007 12:44 PM
> To: Vijay Devarapalli; Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]
> I am slowly catching up with NETLMM and I acknowledge that in 
> some aspects (e.g. security model) I'm definitely late
> 
> I understand from this email that, in this group it has 
> already been decided to go for a per-node security model I 
> followed the discussion about the security model in a PMIP 
> solution in a given forum (Wimax) some years ago, and then it 
> was considered that a per-node security model was was not 
> sufficient The main argument I remember is the threat of the 
> MAG being compromised and indiscriminately allocating 
> resources from the LMA This is especially worrisome when the 
> the MAG and the LMA belong to 2 different administrative 
> domains Has this problem been addressed in this group?
> 
> Thanks
> 
> federico
> 
> 
>  
> 
> association between the MAG and the LMA for protecting the 
> proxy BU and Proxy BAck changes irrespective of whether IPsec 
> or RFC 4285 is used. So

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 10 Sep 2007 22:32:46 +0300

Vijay,

Where did you get that idea ("SHOULD" is not useful for achieving
interoperability) from? Definitely not in RFC 2129.

	1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that
the
	   definition is an absolute requirement of the specification.

	3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
there
	   may exist valid reasons in particular circumstances to ignore a
	   particular item, but the full implications must be understood and
	   carefully weighed before choosing a different course.

Alper 

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Monday, September 10, 2007 6:17 PM
> To: Alper Yegin
> Cc: 'Narayanan, Vidya'; 'Sri Gundavelli'; 'Julien Laganier';
> [email-masked]

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 10 Sep 2007 22:54:43 +0300

I agree.

It is OK for the base spec to define one mechanism (IPsec) used with one
model (per-MAG-LMA SA). But we shall not limit all deployments to those
choices.

Alper

> Sent: Monday, September 10, 2007 6:03 PM
> To: Ahmad Muhanna
> Cc: Sri Gundavelli; Alper Yegin; [email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 10 Sep 2007 13:10:54 -0700

> interoperability) from? Definitely not in RFC 2129.

Why were you looking in 2129? :)

As I said earlier when you want to ensure interoperability, you 
typically use a "MUST". "SHOULD" means there is a probably that it is 
not implemented and you don't have an interoperable implementation.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 11 Sep 2007 11:23:42 +0300

> Why were you looking in 2129? :)

Nevertheless I was right that SHOULD is not defined the way you described in
"RFC2129" :-)

Kidding aside, you are right I had a typo. It should be RFC 2119. That's
where SHOULD is defined as I quoted.

Alper

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Tue, 11 Sep 2007 16:02:44 +0200

Hi Ahmad,

you're right that I was shamelessly abusing of the thread
I apologize for that: I've changed the subject this time

As I said, I understand that the security model has already been discussed and the decision has been to go with a per-node SA
I would appreciate if anybody could send me a pointer to any record capturing the discussion that led to this decision

More concretely, I would like to find out:
   - (first and most important) how the threat of a compromised MAG is addressed with the per-node SA model?
   - did the discussion take into account the fact that MAG and LMA may be located in different administrative domains?
   - did the discussion take place before or after the decision to move away from DT solution to PMIP?

Thanks

federico

-----Message d'origine-----
De : Ahmad Muhanna [mailto:[email-masked]] 
Envoyé : lundi 10 septembre 2007 20:08
À : DE JUAN HUARTE FEDERICO; Vijay Devarapalli
Cc : [email-masked]
Objet : RE: [netlmm] Issue: Auth Option support

Hi Federico,

Regards,
Ahmad

> I am slowly catching up with NETLMM and I acknowledge that in some 
> aspects (e.g. security model) I'm definitely late
> 
> I understand from this email that, in this group it has already been 
> decided to go for a per-node security model I followed the discussion 
> about the security model in a PMIP solution in a given forum (Wimax) 
> some years ago, and then it was considered that a per-node security 
> model was was not sufficient The main argument I remember is the 
> threat of the MAG being compromised and indiscriminately allocating 
> resources from the LMA This is especially worrisome when the the MAG 
> and the LMA belong to 2 different administrative domains Has this 
> problem been addressed in this group?
> 
> Thanks
> 
> federico
> 
> 
>  
> 
> Envoyé : lundi 10 septembre 2007 17:03 À : Ahmad Muhanna Cc : 
> [email-masked] Objet : Re: [netlmm] Issue: Auth Option support
> 
> Ahmad,
> 
> association between the MAG and the LMA for protecting the proxy BU 
> and Proxy BAck changes irrespective of whether IPsec or RFC 4285 is 
> used. So

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 11 Sep 2007 07:16:45 -0700

Hi Federico,

I dont want to reopen this thread or enter any discussions. But, let me
quickly make these points.

1. The security model, Configuring a MAG with all the MN's SA's does not
   offer any greater security than the other security model. Even in the
   Per-Node security model, there could be multiple SA's between the LMA
   and MAG, and different SA's can be used for different flows.

2. If a MAG is compromised, so are all the MN SA's. The damage is the
   same. If we argue that the MAG will not be allowed to create a BCE
   for a MN, that it does not have SA for, the same authorization can
   be achieved in the other model, by requiring the LMA to authorize the
   MAG before it creates BCE for a given MN.

There is no advantage using Per-MN security model. Its just a false sense
of security, IMHO.

With respect to your other question about when the discussions took place,
when the base draft was chosen, there were proposals that pitched other
security models and they were presented in the WG. The WG chose a specific
proposal that supported Per-Node security model.

Sri

> Sent: Tuesday, September 11, 2007 7:03 AM
> To: Ahmad Muhanna
> Cc: [email-masked]
> Subject: [netlmm] Question on security model
> 
> Hi Ahmad,
> 
> As I said, I understand that the security model has already 
> been discussed and the decision has been to go with a per-node SA
> I would appreciate if anybody could send me a pointer to any 
> record capturing the discussion that led to this decision
> 
>    - (first and most important) how the threat of a 
> compromised MAG is addressed with the per-node SA model?
>    - did the discussion take into account the fact that MAG 
> and LMA may be located in different administrative domains?
>    - did the discussion take place before or after the 
> decision to move away from DT solution to PMIP?
> 
> Thanks
> 
> federico
> 
> The issue of using a per-Node SA has been discussed long time 
> ago and reached consensus. This thread is not about the use 
> of Per-Node vs. Per-MN SA. It is about relaxing the mandate 
> of the use IPsec to "MUST implement" and SHOULD use"
> That is it.
> 
> already been

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 11 Sep 2007 09:27:34 -0500

Hi Federico,
No problem.

I agree with Sri on this point too, I do not support Re-opening this topic again.

However, I would like to emphasize one point that Sri mentioned in his reply, if compromised MAG is a real threat, then LMA may optionally choose to authorize the MN PMIP service at initial attach. I guess that takes care of the threat you have in mind.

Regards,
Ahmad

> Sent: Tuesday, September 11, 2007 9:03 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]
> Subject: Question on security model
> 
> Hi Ahmad,
> 
> you're right that I was shamelessly abusing of the thread I 
> apologize for that: I've changed the subject this time
> 
> been discussed and the decision has been to go with a 
> per-node SA I would appreciate if anybody could send me a 
> pointer to any record capturing the discussion that led to 
> this decision
> 
> De : Ahmad Muhanna [mailto:[email-masked]] Envoyé : 
> lundi 10 septembre 2007 20:08 À : DE JUAN HUARTE FEDERICO; 
> Vijay Devarapalli Cc : [email-masked] Objet : RE: [netlmm] 
> Issue: Auth Option support
> 
> Hi Federico,
>

---

From: Julien Laganier <[email-masked]>
Date: Tue, 11 Sep 2007 16:48:19 +0200

On Tuesday 11 September 2007, Sri Gundavelli wrote:
> Hi Federico,
>
> I dont want to reopen this thread or enter any discussions. But, let
> me quickly make these points.
>
>
> 1. The security model, Configuring a MAG with all the MN's SA's does
> not offer any greater security than the other security model. Even in
> the Per-Node security model, there could be multiple SA's between the
> LMA and MAG, and different SA's can be used for different flows.
>
>    be achieved in the other model, by requiring the LMA to authorize
> the MAG before it creates BCE for a given MN.
>
> There is no advantage using Per-MN security model. Its just a false
> sense of security, IMHO.

Trying to be more precise here.

The "Per-MN security model" reffered to is actually one in which the a 
LMA and a given MAG have a different security association for each MN 
attached to that MAG. 

I think it is more precise to denote this model as "Per-MN LMA-MAG 
Security Association" model.

In this model, even though there's one security association per MN, the 
security association is still established between the _MAG_ and LMA. 
Thus, if the _MAG_ is compromised, the per-MN LMA-MAG SA cannot prevent 
the MAG to issue undue signalling on behalf of a MN attached to it 
since it has the corresponding per-MN LMA-MAG security association. On 
the other hand, it would prevent a compromised MAG to issue undue 
signalling on behalf of a MN which is not attached to it _if_ it has no 
per-MN LMA-MAG SA for that MN.

The draft currently specifies a "Per-MAG LMA-MAG Security Association" 
model with no mechanisms in place to prevent a compromized MAG to issue 
undue signalling for any MN (both attached and not attached to it). The 
draft does however call in it security considerations section for such 
a mechanism to be present, but as part of another, unspecified, 
protocol:

   To eliminate the threats related to a compromised mobile access
   gateway, this specification recommends that the local mobility anchor
   before accepting a Proxy Binding Update message for a given mobile
   node, should ensure the mobile node is definitively attached to the
   mobile access gateway that sent the binding registration request.

Thus, the "Per-MN LMA-MAG Security Association" model can be more secure 
than the "per-MAG LMA-MAG Security Association" against MAG 
compromission only if is guaranteed that establishment of the "Per-MN 
LMA-MAG Security Association" cannot happen with a MAG to which the MN 
is not attached. That might be ensured by tying this SA establishment 
to network access control, but this would be, as for the "Per-MAG 
LMA-MAG Security Association", a mechanism implemented as part of 
another, unspecified, protocol.

In conclusion, without another mechanism realizing what's being called 
for in the security considerations, both security models are IMHO 
equivalent.

--julien

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 12 Sep 2007 00:01:56 +0300

There are two types of components to security space for PMIP (so far)...

Security mechanism: IPsec, Auth Option, etc...
Security association: MAG-LMA, per-MN MAG-LMA

All combinations are possible between the two components.

While recommending support for one combination (IPsec with MAG-LMA SA) is
necessary for interop, we shall not prevent use of other combinations in the
base spec.  

I'm fine with the current recommendation, as long as we weed out text that
unnecessarily or accidentally bars other combinations. This is better than
having to enter a beauty contest and try to pick a winner.

Alper 

> From: Julien Laganier [mailto:[email-masked]]
> Sent: Tuesday, September 11, 2007 5:48 PM
> To: [email-masked]
> Cc: 'DE JUAN HUARTE FEDERICO'
> Subject: Re: [netlmm] Question on security model
>