Subject: [Mip6] issue 93 summary

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 7 Jun 2007 12:54:07 +1000

In light of the discussions that went on I thought it would be useful to
summarise the issue and discussions so far to give people who haven't kept
up an insight into what this is all about. 

First the issue text discussed the need for a "TLV" type encoding between
the outer IP header and the inner UDP header. The reason specified in the
issue was that the upper layer parsing the packet can't tell what
information follows UDP unless it is explicitly encoded. Upon further
discussion it was clear that this rationale is not true because the upper
layer can always parse the version field in the IP header following UDP. 

However, the following question was "what if the information following UDP
was not an IP header?". One could encode messages (at least in theory) that
follow UDP and that are not IP. But to save space and reading time, the main
(probably only) example for such information is the use of GRE
encapsulation. Some people don't see the need for the use of GRE and some
people do. I suggested that GRE can be used before UDP and not after, but
that was seen as unhelpful for cases where a NAT is present. 

Since I, after substantial effort, still couldn't find out what the
deployment scenario that needs this might be, I won't try to invent a
scenario for GRE on behalf of people who are calling for it and I'll leave
the floor open for that discussion. The point I wanted to highlight here
that practically this is the only reason left for adding TLV encoding. 

Finally, there are 3 options available for us to move forward and I'll use
the same numbers that Raj use to avoid confusing people:

1. Do nothing, keep the draft as is. 

2. Specify a different port number for the different format suggested.

3. Add the TLV encoding suggested in the issue. 

1) above implies that should there be agreement in future that the format
suggested in this issue is necessary, it can be achieved using option 2
(i.e. specify a new port that carries that format). This can be used if, for
example, GRE is needed for NETLMM. A MAG can use a different port from the
one used by the MN. The main reasons expressed by people for choosing 1
were:
 a) Adding 4 bytes on every packet is not needed. 
 b) GRE is not needed. 

2) above is pretty clear to everyone I think but Karen Nielsen raised some
questions that people should read. 

3) I believe 3 is also clear for everyone. Going to 3 will not require a
move to 2) later. Of course this comes at the cost mentioned above. I
believe the main reason expressed by people for this option was "future
proof". 

So, hopefully this gives a summary of the discussion so far. I think there
are basically two ways of finding concensus:
1. Discuss the rationale a lot more to make either side move. For instance,
discuss the deployment scenarios that require GRE, what is "future proof",
why the extra 4 bytes are an issue for those who chose 1) ...etc
2. Due to current threads more people might express their opionions. 

I'm not too hopeful with 2) above because most of the people that are
actively involved have commented. Plus it would actually be nice to see 1)
being achieved once in a while! So let's try to do that. 

Hesham

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 7 Jun 2007 00:30:13 -0500

Hi all,

If I understand Jari comments correctly, I think at one point, he
mentioned that we need to revisit/revaluate the existing text in the
draft. I looked into the draft but the only thing that I found w.r.t
option (1) is the following text:

LOCATION NO. 1:
===============
2.3.2.1 Visited network supports IPv4 only (private addresses)

   In this scenario the mobile node will need to tunnel IPv6 packets
   containing the binding update to the home agent's IPv4 address. In
   order to traverse the NAT device, IPv6 packets are tunneled UDP and
   IPv4. The UDP port used to send the IPv6 packet is TBD.

Basically there is no text included in the draft to explain how to
identify the type of payload that is encapsulated in UDP. In other words
and strictly speaking, if we take the draft most relevant text above,
this "TBD" reserved UDP port will always indicate that the payload is an
IPv6! 

LOCATION NO. 2:
===============

Under section 8. IANA considerations:
"
8. IANA considerations

   The specification requires the following allocations from IANA:
   - A UDP port is needed for the NAT traversal mechanism described in
     section 4.1.
"

Well, looking under section 4.1, I found the following sentence which
suggest that an IPv4 packet may be encapsulated in UDP in IPv4.
"
.........
   All tunneled IPv4 packets will contain the mobile node's IPv4 home
   address in the source address field of the inner IPv4 packet and the
   correspondent node's IPv4 address in the destination address field.
   The outer IPv4 header is the same whether the inner packet is IPv4 or
   IPv6.
.....
"

The least that I may say about the existing text, it is inadequate. IMO,
it needs serious update to identify the mechanism needed by the
receiving node to identify the type of packet that is encapsulated in
UDP then in IPv4.

Finally, I still favor option 3 considering that the 4 bytes can be
compressed to much less than 4 bytes reducing the overhead on the
wireless link.

Regards,
Ahmad

> -----Original Message-----
> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Wednesday, June 06, 2007 9:54 PM
> To: [email-masked]; [email-masked]
> Subject: [Mip6] issue 93 summary
> 
> 
> 
> In light of the discussions that went on I thought it would 
> be useful to summarise the issue and discussions so far to 
> give people who haven't kept up an insight into what this is 
> all about. 
> 
> First the issue text discussed the need for a "TLV" type 
> encoding between the outer IP header and the inner UDP 
> header. The reason specified in the issue was that the upper 
> layer parsing the packet can't tell what information follows 
> UDP unless it is explicitly encoded. Upon further discussion 
> it was clear that this rationale is not true because the 
> upper layer can always parse the version field in the IP 
> header following UDP. 
> 
> However, the following question was "what if the information 
> following UDP was not an IP header?". One could encode 
> messages (at least in theory) that follow UDP and that are 
> not IP. But to save space and reading time, the main 
> (probably only) example for such information is the use of 
> GRE encapsulation. Some people don't see the need for the use 
> of GRE and some people do. I suggested that GRE can be used 
> before UDP and not after, but that was seen as unhelpful for 
> cases where a NAT is present. 
> 
> Since I, after substantial effort, still couldn't find out 
> what the deployment scenario that needs this might be, I 
> won't try to invent a scenario for GRE on behalf of people 
> who are calling for it and I'll leave the floor open for that 
> discussion. The point I wanted to highlight here that 
> practically this is the only reason left for adding TLV encoding. 
> 
> Finally, there are 3 options available for us to move forward 
> and I'll use the same numbers that Raj use to avoid confusing people:
> 
> 1) above implies that should there be agreement in future 
> that the format suggested in this issue is necessary, it can 
> be achieved using option 2 (i.e. specify a new port that 
> carries that format). This can be used if, for example, GRE 
> is needed for NETLMM. A MAG can use a different port from the 
> 2) above is pretty clear to everyone I think but Karen 
> Nielsen raised some questions that people should read. 
> 
> 3) I believe 3 is also clear for everyone. Going to 3 will 
> not require a move to 2) later. Of course this comes at the 
> cost mentioned above. I believe the main reason expressed by 
> people for this option was "future proof". 
> 
> So, hopefully this gives a summary of the discussion so far. 
> I think there are basically two ways of finding concensus:
> 1. Discuss the rationale a lot more to make either side move. 
> For instance, discuss the deployment scenarios that require 
> GRE, what is "future proof", why the extra 4 bytes are an 
> issue for those who chose 1) ...etc 2. Due to current threads 
> more people might express their opionions. 
> 
> I'm not too hopeful with 2) above because most of the people 
> that are actively involved have commented. Plus it would 
> actually be nice to see 1) being achieved once in a while! So 
> let's try to do that. 
> 
> Hesham
> 
> 
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 7 Jun 2007 17:03:01 +1000

> option (1) is the following text:

=> No that's not true at all. There is an IP version field in the IP header
that tells you what the header is. The fact that the IP header fields (for
v4 or v6) are not revisited in this draft does not in any shape or form
suggest that we have no way of parsing header. I suggest that we get off the
header parsing argument because frankly, it's a waste of time. Everyone
knows (including people who want option 3) that you can do this with the
version field. Let's not debate facts here, it's pointless. 

Hesham

---

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Thu, 7 Jun 2007 10:10:38 +0200

Hi Hesham, All

For completeness it would be good to understand the implications
vis-a-vis IPSec in the three options.

I assume that we are speaking about UDP encapsulated ESP (3948) in
option 1 and option 2,
whether for payload and optionally also for BU/BACK.
But what is the intended approach with option 3 ?

Thanks,
Karen

> Sent: 7. juni 2007 04:54

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 7 Jun 2007 18:33:09 +1000

Hi Karen, 

Good question. I don't know actually. Transport ESP on the outer header is
obviously not a good idea. Transport ESP on the inner header is obviously
possible. It doesn't seem like UDP encapsulated ESP as per 3948 is possible.
Anyone else has a comment on this?  

Hesham

 > From: Karen E. Nielsen (AH/LMD) 
 > [mailto:[email-masked]] 
 > Sent: Thursday, June 07, 2007 6:11 PM
 > To: Hesham Soliman; [email-masked]; [email-masked]
 > Subject: RE: [Mip6] issue 93 summary
 > 
 > Hi Hesham, All
 >

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Jun 2007 11:48:45 +0200

> Anyone else has a comment on this?

YEs.

I don't think implementations of DS-MIPv6 do what rfc3948 says when 
encapsulating IPv6 in UDPv4 with ESP.  The rfc3948 operations are mainly 
about re-computing checksums in UDP header.  Doesn't mean it should be 
ignored.

I think the differences between RFC3948 (UDP-ESP) and DS-MIPv6 use of 
ESP lie in the style of approach of using ESP.  It's not only the 
typical tunnel vs transport mode.

It is about which style of ESP?  IPv4-style or IPv6-style ESP?  The ESP 
as usually used by UDP in IPv4 (ESP is after the UDP header, RFC3948)? 
Or the ESP as used by the inner typical IPv6 packet 
(IPv6baseheader-ESPheader-MobilityHEader).

The exact placing of the ESP header (with respect to UDP and IPv6 
headers) obviously has an impact of the level of protection afforded.  I 
believe for maximum protection there may be two ESP headers.

I think what DS-MIPv6 assumes is this:

IPv4-header
UDP
IPv6-baseheader
ESP
IPv6-MobilityHeader

I think what RFC3948 suggests is this:

IPv4-header                        IPv4-header
UDP                         or     UDP
ESP                                ESP
IPv6-MobilityHeader                IPv6-baseheader
                                    IPv6-MobilityHeader

Two ESP headers - one IPv4 style and the other IPv6 style - would look 
like this:

IPv4-header
UDP
ESP
IPv6-baseheader
ESP
IPv6-MobilityHeader

But that has  two ESP headers and UDP is still exposed.  So better would be:

IPv4-header
ESP
IPv4-header
UDP
ESP
IPv6-header

But that doesn't traverse NATs  because UDP is not seen by NAT :-(  (I 
think this was already discussed recently).

Maybe a shorter-packet alternative is this:

IPv4-header
UDP
ESP
IPv6-MobilityHeader.

I think in practice the implementer will prefer to either use IPsec code 
from that s/he usually uses for IPv4 or for IPv6.  But packets surely 
look different.

Alex

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

---

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Thu, 7 Jun 2007 12:11:13 +0200

Hi,

> IPv6-MobilityHeader

But what about ESP tunnel payload protection (and optional way of BU
protection - read: Section 3 of 4877).
Here it could be appropriate to use UDP ESP 3948 to obtain

IPv4-header
UDP
ESP             
IPv6/4-header
Payload/BU

but, then the question for me is - is that also the intention in case of
option 3 - or
is a different way of ESP tunnel envisaged here.

Karen

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: 7. juni 2007 11:49
> To: Hesham Soliman
> Cc: Karen E. Nielsen (AH/LMD); [email-masked]; [email-masked]
> Subject: Re: [Mip6] issue 93 summary
> 
> Hesham Soliman wrote:
> > Hi Karen,
> > 
> > Good question. I don't know actually. Transport ESP on the outer 
> > header is obviously not a good idea. Transport ESP on the 
> inner header 
> > is obviously possible. It doesn't seem like UDP 
> encapsulated ESP as per 3948 is possible.
> I don't think implementations of DS-MIPv6 do what rfc3948 
> says when encapsulating IPv6 in UDPv4 with ESP.  The rfc3948 
> operations are mainly about re-computing checksums in UDP 
> header.  Doesn't mean it should be ignored.
> 
> I think the differences between RFC3948 (UDP-ESP) and 
> DS-MIPv6 use of ESP lie in the style of approach of using 
> ESP.  It's not only the typical tunnel vs transport mode.
> 
> It is about which style of ESP?  IPv4-style or IPv6-style 
> ESP?  The ESP as usually used by UDP in IPv4 (ESP is after 
> the UDP header, RFC3948)? 
> headers) obviously has an impact of the level of protection 
> afforded.  I believe for maximum protection there may be two 
> ESP headers.
> 
> Two ESP headers - one IPv4 style and the other IPv6 style - 
> would look like this:
> 
> IPv4-header
> UDP
> ESP
> IPv6-baseheader
> ESP
> IPv6-MobilityHeader
> 
> But that doesn't traverse NATs  because UDP is not seen by 
> NAT :-(  (I think this was already discussed recently).
> 
> I think in practice the implementer will prefer to either use 
> IPsec code from that s/he usually uses for IPv4 or for IPv6.  
> But packets surely look different.
> 
> Alex
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Jun 2007 12:26:29 +0200

Karen E. Nielsen (AH/LMD) wrote:
> protection - read: Section 3 of 4877). Here it could be appropriate
> to use UDP ESP 3948 to obtain
> 
> IPv4-header
> UDP
> ESP             
> IPv6/4-header
> Payload/BU

Looks meaningful to me (just don't call MobilityHeader 'payload' :-)

> but, then the question for me is - is that also the intention in case
> of option 3 - or is a different way of ESP tunnel envisaged here.

It's a question.  I show the Chair's call below.   I don't know what Raj 
means by a DS-MIP6 'tunnel type message'.

Is that an intermediary header between UDP and ESP (in the figure 
above)?  Is that intermediary header a MobileIPv4-header?  Is that the 
rfc3012 Generalized MIP Auth Extension replacing ESP?  Is that GRE?

I think your figure above looks good.

Alex

Raj originally posted 'issue 93 summary':
[...]
> Problem: UDP encapsulation is used in DS-MIP6 for NAT traversal. The
> encapculations are either:
>  - IPv6-in-UDP-over-IPv4
>  - IPv4-in-UDP-over-IPv4
> There is a need (or I guess desirable) to indicate the type of
> protocol being encapsulated in the UDP header.
> 
> Choices are:
> 1. Parse the protocol header following the UDP header
> 2. Reserve a UDP port for each protocol header (i.e one UDP port for
>    IPv6-in-UDP-over-IPv4 and another for IPv4-in-UDP-over-IPv4 etc.)
> 3. One reserved UDP port and a DS-MIP6 "tunnel type message"
> 4. Encapsulated protocol header type is indicated in the BU message
> 
> Pros and cons of these choices are in the slides that were presented
> at IETF68 (see URL above).
> 
> Please provide your opinions and comments by May 15th, 07 on the MIP6
> mailing list.
> 
> -Raj

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 7 Jun 2007 22:01:48 +1000

> I agree that DS-MIP model for BU ESP protection is: 

=> Perhaps the draft needs clarification because there is no reason why this
should be the only model.

 > Here it could be appropriate to use UDP ESP 3948 to obtain

=> Right, which we do support today.

 > is a different way of ESP tunnel envisaged here.

=> That's how I understood your original question, it's not a general
question, it's specific to the option 3 case. Unless I'm missing something I
don't think the latter format (3948) would work in this case due to the
additional TLV.

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Jun 2007 14:22:14 +0200

> don't think the latter format (3948) would work in this case due to the

I don't think either.

If the additional TLV is after ESP then we the existing ESP spec may not 
say how to calculate ESP fields across that TLV:

IPv4-header
UDP
ESP
TLV-tunneltypemessage
IPv6-baseheader
IPv6-MobilityHeader

If the additional TLV is before the ESP then it is obviously insecure:

IPv4-header
UDP
TLV-tunneltypemessage
ESP
IPv6-baseheader
IPv6-MobilityHeader

Alex

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 7 Jun 2007 07:59:23 -0700

This discussion is creating confusion. Obviously if we have
the TLV that comes after the UDP header, we are not really
using RFC 3948 (UDP encapsulation for ESP). It would still
work fine. The port number in UDP header would not point
to ESP. It would point this new TLV (MIP tunnel data message
header). The TLV's port/protocol field will then point to ESP. 

There is *no* problem in encryption or calculating the MAC
in the ESP header. It would work fine with the TLV header.
 
Vijay 

> Sent: Thursday, June 07, 2007 5:22 AM
> To: Hesham Soliman
> Cc: [email-masked]; [email-masked]

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 7 Jun 2007 10:03:03 -0500

Thanks Hesham. Understood!

However, the comment was not regarding a technical issue (in the sense
right vs. wrong) here, but about adequacy of the text. It may ,very
well, be straight forward in your mind, however, we are not writing a
standard for the editor to read and understand! Right?

On the other hand, since we are addressing adequacy of the draft text,
let me point out a couple of places that you may need to fix in order to
reduce the reader's confusion.

CASE No. 1:
===========
Under section: 2.3.2.1 Visited network supports IPv4 only (private
addresses)

"

Here, it is clear that the MN needs to use UDP whenever using a Private
IPv4 address, i.e. a NAT is assumed. However, I assume that the MN
probably does not know if it is using a private IPv4 address or to be
more accurate, if there is a NAT in path or not.

Reading further down under the same section when it talks about what the
HA does after receiving a BU with IPv4 HAO, it reads the following:

"
   After accepting the binding update, the home agent MUST create a new
   binding cache entry for the mobile node's IPv6 home address. If an
   IPv4 home address option were included, the home agent MUST create
   another entry for that address. All entries MUST point to the mobile
   node's IPv4 care-of address included in the source address of the
   IPv6 packet and represented as an IPv4-mapped IPv6 address. In
   addition, the tunnel used MUST indicate UDP encapsulation for NAT
   traversal. ....
"

Here it is assumed that there is a NAT and HA marked the tunnel with UDP
encapsulation for NAT traversal. Right?
There is a lot of assumptions can go in the mind of the reader why this
is true, however, the straight forward one is we are talking about
private IP addresses anyway. Ok, let us move on.

"
   .......... Hence, all packets addressed to the mobile node's home
   address(es) (IPv4 or IPv6) will be encapsulated in UDP then
   encapsulated in an IPv4 header that includes the home agent's IPv4
   address in the source address field and the mobile node's IPv4 care-
   of address in the destination address field.
"

Please tell me, which scenario we are talking about now?!
If we assume that we are talking about private IP addresses, then How in
the world, the HA will be able to send packet destined to the MN IPv4
care-of address, which is a private address.

OK here is one needs to be adequately clarified. [1]

CASE No. 2:
===========
Let us continue reading under the same section, the same comments above
applies on how the HA sends the BA as per the text below:

"
...
   ............... The binding acknowledgement is encapsulated in UDP
   then IPv4 with the home agent's IPv4 address in the source address
   field and the mobile node's IPv4 care-of address in the destination
   field. The inner IPv6 packet will contain the home agent's IPv6
   address as a source address and the mobile node's IPv4 care-of
   address in the destination address field. The latter is represented
   as an IPv4-mapped IPv6 address.
"

Are we still talking about private IPv4 addresses in this scenario? I
assume yes, because that is the title of the section and what the
previous text indicates. Then the same comment above applies here and an
adequate clarification is needed. [2]

Finally the section ends the discussion as below, which gives the
impression that this whole section assumes that NAT is always in path
but does not talk how the MN would know that to start with.

"
   The mobile node needs to maintain the NAT bindings for its current
   IPv4 care-of address. This is done through sending the binding update
   regularly to the home agent.
"

May be it is a good idea to up front highlight the assumption that this
section is based on to eliminate a lot of confusion, what is the
assumption behind the text of this section? Is it:
1. The IPv4 is a private IP address and there is a NAT on path all the
time, or
2. The IPv4 address is a private but not necessary there is a NAT, or
3. There is a NAT regardless of the type of IPv4 address allocated to
the MN.

Case No. 3:
=========
Under section 4.1. NAT detection and traversal, it reads:

"
   NAT detection is done when the initial binding update message is sent
   from the mobile node to the home agent. When located in an IPv4-only
   foreign link, the mobile node sends the binding update message
   encapsulated in UDP and IPv4. The source address of the IPv6 packet
   is the mobile node's IPv4 care-of address represented in IPv4-mapped
   IPv6 format. The destination address is the IPv6 address of the home
   agent. The IPv4 header contains the IPv4 care-of address in the
   source address field and the IPv4 address of the home agent in the
   destination address field.
"

This is a clear assumption that the MN uses UDP encapsulation (for
sending BU) any time when it is located in an IPv4 only foreign network.
Which I assume is the intent here. Let us move on and continue to read
under the same section.

Now, the below text MAY give an impression that UDP encapsulation is
done only when HA detects NAT in the path. Correct?

"
   ......... If the two addresses match, no NAT device was in the path.
   Otherwise, a NAT device was in the path and the NAT detection option
   is included in the binding acknowledgement. The binding
   acknowledgement, and all future packets, are then encapsulated in UDP
   and IPv4. The source address in the IPv4 header is the IPv4 address
   of the home agent. The destination address is the IPv4 address
   received in the IPv4 header encapsulating the binding update (this
   address will be different from the IPv4 care-of address when a NAT is
   in the path).
"

May be another place that clarification is needed. [3]
However, here, the dst. IP address is specified correctly:)

Reading the below text, I would suggest that an example for, at least,
data packets UDP encapsulation like the one for BU and BA is very useful
and probably needed. It makes things much cleaner. Instead of just have
an indirect reference as in the below paragraph. [3+.5=3.5]

"
   If no NAT device was detected in the path between the mobile node and
   the home agent then IPv6 packets are tunneled in an IPv4 header,
   unless the home agent forces UDP encapsulation using the F flag. The
   content of the inner and outer headers are identical to the **** UDP
   encapsulation case.*** 
"

CASE NO. 4:
===========
   A. Binding update received by the home agent:

              IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
                 UDP header
                   IPv6 header (src=V4CoA, dst=HAADDR)
                      DST-OPT
                          HAO (IPv6 home address)
                      Mobility header
                          BU [IPv4 HAO]

   Where V4ADDR is either the IPv4 care-of address or the address
   provided by the NAT device. V4COA is the IPv4 care-of address of the
   mobile node. HAO is the home address option and BU is the binding
   update, which MAY contain the IPv4 home address option.

I believe the definition of V4ADDR is very useful and SHOULD be global.
This can be used whenever the text addresses HA functionality where NAT
vs. NO NAT is not clearly identified. It eliminates confusion. [3.5 +
0.5=4]

CASE NO. 5:
===========
Under section: 4.3.1 Sending packets from a visited network.

"
   When the mobile node is located in an IPv4 only network, it will send
   IPv6 packets to its home agent according to the following format:

                IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
                 [UDP header]
                   IPv6 header (src=V6HoA, dst=CN)
                    Upper layer protocols

   Where the UDP header is only used if a NAT were detected between the
   mobile node and the home agent, or if the home agent forced UDP
   encapsulation.
"

Now, the use of the V4ADDR in this context is wrong. We are talking
about the MN sending an IPv6 packet in an IPv4 only network. MN will
always set the src addr of the outer header to MN's IPv4 Care-of
Address. Right?

The above format would be perfect if we are talking about the HA
receiving an IPv6 packet that the MN sent from an IPv4 only network.
Right?

The same comment applies to the following case:

"
  Similarly, IPv4 packets are sent according to the following format:

                IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
                 [UDP header]
                   IPv4 header (src=V4HoA, dst=V4CN)
                    Upper layer protocols
"

An adequate clarification is needed. [4+1=5]

SUGGESTION:
===========
Finally, probably this suggestion is a little too late in the game and
have been discussed earlier, but since the MN is roaming in an IPv4 only
foreign network, SHOULD not we make it optional to the MN to request
that only an IPv4 HoA to be allocated. This would save resources at the
HA.

Regards,
Ahmad

> Sent: Thursday, June 07, 2007 2:03 AM
> To: Muhanna, Ahmad (RICH1:2H10); [email-masked]; [email-masked]
>  > If I understand Jari comments correctly, I think at one 
> point, he  > mentioned that we need to revisit/revaluate the 
> existing text in the  > draft. I looked into the draft but 
> the only thing that I found w.r.t  > option (1) is the following text:
>  >
>  > LOCATION NO. 1:
>  > ===============
>  > 2.3.2.1 Visited network supports IPv4 only (private addresses)  > 
>  > Basically there is no text included in the draft to 
> explain how to  > identify the type of payload that is 
> encapsulated in UDP. In  > other words  > and strictly 
> speaking, if we take the draft most relevant text above,  > 
> this "TBD" reserved UDP port will always indicate that the  > 
> payload is an  > IPv6! 
> 
> => No that's not true at all. There is an IP version field in 
> the IP header that tells you what the header is. The fact 
> that the IP header fields (for
> v4 or v6) are not revisited in this draft does not in any 
> shape or form suggest that we have no way of parsing header. 
> I suggest that we get off the header parsing argument because 
> frankly, it's a waste of time. Everyone knows (including 
> people who want option 3) that you can do this with the

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 7 Jun 2007 08:04:20 -0700

> don't think the latter format (3948) would work in this case 

If ESP over UDP is negotiated, then the port number will be UDP 4500.
We cannot use the DSMIP UDP tunnel port number for this. The packets
have to be handled by IPSec process and not MIP process. So, the IPSec
issue Karen raised is common for both option#1 and option#3, IMO.

Sri

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 8 Jun 2007 01:18:37 +1000

> If ESP over UDP is negotiated, then the port number will be UDP 4500.

=> Agreed.

 > issue Karen raised is common for both option#1 and option#3, IMO.

=> I don't understand this part. If we're using port 4500 and following
3948, how would the IPsec implementation add that TLV or process it at the
receiving end? 
Assume that a packet (v4 or v6) is passed to IPsec for sending, are you
saying that the TLV is added to that packet before passing it to IPsec? If
so, are you asking that this TLV gets treated as a protocol? It might be too
late at night for me here but I don't follow. 
I don't see this issue in option 1 or 2 because there is no confusion about
adding the TLV. 

Assuming that you answer the above issue, how does a packet that contains
the TLV after ESP get processed at the receiving end? I mean, after it's
decapsulated how do you parse the packet? you don't necessarily know that
it's a TLV, it could be an IP packet as described in 3498. 

Hesham

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 7 Jun 2007 08:25:04 -0700

> it's a TLV, it could be an IP packet as described in 3498. 

Ok. If there is no TLV header, how does the IPSec process after
decap, demux the packets ? Will it look in the version field 
as DSMIP ? How does it know, if it needs to feed the packet
to the IPv4 forwarding engine or IPv6 forwarding engine ?

Sri

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 8 Jun 2007 01:37:14 +1000

> to the IPv4 forwarding engine or IPv6 forwarding engine ?

=> There is not much listening going on here obviously, my questions reamin
unanswered....
To answer your questions, it processes them like any other packet received
using 3948, it assumes it's an IP packet and sends it to the stack for
normal processing. You get a packet, check with version and send it to
ip_input or ip6_input. What's the problem? Incidentally, RFC 3948 says that
it works whether the inner packet is v4 or v6.

Hesham

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Jun 2007 17:39:55 +0200

> header). The TLV's port/protocol field will then point to ESP. 

Mostly yes.

> in the ESP header. It would work fine with the TLV header.

???  One doesn't know to encrypt any other thing than an IP packet or 
the payload of an IP packet... and that TLV is neither.

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 7 Jun 2007 08:53:25 -0700

> => There is not much listening going on here obviously, my 

No. I'm :) My comment is that, the issue is the same for both.
The issue exists and I already agreed to it. Either case, the
IPSec process has to parse either the version field of the
packet or the TLV header and I dont believe any implementations
do either of them today.

> ip_input or ip6_input. What's the problem? Incidentally, RFC 

> 3948 says that

>From what I interpret from 3948, the mechanism of UDP transport
can be used when the outer header and the contained header are
both either IPv4 or IPv6. It did not state that the IPSec process
has to look in the version field and do the demux to ip_input or
ipv6_input. So, it did not talk about a scenario where the payload
is IPv6 and the transport is IPv4. If we can get this clarified
from the IPSec guys, that will be good. If 3948 can support IPv4,
IPv6 payloads in an IPv4-UDP-ESP, then the issue exists is not
applicable to option #1.

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 07 Jun 2007 10:58:24 -0500

<Chair-hat-off>

In the context of DS-MIP6 and the scope or usage of this functionality by
MIP6 or NEMO, I do believe that option 1 is sufficient.

The type of packets encapsulated in the UDP tunnel are either IPv4 or IPv6.
And as the discussion has shown, parising of these packets is not really a
problem. There is no need for an explicit indication of the encapsulated
packet type via a header.

The 4 byte header as proposed by option 3 adds to the overhead since every
packet between the MN and HA will now include it. It could be argued that 4
byte overhead in the overall scope of the headers of the tunnelled packets
is not a significant percentage but it still is an overhead that can be
avoided. Additionally HC schemes that may be applied to the normal IP/UDP
headers will need to be updated or will have to consider this 4 byte header
as well. So I do not believe option 3 from an efficiency perspective is a
good choice for MIP6.

It has been mentioned (by Vijay) that we already support option 2 since we
have a separate port for the ESP encapsulated packets and we have this port
for packets tunnelled over UDP. If GRE or other packets are in the future
determined as being essential to be tunnelled over UDP between the MN and HA
another port could be reserved as well. I am of the opinion that when the
need for carrying GRE or other packet types is demonstrated either in the
MIP6 or NEMO WGs or elsewhere and there is agreement on it, a draft could be
written that updates the current DS-MIP6 document and proposes a new port
that would enable the MN and HA to process those packets. I do not believe
this is being short-sighted because the need for GRE in the context of MIP6
and NEMO has not really been proven inspite of the numerous discussions on
the ML. Having felxibility in a protocol is also not a good reason (kitchen
sink theory).

-Raj

</Chair-hat-off>

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 07 Jun 2007 10:58:25 -0500

Hello,

In order to get a better sense of consensus, I would encourage more people
who are on the MIP6 ML to express their opinion on this issue (summarized
below by Hesham). 

-Raj

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 7 Jun 2007 12:52:03 -0700

> it works whether the inner packet is v4 or v6.

Clarification to my earlier email on 3948 about the payload
identification.

The "next header" field in the ESP header identifies the payload.
So, there is a proper payload qualifier in ESP header. The packet
inside can be IPv4, IPv6 or GRE protocol types. So, when using
ESP header, we dont need the additional 4-byte TLV header, as
the protocol type qualifier is present. We need the same qualifier
when there is no ESP header, when riding on UDP. So, the point
to emphasize is that we are asking for a payload qualifier when
using UDP, so that we can send GRE packets. We need this:

IPv4-UDP-ESP-GRE-(IPv4, IPv6) (This works)
IPv4-UDP-TLV-GRE-(IPv4, IPv6) 

FYI, Cisco's IPSec implementation supports
IPv4-UDP-ESP-GRE-IPv6 and not IPv4-UDP-ESP-IPv6, as of now. Just
informational. GRE as a generic transport is supported for IPSec
in many implementations today. The mode is very popular, IMO.

Comments to your other email:

>  > Yes. Your suggestion will work ! A *minor* side affect is that,
>  > if a user does a manual ping to the HA, the HA will not be
>  > able to differentiate between the user ping to the DSMIP
>  > ping, always DSMIP process gets all the packets. 
> 
> => Well, sure, and it should. Just like a user ping in plain 
> MIP might get
> tunnelled unless you force the use of the CoA.

So, the user  doing a simple ping to the HA, will never pass.
The MIP stack on both the ends will capture that and consider
that as a keepalive message. Simple side affect, its ok. No
big deal, as long as the user understands why his pings to the
HA will never pass.

=> Yes but you're referencing drafts for PMIP and MIPv4! We know it's needed
> for IPv4 networks with overlapping IP addresses and we discussed that
before
> (and it's typically used by the infrastructure not the host). None of that
> applies here. I already said that if for some reason you need it in PMIP
> then you can use it before the UDP header. Plus, why are we standardizing
> PMIP extensions in this WG? 

DSMIP must be leveraged by PMIP6, that's Jari's direction, as I
understand. So, IMO, we need to make sure, what we design here
can serve the general MIP6, NEMO and PMIP6 requirements. But, I
agree, GRE may not be required for a normal MIP6 tunnel.

Regards
Sri

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 8 Jun 2007 10:26:55 +1000

> The "next header" field in the ESP header identifies the payload.

=> Ok, so we can't have TLV following that.

 > the protocol type qualifier is present. 

=> Right, we don't need it and we can't have it anyway.

 > that as a keepalive message. 

=> I don't know why you think the MIP stack has to capture it. This is
getting into a side issue but the basic point is that it's done for the NAT,
so it can be processed like any normal ping. If you get too uncomfortable
with this there are many other ways of solving it, like DO option...etc. So
let's not use this point as a justification for an additional header.

 > can serve the general MIP6, NEMO and PMIP6 requirements.

=> Nope. We have requirements from MIP6 and NEMO. Of course it's nice if we
can help any other work (including PMIP) if we can, but I think it's wrong
to do that at the cost of making the base spec worse for its primary users.
If PMIP needs extensions (and it does in other cases) then it can extend
those solutions for its own use and still reference this work. We shouldn't
burden the base for the case of PMIP, especially when PMIP was never the
main user of this work.

 But, I
 > agree, GRE may not be required for a normal MIP6 tunnel.

=> Great. So I think at least we're making progress in understanding where
this is perceived to be needed. The question is whether it needs to be done
here or in NETLMM where the beneficiary is. I don't think we should be
addressing it here. 

Hesham

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 7 Jun 2007 18:24:05 -0700

Hi Hesham

> => Right, we don't need it and we can't have it anyway.

No. We can still have TLV header. But, I'm saying we have a
protocol qualifier. I thought, it might be better to avoid
atleast for ESP, but, Vijay was suggesting why not have it
consistently for all modes ESP or non-ESP modes. This is
how the implementation will work:

I define tunnel interface with the encap mode of IPv4-UDP-TLV.
Now, I apply crypto policy on this interface. All packets
GRE, IPv4, IPv6 packets when sent through this interface, will
get hit the crypto policy and get the ESP header. As the packets
are routed, the tunnel interface will apply the IPv4-UDP-TLV
header. For incomming packets, the packets will match the
tunnel interface, crypto policy check will remove the ESP
header and identify the payloads using the payload qualifier
in the "next header" field of the ESP header. This is one
way of implementation.

With ESP, TLV heeader points to ESP:
IPv4-UDP {TLV {ESP (IPv4, IPv6)}}

Without ESP, TLV header points to GRE:
IPv4-UDP {TLV {GRE (IPv4, IPv6)}}

Like I said, we can get some input from the IPSec folks
on this, if you disagree with this.

We can also avoid TLV header all together, when using ESP.
We can carry all protocol types.

> here or in NETLMM where the beneficiary is. I don't think we should be

I think, we can certainly avoid GRE in DSMIP, if we really want
to ignore that requirement. There are valid use cases that are
there for NETLMM, MIP6 and NEMO, we can solve with a tiny header.
As Yoshi pointed out, if some one wants to tunnel legacy IPX
or other traffic from the MN to home network, GRE is required.
Same thing for routing legacy protocol traffic from a network
behind mobile router to the home network. We already talked
about the NETLMM requirement. I do not think this 4-byte header
will make the "base spec worse", it really addresses all these
usecases.

Sri

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 8 Jun 2007 11:59:06 +1000

> IPv4-UDP {TLV {ESP (IPv4, IPv6)}}

=> Do you agree that this is not 3948? The reason we opened this issue was
Karen's question about how we'd use 3948 which defines UDP ESP
encapsulation. If you run this format on port 4500 then it obviously won't
work. Do you also agree now (given your earlier email) that this is only an
issue for option 3 and not 2 and 1? 

 > on this, if you disagree with this.

=> I don't understand what input you are seeking, this is a different format
from the RFC so if you run it on the same port with an implementation of
that RFC then it won't work. What am I missing? 

 > We can carry all protocol types.

=> I think we'll have to. I don't get this "either or" description. Also
adding and removing the TLV field based on whether ESP is used or not
doesn't seem to be a good way of doing things because it introduces a
dependency between the mobility implementation and the way IPsec is being
used. 

 > or other traffic from the MN to home network, GRE is required.

=> You mean you can't carry IPX in IP using proto 111? If a node does not
implement IP at all then we're not talking about an MN. If the MR want to
tunnel IPX in IP then that would work too. 
I understand you might prefer GRE, but there is a difference between a MUST
and a MAY type goal. A MAY type goal need not be in the base and force
everyone else to use it. A MUST goal has to be in the base. 

I'm a bit sceptical about unexplained scenarios that come piecemeal. If you
have a scenario in mind where this is needed for the MR/MN then please write
it down. I find it difficult to keep up with the discussion when each email
contradicts the one before it. In the last email you said you wanted this
for PMIP and MIPv6 didn't need it. Now it's a different story. It's hard for
me to discuss things this way.

Hesham

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 7 Jun 2007 19:14:55 -0700

> => Do you agree that this is not 3948? 

Yes, it is not 3948.

> The reason we opened 
> this issue was

Port 4500 will not be used. The UDP port number will point to the
TLV and the TLV will say ESP follows.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 7 Jun 2007 19:27:50 -0700 (PDT)

Hesham:

> issue for option 3 and not 2 and 1?

I'm again saying, we need a protocol qualifier. That is the
title of the issue. We just need a way to identify the payload
that is carried in a UDP header. ESP provides that and we dont
need the TLV for that mode. When ESP is not there, we need
the TLV header. Now, with respect to 3948, if it does not
permit TLV on top of UDP, fine. No issue, as we dont need it.
If using TLV after UDP is not 3948, as Vijay says, I agree.
We dont have to use the TLV for that mode.

> dependency between the mobility implementation and the way IPsec is being

I disagree. We can skip the encap, if its not required.

> everyone else to use it. A MUST goal has to be in the base.

Its not about preference. When using IPv4-UDP tunnel, to carry IPX
or other payloads, we need GRE. If there is no NAT, I've no issue,
GRE can be carried in IPv4, IPv6.

> me to discuss things this way.

Lets hear from others. Its my word against your word. We both know
exactly what the requirements are and why this is required not
required.

Sri

---

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Fri, 8 Jun 2007 09:02:47 +0200

Hi,

Our (Ericsson) implementation of 3948 supports IPv6 in UPD ESP IPv4
tunnel.

BR, Karen 

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: 7. juni 2007 17:53
> To: 'Hesham Soliman'; Karen E. Nielsen (AH/LMD); 'Alexandru Petrescu'
> >  > Ok. If there is no TLV header, how does the IPSec 
> process after  > 
> > decap, demux the packets ? Will it look in the version field  > as 
> > DSMIP ? How does it know, if it needs to feed the packet  > to the 
> > IPv4 forwarding engine or IPv6 forwarding engine ?
> > 
> > => There is not much listening going on here obviously, my 
> questions 
> > reamin unanswered....
> 
> packet or the TLV header and I dont believe any 
> implementations do either of them today.
> 
> > To answer your questions, it processes them like any other packet 
> > received using 3948, it assumes it's an IP packet and sends 
> it to the 
> > stack for normal processing. You get a packet, check with 
> version and 
> > send it to ip_input or ip6_input. What's the problem? Incidentally, 
> > RFC
> 
> > 3948 says that
> From what I interpret from 3948, the mechanism of UDP 
> transport can be used when the outer header and the contained 
> header are both either IPv4 or IPv6. It did not state that 
> the IPSec process has to look in the version field and do the 
> demux to ip_input or ipv6_input. So, it did not talk about a 
> scenario where the payload is IPv6 and the transport is IPv4. 
> If we can get this clarified from the IPSec guys, that will 
> be good. If 3948 can support IPv4,
> IPv6 payloads in an IPv4-UDP-ESP, then the issue exists is 
> not applicable to option #1.
> 
> Sri
>

---

From: Pekka Savola <[email-masked]>
Date: Fri, 8 Jun 2007 10:14:34 +0300 (EEST)

> Anyone else has a comment on this?

FWIW, when we were writing RFC 4891 ("Using IPsec to Secure 
IPv6-in-IPv4 Tunnels") Mohan realized that the same issues we were 
seeing (that were specific to "IKE runs on v4, but tunnel is v6" 
scenario; converse IP versions is also true) would likely come up with 
DS-MIP effort as well.  This significantly affected our recommendation 
to use transport mode.

RFC 4891 provides some discussion and references on this issue.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Fri, 8 Jun 2007 09:48:20 +0200

Hi,

How do you envisage to negotiate the ESP SA for 

IPv4-UDP {TLV {ESP (IPv4, IPv6)}} - ??

- and should IP Sec now be made to understand
Ipv4 UDP TVL ESP encapsulation - Or how do you intend to trick
IPSec to respectively decrypt and extract and encrypt and insert the ESP
header ?

In our "fast" IP stack implementation we use 4500 UDP port number
scanning to intercept
UDP ESP packets for IPSec processing.
Option 2 with a specified port for IPv4/IPv6 would be a straightforward
extension of this.
Option 1 and Option 3 both require scanning of the UDP payload for ALL
UDP packets. As a starting point
this does not seem very nice.

Karen 

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: 8. juni 2007 04:15
> To: Hesham Soliman; Sri Gundavelli; Karen E. Nielsen 
> (AH/LMD); Alexandru Petrescu
> Subject: RE: [nemo] RE: [Mip6] issue 93 summary
> 
> >  > No. We can still have TLV header. But, I'm saying we have a  > 
> > atleast 
> > for ESP, but, Vijay was suggesting why not have it  > 
> consistently for 
> > all modes ESP or non-ESP modes. This is  > how the 
> implementation will 
> > work:
> >  >
> >  > Now, I apply crypto policy on this interface. All 
> packets  > GRE, 
> > IPv4, IPv6 packets when sent through this interface, will  
> > get hit 
> > the crypto policy and get the ESP header. As the packets  > are 
> > routed, the tunnel interface will apply the IPv4-UDP-TLV  > 
> header.  
> > For incomming packets, the packets will match the  > tunnel 
> interface, 
> > crypto policy check will remove the ESP  > header and identify the 
> > payloads using the payload qualifier  > in the "next 
> header" field of 
> > the ESP header. This is one  > way of implementation.
> >  >
> > encapsulation. If you run this format on port 4500 then it 
> obviously 
> > won't work. Do you also agree now (given your earlier 
> email) that this 
> > is only an issue for option 3 and not 2 and 1?
> 
> Port 4500 will not be used. The UDP port number will point to 
> the TLV and the TLV will say ESP follows.
> 
> Vijay
> 
> > 
> > 
> > => I don't understand what input you are seeking, this is a 
> different 
> > format from the RFC so if you run it on the same port with an 
> > implementation of that RFC then it won't work. What am I missing?
> > 
> >  >
> > dependency between the mobility implementation and the way IPsec is 
> > being used.
> > 
> >  > > => Nope. We have requirements from MIP6 and NEMO. Of 
> course  > > 
> > it's nice if we  > > can help any other work (including PMIP) if we 
> > can, but I  > > think it's wrong  > > to do that at the 
> cost of making 
> > the base spec worse for its  > > primary users.
> >  > > If PMIP needs extensions (and it does in other cases) 
> then it  > 
> > > can extend  > > those solutions for its own use and still 
> reference 
> > this  > > work. We shouldn't  > > burden the base for the case of 
> > PMIP, especially when PMIP  > > was never the  > > main 
> user of this 
> > work.
> >  > >
> >  > >  But, I
> >  > > => Great. So I think at least we're making progress in  > > 
> > understanding where  > > this is perceived to be needed. 
> The question 
> > is whether it  > > needs to be done  > > here or in NETLMM 
> where the 
> > beneficiary is. I don't think  > we should be  > > 
> addressing it here.
> >  >
> >  >
> >  > I think, we can certainly avoid GRE in DSMIP, if we 
> really want  > 
> > to ignore that requirement. There are valid use cases that are  > 
> >  > As Yoshi pointed out, if some one wants to tunnel legacy 
> IPX  > or 
> > other traffic from the MN to home network, GRE is required.
> > 
> > => You mean you can't carry IPX in IP using proto 111? If a 
> node does 
> > not implement IP at all then we're not talking about an MN. 
> If the MR 
> > want to tunnel IPX in IP then that would work too.
> > I understand you might prefer GRE, but there is a 
> difference between a 
> > MUST and a MAY type goal. A MAY type goal need not be in 
> the base and 
> > force everyone else to use it. A MUST goal has to be in the base.
> > 
> > I'm a bit sceptical about unexplained scenarios that come 
> piecemeal. 
> > If you have a scenario in mind where this is needed for the 
> MR/MN then 
> > please write it down. I find it difficult to keep up with the 
> > discussion when each email contradicts the one before it. 
> In the last 
> > email you said you wanted this for PMIP and MIPv6 didn't 
> need it. Now 
> > it's a different story. It's hard for me to discuss things this way.
> > 
> > Hesham
> > 
> > 
> > 
> > 
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 8 Jun 2007 21:58:53 +1000

Thanks for the pointer Pekka, it's good to know. I'll take a look.

Hesham 

 > From: Pekka Savola [mailto:[email-masked]] 
 > Sent: Friday, June 08, 2007 5:15 PM
 > To: Hesham Soliman
 > Cc: 'Karen E. Nielsen (AH/LMD)'; [email-masked]; [email-masked]
 > Subject: RE: [Mip6] issue 93 summary - IKE/IPsec
 >

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 8 Jun 2007 22:02:57 +1000

Hi Karen, 

 > UDP packets. 

=> I don't understand why option 1 requires that. You can negotiate the
IPsec SA and run over port 4500 with the following format:

IPv4
UDP
ESP
IPv6
...etc

Where do you foresee the need for scanning all UDP packets? I don't think
option 3 is applicable to 3948 as I mentioned in other emails.

Hesham

As a starting point

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 08 Jun 2007 14:14:20 +0200

> Our (Ericsson) implementation of 3948 supports IPv6 in UPD ESP IPv4

For sake of completeness, my implementation of Mobile IPv6 over IPv4 
traversing NATs does this for BU/BAck:

IPv4
UDP
IPv6
AH
ESP
DO/RH/etc
MobilityHader

And this for app:

IPv4
UDP
IPv6
AH
ESP
DO/RH/etc
payload

This is not an implementation of DS-MIPv6 however, it's just Mobile IPv6 
  and NAT traversal.

Alex

---

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Fri, 8 Jun 2007 14:47:57 +0200

Hi,

Just so that we are all clear, the below is ESP IPSec in transport mode
and has nothing to
do with 3948 ESP UDP tunnel encapsulation, :-).

If I understand you correct. Then in your implementation 
payload data is only protected at the HA-MN by virtue of end to end
IPSec protection to CN peer - Right ?

BR, Karen

> For sake of completeness, my implementation of Mobile IPv6 
> over IPv4 traversing NATs does this for BU/BAck:
> 
> IPv4
> UDP
> IPv6
> AH
> ESP
> DO/RH/etc
> MobilityHader
> 
> And this for app:
> 
> IPv4
> UDP
> IPv6
> AH
> ESP
> DO/RH/etc
> payload
> 
> >> The issue exists and I already agreed to it. Either case, 
> the IPSec 
> >> process has to parse either the version field of the packet or the 
> >> TLV header and I dont believe any implementations do 
> either of them 
> >> today.
> >>
> transport can 
> >> be used when the outer header and the contained header are both 
> >> either IPv4 or IPv6. It did not state that the IPSec 
> process has to 
> >> look in the version field and do the demux to ip_input or 
> ipv6_input. 
> >> So, it did not talk about a scenario where the payload is IPv6 and 
> >> the transport is IPv4.
> >> If we can get this clarified from the IPSec guys, that 
> will be good. 
> >> If 3948 can support IPv4,

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 08 Jun 2007 18:37:10 +0200

Karen E. Nielsen (AH/LMD) wrote:
> Hi,
> 
> Just so that we are all clear, the below is ESP IPSec in transport
> mode and has nothing to do with 3948 ESP UDP tunnel encapsulation,
> :-).

Right, it's just a way of implementing Mobile IPv6 over IPv4.

> If I understand you correct. Then in your implementation payload data
> is only protected at the HA-MN by virtue of end to end IPSec
> protection to CN peer - Right ?

Sorry no IPsec at CN is assumed.  The payload is protected by MN and HA 
with rfc3776.

Alex

> 
> BR, Karen
> 
>> For sake of completeness, my implementation of Mobile IPv6 over
>> IPv4 traversing NATs does this for BU/BAck:
>> 
>> IPv4 UDP IPv6 AH ESP DO/RH/etc MobilityHader
>> 
>> And this for app:
>> 
>> IPv4 UDP IPv6 AH ESP DO/RH/etc payload
>> 
>> This is not an implementation of DS-MIPv6 however, it's just Mobile
>> IPv6 and NAT traversal.
>> 
>> Alex
>> 
>>> BR, Karen
>>> 
>>>> -----Original Message----- From: Sri Gundavelli
>>>> [mailto:[email-masked]] Sent: 7. juni 2007 17:53 To:
>>>> 'Hesham Soliman'; Karen E. Nielsen (AH/LMD);
>> 'Alexandru Petrescu'
>>>> Cc: [email-masked]; [email-masked] Subject: RE: [Mip6] issue 93
>>>> summary
>>>> 
>>>> 
>>>>>> 
>>>>> DSMIP ? How does it know, if it needs to feed the packet  >
>>>> process has to parse either the version field of the packet or
>>>> the TLV header and I dont believe any implementations do
>> either of them
>>>> today.
>>>> 
>>>>> To answer your questions, it processes them like any other
>>>>> packet received using 3948, it assumes it's an IP packet and
>>>>> sends
>>>> it to the
>>>>> RFC 3948 says that it works whether the inner packet is v4 or
>>>>> v6.
>>>>> 
>>>> So, it did not talk about a scenario where the payload is IPv6
>>>> and the transport is IPv4. If we can get this clarified from
>>>> the IPSec guys, that
>> will be good.
>>>> If 3948 can support IPv4, IPv6 payloads in an IPv4-UDP-ESP,
>>>> then the issue exists is not applicable to option #1.
>>>> 
>>>> Sri
>>>> 
>> 
>>  This email has been scanned by the MessageLabs Email Security
>> System. For more information please visit 
>> http://www.messagelabs.com/email

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 8 Jun 2007 10:49:58 -0700

Hesham, 

> IPsec SA and run over port 4500 with the following format:

This is option 2. The UDP port here will point to 4500, different
from the UDP port reserved for DS-MIPv6.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 8 Jun 2007 11:04:19 -0700

> IPv4-UDP {TLV {ESP (IPv4, IPv6)}} - ??

You negotiate as if you are negotiating for NAT traversal.

> IPSec to respectively decrypt and extract and encrypt and 

The IPsec implementation shouldn't have to insert the TLV. It would
be done by Mobile IPv6. (similar to how Mobile IPv6 inserts the 
home address option after IPsec is done with adding the ESP header).

> this does not seem very nice.

You don't have to scan for all UDP ports. Your "fast" IP stack
implementation, in addition to port 4500, would need to look for 
the UDP port that points to the TLV and the TLV port/protocol 
field that identifies ESP.

Vijay

---

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Fri, 8 Jun 2007 21:45:11 +0200

Hi,

Thanks! I understand the port scanning issue 
as well as the insertion/extraction of TLV
header much better now. Sorry to have caused any confusion.

So would it be correct to say that the real difference IPSec-wise,
in-between 
option 1,2 and option 3 is that with option 3, then logically MIP need 
"to come in" before inbound and after outbound IPSec processing 
to extract/insert TLV and update length fields.
Whereas this is not the case with option 1 and 2.

As it is also not the case in standard MIPv6 with IPSec tunneling to HA.

Karen

> Sent: 8. juni 2007 20:04
> To: Karen E. Nielsen (AH/LMD); Hesham Soliman; Sri 
> Gundavelli; Alexandru Petrescu
> > Ipv4 UDP TVL ESP encapsulation - Or how do you intend to 
> trick IPSec 
> > to respectively decrypt and extract and encrypt and insert the ESP 
> > header ?
> 
> The IPsec implementation shouldn't have to insert the TLV. It 
> would be done by Mobile IPv6. (similar to how Mobile IPv6 
> inserts the home address option after IPsec is done with 
> adding the ESP header).
> 
> > scanning to intercept UDP ESP packets for IPSec processing.
> > Option 2 with a specified port for IPv4/IPv6 would be a 
> > straightforward extension of this.
> > UDP packets. As a starting point this does not seem very nice.
> 
> You don't have to scan for all UDP ports. Your "fast" IP 
> stack implementation, in addition to port 4500, would need to 
> look for the UDP port that points to the TLV and the TLV 
> port/protocol field that identifies ESP.
> 
> Vijay
> 
> > 
> > Karen
> > 
> > > To: Hesham Soliman; Sri Gundavelli; Karen E. Nielsen (AH/LMD); 
> > > Alexandru Petrescu
> > > > protocol qualifier. I thought, it might be better to 
> avoid atleast 
> > > > IPv4, IPv6 packets when sent through this interface, 
> will get hit 
> > > >  > Like I said, we can get some input from the IPSec folks on 
> > > > this, if you disagree with this.
> > > >

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 8 Jun 2007 14:15:32 -0700

> Whereas this is not the case with option 1 and 2.

Yes. The TVL would be added for all packets that are sent through 
a tunnel setup by DS-MIPv6, when the mobile node is on an IPv4 
access network.

> As it is also not the case in standard MIPv6 with IPSec 

Well, we kind of have tighter integration between MIPv6 and IPsec
already. For e.g, the insertation of home address option and 
routing header is done by MIPv6 after IPsec processing is done. 
The use of 'K' bit (to update the tunnel end point) also requires
this. I am not suggesting we continue doing this, but adding TLV
shouldn't be a big issue. :)

Vijay

---

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Sat, 9 Jun 2007 13:28:10 +0200

Hi,

> 
> > 
> > As it is also not the case in standard MIPv6 with IPSec 
> tunneling to 
> > HA.
> 
> Well, we kind of have tighter integration between MIPv6 and 
> IPsec already. For e.g, the insertation of home address 
> option and routing header is done by MIPv6 after IPsec 
> processing is done. 
> The use of 'K' bit (to update the tunnel end point) also 
> requires this. I am not suggesting we continue doing this, 
> but adding TLV shouldn't be a big issue. :)
> 
> Vijay
> 

Yes, :-). I do not want to be twisting straws here about the pros and
cons. I
am simply trying to understand the differences.

However, (now you may see this as twisting straws, but the angle is
different),
the extraction and insertion of RH/DO is a mobility thing and there is a
very good reason
IPSec shouldn't know about those as we exactly want the movement to be
transparent to
IPSec SAs anchored on the MN's home address.

The TLV header is not a mobility thing, per se, as I understand it. 
So the insertion and extraction outside IPSec seems more like a hack to
allow this
new encapsulation header type IP-UDP-TLV to use IPSec UDP ESP
encapsulation. 

I agree that it is feasible from an implementation perspective. 
It is not a very nice, though. But perhaps need is a better keyword,
than nice here.

Karen

---

From: "Hesham Soliman" <[email-masked]>
Date: Sun, 10 Jun 2007 00:26:43 +1000

> IPSec SAs anchored on the MN's home address.

=> Which does not at all result in tight integration with IPsec, quite the
opposite in fact. It is done to be transparent to IPsec. There is no
extraction/insertion, we swap the content with the src/dst address. Having
tight integration with IPsec means that we would require IPsec to know these
mobility specific events.

Hesham

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sat, 9 Jun 2007 08:46:08 -0700

Hi Karen, 

> From: Karen E. Nielsen (AH/LMD) [mailto:[email-masked]] 
> Sent: Saturday, June 09, 2007 4:28 AM
> To: Vijay Devarapalli; Hesham Soliman; Sri Gundavelli; 
> Alexandru Petrescu

When 3948 is used, ie if the port is 4500 and not DSMIP port, the TLV
header is not required, as we can carry other protocol payloads and
the required headers are present for that mode. So, the behaviour is
consistent to 3948 and its the same for both option#1 and option#3.

If we prefer both the ESP and non ESP traffic to be handled as a 
IP-UDP-TLV traffic on DSMIP port, the MIP is the handler for this
traffic and will remove the tunnel encapsulations and pass it the the
IPSec process. So, its about the registered handlers, IPSec is the
handler on 4500 and MIP on the DSMIP port. MIP understands all the
encapsulation formats and hence can do the proper decaps and pass
it to the crypto system. 

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Sun, 10 Jun 2007 16:38:19 -0700

> new encapsulation header type IP-UDP-TLV to use IPSec UDP ESP

Well, the TLV is specific to DS-MIPv6 tunnels setup over IPv4. 
No other protocol is using the TLV. 

Vijay

---

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Mon, 11 Jun 2007 10:07:05 +0200

Hi Sri,

> > 
> 
> When 3948 is used, ie if the port is 4500 and not DSMIP port, 
> the TLV header is not required, as we can carry other 
> protocol payloads and the required headers are present for 
> that mode. So, the behaviour is consistent to 3948 and its 
> the same for both option#1 and option#3.
> 
> If we prefer both the ESP and non ESP traffic to be handled 
> as a IP-UDP-TLV traffic on DSMIP port, the MIP is the handler 
> for this traffic and will remove the tunnel encapsulations 
> and pass it the the IPSec process. So, its about the 
> registered handlers, IPSec is the handler on 4500 and MIP on 
> the DSMIP port. MIP understands all the encapsulation formats 
> and hence can do the proper decaps and pass it to the crypto system. 
> 

Yes. It is feasible and yes it is a matter of implementation and whether

you see IPSec as a simple insert/extract IPSEc headers or whether IPSec
is considered also to handle the outer headers (the nature of the latter
which is given in the IPSec policies).

Anyway, I will rest here. I have understood the issues - Thanks !!

>From an implementation perspective we can handle all options.
For simplicity, interoperability issues, robustness and such,
I do prefer to keep the IPSec and non-IPSec tunnel dialects as 
few as possible and would rather see
option 1 and option 2, than option 3. But I can live with all options.

Karen

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Jun 2007 12:02:30 +0300

Hesham,
> version field. Let's not debate facts here, it's pointless. 
He's not saying its impossible, he's saying it needs to be
documented. I agree with that requirement. You need
to change the draft no matter what (but of course
adding this description is trivial).

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Jun 2007 12:19:00 +0300

Karen, Vijay,

> new encapsulation header type IP-UDP-TLV to use IPSec UDP ESP

For what it is worth, I would like to see as little changes in IPsec
processing with Mobile IPv6 as possible. (But as Vijay points
out in a later e-mail, the TLV is only used for Mobile IPv6 / DSMIP,
and when IPsec encapsulation is not used. So maybe this is not
creating additional changes. But as a principle, I want to be
very careful about any new interactions.)

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Jun 2007 12:19:06 +0300

Hesham,

> to do that at the cost of making the base spec worse for its primary users.

I do not think we should treat the users of this technology
differently depending on what they are doing. I do think
we need to listen to the PMIP folks, too.

(But its a separate question whether the PMIP use case
truly implies need for the TLV, and even if it does, whether
it should be done as a part of the initial DSMIP application
or as an extension. However, in practice we know that the
NETLMM schedule is quite tight, so I would at least like
to entertain the idea that if they truly need something
then it should be in the base DSMIP document. I've also
told NETLMM that their current charter does not allow
work for IPv4, except when then they can directly reference
an existing spec. This may change -- I want to recharter
them, but that's another consideration to take into
account.)

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Jun 2007 12:19:15 +0300

Sri,

> IPv6 payloads in an IPv4-UDP-ESP, then the issue exists is not
My interpretation of RFC 3948 is that it does not in any way change
the ESP processin rules. That is, a tunnel mode packet contains an
IP packet. IPsec can deal with both IPv4 and IPv6 packets in the
inner packet.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Jun 2007 12:19:29 +0300

Sri,

> will make the "base spec worse", it really addresses all these

As far as I am aware, we are not chartered in any of the
related WGs to produce a legacy protocol mobility solution.
Lets leave that part of the kitchen sink to other protocols :-)

Jari

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 23 Jun 2007 00:14:44 +1000

> shape or form

=> Agreed. Ahmad said in a later email that it is more of an editorial
comment than a technical one. Depending on how we resolve this issue I'll
add this comment among several others that he sent. 

Hesham

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 23 Jun 2007 00:19:54 +1000

> course it's nice if we

=> Again, I completely agree. The main problem here is that we haven't seen
this discussion in NETLMM, so I don't know that we're getting a
*representative* view of NETLMM requirements in this discussion. I think the
main point of my statement above relates to your question of whether this
should be in the base or not. Of course that is after understanding whether
there is a need for this. 

Hesham

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 26 Jun 2007 00:29:41 -0700

Hi Jari,

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Friday, June 22, 2007 2:19 AM
> To: Sri Gundavelli
> Cc: 'Hesham Soliman'; 'Karen E. Nielsen (AH/LMD)'; 'Alexandru 
> Petrescu'; [email-masked]; [email-masked]
> Subject: Re: [nemo] RE: [Mip6] issue 93 summary
> 
> Sri,
> 

Sure, clarified further in that thread with Karen. Copied below.
When using ESP, we dont have any issue supporting GRE. ESP follows
the right protocol convention and it has the "next header" tag 
that identifies the payload and the same we are asking for DSMIP
when riding over UDP.