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

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.

   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.

       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?

  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....")