[ Moderators note: Post was moderated, either because it was posted by
a non-subscriber, or because it was over 20K.
With the massive amount of spam, it is easy to miss and therefore
delete relevant posts by non-subscribers.
Please fix your subscription addresses. ]
From: Eric Rescorla <ekr@networkresonance.com>
... Rather, you can just accept the first key you see...
yes, that's what i'm proposing. we're ensuring identity continuity between
the entity who could hear and speak from an IP at session initialization
time and the entity who can later transmit responses from that IP.
Maybe I'm missing something, but why do you need to change the kernel?
As I recall, UDP sockets, unlike TCP sockets, don't die just because an
ICMP message is received. Can't the application just ignore the error?
if the socket is connected, then read() will show an error if an ICMP
arrives that was putatively due to a previous write(). it's a mess. yes,
you can ignore all ICMP-causable errors from read() or write() (or sendto()
or recvfrom(), etc). or you can just not bother to connect() the socket
in which case you should never see ICMP-causable errno values. but i'm
only speaking from a BSD sockets perspective, i don't know how STREAMS does
it, or WIN32 sockets, or linux sockets, or embedded system sockets. is it
safe to design with application-layer ignore-ICMP as an implementation
requirement? (i really don't know if these errors are ever sticky on some
platforms.)