[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

draft-ietf-ipv6-host-load-sharing-01 comments

I have major, fundamental objection to the premises on which this draft is
based on.  However, I think we should be able to find consensus on the way

Fundamental objection

The document assumes that it is always desirable to do
load-sharing with the equivalent routers.  I don't agree with this

If the router's capacity is sufficient so that it can forward all the
traffic sent by its nodes, there is actually very little need for load
sharing.  On the contrary -- sharing load between routers produces
difficult-to-debug scenarios when some destinations (which are distributed
to some routers) fail in mysterious ways while others work just fine.

Due to that, I, as an operator, would not wish to enable load-sharing on
hosts except when I specifically require that kind of functionality.

So, I'd propose that this document does not describe that the hosts MUST
share the load, but rather describes how the hosts MUST behave if they wish
to share the load -- and if turned on by default, require that there 
MUST be a way to toggle load balancing off.  A difficult issue to settle
might be whether to recommend (and if so, how strongly) to enable
load-sharing by default.


[ND] does not require any particular behavior in this respect.  It
specifies that an implementation may always choose the same router
(e.g., the first in the list) or may cycle through the routers in
a round-robin manner.  Both of these suggestions are problematic.

Clearly, always choosing the same router does not provide load
sharing.  Some problems with naive tie-breaking techniques such as
round-robin and random are discussed in [MULTIPATH].  While the
destination cache provides some stability since the determination
is not per-packet, cache evictions or timeouts can still result in
unstable or unpredictable paths over time, lowering the
performance and making it harder to diagnose problems.  Round-
robin selection may also result in synchronization issues among
hosts, where in the worst case the load is concentrated on one
router at a time.

==> I don't think this document clearly described both of the above
suggestion (1st paragraph): but rather how round-robin and random have
issues.  That is, it does not cleatly describe why choosing the same router
is undesirable.

As mentioned in [MULTIPATH], when next-hop selection is
predictable, an application can synthesize traffic that will all
hash the same, making it possible to launch a denial-of-service
attack against the load sharing algorithm, and overload a
particular router.  A special case of this is when the same
(single) next-hop is always selected, such as in the algorithm
allowed by [ND].  Introducing hashing can make such an attack more
difficult; the more unpredictable the hash is, the harder it
becomes to conduct a denial-of-service attack against any single

==> these threats appear to have no clear threat model.  What's the point of
such an attack, as you're already on-link, and can already DoS the routers
there using a number of means?  Introducing hashing doesn't help much here --
you're making an assumption that the attacker is a "friendly" node.  A
maliscious node will just a) send the packets through raw sockets, DoSing
the routers directly, or b) overload both of the routers :).  It seems the
security considerations needs a rewrite... 


==> all the empty lines in the document appear to have been duplicated for
some reason.


The original IPv6 conceptual sending algorithm does not require
load-sharing among equivalent IPv6 routers, and suggests schemes

==> s/IPv6/IPv6 Neighbor Discovery/

Subsequent traffic to the same
destination address continues to use the same router unless there
is some reason to change to a different router (e.g., a redirect
message is received, or a router is found to be unreachable).

==> s/a router/the router/

9.  Full Copyright Statement

==> IPR boilerplate prior to this document would not hurt.

Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6