Re: [MEXT] TLV header in DSMIP

[RYUJI WAKIKAWA <ryuji.wakikawa at gmail.com>]

Hi Sri,

On 2008/04/08, at 1:11, Sri Gundavelli wrote:
> Hi George,
>
>> 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
>>
>
> 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.

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).

> 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 ?

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

> Also, the two flows needs to be tied for removing the data path
> upon terminating the MIP session.
>
> Thanks
> Sri
>
>
>
>
>> Did I miss the point of your question?
>>
>> Regards
>> George
>>
>> On Mon, Apr 7, 2008 at 3:55 PM, Sri Gundavelli
>> <sgundave at cisco.com> wrote:
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Pasi.Eronen at nokia.com [mailto:Pasi.Eronen at nokia.com]
>>>> Sent: Monday, April 07, 2008 3:06 AM
>>>> To: sgundave at cisco.com
>>>> Cc: mext at ietf.org
>>>> Subject: RE: [MEXT] TLV header in DSMIP
>>>>
>>>>
>>>> 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
>>>>
>>>>> -----Original Message-----
>>>>> From: ext Sri Gundavelli [mailto:sgundave at cisco.com]
>>>>> Sent: 07 April, 2008 07:12
>>>>> To: 'Hesham Soliman'
>>>>> Cc: mext at ietf.org; Eronen Pasi (Nokia-NRC/Helsinki)
>>>>> Subject: RE: [MEXT] TLV header in DSMIP
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>>>>>> Sent: Saturday, April 05, 2008 1:32 AM
>>>>>> To: Sri Gundavelli
>>>>>> Cc: mext at ietf.org; Pasi.Eronen at nokia.com
>>>>>> 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 ?
>>>>>>
>>>>>> => 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
>>>
>>> _______________________________________________
>>> MEXT mailing list
>>> MEXT at ietf.org
>>> https://www.ietf.org/mailman/listinfo/mext
>>>
>
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext