Re: [MEXT] TLV header in DSMIP

["George Tsirtsis" <tsirtsis at googlemail.com>]

Hi again ...inline...

On Mon, Apr 7, 2008 at 5:11 PM, Sri Gundavelli <sgundave at cisco.com> 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.
>

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.

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

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.

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

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

BR,
George
>
>
>
>
>
>
>  > 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