Subject: RE: v6 host load balancing

From: Changming Liu <[email-masked]>
Date: Wed, 3 Mar 2004 18:46:14 -0800

Bob,

Thanks for pointing that out. Actually Dave already mentioned that to me
during discussion. The destination address only based load balance will much
better. As I also memtioned to him, that sometimes this approach still has a
problem due to server load balances. For example, picture a network below: a
FTP server farm protected a firewall, and a FTP client also behind its
firewall and there are multiple firewalls in different locations to pretect
the corporate of the client is in. If the client is doing destination load
balance, it may use different corporate firewall as exit point for FTP data
channels. This is because FTP server can tell its client to use different
server for data channels. This still poses big challenge today.    

As I said, I am not completely oppose to load balance. It cab be very
benificial . The problem is the "MUST NOT" keyword. At end of the day, the
admin should have control whether or to use load balance to its network's
benefit, pretty much like ECMP support on the today's router. ECMP by
default is turn on in some vendor's routers. But it offers an option to do
it differently (packet based or flow based, or whatever) or compeltely turn
it off.

Another question I have is why it has to be "MUST NOT". If it is because of
security, it may be rational. If for performance, it is a little too much.
As Pekka pointed out, who knows better than Admin about the network
performance/bottleneck? Definitely, not protocol designers.

Thanks of taking this into consideration. We just need to make a more
thoughtful decision.

Changming

-----Original Message-----
From: Bob Hinden
To: Changming Liu
Cc: [email-masked]
Sent: 3/3/2004 5:48 PM
Subject: RE: v6 host load balancing

Changming,

>As we talked this moning about this issue, we thought that it might be
a
>good idea to discuss this in the mailing list so that others can
express
>their opinion too.
>
>As one of the top 3 firewall/NAT/IDP vendors, our experience with load
>sharing is very bad. It's only good for router-switch only environment.
>For security gateways with any one of the functionalities as I
mentioned
>above, it will create some poblem here or there. This is because it
>needs to see some consecutive packets, if not all, packets in the same
>flow (some applications need to see it in both directions) in order to
>do the correct ALG for NAT, deep packet inspection for idp, network
>based Anti-Virus, which we also start to do. I completely agree with
>your statement that "packet based randomized LS" is bad. For flow based
>LS, we need to be vey careful about the definition of "the flow". Some
>applications have different channels, such as control/signalling and
>data, like FTP, VOIP (H323 or SIP), packets belong to all these
channels
>are better to belong to the same firewall, or some of the above
>functionality may break because it needs to deal with dynamic ports in
>either forward or backward directions.

I would agree with your concern if it worked that way.  The load
balancing 
being proposed is not load balancing on a per packet basis.  It is load 
sharing when the host is about to pick a router when sending to a new 
destination.  Please reread this part of the neighbor discovery 
specification where it describes the conceptional algorithm for
selecting a 
router.  All of the traffic from a host to the same destination will be 
sent to the same router.  Traffic to a different destination will be
sent 
to a different router.  Firewalls and similar devices will not have any 
problem seeing flows.

Regards,
Bob

>The problem we have with the draft is the "MUST NOT" sent to the same
>router statement. At very minimum, it should be "SHOULD" to just leave
>an option for the host to turn it off if it deems necessary.
>
>Thanks for the chat on this topic this morning.
>
>Changming Liu
>Netsceen Technologies Inc.
>
>-----Original Message---
>From: Gregory M Lebovitz
>To: [email-masked]
>Cc: Changming Liu
>Sent: 3/2/2004 9:32 PM
>Subject: v6 host load balancing
>
>Dave,
>Was sitting in the v6 mtg yesterday, and quickly reviewed your doc on
>LB. I
>see some use cases, particularly involving state-keeping gateways, like
>FW
>and IPS devices, for which this is going to cause tremendous havoc.
>Could
>my co-worker, changming and I get together with you for a bit and
>discuss
>to see if we are accurate in our assessment?
>
>perhaps as the pm break today (at ietf reg desk) or for bfast tomorrow?
>
>Pls advise,
>Gregory.
>
>+++++++++++++++++++++++++
>IETF-related email from
>Gregory M. Lebovitz
>Architect - CTO Office
>NetScreen Technologies
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Dave Thaler" <[email-masked]>
Date: Wed, 3 Mar 2004 19:21:41 -0800

Changming Liu writes:
> For example, picture a network below:
> a FTP server farm protected a firewall, and a FTP client also behind
its
> server for data channels. This still poses big challenge today.

If the server is telling the client who to use, then the client is
connecting out for both the data and the control channels.  If they
go out different exit points on the client side, there's no problem
since both connections are initiated from the inside, right?

Can you elaborate more on what the problematic scenario is?

-Dave

---

From: Changming Liu <[email-masked]>
Date: Wed, 3 Mar 2004 21:14:19 -0800

Hi Dave,

>Can you elaborate more on what the problematic scenario is?

Sure. In case of FTP data channel, the data connection was opened by the
server by default! This is called active FTP. To get around this problem,
RFC1579 Firewall-Friendly FTP, documents a passive open, in this case, the
client initiates a connection. For more info, please see RFC 1579.

No matter it is active or passive open, the modem stateful will need to open
the "hole" by listening to the control channel for "port" and "pasv"
comamnd. The hole is opened only on the firewall which is dealing the
control channel. If the data channel goes to another file, apparently this
will not work.

FTP is just a classical example of this dynamic port problem that a firewall
needs to deal with. For VoiP apps such H323 and SIP, similar problem exists
as well and even severe. This is because the signalling channel and media
channel are totally different and destination are usually completely
different.

As a firewall/NAT/IDP company we've been struggling with these issues all
the time. It really adds lots of complexity to the system. I just don't want
to get it worse in IPv6, if not better.

Hope this makes sense to you. 

Changming

---

From: Changming Liu <[email-masked]>
Date: Wed, 3 Mar 2004 22:09:36 -0800

>Yes I'm aware of both modes.  Since you mentioned the server told the
>client
>what server to use, I assumed you were talking about passive mode, which
>is what I was responding to above.

Sorry about not making it clear at the first place. Now we are on the same
page. One minor point: the passive mode was for old proxy firewalls, which
you can hardly find any around.

>You lost me here.  Since the passive open has the connection initiated
>by the client, there is no need for the firewall around the client to
>open a port based on listening to the control channel, right?

Ok, let me try to explain. Even for outgoing connections, the policy needs
to be matched on the firewall. (The firewall policy is just a complicated
version of access list to match 5 tuples, you can think that way if this is
any easy for you). And in most case, only one policy is defined for both FTP
control and data channel. This is for simplity and accounting, logging and
many other reasons, to list few. This is very common for all firewalls, not
just ours. The data channel can not match the policy defined for control
because of its dynamic port. So the firewall needs to open a hole (like a
dynamic policy for data channel).

>> The hole is opened only on the firewall which is dealing the

>I don't see why not.  It's just another outgoing TCP connection.

Is it clear now? If not, please forgive me, a white board discussion may be
better.

> the time. It really adds lots of complexity to the system. I just
don't
> want

Not particularly.  I'm still at the same point I was before where 
elaborating on what the exact scenario that fails is would help.

Thanks,
-Dave

---

From: Changming Liu <[email-masked]>
Date: Wed, 3 Mar 2004 23:50:01 -0800

Suresh,
 
Thanks. That's exactly what's happening.

Changming

-----Original Message-----
From: Suresh Satapati
To: Dave Thaler
Cc: Changming Liu; [email-masked]
Sent: 2004-03-03 ¿AEA 11:43
Subject: RE: v6 host load balancing

Dave,

Lemme give this a try..

> > No matter it is active or passive open, the modem stateful will need
> to
> > open
> > comamnd.

if there is a fw X on the path to the server, fw X may have to look at
the PASV response and open a hole for the subsequent data traffic
from the client. something like a dynamic (created on-the-fly) outbound
access list.

> > control channel. If the data channel goes to another file,
apparently
> this

coz data from the client may be going thru a different device Y, which
is
being blocked by the fw on that device. fw Y doesn't have the hole
to let the traffic go through.

Hope this helps.

--
Suresh