RIPE24 DNS-WG proposed agenda

On Thu, 18 Apr 96 16:50:34 MET DST  Antonio_Blasco Bonito wrote:
> - *contribute* to improve the agenda

I'd like to have another topic discussed: DNS and UDP checksumming.
I brought this up several weeks ago but got only one response
(thanks Francis, though I don't agree with you on this ;-)

Rationale: We all encounter an increasing amount of junk data in
the various DNS caches, where the data usually just has one bit
flipped. Presumably this is caused by spikes on serial lines which
run without checksumming on the serial protocol itself.
As checksums with UDP are not mandatory, some workstation manufacturers
ship operating system code with UDP checksumming disabled. This means
that data from/to such server can be corrupted, and this will 
remain undetected.

(for those that don't know, UDP checksums are one-complement checksums;
hence there are 2 values for 'zero', one of which is used to flag that
no checksum has been calculated. Hence, a receiver can see per-packet
if the UDP checksum was calculated and can be verified)

Looking though various sources, I found 3 classes of machines.
One can usually switch between two of these 3 categories with
a kernel flag.
1. Some machines send UDP checksums and check for them as well
   Fortunately this is the common case, and it is as things should be.
2. Some machines don't send UDP checksums, but will verify if a packet
   with UDP checksum arrives.
3. Some machines neither generate nor check checksums. This are mostly
   SUNs running 'classic solaris' (SunOS) and this behaviour can be switched
   to 1. by a simple patch.

I also found that it is usually quite hard for an application to
find out if a packet that arrives on a UDP socket did have a checksum
or not.

There are a couple of approaches:
- Leaving things as-is
  Obviously I don't think this is desirable, otherwise I wouldn't
  bring it up ;-)
- Sending warding messages
  On the FR-NIC FTP server there is a small program to test if
  UDP checksumming is enabled on a host. This is done by sending
  UDP packets with a bad checksum to said host; if it responds,
  then it doesn't check checksums.
  I have looked into this approach, but I don't think it scales itself
  to a large scale warning mechanism. I think this method isn't
  reliable to test this problem, although it certainly helps
- Ignoring UDP packets without checksum.
  RFC1122 or 1123 (can't tell now - don't have RFC repository on my
  laptop) has some lines in there that suggest that it is allowable for
  an application to ignore UDP requests without checksum.
  This is hard to switch on BSD-derived machines, but a kernel patch
  to ignore all non-checksum UDP packets is simple.
  If a number of well-known servers would do this, and this mechanism
  would be known (hence bringing it up on in the WG), then there would
  be a good incentive for people to fix their boxes
  (a little bit like the requirement to have in-addr delegation for
  access to certain FTP archives).

While I realize that the last approach is more disruptive, I think
that this is the correct approach. My proposal:
- Make a short document describing the problem, with workarounds for
  common platforms (I can only think of SunOS having a bad default)
- Setting a flag date
- From that date, allowing people to change their servers to reject 
  packets without UDP checksum.

So far, I have had one response on this, suggesting that approach
two (testing and warning) should be used instead. I don't think this
is feasible now, and it certainly has scaling problems, so I'd
rather have the RIPE community reach consensus that the last approach
is acceptable and can be implemented..

Geert Jan

PS: sorry to be long-winded on this, but as I won't be able to
attend the Berlin meeting, I won't be able to give a presentation
on this. I hope that this message is enough to discuss the matter..