Subject: Re: [netlmm] possible ipv4-support edit

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Dec 2009 13:41:31 +0200

Pasi,

> The MH checksum calculation includes an IPv6 "pseudo-header". If we
> don't have any IPv6 header that could be used to construct the
> pseudo-header, it's probably simpler to use UDP checksum
> (alternatively, the draft could say how the MH checksum is computed in
> this situation, but that's probably more text).
OK (I do not think "more text" should be driving our decisions on 
protocol architecture. But I think defining MH transport over UDP as 
employing the UDP checksum is a reasonable solution.)

Jari

---

From: <[email-masked]>
Date: Tue, 1 Dec 2009 22:32:52 +0100

Quick answers to couple of the questions:

Jari Arkko wrote:
> I'm not clear on why the MH checksum needs to be set to zero and UDP
> checksum used instead.

> In Section 4.1.3.2, some text around DHCP has disappeared. I'm not sure
> it should disappear just because of this change. Was this an error?

That text was in the wrong place originally. Section 4.x is about IPv4
transport, while DHCP is about IPv4 home addresses (Section 3.x).

> Section 4.2.2.1 appears to downgrade the use of IPsec to protect the
> signaling messages from a MUST. I'm not sure that is appropriate. No
> matter what form of IPsec encapsulation we choose, that needs to be
> at least mandatory to implement.

At least my intent was not to change anything here (even in RFC 5213,
IPsec is not "MUST use", only "MUST implement").

Best regards,
Pasi

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 3 Dec 2009 13:14:06 -0600

Hi, Jari and All,
I guess a lot of effort went into these changes! 
Please see the below some minor comments.

Comment No. 1:
==============

   o  The Binding Update flag 'F' and the NAT Detection Option defined
      in Sections 3.1.3 and 3.2.2 of [RFC5555] are used by this
      specification in Proxy Binding Update and Proxy Binding
      Acknowledgement messages.  Their sole purpose is to allow forcing
      of UDP encapsulation between a mobile access gateway and a local
      mobility anchor in situations discussed in Sections 4.1 and 4.4.1
      of [RFC5555].

I think the last sentence needs minor tweaking to read as follows:
........ In situations similar to those discussed in sections 4.1 and
4.4.1 of [RFC5555].

Comment No. 2:
==============

If the whole idea is to remove NAT bullet below, why NOT just delete the
whole bullet. I do not see why we need to capture the new text. Also,
this whole section talks about how the IPv4 support as documented in
RFC5555 is being used in this document. All of a sudden we are also
talking about RFC3775 too. I believe there is nothing new in this text.

OLD TEXT:
=========
   o  The NAT traversal logic specified in [RFC-5555] for detecting the
      on-path NAT devices is valid for this specification as well.

NEW TEXT:
=========
   o  In normal Mobile IPv6 [RFC3775] and Dual-Stack Mobile IPv6
      [RFC5555], IPsec security associations (SAs) are specific to a
      single MN; they use the identifier visible to upper-layer
      protocols (HoA/IPv4-HoA) as traffic selector; and the IKE/IPsec
      SAs need to be updated when the MN moves.

      In Proxy Mobile IPv6 (both [RFC5213] and this document), the IPsec
      SAs are specific to MAG (and used for potentially large number of
      MNs); they use the locators used for routing (Proxy-CoA/
      IPv4-Proxy-CoA) as traffic selector; and they are not updated when
      the MN moves.

      This means the IPsec processing for Mobile IPv6 and Proxy Mobile
      IPv6 (whether IPv6 only or dual-stack) is very different.

Comment No. 3:
==============
Why it is necessary of the destination port for the PBA to be a reserved
port?
Does that mean the MAG MUST use this as the source port for PBU? If yes,
is there a reason for that restriction?
Similarly the same can be said about the data packet.

   o  Figure 11 shows the format of the Proxy Binding Acknowledgement
      message sent over IPv4 and protected using ESP.

     IPv4 header (src=IPv4-LMAA, dst=pbu_src_address)
       ESP header (in transport mode)
         UDP header (sport=TBD1, dport=TBD1)
           Mobility Header (PBA)

Comment No. 4:
==============
I assume the first bullet under 4.2.2.1 meant to say .. Mobility Header
containing the PBU.
Also, the last bullet should say ... the Proxy Binding Update .... 

Comment No. 5:
==============
Under section 4.2.2.2 should not the source IP address be the MN-HoA and
the destination is the CN?
Also, the figure caption says the packet is tunneled from the LMA to the
MAG, although the text before it talks about traffic from MAG to LMA.

Also, the following (-rev17 text) should not be a bullet.
o  Forwarding Packets received from the bi-directional tunnel:

Regards,
Ahmad

Ericsson

"The author works for Telefonaktiebolaget L M Ericsson ("Ericsson"), who
is solely responsible for this email and its contents. All inquiries
regarding this email should be addressed to Ericsson. Nortel has
provided the use of the nortel.com domain to Ericsson in connection with
this email solely for the purpose of connectivity and Nortel Networks
has no liability for the email or its contents. The web site for
Ericsson is www.ericsson.com."

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Friday, November 27, 2009 8:24 AM
> To: [email-masked]
> Cc: [email-masked]; Pasi Eronen
> Subject: [netlmm] possible ipv4-support edit
> 
> Hi,
> 
> This document has been revised a couple of times to address 
> IESG review comments. For the last few weeks its been sitting 
> idle because we were trying to argue what to do with one 
> review comment. Pasi's comment was that the way that it uses 
> RFC 5555 and IPsec complicates the implementation 
> considerably from what it was in RFC 5213. For instance, in 
> base PMIP you were able to use a standalone IPsec 
> implementation or even a separate security gateway to secure 
> your PMIP traffic. This is not possible in draft -17 of the 
> ipv4-support, because it requires an integrated 
> implementation of the mobility and IPsec parts.
> 
> We have been unable to decide what the right thing is between 
> the authors, chairs and ADs. We talked about this in 
> Hiroshima in a small group, and decided that it is time to 
> take this issue to the working group. I asked Pasi, Jonne, 
> and Jouni to provide a suggestion on what the changed design 
> is. That suggestion is available here:
> 
> http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-
> support-18a-pasi-jikv3-from-7.diff.html
> http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-
> support-18a-pasi-jikv3.txt
> 
> Without a concrete proposal it has been hard to determine 
> whether a change is necessary and what the impacts may be. 
> Now we have a concrete proposal. Is Pasi's issue serious 
> enough that a change is warranted? Is the changed 
> specification simpler and easier to implement? Are the 
> changes sufficient, or would something else have to be 
> changed as well? 
> Does the change break something? Does the resulting protocol 
> design have the right architecture?
> 
> I would like the WG to weigh in on whether we should (a) move 
> forward with draft -17 as it is or (b) adopt this change. To 
> be clear, Pasi has cleared his Discuss on the document, so we 
> are free to choose whatever alternative appears best. Please 
> respond by next week's Sunday (Dec 6th) by the latest. My 
> plan is that the document is in the RFC Editor queue before 
> the end of the year, no matter what the outcome of this 
> discussion is. I do not plan to issue a new IETF last call 
> due to the changes, but of course we are now reviewing the 
> issue in the working group.
> 
> Jari
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm
>

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 4 Dec 2009 18:10:06 -0800

My take on this:

When the WG originally decided to follow the Proxy Mobile IPv6 route vs. an alternative design, one of the key argument substantiating that decision was that an incremental extension to Mobile IPv6 was the way to go because it would allow re-use existing Mobile IPv6 extensions (and in particular the Dual Stack support for Mobile IPv6) rather than re-invention of the wheel for every required feature, and would allow for combined HA/LMA implementations.

The change now being proposed is rather drastic since it goes exactly against this design principle -- I am thus opposed to it. 

(I have also reviewed in detail the proposed changes and I disagree with some of the specifics. I however do not want to discuss those here for the sake of not diluting the high level point above.)
 
--julien

> Jari Arkko wrote:
> 
> Hi,
> 
> This document has been revised a couple of times to address IESG review
> comments. For the last few weeks its been sitting idle because we were
> trying to argue what to do with one review comment. Pasi's comment was
> that the way that it uses RFC 5555 and IPsec complicates the
> implementation considerably from what it was in RFC 5213. For instance,
> in base PMIP you were able to use a standalone IPsec implementation or
> even a separate security gateway to secure your PMIP traffic. This is
> not possible in draft -17 of the ipv4-support, because it requires an
> integrated implementation of the mobility and IPsec parts.
> 
> We have been unable to decide what the right thing is between the
> authors, chairs and ADs. We talked about this in Hiroshima in a small
> group, and decided that it is time to take this issue to the working
> group. I asked Pasi, Jonne, and Jouni to provide a suggestion on what
> the changed design is. That suggestion is available here:
> 
> http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-support-
> 18a-pasi-jikv3-from-7.diff.html
> http://www.arkko.com/ietf/netlmm/draft-ietf-netlmm-pmip6-ipv4-support-
> 18a-pasi-jikv3.txt
> 
> Without a concrete proposal it has been hard to determine whether a
> change is necessary and what the impacts may be. Now we have a concrete
> proposal. Is Pasi's issue serious enough that a change is warranted? Is
> the changed specification simpler and easier to implement? Are the
> changes sufficient, or would something else have to be changed as well?
> Does the change break something? Does the resulting protocol design
> have
> the right architecture?
> 
> I would like the WG to weigh in on whether we should (a) move forward
> with draft -17 as it is or (b) adopt this change. To be clear, Pasi has
> cleared his Discuss on the document, so we are free to choose whatever
> alternative appears best. Please respond by next week's Sunday (Dec
> 6th)
> by the latest. My plan is that the document is in the RFC Editor queue
> before the end of the year, no matter what the outcome of this
> discussion is. I do not plan to issue a new IETF last call due to the
> changes, but of course we are now reviewing the issue in the working
> group.
> 
> Jari
>

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Tue, 8 Dec 2009 13:13:33 -0600

Hi Jari,

I do not agree with the change to send the mobility header with the Proxy BU directly over IPv4. It is a major change to the protocol and is too late to make this kind of change (many folks are already implementing this).

Vijay

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jari Arkko
> Sent: Friday, November 27, 2009 6:24 AM
> To: [email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Dec 2009 13:46:44 +0200

Vijay,

> I do not agree with the change to send the mobility header with the Proxy BU directly over IPv4. It is a major change to the protocol and is too late to make this kind of change (many folks are alr…

Ok. But are those people implementing the security part as well? With 
the change, they wouldn't have to do anything particular...

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Dec 2009 15:43:18 +0200

Julien,

> The change now being proposed is rather drastic since it goes exactly against this design principle -- I am thus opposed to it. 

And remember those discussions. (In fact, earlier I was quite concerned 
that the specification already duplicated too much of DSMIP, even still 
being based on it.)

However, I don't think we can cast this as a re-use vs. re-invent 
question. To me, there's really two building blocks: we can choose to 
build this on the RFC 5213 security model or on RFC 5555. I think the 
former option is far simpler and more likely to lead to implementations 
actually doing this.

> (I have also reviewed in detail the proposed changes and I disagree with some of the specifics. I however do not want to discuss those here for the sake of not diluting the high level point above.)

OK

Jari

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 15 Dec 2009 11:24:25 -0800

Jari Arkko wrote:
> > When the WG originally decided to follow the Proxy Mobile IPv6 route
> > vs. an alternative design, one of the key argument substantiating that
> > decision was that an incremental extension to Mobile IPv6 was the way
> > to go because it would allow re-use existing Mobile IPv6 extensions
> > (and in particular the Dual Stack support for Mobile IPv6) rather than
> > re-invention of the wheel for every required feature, and would allow
> > for combined HA/LMA implementations.
> >
> > The change now being proposed is rather drastic since it goes exactly
> > against this design principle -- I am thus opposed to it.
> 

I actually find it difficult to circumvent the security model as a distinct building block in this situation because it depends intrinsically on how security policy is specified in terms of which packets to accept and which not, and this depends almost entirely on the ability of traffic selectors to operate with the chosen mobility signaling layering.

With MIPv6, mobility signaling is always layered on top of IPv6. As a result the IPsec policy operates on IPv6. Proxy MIPv6 has built on that model. 

The change proposed at this stage layers mobility signaling on top of UDP, which is inconsistent with design choices that were made for MIPv6. IMHO this is not acceptable for an extension to a MIPv6 extension.

--julien

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Dec 2009 09:54:00 +0200

Julien,

<chair hat off>

On 12/15/09 9:24 PM, "ext Laganier, Julien" <[email-masked]> wrote:

[snip]

> 
> I actually find it difficult to circumvent the security model as a distinct
> building block in this situation because it depends intrinsically on how
> security policy is specified in terms of which packets to accept and which
> not, and this depends almost entirely on the ability of traffic selectors to
> operate with the chosen mobility signaling layering.
> 
> With MIPv6, mobility signaling is always layered on top of IPv6. As a result
> the IPsec policy operates on IPv6. Proxy MIPv6 has built on that model.

While using IPv6 as transport this is certainly true. However, with IPv4 as
transport document the IPv6 header is practically just dead weight in the
packets. All the processing is done practically for the IPv4 header.

Though, you can perhaps argue that with IPv4 transport, PMIP6 is used as
IPv6 and just tunneled over IPv4, this is true only in spirit. In reality
the IPv6 header is practically just for show.

> 
> The change proposed at this stage layers mobility signaling on top of UDP,
> which is inconsistent with design choices that were made for MIPv6. IMHO this
> is not acceptable for an extension to a MIPv6 extension.

The thing here is that in PMIP6 there is no problem with the security. The
issue comes up just with the IPv4 support where the packet has to move back
and forth between stacks when IPSec is used. I firmly believe that if we
wouldn't fix this, most probably the IPSec would not be used in PMIP6
deployments.

I understand that people feel a bit uneasy if we would move away from the
model we have discussed so long. However, as there is no technical reason
why we shouldn't change the model, and as it would make PMIP6 IPv4 support
easier to implement, I'm at least personally willing to do this step.

I wonder if people are more just stuck to the idea of having PMIPv6 as is
with IPv4 transport, and not really thinking how the packets are really
actually processed.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Kowsalya Subramanian <[email-masked]>
Date: Thu, 17 Dec 2009 14:07:08 +0530

Jonne,

[snip]

> > 
> > I actually find it difficult to circumvent the security model as a 
> > distinct building block in this situation because it depends 
> > intrinsically on how security policy is specified in terms of which 
> > packets to accept and which not, and this depends almost entirely on 
> > the ability of traffic selectors to operate with the chosen mobility
signaling layering.
> > 
> > With MIPv6, mobility signaling is always layered on top of IPv6. As a 
> > result the IPsec policy operates on IPv6. Proxy MIPv6 has built on that
model.
>
> While using IPv6 as transport this is certainly true. However, with IPv4
as transport document the IPv6 header is 
> practically just dead weight in the packets. All the processing is done
practically for the IPv4 header.

Then why do we extend PMIP6 over IPv4, UDP, UDP-TLV etc. We can actually
extend PMIPv4 signaling to 
intimate MNs' IPv6 HomeNetworkPrefix. 

Is it because LMA is not generally co-located with HA ?

Thanks
Kowsalya
> 
> The change proposed at this stage layers mobility signaling on top of 
> UDP, which is inconsistent with design choices that were made for 
> MIPv6. IMHO this is not acceptable for an extension to a MIPv6 extension.
> 
issue comes up just with the IPv4 support 
> where the packet has to move back and forth between stacks when IPSec is
used. I firmly believe that if we wouldn't fix > this, most probably the
IPSec would not be used in PMIP6 deployments.

> I understand that people feel a bit uneasy if we would move away from the
model we have discussed so long. However, as 
> there is no technical reason why we shouldn't change the model, and as it
would make PMIP6 IPv4 support easier to 
> implement, I'm at least personally willing to do this step.

> I wonder if people are more just stuck to the idea of having PMIPv6 as is
with IPv4 transport, and not really thinking 
> how the packets are really actually processed.
>
> Cheers,
>
> Jonne.

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Dec 2009 16:18:38 +0200

Hi Kowsalya,

> Is it because LMA is not generally co-located with HA ?

There was a decision long, long time ago for not standardizing PMIPv4 for
various reasons, and the decision was to go with PMIP6. At that time it was
decided that PMIP6 will be added the IPv4 support, rather than specifying
PMIP4 as a stand alone protocol.

I hope this helps.

Cheers,

Jonne. 

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 17 Dec 2009 07:37:29 -0800

Folks:

Please comment on this issue and the change. We need to send this to RFC
editor queue before the end of the month.

Regards
Sri

On 12/17/09 6:18 AM, "Soininen, Jonne (NSN - FI/Espoo)"
<[email-masked]> wrote:

---

From: Kowsalya Subramanian <[email-masked]>
Date: Fri, 18 Dec 2009 06:53:46 +0530

Jonne,

[snip]

> > Then why do we extend PMIP6 over IPv4, UDP, UDP-TLV etc. We can 
> > actually extend PMIPv4 signaling to intimate MNs' IPv6 
> > HomeNetworkPrefix.
> > 

> There was a decision long, long time ago for not standardizing PMIPv4 for
various reasons, and the decision was to go 
> with PMIP6. At that time it was decided that PMIP6 will be added the IPv4
support, rather than specifying
> PMIP4 as a stand alone protocol.

Fine. But if that was the idea how did we initially start with IPV6 packet
format and tunnel it inside IPv4 etc..
When defining a mobility protocol which has to work for both ipv6 and ipv4
(i.e any type of L3 address), isn't it best 
to do it at the L4 level thereby making it network agnostic.

I am quite new to this area, so apologies if this sounds pretty silly

Thanks
Kowsalya

> used. I firmly believe that if we wouldn't fix > this, most probably 
> the IPSec would not be used in PMIP6 deployments.
> 

--
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: jouni korhonen <[email-masked]>
Date: Fri, 18 Dec 2009 15:22:07 +0200

Hi,

> With MIPv6, mobility signaling is always layered on top of IPv6. As a result the IPsec policy operates on IPv6. Proxy MIPv6 has built on that model. 

The nice property of RFC5213 way of integrating with IPsec was that one could properly separate it from the rest of PMIP6 functions. With the current IPv4 support you really cannot. The proposed edit would allow this again, and streamline the actual IPsec functionality in PMIP6 with and without IPv4 support. I myself find this appealing.

Jouni