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

RE: I-D ACTION:draft-ietf-ipv6-host-load-sharing-02.txt



Coming back to the old thread, sorry for not responding earlier..

Also comments regarding the SHOULD/MUST/MAY debate below.  I think we 
should be first clearer to _what_ we're putting on these keywords.

On Thu, 6 May 2004, Dave Thaler wrote:
> Pekka Savola wrote:
> > 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
> 
> To summarize the other discussion on the list on this topic:
> A number of other folks (Changming Liu, Tim Chown, and Suresh Satapati)
> also argued on the list against the MUST, while others (such as Bob
> Hinden) have argued for it on and off the list.
> 
> In draft-02, I have changed the MUST to a SHOULD as a result.

I'm still having the difficulty in understanding the paragraph:

=========
When a host chooses from multiple equivalent routers, it SHOULD
support choosing using some method which distributes load for
different destinations among the equivalent routers rather than
always choosing the same router (e.g., the first in the list).
Furthermore, a host that does attempt to distribute load among
routers SHOULD use a hash-based scheme, such as those described in
[MULTIPATH], which takes the destination IP address into account.
=========

.. this seems to say, in essence:

1) "you SHOULD implement host load sharing, whether you turn it on is
out of scope", and
2) "even if you choose not to share the load, you SHOULD use a 
hash-based scheme".
 2.b) ".. and the hash-based scheme should take dest IP into account"

If the intent if 1) is that and not "you SHOULD turn on load 
sharing", it's fine but could maybe be clarified by adding e.g. the 
following after the first sentence:

  This memo takes no stance on whether the support for load sharing
  should be turned on or off by default.

As for 2), it took a while to figure out _where_ to use hash-based
scheme would be used.  I think it would be better to add a note about
a tie-breaker this to e.g.:

Furthermore, a host that does attempt to distribute load among routers
SHOULD use a hash-based scheme for choosing a single router to be
used, [...]

As for 2.b), it seems if you take destination IP address into account 
and require hash-based mechanism, you're just creating the same kind 
of load sharing.  For tie-breaking purposes, it's unnecessary to 
consider the destination address, right?  So, I'd suggest removing the 
", which .." -part from the end of the last sentence.

> > substantial
> > -----------
> > 
> > [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.
> 
> Clarfied by changing second sentence to
> | Some problems with load sharing using naive tie-breaking techniques 
> | such as round-robin and random are discussed in [MULTIPATH].

This only addresses one part of my comment (sorry, should have been 
clearer).  It still does not state why exactly the load-sharing is 
desirable in the first place, and what are the reasons why it might 
not be desirable.

Suggestion: reword:

It is typically desirable when there is more than one equivalent
router that hosts distribute their outgoing traffic among these
routers.  This shares the load among multiple routers and provides
better performance for the host's traffic.

to something like:

It is typically desirable when there is more than one equivalent
router that hosts distribute their outgoing traffic among these
routers.  This shares the load among multiple routers and provides
better performance for the host's traffic.  On the other hand, the
load sharing can be undesirable in the situations where sufficient
capacity is available through a single router and the traffic patterns
could be more predictable by using a single router; in particular,
this helps to diagnose connectivity problems upstream from the
first-hop routers.

.. this gives a more balanced view of the need for load sharing.
 
> > 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 router.
> > 
> > ==> 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?
> 
> Not quite true.  A remote attacker can conduct such an attack too, as
> long as he has the ability to spoof/use a bunch of different source
> addresses.
> Added the sentence:

> + This can even be done by a remote application that can cause a host to
> + respond to a given destination address.
> 
> However, you are correct in that there's not really much of a threat
> there, since there are other ways of doing the same thing.  But it seems
> better than claiming there's no security issues whatsoever.

Yes, it's better to say something than nothing at all, but I do not 
think the current text says enough.. below..

> > 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...
> 
> With the above clarification, I think the text is sufficient.  If you
> feel otherwise, please submit proposed text.

Yes, I don't think the text says enough.  Add a paragraph:

The added protection of load sharing is not significant: hosts can
overload the routers on directly especially if they're on-link;  if
on-link, hosts can circumvent the sending algorithm by using "raw
sockets"; if the host is capable of taking down one router, the load 
sharing only requires double the capability, and as a consequence, 
both routers can be taken down simultaneously by a denial-of-service 
attack.

 
> > editorial
> > ---------
> > 
> > ==> all the empty lines in the document appear to have been duplicated
> > for some reason.
> 
> I don't see this.  Perhaps a CR/LF issue?

Probably, possibly by the secretariat as the current document has 
CR/LF's, but not duplicated empty lines.

> > Abstract
> > 
> > The original IPv6 conceptual sending algorithm does not require 
> > load-sharing among equivalent IPv6 routers, and suggests schemes
> > 
> > ==> s/IPv6/IPv6 Neighbor Discovery/
> 
> Disagree.  Although it's in the ND spec, the relevant part of the
> algorithm here is not specific to links which actually run full ND.
> Hence I find it less confusing the way it is.  It's a trivial point in
> any case.

I'm fine with this in the abstract.
 
-- 
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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------