Subject: RE: Again on port number for DS-MIPv6 (was: [Mip6] MN's address as seen by HA is not its CoA but NAT's address (when NAT))

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 28 Apr 2006 10:22:25 -0700

> > The port numbers can be stored in the MIP6 implementation 
 > after a BU
 > >  is received and reused for normal traffic. You can store 
 > them in the
 > >  relevant BCE.
 > 
 > I thought along the same lines.
 > 
 > Except that (1) the NAT src port number is visible in clear 
 > in UDP and
 > thus spoofable.  I guess it should not only present but 
 > protected too.

=> I disagree. This is not different from any other UDP connection. 
I don't see why we should treat it differently. Of course the IPv6
packet can be protected with IPsec. 

 > 
 > And (2) the port number may change while BU/BAck is not 
 > happening, and
 > depending on its periodicity it may be bad for apps.  I.e. if the
 > BU/BAck happens every 5 minutes then the worse an 
 > application can expect
 > is a break for 5 minutes.

=> My response to this comment and your response to Ryuji is that
you should read the NAT traversal and keepalive section in the draft. 
The default value for keepalives is 110s I think. This is used when the
NAT binding is not refreshed with normal traffic.

 > 
 > Last meeting there was discussion on the mike about what to use
 > for heartbeat keepalive.  Echo request/Reply and figures 
 > like 100seconds
 > were mentioned.  That is still a lot for a streaming app, 
 > not to mention
 > VoIP.

=> If you have an app running then you don't need to send keepalives at
all.
Please read this part in the draft.

 > 
 > Ping could be sent from MN to GW.  But at the same time 
 > there are IPv6
 > RAs sent on the UDP "tunnel" interface.  So Echo Reply might not be
 > needed actually, because the RAs represent the keepalive 
 > from GW to MN.

=> huh? I didn't understand this at all, then I saw your explanation to
Ryuji:

"For MN to be able to simply auto-configure a IPv6 CoA when behind NAT.
How do you propose MN to auto-configure an IPv6 CoA when behind NAT?"

=> You don't do stateless autoconfig. I've assumed that the GW you refer
to is the HA. 
But now I'm confused, what's this GW you refer to?

Hesham

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Apr 2006 20:44:15 +0200

Soliman, Hesham wrote:
>> Except that (1) the NAT src port number is visible in clear in UDP
>>  and thus spoofable.  I guess it should not only present but 
>> protected too.
> 
> => I disagree. This is not different from any other UDP connection. I
>  don't see why we should treat it differently. Of course the IPv6 

(1) in case HA is different than GW, and attacker spoofs that port
number, then the link between HA and GW can be DoS'ed.

(2) in case HA and GW are the same, and depending of the NAT keepalive
mechanism, it is easy for attacker to fake a source port number as
coming from NAT to GW and make it think the NAT state is up.

>> And (2) the port number may change while BU/BAck is not happening,
>>  and depending on its periodicity it may be bad for apps.  I.e. if
>>  the BU/BAck happens every 5 minutes then the worse an application
>>  can expect is a break for 5 minutes.
> 
> => My response to this comment and your response to Ryuji is that you
>  should read the NAT traversal and keepalive section in the draft. 
> The default value for keepalives is 110s I think. This is used when 
> the NAT binding is not refreshed with normal traffic.

I've read it.  If the BU/BAck happens every 110s and the NAT changed src
port right at the beginnning of this 110s period, then the IPv6 app on
GW streaming to MN will suffer a 110s delay until next BU/BAck.  Would
you agree?

Know that UDP traffic through NAT originating from MN - even every
millisecond, does not guarantee NAT keeps that src port stable.  Traffic
from GW through NAT doesn't either.

>> Last meeting there was discussion on the mike about what to use for
>>  heartbeat keepalive.  Echo request/Reply and figures like 
>> 100seconds were mentioned.  That is still a lot for a streaming 
>> app, not to mention VoIP.
> 
> => If you have an app running then you don't need to send keepalives
>  at all.

That's plain wrong.  Again, even if there is traffic, the NAT src port
may change with a periodicity that is not detectable.  So, again, if
BU/BAck happens every 110s and app from GW streams to MN through NAT
then it is very probable that the app will suffer 110s interruptions.

> Please read this part in the draft.

I did.  Please allow me to return the recommendation: please play more
with deployed NATs before writing text about them.

>> Ping could be sent from MN to GW.  But at the same time there are 
>> IPv6 RAs sent on the UDP "tunnel" interface.  So Echo Reply might 
>> not be needed actually, because the RAs represent the keepalive 
>> from GW to MN.
> 
> => huh? I didn't understand this at all, then I saw your explanation
>  to Ryuji:
> 
> "For MN to be able to simply auto-configure a IPv6 CoA when behind 
> NAT. How do you propose MN to auto-configure an IPv6 CoA when behind
>  NAT?"
> 
> => You don't do stateless autoconfig.

Why not?  Stateless auto-config is a quick and widely implemented way of
auto-configuring an address.  How else would MN auto-configure an IPv6
address when MN behind NAT?

> I've assumed that the GW you refer to is the HA. But now I'm 
> confused, what's this GW you refer to?

Simply put because it is good to have the GW supporting NAT traversal
and IPv6/IPv4 conversion separated from the HA doing MIP6.

Even if HA were co-located with the GW, one surely doesn't want the NAT
UDP "tunnel" to be a home link for all MNs managed by that HA.  That HA
may have some Ethernet links, and it could serve normal MNs on that
links too.  I hope we both assume UDP "tunnel" is a virtual tunnel
interface, do we?

Why would one co-locate the NAT/GW/IPv4-IPv6 conversions with the MIP6 HA?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Apr 2006 20:45:19 +0200

> => I disagree. This is not different from any other UDP connection.

Hesham, wasn't a UDP socket "connectionless"?  What's this UDP
connection term?

Alex