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 12:00:28 -0700

> > => 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.
 > 
 > (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.

=> What GW are you talking about???? 

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

=> No. There is no change in the port numbers if you maintain
the NAT bindings. I don't know what NAT implementation you have in
mind but it sounds like a broken one.

 > > => If you have an app running then you don't need to send 
 > keepalives
 > >  at all.
 > 
 > That's plain wrong.  

=> No, it's right.

  Again, even if there is traffic, the 
 > NAT src port
 > may change with a periodicity that is not detectable.  

=> That's nonesense. If a NAT changes its bindings despite ongoing
traffic 
then the implementation is broken.

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

=> It doesn't! So may be you read the draft but I don't think you
understood the scenarios. Stateless applies to the CoA, in this scenario
the CoA is a v4 address.

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

=> That's not in the draft today so I don't know where you
got that from. 

Hesham

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Apr 2006 21:53:40 +0200

Soliman, Hesham wrote:
>> 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.
> 

The one different than HA.  HA would run only IPv6 and GW would run both
v4 and v6.  This would be very helpful.  I don't see why not.  Much
infrastructure is IPv6 exclusively today.  That was said many times,
would you agree?

>> 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?
> 
> => No. There is no change in the port numbers if you maintain the NAT
>  bindings.

Well, that's plain wrong again.  There's no way to maintain NAT
bindings, even with running traffic.  Try it.  Some NAT/firewalls are
more gentle than others.  Try some tough ones.  The only possibility is
to dynamically detect them.

You never know the sauce a NAT is doing to ensure connectivity.

> I don't know what NAT implementation you have in mind but it sounds 
> like a broken one.

A "broken" NAT implementation???  As if there are "right NAT
implementations"?  C'mmon... What's a "right NAT implementation" that is
not broken?  Every fw admin configures his/her admin at his/her own will.

>>> => If you have an app running then you don't need to send

No, it's wrong.  Try it.  Otherwise how can I prove it to you?

>> Again, even if there is traffic, the NAT src port may change with a
>>  periodicity that is not detectable.
>> 
> 
> traffic then the implementation is broken.

Again, what's a "broken NAT" implementation?  Is there a right one?  I'm
afraid we're not clear on what a NAT is.

This may turn into having a DS-MIPv6 section specifying what assumptions
we make on NAT.  And/or whether DS-MIPv6 will have any software
components implemented on NAT.

>> 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?
> 
> understood the scenarios. Stateless applies to the CoA, in this 
> scenario the CoA is a v4 address.

Why not having an IPv6 CoA?  Why not sending IPv6 RAs over the tunnel?
I've tried, it works.

>> Simply put because it is good to have the GW supporting NAT 
>> traversal and IPv6/IPv4 conversion separated from the HA doing 
>> MIP6.
> 
> => That's not in the draft today so I don't know where you got that 
> from.

Let's say I've silently invented it.  Anything wrong with that?

Alex

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 29 Apr 2006 00:35:29 +0200

Hi Alexandru,

on 2006-04-28 21:53 Alexandru Petrescu said the following:

> bindings, even with running traffic.  Try it.

No.

You try it.

We've tried extensively, and your statement doesn't match the reality
we've observed.

>  Some NAT/firewalls are

Thank you for the lecture.  I've written RFC 3519, implemented it,
tested the code, deployed it.

That you're throwing out statements which is contrary to everything
I've seen doesn't convince me that I should throw out all the experience
I have.

Sorry, but no go.

The only way you're going to get some credibility here is to provide
actual measurements of actual named products to back up your allegations.

	Henrik