A Lightweight UDP Transfer Protocol for the Internet Registry Information Service
draft-ietf-crisp-iris-lwz-08

[Ballot discuss]
Section 3.

Each IRIS-LWZ query or response is contained in a single UDP packet.
  Servers MUST be prepared to accepted packets as large as 4000 octets,
  and clients MUST NOT send packets larger than 4000 octets.

What does one do if ones request or even worse response is larger than 4K?
Please define what actions should be taken in these cases. I am especially interested in to have a definition on how the responder should behave if the request results in a response that is larger than 4K. Yes, if one continues to read one can work out that one needs to send a size information in this case.

A requesting entity should try to perform Path MTU discovery between itself and the responder. To me it seems possible that the sender could try classic style. It could also keep track of what size has resulted in fragmentation. A good question is if one could actually use the transaction ID to determine if one can use (draft-ietf-pmtud-method-11) to determine what MTU that exist.

Section 4.

I think this document is missing a few important pointers about the usage of UDP as transport protocol. The LZW transport must have mechanisms in place that ensure that it is TCP-friendly and thus does not cause congestion without checks and are sharing bandwidth fairly (on the same magnitude and a reasonable short timescale) with TCP flows.

This is actionable in several ways as I see it:

1. Insert a limitation on not having more than a single outstanding request. This is definitely TCP-friendly but is more limiting to performance than what TCP can achieve. However as TCP is available as option. Switching to using TCP at the point when you have the need for more than a single request outstanding at the same time seems very reasonable.

2. Define a real congestion response into the LZW protocol. So that it fulfills TCP friendliness. However as CRISP works over TCP, I don't see the point in this. But if that is what you really need, then it can be done. 

There is also need to have better guidance on when this transport is reasonable to use. In addition to the payload size restrictions it also needs to consider the request behavior of an application. If the application is naturually rate limiting itself then it seems to be a better choice than if the application can theoretically throw any number of request at a server.

Using the transaction ID as a sequence number for request would be possible but would probably result in loss of all the intended security functions of it. However the security potentially provided by the transaction ID seems anyway very week due to the small number of bits used.

[Ballot comment]
I fully agree with Magnus' DISCUSS and will let him hold it. This protocol is only "lightweight" because it lacks basic features, such as even rudimentary congestion control, retransmission handling, path MTU awareness, etc. All these issues have been brought up during the IETF last call, but weren't addressed.

This protocol requires major changes before it can be published. Given that a TCP-based transport for CRISP has also been defined, I am personally unconvinced that adding all the missing features to an UDP-based transport is useful. It is also likely that CRISP lacks the required transport expertise.

[Ballot discuss]
Section 9., paragraph 1:
>    [1]  Deutsch, P., "DEFLATE Compressed Data Format Specification
>          version 1.3", RFC 1951, May 1996.

  DISCUSS: Is a DOWNREF (PS->Informational).


Section 9., paragraph 10:
>    [10]  Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers",
>          RFC 1166, July 1990.

  DISCUSS: Is a DOWNREF (PS->Informational).

[Ballot comment]
First, I agree with what Magnus says in his Discuss.

I would like to add that the rules in Section 4
appear to assume that it is always desirable
to send 4K UDP messages. Please consider a
more aggressive set of rules where compression
is applied so that packets in general would fit
in MTU, if possible. And add a discussion of the
impacts of fragmentation for this protocol.

Also, I am concerned about the creation of
new protocols that can be used in a
reflection attact similar to what we have
seen for DNS.

[Ballot comment]
0xFFFF, servers MUST us a transaction ID of 0xFFFF and send a

s/us/use

In the figure located in section 3.1.2, you may wish to call the "header" "payload header" to be
more consistent with the text (and a bit more descriptive).

Why only allow the DEFLATE algorithm? Perhaps allow the reserved bit 5 to be part of an algorithm identifier?

Where does 4000 bytes come from?

[Ballot comment]
By randomizing the
  transaction IDs being used (i.e. not using sequential numbers),
  attackers flooding the network with a large amount of spoofed packets
  have a lesser chance of succeeding with the attack.

This seems under-analyzed. "not sequential" is not the same thing
as "randomized". "lesser chance" is not a useful metric.

  1.  If the transaction ID in the corresponding request could not be
      read due to truncation,

How can truncation occur that early in the packet?

Conversation re Gen-ART review by Spencer Dawkins:

On 2007-01-24 18:14, Andrew Newton wrote:
>
> On Jan 24, 2007, at 12:02 PM, Spencer Dawkins wrote:
>> - Sequential Transaction IDs are still SHOULD NOT in 3.1.1, but the
>> updated Section 8 now justifies SHOULD and adds a new MUST for
>> implementers who are violating the SHOULD NOT. I'm not asking for
>> 3.1.1 to be MUST NOT, but I'm really curious why the requirement isn't
>> "MUST NOT be sequential", and I don't see any explanation about why
>> MUST NOT was not chosen.
>
> If an implementation does pick sequential numbers (i.e. violates the
> SHOULD), they will still be able to interoperate.  If they break this
> rule, they ought to know what they are doing and the consequences for
> it.  Informing implementers that running with scissors is a good thing,
> legislating against it is not.
>
>> - New text in Section 4 defines retransmission behavior, but initial
>> RTO of one second and subsequent RTO doubling is SHOULD, not MUST,
>> with no explanation about why an implementor might choose to violate
>> the SHOULD. I'd love to know why this protocol is "special" - any
>> TCP-based application protocol would be doing something like what this
>> protocol has as a SHOULD...
>
> Essentially, the same argument applies here.  Though I will admit that a
> violation of this SHOULD might have consequences on others.

[Ballot comment]
One comment from the SecDir Review by Rob Austein was ignored in the
  recent update:
  >
  > Section 4: Recommendation (1) says that IRIS-LWZ is insecure. :)
  > Seriously, this recommendation should be brought into line with
  > the first paragraph of the Security Considerations, which gives a
  > more useful explanation than this recommendation does.

  When Rob took a look at -07, he came up with another suggestion:
  >
  > I'd drop the last sentence of the security considerations
  > ("Client implementers MUST take appropriate measures when ignoring
  > this advice"), it adds nothing, and the use of normative language
  > here is confusing.  Client implementors who ignore your advice MUST
  > do, um, what, exactly?  You don't say. ("We're now at Threat Level
  > Orange but you'll have to work out what to do about it on your own,
  > have a nice day....")

[Ballot discuss]
Section 3.

Each IRIS-LWZ query or response is contained in a single UDP packet.
  Servers MUST be prepared to accepted packets as large as 4000 octets,
  and clients MUST NOT send packets larger than 4000 octets.

What does one do if ones request or even worse response is larger than 4K?
Please define what actions should be taken in these cases. I am especially interested in to have a definition on how the responder should behave if the request results in a response that is larger than 4K. Yes, if one continues to read one can work out that one needs to send a size information in this case.

A requesting entity should try to perform Path MTU discovery between itself and the responder. To me it seems possible that the sender could try classic style. It could also keep track of what size has resulted in fragmentation. A good question is if one could actually use the transaction ID to determine if one can use (draft-ietf-pmtud-method-11) to determine what MTU that exist.

Section 4.

I think this document is missing a few important pointers about the usage of UDP as transport protocol. The first one is in regards to reliability. There is no discussion regarding what happens if one lose either the request or the response. Some consideration on retransmission timers seems necessary and back off of these.

The second issue is about congestion control and rate limiting the number of requests. There needs to be monitoring of packet losses. That needs to affect the current rate of the requests sent. This means defining some reasonable response to congestion when experienced.

There is also need to have better guidance on when this transport is reasonable to use. In addition to the payload size restrictions it also needs to consider the request behavior of an application. If the application is naturually rate limiting itself then it seems to be a better choice than if the application can theoretically throw any number of request at a server.

Using the transaction ID as a sequence number for request would be possible but would probably result in loss of all the intended security functions of it. However the security potentially provided by the transaction ID seems anyway very week due to the small number of bits used.

[Ballot comment]
By randomizing the
  transaction IDs being used (i.e. not using sequential numbers),
  attackers flooding the network with a large amount of spoofed packets
  have a lesser chance of succeeding with the attack.

This seems under-analyzed. "not sequential" is not the same thing
as "randomized". "lesser chance" is not a useful metric.

  1.  If the transaction ID in the corresponding request could not be
      read due to truncation,

How can truncation occur that early in the packet?

IANA Last Call Comment:

Upon approval of this document IANA understands that there are three actions it
must complete.

First, IANA will register a new URI scheme in:
http://www.iana.org/assignments/uri-schemes.html

The name of the new URI scheme will be:
iris.lwz

Second, IANA will allocate a well known port number for UDP
for iris.lwz.

Third, IANA will register a new S-NAPTR Application Protocol
Tag whose tag is:
iris.lwz

IANA understands that these three actions are the only IANA
actions required upon approval of the document.