Subject: [Tsvwg] draft-ietf-tsvwg-quickstart-00: Consideration of QS NONCE.

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 17 Aug 2005 09:09:08 +0100

This email briefly sets out some thoughts on the usage and potential of the
QS NONCE - following a call at the Transport Area meeting of the last IETF
meeting. Existing QS mechanisms describe how to get good assurance that
routers are on the Path, and to determine their response. A method using a
NONCE is proposed as a way to statistical verification of the receiver's
response.

A) Is NONCE good?
-----------------

My discussion of the value of a QS NONCE will look at two issues. (I'm not
sure these exactly match that expressed in the draft, and there may be other
interpretations.)

Problem 1 - A receiver can lie about the QS message it receives and return a
forged value to the sender: This attack only requires knowledge of the
default sender choice of the initial QS value. I agree with the suggestion
that it **is** likely that senders will select this value in a consistent
(predictable) way. (e.g. Implementations may be simpler if they use a
default value, and in many cases it will be hard to pre-judge the required
value before a session is established. Section 4-6-1, para 2, seems to
suggest a default value for a QS request, p21).

Problem 2 - The incentive in the current QS method is that it always
benefits a sender to ask for as much QS capacity as possible. In general, I
am concerned at algorithms that promote greed. Greed tends to imply
potential over-commitment in the network (which may be unused, or
subsequently reduced along the path as the negotiation proceeds). I would
have liked to have seen a mechanism to provide an incentive for the sender
to choose a more modest size. This would be good for stability.

* The proposed QS NONCE described in the draft is a partial remedy for (1).
But it does not verify a downward-negociated value (the receiver could lie
about this and forge a QS value one size smaller than the sender initial QS
request). That is, it allows a forging receiver to advertise a value lower
than the "known" sender value without regard to the NONCE value.

* The proposed method satisfy (2), unless there is a *penalty* against a QS
response without a valid NONCE (or a downward-negotiated reduced QS
response). Is there any incentive for a receiver to choose an appropriate
value?

* The method lends itself to optimisation using a cache of previously
*successful* approved QS request (i.e. with a valid NONCE). The method could
be as currently done for PMTU by the PMTUD algorithm, although the
information could be more volatile (i.e. could change rapidly with time, in
some scenarios).

I think these issues are important, and that unless other methods are found,
I would support this use of a NONCE. I believe the method also lends itself
to extension (see a proposal in (B) below).

B) Thoughts on a more conservative NONCE operation.
---------------------------------------------------

Following on from (A), I suggest consideration of a different safe
(conservative) method, that is based on the NONCE method in the draft.
Comments/suggestions/issues on this would be welcome!

My proposal is that the sender could be modified to only accept a QS
response as a value for modified congestion behaviour, when the response has
a valid NONCE. 

An invalid NONCE would allow the receiver to use the down-ward negotiated
value that was returned, but only as "advisory" of what may be accepted by
routers.  In the most conservative modified scheme, the sender should try
probing again end-to-end with the new returned QS value .... by using QS a
second time. This should be successful, and return the same value (albeit
one RTT later) but with a valid NONCE. This would then be used.

This method has a penalty of slower ramp-up (one RTT delay) when there is a
router wishing to negotiate down-wards. When the QS value is viable first
time, it is immediately used. An incentive is introduced for the sender not
to over-estimate its needs.

C) Zero NONCE value?
--------------------
One thing to be considered when using a QS NONCE, is the need for routers to
assign a random number to an "erased" nonce. This sounds like it does not
lend itself to a simple implementation (router hardware/software engineers
may tell you different).  If it is a problem, is it possible for a
negotiating router to simply reset the nonce value to zero instead. There
would be some implications:
+ The sender would have to choose a non-zero nonce for the QS probes it
sends (simple to implement).
+ A down-stream device would immediately know the nonce had been erased (is
this an issue?).
+ The nonce properties become 1/15 rather than 1/16.

Thoughts?

Best wishes,

Gorry
(please cc [email-masked])

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

---

From: Sally Floyd <[email-masked]>
Date: Mon, 29 Aug 2005 08:22:10 -0700

>My quick comment is that I don't think the smaller request in the
>re-probe mitigates this at all because at some point in the network the
>re-probe is not, in fact, "smaller" but is really the same size.

Yep, I agree.