Subject: [MEXT] TLV header in DSMIP

From: Hesham Soliman <[email-masked]>
Date: Thu, 3 Apr 2008 19:44:44 +1100

Folks,

During one of the reviews for DSMIP the issue came up regarding the  
TLV header Type field values and how the current spec doesn't describe  
how it can be used for IPsec.
After looking into this a bit I don't see why we would need IPsec for  
this. We originally defined because people wanted to use GRE so the  
format would be:
IP
UDP
GRE
IP
...etc

It seems like it would be sufficient to only define this now for GRE  
and if someone comes up with a need for using IP/IPsec directly after  
the TLV header they can define that behaviour and request a new type  
value.

So the new draft would only allocate one value for GRE.

Any objections to this ? please respond quickly, we need to finish  
this ASAP.

Thanks,
Hesham
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 3 Apr 2008 15:54:16 +0200

Hi Hesham,
I posted before on using TLV-encap for tunnel optimization (e.g. header
compression).
I think type values can be requested at time of defining protocols for this.
But I think tunnel optimization needs a more efficient TLV structure: 1
octet for only the type is needed, the other 3 octets are overhead and
should be eliminated.
Any objection mentioning such a usage? If not, we block something that
really makes sense.
Teco.

> -----Oorspronkelijk bericht-----
> Van: [email-masked] [mailto:[email-masked]] Namens Hesham
> Soliman
> Verzonden: donderdag 3 april 2008 10:45
> Aan: [email-masked]
> Onderwerp: [MEXT] TLV header in DSMIP
> 
> Folks,
>

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 03 Apr 2008 09:03:22 -0500

Hi Hesham,

Your proposal below is fine and we can move forward.

-Raj

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 4 Apr 2008 01:18:31 +1100

Hi teco,

> Any objection mentioning such a usage? If not, we block something that

=> While i sympathise with your idea, I think that, as I said before,  
the benfits are minimal. Please note
that practically we don't expect this TLV header to be used by MNs. So  
compression is not needed.
Especially, at this stage (including the time you raised it), I don't  
think it's worth delaying things for it.
That's my opinion anyway.

Hesham

> Mipshop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mipshop

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 3 Apr 2008 15:21:01 +0100

Teco,

I am afraid I agree with Hesham, this seems like a really minor optimization.
I would suggest we move on.

Regards
George

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 03 Apr 2008 19:23:59 +0200

Below:

> Any objections to this ? please respond quickly, we need to finish  

WFM

	Henrik

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 3 Apr 2008 14:43:34 -0700

Question .. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hesham Soliman
> Sent: Thursday, April 03, 2008 1:45 AM
> To: [email-masked]
> Subject: [MEXT] TLV header in DSMIP
> 
> Folks,
> 

I assume you mean ..

IP 
UDP
TLV-header
Other headers (GRE ..)

So, we assume 3948 scheme is in use and since ESP has the
semantics to identify the contained types ...

IPv4-UDP-ESP-GRE-(IPv4, IPv6) -- 3948 is in use, UDP port 4500.
IPv4-UDP-TLV-GRE-(IPv4, IPv6) -- DSMIP6 port.

This is ok.

Thanks
Sri

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Thu, 3 Apr 2008 17:41:01 -0700

>  how it can be used for IPsec.

What was the issue?

>  Any objections to this ?

Yes. When we specified the TLV header, it was felt that the mobile
node and the home agent need can use the same UDP port for
both traffic tunneled with ESP encryption and for traffic without ESP
encryption. The same TLV header would tell the home agent whether
there is a GRE, IPv4, IPv6 or IPsec header that follows the TLV
header.

Without this, you end up using UDP port 4500 for IPsec protected
data traffic between the mobile node and the home agent and the
DS-MIPv6 UDP port for non-IPsec protected data traffic between the
mobile node and the home agent. I would prefer to avoid this.

Perhaps you could explain what the issue is with using the TLV
header followed by the ESP header.

Vijay

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 4 Apr 2008 13:15:26 +1100

> Other headers (GRE ..)

=> No, I meant the above.

> semantics to identify the contained types ...

=> Not really, 3948 is not used for IPv6, so we can't assume that for  
all cases.

> IPv4-UDP-TLV-GRE-(IPv4, IPv6) -- DSMIP6 port.

=> If you want to have ESP come right after the TLV then please send  
some text to describe this behaviour in terms of IPsec operation. I'm  
trying to avoid extending the IPsec
mess in the spec to strange cases that need more inquiries and more  
time at this stage. So I'd rather have that specified elsewhere.
I think the easiest thing now is to do the format I sent above and  
later if you want to add ESP/AH ...etc then you can specify that in a  
draft.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 4 Apr 2008 13:18:25 +1100

>> how it can be used for IPsec.

=> The use of IPsec with this format was not specified. Sec AD's  
comment.

> there is a GRE, IPv4, IPv6 or IPsec header that follows the TLV

=> None of the above is impacted. The suggestion here is that this  
gets done in a separate document. The TLV is still specified with GRE  
in the current spec.
You can specify it for IP, IPsec ...etc in another draft. It's a  
matter of doing things in a modular way for the sake of documentation.  
There is no technical difference.

> mobile node and the home agent. I would prefer to avoid this.

=> See above, this is not an issue.

Hesham

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Thu, 3 Apr 2008 20:09:18 -0700

On Thu, Apr 3, 2008 at 7:18 PM, Hesham Soliman <[email-masked]> wrote:

>  => The use of IPsec with this format was not specified. Sec AD's comment.

Was it in Pasi's review? What needs to be specified in addition? IPsec
shouldn't care about the TLV header that comes before the ESP header.

>  => None of the above is impacted. The suggestion here is that this gets
> done in a separate document. The TLV is still specified with GRE in the
> current spec.
>  You can specify it for IP, IPsec ...etc in another draft.

IP? We are already reserving values for IPv4 and IPv6. Reserving a value
for IPsec is important because payload protection for the DS-MIPv6 tunnel
has useful use cases. There are proposals to use DS-MIPv6 to enable
direct access from the Internet to a home agent in the operator network.
This would require ESP tunnel mode encryption for the DS-MIPv6 tunnel.
I don't care about the "etc"...

> It's a matter of
> doing things in a modular way for the sake of documentation. There is no
> technical difference.

Its not clear what additional specification is needed. It wouldn't make
sense to have a separate document just to reserve one value for ESP.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 3 Apr 2008 20:29:25 -0700

> later if you want to add ESP/AH ...etc then you can specify 

Sure. I understand the pain dealing with all these IPsec issues that
were raised in the last few months.

However, on this, probably there is not much to specify. Atleast from
an implementation angle, its matter of implementing a tunnel interface
with a given encap mode and the ESP header just goes after the TLV,
just as how 3948 allows ESP right after UDP. We can borrow some text
from Sec 3.4 [3948]. Its just one more encap layer after UDP.

Appears to be straight forward to me. But, I'm not sure what issues
you or Pasi is referring to. 

Sri

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 4 Apr 2008 16:45:18 +1100

On 04/04/2008, at 2:09 PM, Vijay Devarapallli wrote:
> On Thu, Apr 3, 2008 at 7:18 PM, Hesham Soliman <[email-masked] 
> > wrote:
>
>>>> Folks,
>>>>

=>  Yes it's from Pasi's review. I'm cc'ing him so he can answer you  
directly and he needs to be aware of this
conversation.

>> gets

=> I've already said at least twice that I'm not suggesting we don't  
ever support IPsec for the TLV. Please
understand that I'm talking about moving this to another doc. So no  
need to tell me that you need to use it. If you
do, you can specify that.

> sense to have a separate document just to reserve one value for ESP.

=> If the WG agrees that no additional specification is needed and the  
AD agrees then I'm fine with that.
If additional specification is needed then we should take it out of  
this spec.

Pasi, please clarify to the WG what additional specification is needed  
for the use of ESP/AH following the
TLV header.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 4 Apr 2008 16:51:21 +1100

> from Sec 3.4 [3948]. Its just one more encap layer after UDP.

=> Sri, if you think there is not much to do here then please send text.

Thanks,
Hesham

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 4 Apr 2008 09:22:05 +0200

Hi Hesham,
I do not want to delay something.
On 3 octets unneeded overhead: I think this is a major issue in any HC
scheme. My background is radio links with low data rates. Check for example
RFC4944 (IPv6 over IEEE 802.15.4).
I appreciate comments from HC experts.
Regards, Teco

> Van: Hesham Soliman [mailto:[email-masked]]
> Verzonden: donderdag 3 april 2008 16:19
> Aan: Teco Boot
> CC: [email-masked]
> Onderwerp: Re: [Mipshop] [MEXT] TLV header in DSMIP
> 
> Hi teco,
>

---

From: <[email-masked]>
Date: Fri, 4 Apr 2008 12:42:46 +0300

> mobile node and the home agent. I would prefer to avoid this.

In the current spec (version -01) this is precisely the situation:
traffic protected with IPsec tunnel mode uses port 4500.

(BU/BAck is protected with transport mode IPsec, but in that case,
the packet also has an IPv6 header, so the TLV-Header type would
be IPv6.)

Best regards,
Pasi

---

From: "George Tsirtsis" <[email-masked]>
Date: Fri, 4 Apr 2008 14:05:21 +0100

Pasi, you describe this as the way it is ...but do you have a problem
with that and why?

Thanks
George

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Fri, 4 Apr 2008 23:14:33 -0700

>  traffic protected with IPsec tunnel mode uses port 4500.

Ok, got it. I looked at the security considerations section again. I
forgot that in version 06, we mandate that port 4500 is always used
for IPsec protected payload traffic, irrespective of whether we use
vanilla UDP or TLV-header UDP encapsulation. In version 05 and
earlier, we didn't have this restriction. One could use the TLV-header
UDP encapsulation (and the DS-MIPv6 port) for the IPsec protected
payload traffic too.

Since we mandate that port 4500 is always used, it does not make sense
to reserve the 'IPsec Type" value in the TLV header. So, we can remove
that.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 5 Apr 2008 00:10:04 -0700 (PDT)

> UDP encapsulation (and the DS-MIPv6 port) for the IPsec protected

I dont follow this. If port 4500 is in use, 3947/3948 considerations
apply. Where does the use of TLV specified ? ESP decapsulation
starts right after UDP header.

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sat, 5 Apr 2008 00:16:05 -0700

> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Thursday, April 03, 2008 10:51 PM
> To: Sri Gundavelli
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MEXT] TLV header in DSMIP
> 
> 

I can provide the text, if there is agreement that we are using
DSMIP port and the TLV-ESP follows the UDP. I'm bit confused, on
what is the port number that is in use. 4500 or the DSMIP port ?

Sri

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 5 Apr 2008 19:31:40 +1100

> what is the port number that is in use. 4500 or the DSMIP port ?

=> I don't think we need the text now, there is agreement to remove  
this.
We're using 4500 for secure traffic and DSMIP port for other traffic.

Hesham

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Sat, 5 Apr 2008 08:16:41 -0700

Hi Sri

>  starts right after UDP header.

In version 06, the security considerations section mandates that

- For IPsec protected payload traffic, port 4500 is used
- For non-IPsec protected payload traffic, the DS-MIPv6 UDP port is used
- When the DS-MIPv6 UDP port is used, you have the option of using
plain UDP encapsulation or TLV-header UDP encapsulation. That is
negotiated with the BU/BAck exchange.

Messy, but we have to live with it since we have two different NAT
traversal mechanisms (IKEv2 and DS-MIPv6) being used at the same time.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sat, 5 Apr 2008 09:14:00 -0700

Hi Vijay,
 
> negotiated with the BU/BAck exchange.

Ok. So, this is what I said last week (see below) ..Use
of two ports 4500 when using ESP and DSMIP6 port when
using TLV (offcourse when not using TLV as well) and
when ESP is not in use. This allows one to use GRE
encap in all modes, secure or non-secure and for IPv4
or IPv6 payload traffic. The comment was that "3948 is
not used for IPv6", ...what in this will not work ? Cannot
carry IPv6 traffic over port 4500 ? If there is no issue
here, we all are on the same page.

---
> Sent: Thursday, April 03, 2008 2:44 PM
> From: Sri Gundavelli
> ...
> ...

> =>[Hesham]  Not really, 3948 is not used for IPv6, so we can't assume that
for  
> all cases.
---

> traversal mechanisms (IKEv2 and DS-MIPv6) being used at the same time.

I understand.

Thanks
Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sat, 5 Apr 2008 09:16:39 -0700

> Sent: Saturday, April 05, 2008 1:32 AM
> To: Sri Gundavelli

Ok. I've no issue using 4500 when using ESP and DSMIP port for non-ESP
traffic. Offcourse, we could have just used DSMIP port and relied on
one NAT traversal mechanism ...

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 6 Apr 2008 21:12:23 -0700

Hi Hesham,

Also, can you please clarify the operation for this
below scenarioe. We are updating our PMIP6 IPv4 document
and we are not clear how this scenario works, in liu of
the latest DSMIP6 resolutions. Some clarifications will
help.

When ESP is used only for control traffic and not for data
traffic, how does the NAT traversal scheme work ? The NAT
mappings for both the flows are different, howz the relation
maintained ?

My Assumption: IPv4 transport in use, NAT in path and
the resolution that the port 4500 is used for secure
ESP traffic and for non secure traffic DSMIP port is
used. 

Operation: 
===========
- MN sends MIP BU encapsulated in UDP to port 4500

- NAT binding is created on the NAT device, having a
  relation to src port of the BU, port 4500, IPv4-private-coa,
  IPv4-public-coa and HA-V4-Address
 
- HA creates a tunnel with UDP encap and with the above 
  properties (Src/Dest ports)

- If MN or HA needs to forward data traffic and unprotected,
  does it needs to be sent to port 4500 or DSMIP port ?
  We cannot send non-ESP traffic to port 4500.

- If this is sent to DSMIP port, what triggers the new NAT
  mapping and howz the tunnel encap header modified on the HA ?

- How do keepalives work ?

Appreciate your time on this.

Regards
Sri

---

From: <[email-masked]>
Date: Mon, 7 Apr 2008 13:06:01 +0300

BTW, I've stated several times that I believe that an average
implementor (i.e., someone who hasn't participated in writing this
specification and doesn't have a PhD) can't actually figure out how
the DSMIPv6/IPsec interaction works based on the current spec
(which is already in much better shape than earlier versions).

I do understand that Hesham as the editor cannot (and should not) 
fix this alone -- so I would really appreciate if other WG members
would help with writing the needed text. 

I've suggested e.g. showing packets (both before and after IPsec 
processing) with their headers to show what traffic is sent from/to 
which port (and how IPsec interacts with this). In particular, 
"using 4500 for secure traffic and DSMIP port for other traffic" 
is *not* what the current spec says.

Could someone from the WG volunteer to produce those packet diagrams,
and propose improved text around those diagrams?

(My apologies for being blunt, but I'd rather see this fixed before
the draft comes to IESG -- remember that the ADs who have to ballot 
"Yes" or "No objection" mostly haven't participated in writing this 
spec, and don't have PhDs.)

Best regards,
Pasi

> From: ext Sri Gundavelli [mailto:[email-masked]] 
> Sent: 07 April, 2008 07:12
> To: 'Hesham Soliman'
> Cc: [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: RE: [MEXT] TLV header in DSMIP
> 
> Hi Hesham,
> 
> > => I don't think we need the text now, there is agreement 
> > to remove  this. We're using 4500 for secure traffic and DSMIP port 
> > for other traffic.
> > 
> > Hesham
> > 
> > >
> > >
> > > Sri

---

From: <[email-masked]>
Date: Mon, 7 Apr 2008 13:10:45 +0300

Well... I can't say that I like it, but it probably works. And 
none of the other solutions (like adding a new DSMIPv6 specific
payload to IKE, or running a separate copy of IKE/IPsec for DSMIPv6)
were very good either.

Best regards,
Pasi 

> From: ext George Tsirtsis [mailto:[email-masked]] 
> Sent: 04 April, 2008 16:05
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 7 Apr 2008 21:25:28 +1000

> (which is already in much better shape than earlier versions).

=> Actually that comment was on an older version but feel free to make  
it now again :)

> is *not* what the current spec says.

=> George and Wassim have volunteered to do this, thanks guys.

Hesham

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 7 Apr 2008 12:31:13 +0100

Well, I have volunteered and indicated that Wassim will probably help,
but have not asked him yet :-)
Note that I am not convinced that diagrams are really appropriate for
the packet descriptions...I will have to look at that. In any case the
idea is to provide clear description of packet headers before and
after IPSEC processing in various cases.

Regards
George

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 7 Apr 2008 07:55:50 -0700

I'm not sure how the NAT traversal scheme works if only
control traffic is enabled for IPsec protection and
not the data traffic. 3775 clearly allows this and is
probably the most default mechanism given the crypto
hardware accelerator requirements on the boxes. In this
scenario of MN using a private address and behind a NAT,
there will be two NAT flows and not sure how they are
tied. This is not an issue in 3775, a secured MIP control
packets result in a L3 tunnel and its optional if ESP
is enabled on that tunnel for data traffic. Given the port
4500 for ESP only traffic, not sure how non-ESP traffic
can be sent there. Especially the initial packets from CN
to MN, when there is no NAT mapping for that flow ...

May be I'm missing some thing basic ... if this is already
discussed and worked out ...some clarifications or pointers
to the draft will help ...

Sri

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, April 07, 2008 3:06 AM
> To: [email-masked]
> Cc: [email-masked]

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 7 Apr 2008 16:57:14 +0100

Hi Sri,

In the case you describe, why do you think the two flows must be tied
in some fashion?

From IPSEC perspective only one flow is secured, so the other flow
(tunneled data) is irrelevant. Tunneled data are then sent with
unsecured UDP encapsulation using the DSMIPv6 port number, as defined
in the draft i.e., IPv4/IPv6 over UDP, or GRE/TLV over UDP

Did I miss the point of your question?

Regards
George

On Mon, Apr 7, 2008 at 3:55 PM, Sri Gundavelli <[email-masked]> wrote:
>  tied.
> This is not an issue in 3775, a secured MIP control

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 7 Apr 2008 09:11:07 -0700

Hi George,

> in the draft i.e., IPv4/IPv6 over UDP, or GRE/TLV over UDP

After the signaling is complete, there should be tunnel encaps
with proper UDP port numbers on both ends for sending the data
traffic. If we treat them separate, how does the HA know what
encap to use for the initial traffic comming from the CN towards
the MN (Note that the signaling is complete and there is a NAT
state for the signaling flow and no data traffic yet from the
MN and so there is no NAT state for the second flow). MN is
behind a NAT and so the trigger needs to come from the MN for
the second flow.

Secondly, if the two flows are not tied, how does keepalive
messaging work for keeping the NAT states active ? Will there be
two NAT keepalive messaging for both the flows ?

Also, the two flows needs to be tied for removing the data path
upon terminating the MIP session.

Thanks
Sri

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 7 Apr 2008 17:29:43 +0100

Hi again ...inline...

>  behind a NAT and so the trigger needs to come from the MN for

GT> Yes, which means that the MN must immediately start sending
keepalives for the data traffic i.e., to the DSMIPv6 port number. This
allows the tunnel to be open for outgoing as well as incomming
sessions. The draft has language to this effect already.

>  two NAT keepalive messaging for both the flows ?

GT> If both of the flows need to be maintained then I think we need
two keepalives. It is not clear to me, however, why we need to
maintain the signaling flow in that case, since we might not have to
send another BU for hours; or am I missing something?
GT> In any case the cost of two keepalives is probably lower than the
cost of turning on encryption which then only requires a single
keepalive. Also note that sending two keepalives is not that bad for
the MN since most of the cost of keepalives is in the fact that the MN
must come out of sleep mode to transmit something. Once the MN wakes
up, transmitting one vs two small packets makes little difference.
There is of course processing cost at the HA side to consider too.

>  upon terminating the MIP session.

GT> Yes I think they are still tied in the HA based on the HoA, no?

BR,
George

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 8 Apr 2008 01:30:53 +0900

Hi Sri,

> behind a NAT and so the trigger needs to come from the MN for

I think this is an issue.

After binding registration, MN should trigger some packet to the HA  
using the
DSMIP port in order to create NAT state for non-ESP data flow.
Otherwise, NAT box may drop the packets tunneled by HA
because there is no NAT state for the UDP packets (DSMIP port).

> two NAT keepalive messaging for both the flows ?

DSMIP uses BU/BA exchange for the keepalive. BU/BA will be sent with  
the 4500 port.
We don't have keepalive mechanism for data flow (DSMIP port) in the  
current spec.

regards,
ryuji

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 7 Apr 2008 09:48:55 -0700

> sessions. The draft has language to this effect already.

I will take a look at the draft again, I missed this language.
Also, requires some text in Security Considerations (quite a bit
of text in 3519 related to this, it has the "R" bit support and
the HA keeps the tunnel in half-created state .. very similar).
Need to understand the implications of this ...

> send another BU for hours; or am I missing something?

All along during DSMIP6 discussions, the general though from the
Authors was that we dont need a seperate KA mechanism, we can very
well use BU/BA and that changes now. If we dont keep the NAT mapping
active for the  control flow, HA cannot send any asynchronous events
such as  Revocation or Notification events.

> There is of course processing cost at the HA side to consider too.

Sure, there needs to be two keepalives. One in control and the
other in data plane. I assume the KA for control is still BU/BA ?
For data flow, how will this be achieved ?

> GT> Yes I think they are still tied in the HA based on the HoA, no?

HoA is just a route over the tunnel. The tunnel endpoints with
src/dest address and port numbers, needs to be reflected in the
BCE. Implementation wise, its very difficult to locate a tunnel
by looking at the routing table.

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 7 Apr 2008 09:56:38 -0700

Hi Ryuji,

> because there is no NAT state for the UDP packets (DSMIP port).

Implementation wise, I'm not sure ..how this really works
on the HA. When and how does it create the UDP tunnel for
the data packets ? We always create tunnel encap after control,
but, this is after receiving a data packet.

> We don't have keepalive mechanism for data flow (DSMIP port) in the  

That will be a problem, if we dont have KA for data flows.

Sri

---

From: <[email-masked]>
Date: Tue, 8 Apr 2008 13:47:36 +0300

RYUJI WAKIKAWA wrote:

> the 4500 port.  We don't have keepalive mechanism for data flow
> (DSMIP port) in the current spec.

No, in the current draft BU/BAck is sent over the DSMIPv6 port, 
not 4500. (And yes, the draft is extremely difficult to understand
here, and needs to be much more understandable before it has 
any chance of being approved...)

Best regards,
Pasi

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 8 Apr 2008 23:12:35 +1000

> one NAT traversal mechanism ...

=> I guess we didn't think of that!  Please read the discussions on  
IKE and DSMIP. We can't do what you're suggesting and the best way to  
find out why is to read those threads, look for pasi's emails on the  
list, it doesn't cover the private discussions but it shows why we  
need both.

Hesham

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 8 Apr 2008 07:28:38 -0700 (PDT)

> => I guess we didn't think of that!  Please read the discussions on IKE and 
> => DSMIP. We can't do what you're suggesting and the best way to find out why 
> => is to read those threads, look for pasi's emails on the list, it doesn't 
> => cover the private discussions but it shows why we need both.
>

Yes, I did not follow the threads. But, I do realize lot of time and
discussions went into this and that its a very complex problem. But,
right now I'm only trying to understand how this works. My issue with
the two ports is from the HA perspective. How it can identify the first
data packet from the MN and setup the UDP tunnel in that path. How it
ties this keepalive packet to a recently accepted BU. All this logic
from the MN perspective appears very simple, but the logic on the HA
is complex and I'm trying to understand the flow.

Sri

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 9 Apr 2008 00:42:26 +1000

> ties this keepalive packet to a recently accepted BU.

=> What keepalive packet? We're using the BU/BA exchange for  
keepalive. IKE has its own KA mechanisms.
I'm not sure what you mean.

I know the current security considerations section is not easy to  
understand and we're working on making it much clearer, but the "DSMIP"
part of the spec is very clear I think. So read everything else in the  
spec and read the security section sometime next week when I send out  
the new
version. In the meantime read the spec from:
http://www.elevatemobile.com/ietf/draft-ietf-mext-nemo-v4traversal-02.txt

There are two bugs, the Type field in the TLV is 4 bits not 8 and the  
values for the type will only contain GRE.

Hesham

> All this logic

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 8 Apr 2008 07:50:30 -0700 (PDT)

On Wed, 9 Apr 2008, Hesham Soliman wrote:

> =>  What keepalive packet? We're using the BU/BA exchange for keepalive. IKE 
> =>  has its own KA mechanisms.

But, your BU/BA is a UDP encapsulated ESP packet and thats going to
4500 not DSMIP port ? (I did see a mail just now from Pasi clarifying
this part). I'm not clear on two NAT flows, what packets are triggering
the flows towards port 4500 and what is triggering flows towards DSMIP
port.

I will read the spec again and may be that should clear it.

Thanks
Sri

> I know the current security considerations section is not easy to understand 
> and we're working on making it much clearer, but the "DSMIP"
> part of the spec is very clear I think. So read everything else in the spec 
> and read the security section sometime next week when I send out the new
> There are two bugs, the Type field in the TLV is 4 bits not 8 and the values 
> for the type will only contain GRE.
>
> Hesham
>
>
>> All this logic

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 9 Apr 2008 00:55:11 +1000

On 09/04/2008, at 12:50 AM, Sri Gundavelli wrote:

>> keepalive. IKE =>  has its own KA mechanisms.
> this part).

=> ok so you know this is not correct.

> I'm not clear on two NAT flows, what packets are triggering
=> ok. Let me know if you have more comments.

Hesham
>> part of the spec is very clear I think. So read everything else in  
>> the spec and read the security section sometime next week when I  
>> send out the new
>> There are two bugs, the Type field in the TLV is 4 bits not 8 and  
>> the values for the type will only contain GRE.
>>
>> Hesham
>>
>>
>>> All this logic

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Wed, 9 Apr 2008 07:29:49 +0900

Pasi,

Thanks for your correction.
I will wait for the packet diagrams in the next revision:-)

ryuji