[ntp:questions] Source address in response always the same as target address in request?
Are there any clear requirements in NTP/SNTP RFC docs about the UDP source address in all responses the same as the UDP target address in the original requests? I doubt it would be a UDP requirement because this is domain of upper protocols. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
[EMAIL PROTECTED] wrote: > Are there any clear requirements in NTP/SNTP RFC docs about the UDP > source address in > all responses the same as the UDP target address in the original > requests? > I doubt it would be a UDP requirement because this is domain of upper > protocols. Yes and no. The basic protocol does not require it. The reference implementation does require it. The Autokey crypto authentication scheme currently requires it, but there has been some discussion recently about the nature of that requirement and whether it could be relaxed, but I don't see that discussion going anywhere in this regard. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Guys, In both the NTPv4 specification and reference implementation the destination address used by the client when mobilizeing the association and sending the request must match the source address when receiving the response. This is a property of all RPC protocols known to me that use addresses to match requests with responses. This is so obvious a requirement that maybe the specification doesn't make it clear enough. Dave Brian Utterback wrote: > [EMAIL PROTECTED] wrote: > >> Are there any clear requirements in NTP/SNTP RFC docs about the UDP >> source address in >> all responses the same as the UDP target address in the original >> requests? >> I doubt it would be a UDP requirement because this is domain of upper >> protocols. > > > > Yes and no. The basic protocol does not require it. The reference > implementation does require it. The Autokey crypto authentication > scheme currently requires it, but there has been some discussion > recently about the nature of that requirement and whether it could > be relaxed, but I don't see that discussion going anywhere in this > regard. > > Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
[EMAIL PROTECTED] wrote: > Are there any clear requirements in NTP/SNTP RFC docs about the UDP > source address in > all responses the same as the UDP target address in the original > requests? > I doubt it would be a UDP requirement because this is domain of upper > protocols. If you want to use Autokey, it's a requirement. However, firewalls can also fail if you don't reply from the same address as it cannot match the source of the reply packet to the address of the outgoing packet. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
I beg to differ. Most UDP based protocols do not have this requirement. If they did, it would not be the case that in the (mumble mumble) years since the invention of the UDP protocol and the sockets interface, that the interface even provided the ability for the application to to do this within the interface within the last few years. The UDP protocol itself has no such requirement. Although the Hosts requirements RFC says that a host SHOULD provide a mechanism to do it, until IPv6 came along, few systems actually did. The only way to guarantee it was using the awful "bind every interface" trick that the reference implementation uses. The "RPC protocol" itself (RFC 1050) does not have this requirement. I do not know why the original designers of UDP did not include this requirement. I suspect they did not foresee the security requirements we have today. Or perhaps they had a good reason. But in any case the NTPv3 spec does not have the requirement in it. If I recall correctly, the NTPv4 spec does have the requirement, but I also recall commenting on this ages ago, comments that were ignored. I don't disagree that UDP should have the requirement, but it does not, and as such I do object to gratuitously adding the requirement to NTP, which has complicated the code base to no end. Of course, as I said above, it is now possible to implement this cleanly on many OS's, which would allow us to simplify the code immensely. But until such support is universal, that won't happen. Brian David L. Mills wrote: > Guys, > > In both the NTPv4 specification and reference implementation the > destination address used by the client when mobilizeing the association > and sending the request must match the source address when receiving the > response. This is a property of all RPC protocols known to me that use > addresses to match requests with responses. This is so obvious a > requirement that maybe the specification doesn't make it clear enough. > > Dave > > Brian Utterback wrote: >> [EMAIL PROTECTED] wrote: >> >>> Are there any clear requirements in NTP/SNTP RFC docs about the UDP >>> source address in >>> all responses the same as the UDP target address in the original >>> requests? >>> I doubt it would be a UDP requirement because this is domain of upper >>> protocols. >> >> >> >> Yes and no. The basic protocol does not require it. The reference >> implementation does require it. The Autokey crypto authentication >> scheme currently requires it, but there has been some discussion >> recently about the nature of that requirement and whether it could >> be relaxed, but I don't see that discussion going anywhere in this >> regard. >> >> Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Brian, UDP is stateless. There is absolutely no way that the UDP protocol developers could require that that a reply go back to the same address from which the packet was sent or that it be sent from the same IP address. No reply is ever required of a datagram. It would be a protocol layering violation to do so. The NTP protocol requirement is proper in this context. Danny Brian Utterback wrote: > I beg to differ. Most UDP based protocols do not have this requirement. > If they did, it would not be the case that in the (mumble mumble) years > since the invention of the UDP protocol and the sockets interface, > that the interface even provided the ability for the application to > to do this within the interface within the last few years. > > The UDP protocol itself has no such requirement. Although the > Hosts requirements RFC says that a host SHOULD provide a mechanism > to do it, until IPv6 came along, few systems actually did. The > only way to guarantee it was using the awful "bind every interface" > trick that the reference implementation uses. > > The "RPC protocol" itself (RFC 1050) does not have this requirement. > > I do not know why the original designers of UDP did not include this > requirement. I suspect they did not foresee the security requirements > we have today. Or perhaps they had a good reason. But in any case the > NTPv3 spec does not have the requirement in it. If I recall correctly, > the NTPv4 spec does have the requirement, but I also recall commenting > on this ages ago, comments that were ignored. > > I don't disagree that UDP should have the requirement, but it does not, > and as such I do object to gratuitously adding the requirement to NTP, > which has complicated the code base to no end. > > Of course, as I said above, it is now possible to implement this cleanly > on many OS's, which would allow us to simplify the code immensely. But > until such support is universal, that won't happen. > > Brian > > > David L. Mills wrote: >> Guys, >> >> In both the NTPv4 specification and reference implementation the >> destination address used by the client when mobilizeing the association >> and sending the request must match the source address when receiving the >> response. This is a property of all RPC protocols known to me that use >> addresses to match requests with responses. This is so obvious a >> requirement that maybe the specification doesn't make it clear enough. >> >> Dave >> >> Brian Utterback wrote: >>> [EMAIL PROTECTED] wrote: >>> Are there any clear requirements in NTP/SNTP RFC docs about the UDP source address in all responses the same as the UDP target address in the original requests? I doubt it would be a UDP requirement because this is domain of upper protocols. >>> >>> >>> Yes and no. The basic protocol does not require it. The reference >>> implementation does require it. The Autokey crypto authentication >>> scheme currently requires it, but there has been some discussion >>> recently about the nature of that requirement and whether it could >>> be relaxed, but I don't see that discussion going anywhere in this >>> regard. >>> >>> Brian Utterback > > ___ > questions mailing list > questions@lists.ntp.org > https://lists.ntp.org/mailman/listinfo/questions > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Perhaps proper, but ill-advised. Look at the trouble we have had trying to satisfy that requirement. I am sitting at a system that currently has over 300 UDP ports in use. Exactly one of those UDP ports is bound on each interface, namely 123. Interestingly, it is also bound twice on the wildcard address as well. Until recently, it wasn't possible in a portable manner, for a process to listen on a UDP port, receive a request and then issue a reply with the reply's source address guaranteed to be the same as the request's destination address. And virtually all UDP protocols had a way to deal with it, except NTP. Danny Mayer wrote: > Brian, > > UDP is stateless. There is absolutely no way that the UDP protocol > developers could require that that a reply go back to the same address > from which the packet was sent or that it be sent from the same IP > address. No reply is ever required of a datagram. It would be a protocol > layering violation to do so. The NTP protocol requirement is proper in > this context. > > Danny > > Brian Utterback wrote: >> I beg to differ. Most UDP based protocols do not have this requirement. >> If they did, it would not be the case that in the (mumble mumble) years >> since the invention of the UDP protocol and the sockets interface, >> that the interface even provided the ability for the application to >> to do this within the interface within the last few years. >> >> The UDP protocol itself has no such requirement. Although the >> Hosts requirements RFC says that a host SHOULD provide a mechanism >> to do it, until IPv6 came along, few systems actually did. The >> only way to guarantee it was using the awful "bind every interface" >> trick that the reference implementation uses. >> >> The "RPC protocol" itself (RFC 1050) does not have this requirement. >> >> I do not know why the original designers of UDP did not include this >> requirement. I suspect they did not foresee the security requirements >> we have today. Or perhaps they had a good reason. But in any case the >> NTPv3 spec does not have the requirement in it. If I recall correctly, >> the NTPv4 spec does have the requirement, but I also recall commenting >> on this ages ago, comments that were ignored. >> >> I don't disagree that UDP should have the requirement, but it does not, >> and as such I do object to gratuitously adding the requirement to NTP, >> which has complicated the code base to no end. >> >> Of course, as I said above, it is now possible to implement this cleanly >> on many OS's, which would allow us to simplify the code immensely. But >> until such support is universal, that won't happen. >> >> Brian >> >> >> David L. Mills wrote: >>> Guys, >>> >>> In both the NTPv4 specification and reference implementation the >>> destination address used by the client when mobilizeing the association >>> and sending the request must match the source address when receiving the >>> response. This is a property of all RPC protocols known to me that use >>> addresses to match requests with responses. This is so obvious a >>> requirement that maybe the specification doesn't make it clear enough. >>> >>> Dave >>> >>> Brian Utterback wrote: [EMAIL PROTECTED] wrote: > Are there any clear requirements in NTP/SNTP RFC docs about the UDP > source address in > all responses the same as the UDP target address in the original > requests? > I doubt it would be a UDP requirement because this is domain of upper > protocols. Yes and no. The basic protocol does not require it. The reference implementation does require it. The Autokey crypto authentication scheme currently requires it, but there has been some discussion recently about the nature of that requirement and whether it could be relaxed, but I don't see that discussion going anywhere in this regard. Brian Utterback >> ___ >> questions mailing list >> questions@lists.ntp.org >> https://lists.ntp.org/mailman/listinfo/questions >> > -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. -- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Danny Mayer wrote: > Brian, > > UDP is stateless. There is absolutely no way that the UDP protocol > developers could require that that a reply go back to the same address > from which the packet was sent or that it be sent from the same IP > address. No reply is ever required of a datagram. It would be a protocol > layering violation to do so. And yet the host requirements RFC does so require it, at least to the "SHOULD" level: When the local host is multihomed, a UDP-based request/response application SHOULD send the response with an IP source address that is the same as the specific destination address of the UDP request datagram. My contention is that although it is a SHOULD, the sockets API did not provide a way to actually accomplish it, so very few UDP protocols do not deal with the failure to do so. Except NTP. -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. -- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Brian, I beg to differ with your beg to differ. RFC 768 requires that the UDP checksom includes the pseudo header, which itself contains the IP source and destination addresses. Technically speaking the addresses don't have to mean anything, but it would be pretty silly for a RPC server not to know how to return the goods to its client. Maybe you are talking about the socket interface, rather than the protocol data unit. I wasn't. Dave Brian Utterback wrote: > I beg to differ. Most UDP based protocols do not have this requirement. > If they did, it would not be the case that in the (mumble mumble) years > since the invention of the UDP protocol and the sockets interface, > that the interface even provided the ability for the application to > to do this within the interface within the last few years. > > The UDP protocol itself has no such requirement. Although the > Hosts requirements RFC says that a host SHOULD provide a mechanism > to do it, until IPv6 came along, few systems actually did. The > only way to guarantee it was using the awful "bind every interface" > trick that the reference implementation uses. > > The "RPC protocol" itself (RFC 1050) does not have this requirement. > > I do not know why the original designers of UDP did not include this > requirement. I suspect they did not foresee the security requirements > we have today. Or perhaps they had a good reason. But in any case the > NTPv3 spec does not have the requirement in it. If I recall correctly, > the NTPv4 spec does have the requirement, but I also recall commenting > on this ages ago, comments that were ignored. > > I don't disagree that UDP should have the requirement, but it does not, > and as such I do object to gratuitously adding the requirement to NTP, > which has complicated the code base to no end. > > Of course, as I said above, it is now possible to implement this cleanly > on many OS's, which would allow us to simplify the code immensely. But > until such support is universal, that won't happen. > > Brian > > > David L. Mills wrote: > >> Guys, >> >> In both the NTPv4 specification and reference implementation the >> destination address used by the client when mobilizeing the >> association and sending the request must match the source address >> when receiving the response. This is a property of all RPC protocols >> known to me that use addresses to match requests with responses. This >> is so obvious a requirement that maybe the specification doesn't make >> it clear enough. >> >> Dave >> >> Brian Utterback wrote: >> >>> [EMAIL PROTECTED] wrote: >>> Are there any clear requirements in NTP/SNTP RFC docs about the UDP source address in all responses the same as the UDP target address in the original requests? I doubt it would be a UDP requirement because this is domain of upper protocols. >>> >>> >>> >>> >>> Yes and no. The basic protocol does not require it. The reference >>> implementation does require it. The Autokey crypto authentication >>> scheme currently requires it, but there has been some discussion >>> recently about the nature of that requirement and whether it could >>> be relaxed, but I don't see that discussion going anywhere in this >>> regard. >>> >>> Brian Utterback >> > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Brian Utterback wrote: > Perhaps proper, but ill-advised. Look at the trouble we have > had trying to satisfy that requirement. I am sitting at a > system that currently has over 300 UDP ports in use. Exactly > one of those UDP ports is bound on each interface, namely 123. > Interestingly, it is also bound twice on the wildcard address > as well. > > Until recently, it wasn't possible in a portable manner, for > a process to listen on a UDP port, receive a request and > then issue a reply with the reply's source address guaranteed > to be the same as the request's destination address. And > virtually all UDP protocols had a way to deal with it, except > NTP. > Not true. NTP had a number of bugs in it that needed to get fixed. Getting through all of the use cases took a long time to get right. That's a bug not an architectural flaw. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Danny Mayer wrote: > Brian Utterback wrote: > >> Perhaps proper, but ill-advised. Look at the trouble we have >> had trying to satisfy that requirement. I am sitting at a >> system that currently has over 300 UDP ports in use. Exactly >> one of those UDP ports is bound on each interface, namely 123. >> Interestingly, it is also bound twice on the wildcard address >> as well. >> >> Until recently, it wasn't possible in a portable manner, for >> a process to listen on a UDP port, receive a request and >> then issue a reply with the reply's source address guaranteed >> to be the same as the request's destination address. And >> virtually all UDP protocols had a way to deal with it, except >> NTP. >> >> > > Not true. NTP had a number of bugs in it that needed to get fixed. > Getting through all of the use cases took a long time to get right. > That's a bug not an architectural flaw. > What's not true? Are you saying that NTP doesn't need to bind all the interfaces anymore? If that is the case, then great, but the argument still stands. If that is not the case, then nothing has changed and the argument still stands. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
I went back to your original message and re-read it. I think the problem here is in the phrase "property of all RPC protocols [...] that use addresses to match requests with responses." What is not clear and what the original poster is in fact asking, is whether or not NTP is such a protocol that uses "addresses to match requests with responses". My point is that while NTP may be designed to be such a protocol, I think it was a mistake to to make it so. Or if there was a good reason to make it so, I would like it explained to me why. "David L. Mills wrote: > Brian, > > I beg to differ with your beg to differ. RFC 768 requires that the UDP > checksom includes the pseudo header, which itself contains the IP source > and destination addresses. Technically speaking the addresses don't have > to mean anything, but it would be pretty silly for a RPC server not to > know how to return the goods to its client. Maybe you are talking about > the socket interface, rather than the protocol data unit. I wasn't. > > Dave > > Brian Utterback wrote: > >> I beg to differ. Most UDP based protocols do not have this requirement. >> If they did, it would not be the case that in the (mumble mumble) years >> since the invention of the UDP protocol and the sockets interface, >> that the interface even provided the ability for the application to >> to do this within the interface within the last few years. >> >> The UDP protocol itself has no such requirement. Although the >> Hosts requirements RFC says that a host SHOULD provide a mechanism >> to do it, until IPv6 came along, few systems actually did. The >> only way to guarantee it was using the awful "bind every interface" >> trick that the reference implementation uses. >> >> The "RPC protocol" itself (RFC 1050) does not have this requirement. >> >> I do not know why the original designers of UDP did not include this >> requirement. I suspect they did not foresee the security requirements >> we have today. Or perhaps they had a good reason. But in any case the >> NTPv3 spec does not have the requirement in it. If I recall correctly, >> the NTPv4 spec does have the requirement, but I also recall commenting >> on this ages ago, comments that were ignored. >> >> I don't disagree that UDP should have the requirement, but it does not, >> and as such I do object to gratuitously adding the requirement to NTP, >> which has complicated the code base to no end. >> >> Of course, as I said above, it is now possible to implement this cleanly >> on many OS's, which would allow us to simplify the code immensely. But >> until such support is universal, that won't happen. >> >> Brian >> >> >> David L. Mills wrote: >> >>> Guys, >>> >>> In both the NTPv4 specification and reference implementation the >>> destination address used by the client when mobilizeing the >>> association and sending the request must match the source address >>> when receiving the response. This is a property of all RPC protocols >>> known to me that use addresses to match requests with responses. This >>> is so obvious a requirement that maybe the specification doesn't make >>> it clear enough. >>> >>> Dave >>> >>> Brian Utterback wrote: >>> [EMAIL PROTECTED] wrote: > Are there any clear requirements in NTP/SNTP RFC docs about the UDP > source address in > all responses the same as the UDP target address in the original > requests? > I doubt it would be a UDP requirement because this is domain of upper > protocols. Yes and no. The basic protocol does not require it. The reference implementation does require it. The Autokey crypto authentication scheme currently requires it, but there has been some discussion recently about the nature of that requirement and whether it could be relaxed, but I don't see that discussion going anywhere in this regard. Brian Utterback >>> >> > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Brian Utterback wrote: > Danny Mayer wrote: >> Brian Utterback wrote: >> >>> Perhaps proper, but ill-advised. Look at the trouble we have >>> had trying to satisfy that requirement. I am sitting at a >>> system that currently has over 300 UDP ports in use. Exactly >>> one of those UDP ports is bound on each interface, namely 123. >>> Interestingly, it is also bound twice on the wildcard address >>> as well. >>> >>> Until recently, it wasn't possible in a portable manner, for >>> a process to listen on a UDP port, receive a request and >>> then issue a reply with the reply's source address guaranteed >>> to be the same as the request's destination address. And >>> virtually all UDP protocols had a way to deal with it, except >>> NTP. >>> >>> >> >> Not true. NTP had a number of bugs in it that needed to get fixed. >> Getting through all of the use cases took a long time to get right. >> That's a bug not an architectural flaw. >> > What's not true? Are you saying that NTP doesn't need to bind all the > interfaces anymore? No, it does to thast. > If that is the case, then great, but the argument still stands. If that > is not the case, > then nothing has changed and the argument still stands. > If you want to send a reply back to a client how would you specify the outgoing local interface address? Even using sendmsg() you cannot do that if you want to use, for example, the wildcard socket. Don't forget this is UDP so it's connectionless and is a separate datagram each time. There are very few choices here. With TCP there is an established connection and you can reply on that connection. This is not the case here. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Danny Mayer wrote: > If you want to send a reply back to a client how would you specify the > outgoing local interface address? Even using sendmsg() you cannot do > that if you want to use, for example, the wildcard socket. Don't forget > this is UDP so it's connectionless and is a separate datagram each time. > There are very few choices here. With TCP there is an established > connection and you can reply on that connection. This is not the case here. > That's my point. The socket interface does not provide a way to do something that is required to use the NTP protocol. The fact that the sockets API has existed for so long without that ability is my evidence that the requirement should not have been so lightly made. If the requirement was really so universal (as Dave suggested) as to not even need to be mentioned in the spec and just assumed, then I contend that the sockets API would have a way to easily meet that requirement. Which as you pointed out, it does not. -- blu "You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity?" - Disk management as it should be. -- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Brian, I recall the SHOULD was inserted to support the anycast model where any of a number of servers could respond to a specific request. NTP along with many others in the late 1970s did not anticipate such a model and, even if they did, as later in NTP manycast, the addresses are still necessary for operation sugbsequent to discovery. Dave Brian Utterback wrote: > > Danny Mayer wrote: > >>Brian, >> >>UDP is stateless. There is absolutely no way that the UDP protocol >>developers could require that that a reply go back to the same address >>from which the packet was sent or that it be sent from the same IP >>address. No reply is ever required of a datagram. It would be a protocol >>layering violation to do so. > > > And yet the host requirements RFC does so require it, at least to > the "SHOULD" level: > >When the local host is multihomed, a UDP-based request/response >application SHOULD send the response with an IP source address >that is the same as the specific destination address of the UDP >request datagram. > > My contention is that although it is a SHOULD, the sockets API did > not provide a way to actually accomplish it, so very few UDP > protocols do not deal with the failure to do so. Except NTP. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Brian, You say "until recently"; NTP has been intimate with Unix since the early 1980s. Is this recent? Second and more importantly, if the address is not used to bind a request to a reply, what else can replace it? Why do you have 300 sockets bound to an interface with a stateless protocol? This appears to be a fundamental violation of the stateless paradigm. Dave Brian Utterback wrote: > Perhaps proper, but ill-advised. Look at the trouble we have > had trying to satisfy that requirement. I am sitting at a > system that currently has over 300 UDP ports in use. Exactly > one of those UDP ports is bound on each interface, namely 123. > Interestingly, it is also bound twice on the wildcard address > as well. > > Until recently, it wasn't possible in a portable manner, for > a process to listen on a UDP port, receive a request and > then issue a reply with the reply's source address guaranteed > to be the same as the request's destination address. And > virtually all UDP protocols had a way to deal with it, except > NTP. > > > Danny Mayer wrote: > >>Brian, >> >>UDP is stateless. There is absolutely no way that the UDP protocol >>developers could require that that a reply go back to the same address >>from which the packet was sent or that it be sent from the same IP >>address. No reply is ever required of a datagram. It would be a protocol >>layering violation to do so. The NTP protocol requirement is proper in >>this context. >> >>Danny >> >>Brian Utterback wrote: >> >>>I beg to differ. Most UDP based protocols do not have this requirement. >>>If they did, it would not be the case that in the (mumble mumble) years >>>since the invention of the UDP protocol and the sockets interface, >>>that the interface even provided the ability for the application to >>>to do this within the interface within the last few years. >>> >>>The UDP protocol itself has no such requirement. Although the >>>Hosts requirements RFC says that a host SHOULD provide a mechanism >>>to do it, until IPv6 came along, few systems actually did. The >>>only way to guarantee it was using the awful "bind every interface" >>>trick that the reference implementation uses. >>> >>>The "RPC protocol" itself (RFC 1050) does not have this requirement. >>> >>>I do not know why the original designers of UDP did not include this >>>requirement. I suspect they did not foresee the security requirements >>>we have today. Or perhaps they had a good reason. But in any case the >>>NTPv3 spec does not have the requirement in it. If I recall correctly, >>>the NTPv4 spec does have the requirement, but I also recall commenting >>>on this ages ago, comments that were ignored. >>> >>>I don't disagree that UDP should have the requirement, but it does not, >>>and as such I do object to gratuitously adding the requirement to NTP, >>>which has complicated the code base to no end. >>> >>>Of course, as I said above, it is now possible to implement this cleanly >>>on many OS's, which would allow us to simplify the code immensely. But >>>until such support is universal, that won't happen. >>> >>>Brian >>> >>> >>>David L. Mills wrote: >>> Guys, In both the NTPv4 specification and reference implementation the destination address used by the client when mobilizeing the association and sending the request must match the source address when receiving the response. This is a property of all RPC protocols known to me that use addresses to match requests with responses. This is so obvious a requirement that maybe the specification doesn't make it clear enough. Dave Brian Utterback wrote: >[EMAIL PROTECTED] wrote: > > >>Are there any clear requirements in NTP/SNTP RFC docs about the UDP >>source address in >>all responses the same as the UDP target address in the original >>requests? >>I doubt it would be a UDP requirement because this is domain of upper >>protocols. > >Yes and no. The basic protocol does not require it. The reference >implementation does require it. The Autokey crypto authentication >scheme currently requires it, but there has been some discussion >recently about the nature of that requirement and whether it could >be relaxed, but I don't see that discussion going anywhere in this >regard. > >Brian Utterback >>> >>>___ >>>questions mailing list >>>questions@lists.ntp.org >>>https://lists.ntp.org/mailman/listinfo/questions >>> >> > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Brian, Are we having a disconnect here or are we talking right past each other? NTP has evolved from very many protocols of the late 1970s and early 1980s, including ICMP, GGP, EGP, UDP/TIME, UTP/DAYTIME, UDP/QOD, SNMP and countless others. These protocols multiplex among possibly many servers and clients using the IP addresses and ports (UDP). A client sending a request to a server must know the source address of the reply in ordet to match the request to the reply data structures. This was the intent of the original design and as evolved in the Gateway Architecture and Data Structures (GADS) task force and its successor the Internet Architecture (INARC) task force, both of which I happened to chair. This engineering design might today be considered archaic and maybe even a collossal mistakce. However, you need to make the case. Furthermore, this has absolutely nothing to do with sockets or Unix programming style. I made this abundantly clear to Mike Karels of UCB at the time in a meeting with DARPA principals concerned that UCB was a loose cannon and uncooperative with Internet design principles. Hyde Park in London on Sunday Morning... Dave Brian Utterback wrote: > I beg to differ. Most UDP based protocols do not have this requirement. > If they did, it would not be the case that in the (mumble mumble) years > since the invention of the UDP protocol and the sockets interface, > that the interface even provided the ability for the application to > to do this within the interface within the last few years. > > The UDP protocol itself has no such requirement. Although the > Hosts requirements RFC says that a host SHOULD provide a mechanism > to do it, until IPv6 came along, few systems actually did. The > only way to guarantee it was using the awful "bind every interface" > trick that the reference implementation uses. > > The "RPC protocol" itself (RFC 1050) does not have this requirement. > > I do not know why the original designers of UDP did not include this > requirement. I suspect they did not foresee the security requirements > we have today. Or perhaps they had a good reason. But in any case the > NTPv3 spec does not have the requirement in it. If I recall correctly, > the NTPv4 spec does have the requirement, but I also recall commenting > on this ages ago, comments that were ignored. > > I don't disagree that UDP should have the requirement, but it does not, > and as such I do object to gratuitously adding the requirement to NTP, > which has complicated the code base to no end. > > Of course, as I said above, it is now possible to implement this cleanly > on many OS's, which would allow us to simplify the code immensely. But > until such support is universal, that won't happen. > > Brian > > > David L. Mills wrote: > >> Guys, >> >> In both the NTPv4 specification and reference implementation the >> destination address used by the client when mobilizeing the >> association and sending the request must match the source address when >> receiving the response. This is a property of all RPC protocols known >> to me that use addresses to match requests with responses. This is so >> obvious a requirement that maybe the specification doesn't make it >> clear enough. >> >> Dave >> >> Brian Utterback wrote: >> >>> [EMAIL PROTECTED] wrote: >>> Are there any clear requirements in NTP/SNTP RFC docs about the UDP source address in all responses the same as the UDP target address in the original requests? I doubt it would be a UDP requirement because this is domain of upper protocols. >>> >>> >>> >>> >>> Yes and no. The basic protocol does not require it. The reference >>> implementation does require it. The Autokey crypto authentication >>> scheme currently requires it, but there has been some discussion >>> recently about the nature of that requirement and whether it could >>> be relaxed, but I don't see that discussion going anywhere in this >>> regard. >>> >>> Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
David L. Mills wrote: > Brian, > > I recall the SHOULD was inserted to support the anycast model where any > of a number of servers could respond to a specific request. NTP along > with many others in the late 1970s did not anticipate such a model and, > even if they did, as later in NTP manycast, the addresses are still > necessary for operation sugbsequent to discovery. > > Dave > Perhaps. You were there, I was not involved at the time. However, my understanding is that not all systems at the time could be made to meet the requirement and thus the SHOULD was necessary. But even so, my point is that although ther SHOULD is there, most UDP applications on most operating systems do not actually follow the SHOULD at all. Brian Utterback. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
David L. Mills wrote: > Brian, > > You say "until recently"; NTP has been intimate with Unix since the > early 1980s. Is this recent? > What I am saying here is that the ability to easily accomplish the necessary address bindings have been added on some operating systems to the sockets protocol, not that NTP was recently added. > Second and more importantly, if the address is not used to bind a > request to a reply, what else can replace it? Port number and transaction id's for example. That's what are used in the current RPC protocol, for instance. Not IP address. > > Why do you have 300 sockets bound to an interface with a stateless > protocol? This appears to be a fundamental violation of the stateless > paradigm. Not sure what you mean here. The 300 sockets are bound to 300 different UDP ports by some large number of different processes. All of them bound to the wildcard address except NTP. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
>>> In article <[EMAIL PROTECTED]>, "David L. Mills" <[EMAIL PROTECTED]> writes: David> Why do you have 300 sockets bound to an interface with a stateless David> protocol? This appears to be a fundamental violation of the David> stateless paradigm. Dave, this tells me that Brian is on a machine that has 300 virtual IPs on it. This is becoming more and more common - people assign 1 IP per 'service' so the service can be easily put on an arbitrary machine, or they use several IPs for the service on different subnets/vlans for network architecture and security reasons. -- Harlan Stenn <[EMAIL PROTECTED]> http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
David L. Mills wrote: > Brian, > > Are we having a disconnect here or are we talking right past each other? Probably both. 8-) > NTP has evolved from very many protocols of the late 1970s and early > 1980s, including ICMP, GGP, EGP, UDP/TIME, UTP/DAYTIME, UDP/QOD, SNMP > and countless others. These protocols multiplex among possibly many > servers and clients using the IP addresses and ports (UDP). A client > sending a request to a server must know the source address of the reply > in ordet to match the request to the reply data structures. Well, ICMP packets rarely have a source address that matches the original packets destination address. Many UDP protocols that deal with routing and network management need to have knowledge the interface used, so they do indeed follow the same model of binding all the interfaces; I certainly do not claim that NTP is alone in that regard. > > This was the intent of the original design and as evolved in the Gateway > Architecture and Data Structures (GADS) task force and its successor the > Internet Architecture (INARC) task force, both of which I happened to > chair. > > This engineering design might today be considered archaic and maybe even > a collossal mistakce. However, you need to make the case. Furthermore, > this has absolutely nothing to do with sockets or Unix programming > style. I made this abundantly clear to Mike Karels of UCB at the time in > a meeting with DARPA principals concerned that UCB was a loose cannon > and uncooperative with Internet design principles. I do not think that the requirement that the addresses match to be mistake in the UDP protocol. I think that it would have been a good idea. What I am saying is that the requirement is not in the protocol at all, so the need for NTP to have it be so is a NTP decision. The fact that it was unnecessary and to have resulted in the bind all interfaces ugliness is the reason I think it was ill-advised. If the UDP protocol had had this requirement all along, then the sockets API would have had a way to do it easily and then I would not object at all. > > Hyde Park in London on Sunday Morning... If you are saying that you are going, then have a good trip. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Brian Utterback wrote: > David L. Mills wrote: >> Brian, >> >> You say "until recently"; NTP has been intimate with Unix since the >> early 1980s. Is this recent? >> > > What I am saying here is that the ability to easily accomplish > the necessary address bindings have been added on some operating > systems to the sockets protocol, not that NTP was recently added. > > >> Second and more importantly, if the address is not used to bind a >> request to a reply, what else can replace it? > > Port number and transaction id's for example. That's what are used > in the current RPC protocol, for instance. Not IP address. > >> Why do you have 300 sockets bound to an interface with a stateless >> protocol? This appears to be a fundamental violation of the stateless >> paradigm. > > Not sure what you mean here. The 300 sockets are bound to 300 > different UDP ports by some large number of different processes. > All of them bound to the wildcard address except NTP. > How many of them use UDP? Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Harlan Stenn wrote: In article <[EMAIL PROTECTED]>, "David L. Mills" <[EMAIL PROTECTED]> writes: > > David> Why do you have 300 sockets bound to an interface with a stateless > David> protocol? This appears to be a fundamental violation of the > David> stateless paradigm. > > Dave, this tells me that Brian is on a machine that has 300 virtual IPs on > it. > > This is becoming more and more common - people assign 1 IP per 'service' so > the service can be easily put on an arbitrary machine, or they use several > IPs for the service on different subnets/vlans for network architecture and > security reasons. This sounds like laziness. Instead of updating the DNS to change the IP address of a name, they add move the IP address to a different machine. It doesn't make much sense to me. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
>>> Why do you have 300 sockets bound to an interface with a stateless >>> protocol? This appears to be a fundamental violation of the stateless >>> paradigm. >> Not sure what you mean here. The 300 sockets are bound to 300 >> different UDP ports by some large number of different processes. >> All of them bound to the wildcard address except NTP. >> > > How many of them use UDP? > I said that "300 sockets are bound to 300 different UDP ports". To be clear; This is a Sun Ray server with many different users. At this point in time, there are some large number of applications in use which are using UDP, all bound to the wildcard interface, none of them bound explicitly to any particular local IP address. My point is that NTP is, while not unique, one of a small number of applications that feels the need to bind all the local IP addresses. -- blu "Mr. Jefferson, build up that wall!" -- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Danny Mayer wrote: > Harlan Stenn wrote: >> This is becoming more and more common - people assign 1 IP per 'service' so >> the service can be easily put on an arbitrary machine, or they use several >> IPs for the service on different subnets/vlans for network architecture and >> security reasons. > > This sounds like laziness. Instead of updating the DNS to change the IP > address of a name, they add move the IP address to a different machine. > It doesn't make much sense to me. > Really? Consider: The service is administered locally to a system and although the IP address may be administered by someone else, it will usually be fairly close (i.e. the local sub-net) and doesn't require any further administration once assigned. The DNS may be administered non-locally or even globally, with potentially two separate organizations required to change it (one for forward lookups and one for reverse lookups). Once the DNS is changed, it takes some time to propagate the change due to caching, and already running applications may never see the change unless they re-resolve. Having one service per IP address also makes the job of load-balancing software much simpler. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Brian Utterback wrote: > Danny Mayer wrote: > >> Harlan Stenn wrote: >> >>> This is becoming more and more common - people assign 1 IP per >>> 'service' so >>> the service can be easily put on an arbitrary machine, or they use >>> several >>> IPs for the service on different subnets/vlans for network >>> architecture and >>> security reasons. >> >> >> This sounds like laziness. Instead of updating the DNS to change the IP >> address of a name, they add move the IP address to a different machine. >> It doesn't make much sense to me. >> > > Really? Consider: > > The service is administered locally to a system and although the > IP address may be administered by someone else, it will usually > be fairly close (i.e. the local sub-net) and doesn't require any > further administration once assigned. The DNS may be administered > non-locally or even globally, with potentially two separate > organizations required to change it (one for forward lookups and > one for reverse lookups). Once the DNS is changed, it takes some > time to propagate the change due to caching, and already running > applications may never see the change unless they re-resolve. > Having one service per IP address also makes the job of > load-balancing software much simpler. > > Brian Utterback I believe that there is a solution to the DNS caching problem. Each DNS record can be given a "Time To Live" or TTL. If you are planning to change the record, set the TTL to seven days, then six, five, four, three, two, one. . . . All of those cached records should expire at more or less the same time. It's not perfect but it works. If you time it just right, you can minimize the amount of disruption. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Richard B. Gilbert wrote: > I believe that there is a solution to the DNS caching problem. Each DNS > record can be given a "Time To Live" or TTL. If you are planning to > change the record, set the TTL to seven days, then six, five, four, > three, two, one. . . . All of those cached records should expire at > more or less the same time. It's not perfect but it works. If you time > it just right, you can minimize the amount of disruption. Still requires the clients to re-resolve the server address (something ntpd famously does not do currently; desparate attempt at getting back on-topic ;-) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Jan Ceuleers wrote: > Richard B. Gilbert wrote: > >> I believe that there is a solution to the DNS caching problem. Each >> DNS record can be given a "Time To Live" or TTL. If you are planning >> to change the record, set the TTL to seven days, then six, five, four, >> three, two, one. . . . All of those cached records should expire at >> more or less the same time. It's not perfect but it works. If you >> time it just right, you can minimize the amount of disruption. > > > Still requires the clients to re-resolve the server address (something > ntpd famously does not do currently; desparate attempt at getting back > on-topic ;-) Well, how often does a typical NTP server change it's address? Any server with a dynamic address is going to create problems. AFAIK it's not a common situation. ISTR that you can use ntpdc or ntpq (I'm too lazy to look up which one) to drop or add servers without needing to restart ntpd. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Richard B. Gilbert wrote: > I believe that there is a solution to the DNS caching problem. Each DNS > record can be given a "Time To Live" or TTL. If you are planning to > change the record, set the TTL to seven days, then six, five, four, > three, two, one. . . . All of those cached records should expire at > more or less the same time. It's not perfect but it works. If you time > it just right, you can minimize the amount of disruption. > This is exactly how we tell people who are changing IP addresses of the DNS servers for a zone to migrate. We also tell them to keep the old server running for a short while after the changeover but handing out the new NS records of the new server(s). After requests stop coming in to the old server then it can be shutdown permanently. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Jan Ceuleers wrote: > Richard B. Gilbert wrote: >> I believe that there is a solution to the DNS caching problem. Each DNS >> record can be given a "Time To Live" or TTL. If you are planning to >> change the record, set the TTL to seven days, then six, five, four, >> three, two, one. . . . All of those cached records should expire at >> more or less the same time. It's not perfect but it works. If you time >> it just right, you can minimize the amount of disruption. > > Still requires the clients to re-resolve the server address (something > ntpd famously does not do currently; desparate attempt at getting back > on-topic ;-) I'm working on it. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
