Subject: Re: Last Call: 'A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service' to Proposed Standard (draft-ietf-crisp-iris-lwz)

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 Aug 2006 15:46:56 +0200

The IESG wrote:

> <draft-ietf-crisp-iris-lwz-06.txt> as a Proposed Standard

Some general questions about this draft:

1 - Has anybody implemented it ?
2 - If so, do test servers exist for client developers ?
3 - Why is LWZ limited to UDP, desperately trying to solve
    various size issues with delated XML and other tricks ?
4 - Could a server just offer a whois interface and be done
    with it ?

Other nits:  Reference [5] RFC 2396 isn't state of the art.
[2] Unicode version 3 is unclear, XML 1.0 third ed. apparently
uses 3.2 (?), and it requires UTF-8 and UTF-16, as repeated in
the I18N considerations (chapter 5).  Maybe the RFCs for UTF-8
and UTF-16 should be referenced if that's explicitly mentioned,
that boils down to "MUST accept (and for UTF-16 send) a BOM".

s/draft-ietf-crips/draft-ietf-crisp/ and s/-00// (that typo is
also in the common-transport draft pointing back to [9} LWZ).

s/3891/3981/ in both drafts.

Example A.1 contains elements <salt> and <md5>, what is this ?

Frank

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

---

From: Andrew Newton <[email-masked]>
Date: Tue, 15 Aug 2006 11:40:31 -0400

> 1 - Has anybody implemented it ?

Yes. See http://iris.verisignlabs.com/blojsom/blog/iris/

> 2 - If so, do test servers exist for client developers ?

Yes.  See above.  Additionally, see the archives of the CRISP wg.

>     various size issues with delated XML and other tricks ?

TCP is handled by XPC and BEEP.  But for very short and quick answers (and 
lots of them, such as domain availability checks) UDP is better.  Don't know 
what you mean by tricks, but the deflation is optional.

> s/3891/3981/ in both drafts.

All good catches.  Thanks.

> Example A.1 contains elements <salt> and <md5>, what is this ?

Those are in the http://example.com namespace, and this is just an example 
extension.  Perhaps it would be clearer if the example just had text content 
saying "example extension".

-andy

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Tue, 15 Aug 2006 16:59:35 +0200

Frank,

> 1 - Has anybody implemented it ?

Yes, we have implemented it (as of ID-version 05). VeriSign, too. I've 
heard there is at least another implementation.

> 2 - If so, do test servers exist for client developers ?

I can't provide (yet) with a link from us. VeriSign's got an open source 
implementation:
http://iris.verisignlabs.com/
Both, IRISserv and FlowerBed include an LWZ-transport implementation, the 
latter being more current, I think.

> 4 - Could a server just offer a whois interface and be done

I don't understand this question.

> Example A.1 contains elements <salt> and <md5>, what is this ?

The parent element (<bag>) is explained in RFC3981, the contents of the 
parent are not defined by IRIS. Read section 4.4 of that RFC for 
clarifications.

Best regards,
Marcos Sanz

---

From: Ted Hardie <[email-masked]>
Date: Tue, 15 Aug 2006 10:03:06 -0700

>4 - Could a server just offer a whois interface and be done

Andy and Marcos seem to have tackled the other issues you
raise, but I'd like to point out the following from the charter:

>Specific topics that are NOT goals of this WG are:
>
>- Backwards compatibility with existing administrative directory
>services such as WHOIS.

Servers can, of course, offer whatever services they like.
Two of the main problems driving the development of
CRISP's protocols were, however, the lack of interoperability
and security in whois.  The decision not to be base further
work on it was made at the beginning of the WG.

				Ted Hardie

---

From: Sam Hartman <[email-masked]>
Date: Tue, 15 Aug 2006 23:40:41 -0400

I notice that this transport provides no authentication of the data
that is retrieved.

The security considerations needs to discuss the potential attacks if
an attacker modifies this public data.  The security considerations
section also needs to point to best practice for avoiding UDP
reflection attacks.  It is not good enough to say "Do what other
people do."

In both cases these may be included by reference.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 16 Aug 2006 08:47:04 +0200

Marcos Sanz/Denic wrote:
 
> open source implementation:  http://iris.verisignlabs.com/

Thanks, that should help client developers to figure it out.

> I don't understand this question.

I'm not exactly happy with LWZ, your old (2004) whois-srv draft
was more in a direction I'd like.  What I really want sometimes
is a working address, or _incorrect_ data, because it's always
about abuse, and for "WDPRS" or similar I need incorrect data.

> The parent element (<bag>) is explained in RFC3981

Yes, that's how I stumbled over the typos in the references -
trying to find a source for the <salt> and <md5> example... :-)
  
> Read section 4.4 of that RFC for clarifications.

Admittedly I looked only at the examples in 3981.  With 4.4 it
is clearer, example A.1 in LWZ is apparently a second query to
another server, after the client got a "bag" elsewhere before.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 16 Aug 2006 09:11:30 +0200

> TCP is handled by XPC and BEEP.

But those are the (complex) protocols for more serious tasks
than only "whois" queries, updates / confidential data / etc.

If LWZ would allow TCP all its "size considerations" would be
harmless.  I never tried / considered "whois" over UDP so far.

> for very short and quick answers (and lots of them, such as
> domain availability checks) UDP is better.

Yes, but that's not the application I'm interested in.  It's
fine that UDP is supported for those who want short and quick
answers, selling domains or whatever they do.

> Don't know what you mean by tricks, but the deflation is
> optional.

What I meant is that clients can signal the maximum response
size they can handle, and they can signal support for deflated
responses.  Based on that info servers then either send what
the client wanted, or indicate which size would be required.

IMO that's "tricky", making the best of UDP that's possible.
But "just use TCP" would be simpler.

 [salt and md5]
> just an example extension.  Perhaps it would be clearer if
> the example just had text content saying "example extension".

No, it's fine after Marcos told me that it's explained in 3981
section 4.4.  Maybe add the info, that the content of the "bag"
is some opaque data the client got before from another server -
if I now understod it correctly.

Frank

---

From: Andrew Newton <[email-masked]>
Date: Wed, 16 Aug 2006 11:55:58 -0400

Harald Alvestrand wrote:
> There's nothing in the document that says "if you want to send 4000 
> requests, and 70 out of the first 100 get lost, you should slow down 
> your sending rate to that server".

I just checked the simple user-drive, cli client I wrote and it doesn't 
retransmit at all (perhaps not the best UI experience).  I'll check with the 
other implementers to see what they did.  But you are right, guidance needs 
to be given, especially if these things get embedded into automated scripts.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 16 Aug 2006 12:07:06 -0400

> In both cases these may be included by reference.

Sam,

For the second case, you are referring to BCP 38, correct?  This was 
mentioned on the wg list by William Leibzon, and should have been 
incorporated into the draft.  Thanks for noting this.

For the first case, which reference were you thinking about?

-andy

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Aug 2006 12:31:26 -0400

>>>>> "Andrew" == Andrew Newton <[email-masked]> writes:

    Andrew> Sam,

    Andrew> For the second case, you are referring to BCP 38, correct?
    Andrew> This was mentioned on the wg list by William Leibzon, and
    Andrew> should have been incorporated into the draft.  Thanks for
    Andrew> noting this.

I don't know what I'm referring to.  I don't know what state of the
art is here.

---

From: kent crispin <[email-masked]>
Date: Wed, 16 Aug 2006 10:06:07 -0700

On Wed, Aug 16, 2006 at 11:55:58AM -0400, Andrew Newton wrote:
> retransmit at all (perhaps not the best UI experience).  I'll check with 
> the other implementers to see what they did.  But you are right, guidance 
> needs to be given, especially if these things get embedded into automated 
> scripts.

s/if/when/

-- 
Kent Crispin 
[email-masked]    p: +1 310 823 9358  f: +1 310 823 8649

---

From: Lars Eggert <[email-masked]>
Date: Wed, 16 Aug 2006 19:02:22 +0200

Hi,

On Aug 16, 2006, at 17:55, Andrew Newton wrote:
> Harald Alvestrand wrote:
>> There's nothing in the document that says "if you want to send  
>> 4000 requests, and 70 out of the first 100 get lost, you should  
>> slow down your sending rate to that server".
>
> I just checked the simple user-drive, cli client I wrote and it  
> doesn't retransmit at all (perhaps not the best UI experience).

the issue isn't with retransmissions. If - to use Harald's example -  
no reply arrives for 70 out of 100 issued requests, this is a pretty  
strong indication that the server or something on the way to or from  
the server is congested. In response to such a signal, the request  
rate should be reduced.

One reason is that injecting traffic at a higher rate than the  
network can handle is obviously bad. A second reason is that assuming  
that the sender is interested in receiving responses, it should  
really try to issue them at a rate that attempts to maximize the  
response rate.

At which point we're basically talking about congestion control. I'd  
really like to avoid redesigning congestion control mechanisms inside  
application-layer protocols.

Thus, have you looked at DCCP as a transport? It's basically a  
congestion-controlled UDP. Unlike UDP, it requires a handshake, so  
there is some overhead, but for larger request loads this should be  
negligible. And it might be OK to keep using UDP for very small  
request loads, where the overhead would matter.

I'd also like to bring up a second, somewhat related issue. Section 3  
says:

    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.

and Section 4 says

    2.  If a request is less than or equal to 4000 octets, send it
        uncompressed.

    3.  If a request can be compressed to a size less than or equal to
        4000 octets, send the request using compression.  Otherwise use
        another transfer protocol.

Sending packets larger than the minimum MTU of ~512 bytes is likely  
to cause fragmentation, which can significantly reduce transmission  
efficiency and reliability [1] and cause data corruption [2].

Fragmentation becomes more likely as packets get larger. With packets  
of 4000 bytes (where does this number come from, anyway?),  
fragmentation is pretty much guaranteed across most links. If IRIS- 
LZW messages are expected to be larger than ~512 bytes in general,  
the use of a transport protocol other than UDP is probably a good idea.

Lars

[1]   Kent, C. and J. Mogul. Fragmentation Considered harmful.
       Proc. ACM SIGCOMM, Vol. 17, No. 5, October 1987.

[2]   Heffner, J., M. Mathis and B. Chandler. Fragmentation Considered
       Very Harmful. Internet Draft draft-heffner-frag-harmful-02,
       Work in Progress, June 2006.
-- 
Lars Eggert                                     NEC Network Laboratories

---

From: Andrew Newton <[email-masked]>
Date: Wed, 16 Aug 2006 14:04:23 -0400

Lars Eggert wrote:
> the issue isn't with retransmissions. If - to use Harald's example - no 
> reply arrives for 70 out of 100 issued requests, this is a pretty strong 
> indication that the server or something on the way to or from the server 
> is congested. In response to such a signal, the request rate should be 
> reduced.

I'm not disagreeing.  I was merely pointing to one reason why this never 
came up as feed back from implementations.

> I'd also like to bring up a second, somewhat related issue. Section 3 says:
> 
>    Servers MUST be prepared to accepted packets as large as 4000 octets,
> Sending packets larger than the minimum MTU of ~512 bytes is likely to 
> cause fragmentation, which can significantly reduce transmission 

This section came about as feedback from a server implementation where the 
implementor wanted to know how big of a buffer to reserve.  To answer your 
question below, 4000 was picked using DNSSEC as guidance.  However, looking 
at my code I see that MTU is the actual maximum value (I'll ask what others 
have done).  There likely should be a step 0: determine maximum size of 
packet (the lesser of mtu or 4000, which is almost always likely to be mtu).

> Fragmentation becomes more likely as packets get larger. With packets of 
> 4000 bytes (where does this number come from, anyway?), fragmentation is 
> pretty much guaranteed across most links. If IRIS-LZW messages are 
> expected to be larger than ~512 bytes in general, the use of a transport 
> protocol other than UDP is probably a good idea.

That section does say: "Not all IRIS requests and responses will be able to 
utilize UDP and may require the use of other transfer protocols (i.e. 
IRIS-XPC and/or BEEP)."

-andy

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 16 Aug 2006 00:20:23 -0700

Andrew Newton wrote:
> TCP is handled by XPC and BEEP.  But for very short and quick answers 
> (and lots of them, such as domain availability checks) UDP is better.  
> Don't know what you mean by tricks, but the deflation is optional.
my congestion control alarm went off.

after reviewing the document, it's still ringing.

The word "retransmit" does not occur in the document.
The word "packet loss" does not occur in the document.
The word "congestion" does not occur in the document.

4000-byte UDP packets will have 3x the drop rate of 1500-byte UDP 
packets. So retransmissions are more likely than with DNS over the same 
wire. I can't envision an implementation of this that wouldn't 
retransmit. So guidance is needed.

Using UDP is fine, but I regard this specification as incomplete.

                       Harald

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 16 Aug 2006 14:20:51 -0700 (PDT)

On Wed, 16 Aug 2006, Harald Alvestrand wrote:

>> lots of them, such as domain availability checks) UDP is better.  Don't 
>> know what you mean by tricks, but the deflation is optional.
> There's nothing in the document that says "if you want to send 4000 requests, 
> and 70 out of the first 100 get lost, you should slow down your sending rate 
> to that server".
>

Session control is why we have TCP.

Tell us where 'retransmit', 'packet loss' and 'congestion' appear in DNS,
DHCP or some other UDP-based protocol documents and I'm sure author of
this spec will be happy to put something similar in his document.

> 4000-byte UDP packets will have 3x the drop rate of 1500-byte UDP packets.

This is general UDP issue specifically due to currently deployed 
network equipment. It need not be mentioned in every UDP-based
protocol spec especially since its operations issue.

> So  retransmissions are more likely than with DNS over the same wire.
> I can't envision an implementation of this that wouldn't retransmit.
> So guidance is needed.
>

---

From: Ted Faber <[email-masked]>
Date: Wed, 16 Aug 2006 14:34:38 -0700

> this spec will be happy to put something similar in his document.

There might be a few words about it in the DCCP spec.  It's UDP based.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Ted Faber <[email-masked]>
Date: Wed, 16 Aug 2006 14:46:20 -0700

> There might be a few words about it in the DCCP spec.  It's UDP based.

Aaron Falk pointed out to me that DCCP is not-UDP based, but an
alternative to UDP to provide congestion control.

Mea culpa.

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 16 Aug 2006 15:47:10 -0700

Hi -

> From: "william(at)elan.net" <[email-masked]>
> To: "Harald Alvestrand" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, August 16, 2006 2:20 PM
> Subject: Re: Last Call: 'A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service' to Proposed
Standard (draft-ietf-crisp-iris-lwz)
...
> this spec will be happy to put something similar in his document.
...

One example would be STD 62, SNMP.
Specifically, clause 2.2 of RFC 3416.

Randy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 16 Aug 2006 20:22:16 -0400

> Specifically, clause 2.2 of RFC 3416.

Thanks.  I've also looked at the advice in RFC 1035.  After reading  
both, I felt the advice to implementers amounted to "don't flood the  
network with packets; it is bad."  Such things should be said, but I  
rather like the more explicit algorithm and strongly suggested values  
specified in DTLS.

-andy

---

From: Ned Freed <[email-masked]>
Date: Wed, 16 Aug 2006 16:44:18 -0700 (PDT)

> this spec will be happy to put something similar in his document.

I believe SIP is specified to use exponential backoff when running over UDP.
There certainly is plenty of discussion of this stuff throughout RFC 3261, and
the words "retransmit" and "congestion" appear plenty of times in the document.

But let's suppose for a moment that no previous IETF protocol had ever
discussed congestion control or retransmits or anything similar when using UDP.
So what? This doesn't mean these aren't issues that a new protocol should deal
with. It doesn't mean we can simply ignore these issues and expect things to
just work. There are plenty of things we know now that we didn't know just a
few years ago, and as a result the list of details we know are best dealt with
in order to have a successful protocol has grown, and will probably continue to
grow. The argument that "so and so done some years ago didn't do foo so I don't
need to either" doesn't hold water IMO.

RFC 2914 was written for a reason, and didn't become a BCP because it sounded
nice to call it that.

> Session control is why we have TCP.

No, we have TCP because it is useful to have a standardized stream transport
that takes care of the various transport-layer tasks, including but not limited
to session control, so we don't have to reinvent these wheels in every
application. And we have UDP because TCP isn't the right choice for every
application out there. But UDP is in some senses a sharper tool than TCP, and
requires extra care when it is used.

I take no position on whether or not the use of UDP is appropriate in this
case. But if it is, congestion control issues need to be addressed.

				Ned

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 17 Aug 2006 07:26:17 +0200

> this spec will be happy to put something similar in his document.

You asked for it...

DNS: RFC 1035 section 4.2.1
DHCP: RFC 2131 section 4.1

When I thought this protocol was about sending occasional queries, I 
didn't worry too much, but Andy indicated that it could be used in 
applications that would send a *lot* of queries, too.

---

From: Mark Townsley <[email-masked]>
Date: Thu, 17 Aug 2006 10:41:43 +0200

> In both cases these may be included by reference.

I noticed this in the draft:

"   1.  If a request requires authentication, confidentiality, or other
        security, use another transfer protocol."

It seems to me that the intent is to not provide authentication here. This seems more fundamental than a fix by reference.

In a different vein, we have:

"  Its message exchange
   pattern is simple: a client sends a request in one UDP packet, and a
   server responds with an answer in one UDP packet."

I see no mention of what to do if the one UDP packet is lost. 
Resend? After how long? Exponentially backoff? 

- Mark

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Aug 2006 11:03:17 -0400

>>>>> "Mark" == Mark Townsley <[email-masked]> writes:

    Mark> Sam Hartman wrote:
    >> I notice that this transport provides no authentication of the
    >> data that is retrieved.
    >> 
    >> The security considerations needs to discuss the potential
    >> attacks if an attacker modifies this public data.  The security
    >> considerations section also needs to point to best practice for
    >> avoiding UDP reflection attacks.  It is not good enough to say
    >> "Do what other people do."

s/reflection/amplification sorry

    Mark> " 1.  If a request requires authentication, confidentiality,
    Mark> or other security, use another transfer protocol."

    Mark> It seems to me that the intent is to not provide
    Mark> authentication here. This seems more fundamental than a fix
    Mark> by reference.

Sure.  What I'm asking for is that they explain what the consequences
of providing no authentication are.  I'll then evaluate those
consequences and either conclude that authentication is not required
for this data for an Internet deployment or come back with another
comment that the security is inadequate.  But the first step of
determining whether the security is adequate is to determine the risk.

col between them, as long as the routing protocol
>> runs over IP.
> 
> 
> The document says,
> 
>      10. IPV6 Considerations
> 
>      The support for IPV6 is not addressed in this draft and is for
>      future study.
> 
> This needs to be addressed throughout the document.
> 
> The whole point of L2VPNs (IMHO) is that it's agnostic of what protocols 
> users run above L2.  Users depend on a transparent L2 service model and 
> this model breaks that assumption.
>

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Aug 2006 11:03:17 -0400