Subject: [netlmm] pmip6-ipv4-support-01

From: "Alper Yegin" <[email-masked]>
Date: Wed, 11 Jul 2007 12:26:02 +0300

And these are my questions and comments on pmip6-ipv4-support-01.

   As specified in the Proxy Mobile IPv6 specification [ID-PMIP6], this
   specification assumes that the link between the mobile access gateway
   and the local mobility anchor is a point-to-point link.

We don't really mean that, do we? Or, is this text referring to the tunnel
between the two as the point-to-point link?

      If a local mobility anchor
      is configured behind NAT, IPv4-LMAA is the IPv6 global address of
      the NAT box.

s/IPv6/IPv4

      The proxy binding
      update MUST be protected by IPsec ESP.

Why are we completely ruling out the use of MIP6 auth option?

Alper 

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

---

From: "Jong-Hyouk Lee" <[email-masked]>
Date: Wed, 11 Jul 2007 19:29:35 +0900

Dear Alper.

In the document, the proxy binding update messages between MAG and LMA are
assumed to be protected by IPsec ESP. It is a nature way to protect IP
traffic in IPv6 neworks. IPsec is provided in IPv6 networks as a common
security way. Also, IPsec ESP mode is enough to protect all type of IP
traffic, especially for wired networks (Almost case, MAG and LMA are
connected by wired networks).

So, do you have another way to protect IP traffic between MAG and LMA, not
IPsec mechanism? Actually, there might be. However, could you provide why we
should not use IPsec ESP for that?

P.S.: I like your way (using perl or regular expressions) :)

Cheers.

-- 
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 11 Jul 2007 13:55:49 +0300

Hello Jong-Hyouk Lee,

This is about protecting the PBU signaling, not the general IP data traffic.
And for the former, I was asking why not allowing use of  rfc4285

Alper

 

  _____  

From: Jong-Hyouk Lee [mailto:[email-masked]] 
Sent: Wednesday, July 11, 2007 1:30 PM
To: Alper Yegin
Cc: [email-masked]
Subject: Re: [netlmm] pmip6-ipv4-support-01

Dear Alper.

Cheers.

s/IPv6/IPv4

     The proxy binding 

Alper

---

From: "Jong-Hyouk Lee" <[email-masked]>
Date: Wed, 11 Jul 2007 20:42:25 +0900

Hello, Alper.

Well, I considered PBU signaling messages as IP traffic. Oops, did you
mention RFC 4285 in the previous thread? Ok, RFC 4285 is designed for a
secure binding process between a mobile node (MN) and a home agent (HA). The
document (RFC 4285) reduces the burden for establishing IPsec security
associations (SAs). Right? Key distributions in mobile environments is not
easy so that IKEv2 negotiation problems were fully discussed until the
opening this year as I know. So, using RFC 4285 in mobile environment is one
of good way.

However, we are now talking about the PBU signaling protection between MAG
and LMA. As I mentioned before, MAG and LMA are normally connected by wired
link. So, it is easy to make SAs. They (MAG and LMA) would be not mobile
nodes. With such assumptions, using IPsec is a natural way!

Cheers.

On 7/11/07, Alper Yegin <[email-masked]> wrote:
> This is about protecting the PBU signaling, not the general IP data
> traffic. And for the former, I was asking why not allowing use of  rfc4285
>
>
>
> Alper
>
>
>
>
>
>
>
>
>   ------------------------------
>
> *From:* Jong-Hyouk Lee [mailto:[email-masked]]
> *Sent:* Wednesday, July 11, 2007 1:30 PM
> *To:* Alper Yegin
> *Cc:* [email-masked]
> *Subject:* Re: [netlmm] pmip6-ipv4-support-01
>
>
>
> Dear Alper.
>
> On 7/11/07, *Alper Yegin* <[email-masked]> wrote:
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 16 Jul 2007 00:05:25 -0700

Hi Alper,

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Wednesday, July 11, 2007 2:26 AM
> To: [email-masked]
> Subject: [netlmm] pmip6-ipv4-support-01
> 

This is a typo. This is referring to the link between the MN and the
MAG. Ryuji/me will fix this. Some last minute text.

> Why are we completely ruling out the use of MIP6 auth option?

We should probably allow Auth Option as well. Will discuss this.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 16 Jul 2007 10:11:09 -0700

> Why are we completely ruling out the use of MIP6 auth option?

RFC 4285 obviously is not applicable to PMIPv6, since there is
no per-mobile security associations. One of the biggest reasons
for standardizing RFC 4285 was that IPsec was too heavy/cumbersome
for just protecting MIPv6 signaling messages. This does not apply
for PMIPv6.

The other main reason was the use of AAA infrastructure which RFC
3776 did not allow. But with the bootstrapping work that has been
done so far, you can use the AAA infrastructure with IKEv2 and
IPsec.

IMO, IPsec would be default mechanism between the MAG and the LMA.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 17 Jul 2007 00:05:10 +0300

> no per-mobile security associations. 

I don't quite understand how supporting per-MN SA "gets in the way".

> One of the biggest reasons

I presume you are referring to "over-the-air" segment of the signaling.

> IMO, IPsec would be default mechanism between the MAG and the LMA.

In what sense of "default"? The text from the spec says MUST be used. So, it
shuts the door to anything else. It means "one and only".

Alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 16 Jul 2007 16:54:39 -0700

> I don't quite understand how supporting per-MN SA "gets in the way".

RFC 4285 makes sense only when you have security associations
between each mobile node and the home agent. For PMIPv6, the
security associations are setup once between the MAG and the
LMA and used for all signaling messages. These are more like
long lived security associations between two entities in the
network.

> I presume you are referring to "over-the-air" segment of the signaling.

No. IPsec being heavy for the handsets, in terms of processing
requirements, was the main argument for RFC 4285. Relying on
IKEv1 in RFC 3776 didn't make it any easy.

> shuts the door to anything else. It means "one and only".

You are right. That is the only mechanism.

Vijay

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 17 Jul 2007 10:30:47 +0900

Hi Alper,

Thanks for comments.
I'll fix typos in next revision.

Why do you need RFC4285 for PMIP?
As Vijay pointed out, auth-option is not well fitted to PMIP.

regards
ryuji

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 17 Jul 2007 01:07:09 -0500

Hi Alper/Vijay,
Please allow me to say few words here, please see comments inline.

Regards,
Ahmad

> >> RFC 4285 obviously is not applicable to PMIPv6, since there is no 
> >> per-mobile security associations.
> > 
> between each mobile node and the home agent. 

[Ahmad]
By the same talking, RFC3775 talks/allows ONLY a per-MN IPsec SA. In
other words, PMIPv6 base protocol deviated from RFC3775 to allow what
you refer to as a per-Node IPsec long lived SA between the MAG and LMA.
I am just wondering, if any of the following options would be
acceptable?

1. Continue to use a per-MN SA as long as there is a reliable mechanism
to dynamically derive the per-MN SA? or
2. Allow a per-Node SA by deviating from RFC4285 using a new
authentication option similar to MIPv4 FA-HA AE?

[Ahmad-END]

> For PMIPv6, the 
> long lived security associations between two entities in the network.
> 
> >> for just protecting MIPv6 signaling messages. This does 
> not apply for 
> >> PMIPv6.
> > 
> No. IPsec being heavy for the handsets, in terms of 
> processing requirements, was the main argument for RFC 4285. 
> Relying on
> >> done so far, you can use the AAA infrastructure with IKEv2 
> and IPsec.
> >>
> > In what sense of "default"? The text from the spec says 
> MUST be used. 
> > So, it shuts the door to anything else. It means "one and only".
>

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 17 Jul 2007 12:11:30 +0300

> long lived security associations between two entities in the

My point is, can anyone claim "rfc 4285 does not work with PMIPv6"? I'm not
arguing about the better suitability, or historical motivations behind the
protocol.

> IKEv1 in RFC 3776 didn't make it any easy.

I understand. With "OtA segment" I meant to include the MN as well.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 17 Jul 2007 12:17:19 +0300

Hi Ryuji,

> Why do you need RFC4285 for PMIP?

I was questioning the need to exclude it.

WiMAX is using RFC 4285 as the mandatory-to-implement protocol. IKE/IPsec is
optional. Changing that, or having to also implement IKE/IPsec and use one
protocol for MIP6 and the other protocol for PMIP6 better have a good
reason.

> As Vijay pointed out, auth-option is not well fitted to PMIP.

Auth-option appears to be one larger size for PMIP (due to the unnecessary
per-MN SA support). I don't think that causes a fitting problem. 

Alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 17 Jul 2007 10:25:03 -0700

Alper Yegin wrote:
> My point is, can anyone claim "rfc 4285 does not work with PMIPv6"? 

4285 only defines MN-HA authentication option today. So you would
need to extend it before it can be used between the MAG and the LMA.
So one could say RFC 4285 would not work with PMIPv6.

I'm not
> arguing about the better suitability, or historical motivations behind the

Well, there has to be a reason for you wanting to use RFC 4285
between the MAG and the LMA. If you can explain that, we could
probably have a more meaningful discussion. IMO, IPsec makes more
sense between the MAG and the LMA.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 17 Jul 2007 10:26:48 -0700

> you refer to as a per-Node IPsec long lived SA between the MAG and LMA.

Of course, the security model for PMIPv6 is different from MIPv6.

> to dynamically derive the per-MN SA? or

Why would you want to do this?

> authentication option similar to MIPv4 FA-HA AE?

Yikes! Please don't.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 17 Jul 2007 12:34:45 -0500

> IMO, IPsec 
> makes more sense between the MAG and the LMA.

[Ahmad]
I tend to agree with your opinion here!

> not apply 
> >> So, it

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 17 Jul 2007 12:37:12 -0500

> > 1. Continue to use a per-MN SA as long as there is a reliable 
> > mechanism to dynamically derive the per-MN SA? or
> 

[Ahmad]
Just was wondering if hypothetically that would make it easier to adopt
RFC4285?

> > authentication option similar to MIPv4 FA-HA AE?

[Ahmad]
Ok, I do not:-)

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 22 Jul 2007 03:31:49 +0300

> So one could say RFC 4285 would not work with PMIPv6.

Are you just picking on the terminology here (like it is called "MAG" not 
"MN"), or something else? If former, RFC3776 has "MN" and "HA" written all
over it.

> sense between the MAG and the LMA.

Please see my response to Ryuji.

Alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 22 Jul 2007 12:10:06 -0700

> "MN"), or something else? If former, RFC3776 has "MN" and "HA" written all

We have defined in detail how IPsec is used between the MAG and the
LMA in draft-ietf-netlmm-proxymip6-01.txt. This includes defining
new SPD and PAD entries. See section 4. We didn't try to hack RFC
3776 or 4877 to make them work for PMIPv6.

For using RFC 4285, you would need to define a new sub-type to say
MAG-HA authentication option. Currently it only defines a MN-HA
authentication option. From RFC 4285

       Subtype:

          A number assigned to identify the entity and/or mechanism to be
          used to authenticate the message.

> Please see my response to Ryuji.

You said you wanted to use the same protocol for MIPv6 and PMIPv6.
But MIPv6 and PMIPv6 have different security models.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 23 Jul 2007 18:41:44 +0300

Vijay,

I think it is "overly constraining" to *mandate* **use** of any specific
security mechanism for PMIPv6. Why would you want to shut down any
alternatives, that may be available today or come along in the future? 

This is all about protocol modularity.

As for the security model compatibility, consider how PMIPv4 is secured
using MIPv4 extensions.

Alper

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Sunday, July 22, 2007 10:10 PM
> To: Alper Yegin
> Cc: [email-masked]