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?
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?
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?
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?
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?
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?
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?
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
[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
