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