Re: [ntp:questions] Embedded solutions
On Sat, 05 Jul 2014 23:37:05 +, Jaap Winius wrote: Hi folks, Has anyone here managed to turn a relatively cheap, ARM-based embedded system with a serial port into a decent stratum 1 NTP server? Thus far I've always attached my GPS and radio time signal receivers to much larger x86 hardware platforms, but those machines have other things to do and make the NTP server less stable than it can be. However, if I were to use dedicated hardware for the NTP server, I'd rather it power- efficient and as cheap as possible. I've looked at the BeagleBone Black (with an RS232 Cape) and the Wandboard (both ARM platforms), but have not had any success with them. There are stories stories of people who have done it with Soekris hardware (x86), but that's much more expensive. A fair amount of info on a Raspberry Pi based solution can be found at http://satsignal.eu/ntp/Raspberry-Pi-NTP.html I have been running something based on this for the last year or so, and all I can say is 'it works for me'. Be sure to include some form of external RTC though. -d ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Thoughts on KOD
Harlan Stenn st...@ntp.org wrote: Discussion appreciated. I think it is best to remove KOD from ntpd. It does not serve a useful purpose, because precisely the kind of clients that you want to say goodbye to, do not support it. In real life it has either no effect at all, or it even has a negative effect because the client does not understand it and re-tries the request sooner than it would when no reply was sent at all. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Thoughts on KOD
On 07/06/2014 08:42 AM, Rob wrote: Harlan Stenn st...@ntp.org wrote: Discussion appreciated. I think it is best to remove KOD from ntpd. It does not serve a useful purpose, because precisely the kind of clients that you want to say goodbye to, do not support it. In real life it has either no effect at all, or it even has a negative effect because the client does not understand it and re-tries the request sooner than it would when no reply was sent at all. Seconded. I recommend providing motivation for the undesired clients to stop using the server, by the server sending a regular response indicating that it is not synchronised or replying in some other way that has no timekeeping value to the offending client. Another way would be to use a bogus fixed timestamp that is in the past (i.e. one that suggests that there is no passage of time on the server). My recommendation is based on the assumption, yet to be verified in practice, that this server behaviour won't result in worse client behaviour than would be the case if the server just served the client's request as normal. Jan ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Thoughts on KOD
Jan Ceuleers jan.ceule...@computer.org wrote: I recommend providing motivation for the undesired clients to stop using the server, by the server sending a regular response indicating that it is not synchronised or replying in some other way that has no timekeeping value to the offending client. Well, that is what KOD actually is. However, it has so many broken and inconsistent bits that some clients believe that they have received a corrupted packet and decide to re-try the request to see if that results in a better response. (of course a programmer that would even try that, will not be clever enough to put a retry limit or an increasing delay in the code. so those badly written clients just start to hammer on the server) Another way would be to use a bogus fixed timestamp that is in the past (i.e. one that suggests that there is no passage of time on the server). Probably that would be better, but of course KOD has already been defined and changing its definition yet again would be risky as well. My recommendation is based on the assumption, yet to be verified in practice, that this server behaviour won't result in worse client behaviour than would be the case if the server just served the client's request as normal. This has to be tested very well. When I was still in the IPv4 NTP pool I had some very bad experiences with KOD. And I was not the only one. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Thoughts on KOD
Rob wrote: Harlan Stenn st...@ntp.org wrote: Discussion appreciated. I think it is best to remove KOD from ntpd. It does not serve a useful purpose, because precisely the kind of clients that you want to say goodbye to, do not support it. In real life it has either no effect at all, or it even has a negative effect because the client does not understand it and re-tries the request sooner than it would when no reply was sent at all. I'm afraid this is exactly right: KOD is a way to keep honest guys honest, i.e. it only helps against programmers/users why actually try (hard) to do the right thing. Currently it will cause a badly configured ntpd installation (burst + minpoll 4 + maxpoll 4) to possibly stop using any server which sends back KOD, but only if it also uses the pool directive to actively search out the best servers. I don't want to think about users actively trying to generate as much traffic as possible. :-( Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Thoughts on KOD
Magnus Danielson wrote: Harlan, On 07/05/2014 11:40 PM, Harlan Stenn wrote: Folks, I was chatting with PHK about: http://support.ntp.org/bin/view/Dev/NtpProtocolResponseMatrix http://bugs.ntp.org/show_bug.cgi?id=2367 and how we probably want to extend KOD coverage to more than just the limited case. I was assuming folks would want finer-grained control over this behavior, and thought about being able to choose any of kod-limited, kod-noserve, and kod-query. PHK suggested that we consider going the other way - KOD would mean Send KODs whenever appropriate. We want KOD generation to be at worst equally expensive as a normal reply, particularly for a high-performance multi-threaded/wire-speed server. This is actually _very_ hard to do, since a default reply to a client request is by far the most common pattern, something that people have already implemented in FPGAs. 1 Gbit/s corresponds to more than a million request/reply pairs per second, this is just within the realm of the possible for a multi-core/multi-thread server where every thread can handle these requests autonomously, passing more complicated stuff on to a regular (full ntpd) backend thread. Even simple KOD processing might well slow this code down too much to keep up. I wonder what the costs/benefits will be when weighing the extra complexity of multiple choices against when the defaults change and we get new behavior that we can't tune, that costs us in X and Y. This gets a bit more complicated when taking into consideration: - we'll get more traffic from a NAT gateway - - do we need to be able to configure a threshhold for this case? - we should pay attention to how a client, whom we find to be abusive, reacts to: - - getting no response - - getting a KOD response and adapt accordingly. Seems like an obviously good idea, but see below: Any forced extra processing becomes another way to DOS the ntp server. Discussion appreciated. There is also the aspect when KOD does not bite. We have seen that. Like other forms of defenses, inserting drop rules into firewall rules for the offending node is an alternative to consider. KOD only bites for nodes which follows the protocol, but somehow is offending in their configuration. More offensive configuration or packet generation will render KOD relatively useless. Thus, there might be a limit on how much effort should be going into perfecting KOD-generation when maybe raising the bar even further is needed. Then, we should also consider how KOD and drop-rule triggering can be used to trigger denial of service, and how to potentially protect against them. This was my immediate worry: Forcing KOD to maintain even more state per session would make it easier to overload the NTP server. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Thoughts on KOD
On 07/06/2014 11:23 AM, Rob wrote: Jan Ceuleers jan.ceule...@computer.org wrote: I recommend providing motivation for the undesired clients to stop using the server, by the server sending a regular response indicating that it is not synchronised or replying in some other way that has no timekeeping value to the offending client. Well, that is what KOD actually is. Sorry, I was not clear. By a 'regular' response I mean one that has a non-zero stratum value. I had actually forgotten that a stratum value of zero indicates that the server is not synchronised (as it is a collision with LI=3, which also means that). So I guess I'm dropping my first suggestion. The second-one stands: pick a non-zero stratum value and report an immutable time stamp. Note that the stratum field occupies 8 bits in the packet format, but currently only values between 0 and 15 are defined (where we have seen that a value of 0 is not uniformly understood by real-life clients). So the choice of stratum value should be in the range 1-15. I have no particular preference for the immutable time stamp value to pick. Could be zero, could be some other meaningful value (such as 0xeee4baadeee4baad - twice Eek! Bad!). Jan ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Thoughts on KOD
On 07/06/2014 12:38 PM, Terje Mathisen wrote: Rob wrote: Harlan Stenn st...@ntp.org wrote: Discussion appreciated. I think it is best to remove KOD from ntpd. It does not serve a useful purpose, because precisely the kind of clients that you want to say goodbye to, do not support it. In real life it has either no effect at all, or it even has a negative effect because the client does not understand it and re-tries the request sooner than it would when no reply was sent at all. I'm afraid this is exactly right: KOD is a way to keep honest guys honest, i.e. it only helps against programmers/users why actually try (hard) to do the right thing. Currently it will cause a badly configured ntpd installation (burst + minpoll 4 + maxpoll 4) to possibly stop using any server which sends back KOD, but only if it also uses the pool directive to actively search out the best servers. Maybe it's time to figure out how to auto-tune configurations as a better alternative than people keep following aged advice. In the meanwhile, make sure that good concrete advice with a section of don't do this anymore is on ntp.org. I don't want to think about users actively trying to generate as much traffic as possible. :-( Unfortunately we need to. The use of NTP features as accelerator in DDOS attack happen this spring. We had to turn of nice features, which in itself becomes a form of DOS. If we rather had ways to protect a server (remember that clients also act as servers) so that proper use does not cause loss of service, but aggressive use cause block-out. Soft-state remembering signaling peers for some time and then forget them to keep statistics of packets per time-period, and if the signaling peer acts reasonably well it is stays, overtransmitting packets will cause black-listing. KOD is the least, but inserting drop rules into the local host should follow, and possibly push the block rule into the network to clear off the machine and part of the network with the offending traffic. For cases like that, KOD won't help at all. Cheers, Magnus ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Thoughts on KOD
On Sun, 06 Jul 2014 12:28:09 +, Magnus Danielson wrote: On 07/06/2014 12:38 PM, Terje Mathisen wrote: Rob wrote: Harlan Stenn st...@ntp.org wrote: Discussion appreciated. I think it is best to remove KOD from ntpd. It does not serve a useful purpose, because precisely the kind of clients that you want to say goodbye to, do not support it. In real life it has either no effect at all, or it even has a negative effect because the client does not understand it and re-tries the request sooner than it would when no reply was sent at all. I'm afraid this is exactly right: KOD is a way to keep honest guys honest, i.e. it only helps against programmers/users why actually try (hard) to do the right thing. Currently it will cause a badly configured ntpd installation (burst + minpoll 4 + maxpoll 4) to possibly stop using any server which sends back KOD, but only if it also uses the pool directive to actively search out the best servers. Maybe it's time to figure out how to auto-tune configurations as a better alternative than people keep following aged advice. In the meanwhile, make sure that good concrete advice with a section of don't do this anymore is on ntp.org. A proper default configuration (i.e. no fiddling) already auto-tunes sufficient for 90% of the cases. I don't want to think about users actively trying to generate as much traffic as possible. :-( Unfortunately we need to. The use of NTP features as accelerator in DDOS attack happen this spring. We had to turn of nice features, which in itself becomes a form of DOS. If we rather had ways to protect a server (remember that clients also act as servers) so that proper use does not cause loss of service, but aggressive use cause block-out. Soft-state remembering signaling peers for some time and then forget them to keep statistics of packets per time-period, and if the signaling peer acts reasonably well it is stays, overtransmitting packets will cause black-listing. KOD is the least, but inserting drop rules into the local host should follow, and possibly push the block rule into the network to clear off the machine and part of the network with the offending traffic. For cases like that, KOD won't help at all. All the state table/KOD/filter rules mitigation approaches I have seen so far are limited to one server. Maybe time to take a look at a DNSBL-type approach for abusive clients; that way, once a client is labeled 'abusive', it will stop working with any of the pool servers that use the blacklist. Policies (for how long to auto-blacklist, how to prevent DoS by blacklisting the competition, how to 'promise to behave and express-delist' etc.) to be defined. -d ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
On Sun, Jul 6, 2014 at 2:25 AM, detha de...@foad.co.za wrote: Be sure to include some form of external RTC though. While sometimes useful a real time clock isn't required on a typical* S1 server. By the way, some GPS modules have an RTC which (if battery supported) will produce a reasonable date/time stamp before lock. *i.e. a date and time stamp can be retrieved from the S0 device. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Thoughts on KOD
Detha, On 07/06/2014 03:23 PM, detha wrote: On Sun, 06 Jul 2014 12:28:09 +, Magnus Danielson wrote: For cases like that, KOD won't help at all. All the state table/KOD/filter rules mitigation approaches I have seen so far are limited to one server. Maybe time to take a look at a DNSBL-type approach for abusive clients; that way, once a client is labeled 'abusive', it will stop working with any of the pool servers that use the blacklist. Policies (for how long to auto-blacklist, how to prevent DoS by blacklisting the competition, how to 'promise to behave and express-delist' etc.) to be defined. Maybe. For the moment I think it is sufficient if we provide a mechanism by which offenders gets reported to *some* system. We *could* also provide a method by which white/black-list can be dynamically set from an external source, so enough hooks exists, but I do not think that NTPD should be burned with the rest of that system. Once NTPD can report it feels offended by a source, and beyond KODing it also report to some external mechanism that could potentially block it by any external means, NTPD does not have to do much more. My point being with this line of thinking is that KOD in itself makes assumptions on the offending source actually respects it, and while KOD rules probably can be improved, it does not provide a very effective means of protection with sources not respecting KOD, and thus we also needs to think i broader terms. In my mind, the defenses is according to these lines: 0) NTPD tolerates a source, packet approval checks 1) NTPD does not tolerate a source, fires of KOD, source is expected to shut up 2) NTPD admin does not tolerate a source, blacklist it, NTPD will drop the traffic 3) NTPD admin does not tolerate a source, filters in in box firewall, box firewall drops the traffic 4) NTPD admin does not tolerate a source, filters in network firewall, network firewall drops the traffic Notice how step 2-4 moves the traffic load further away from NTPD process, interface and eventually subnetwork. What I proposed would allow for automation of these steps. It is reasonable that escalation should be done when a source does not respect KOD and keeps transmitting requests. It is also resonable that blocking times out, such that blocking is removed after some reasonable time, as offenders can be on dynamic addresses, and usually works over limited time when intentional. How to automate step 2-4 is however not a core concern for NTPD, but feeding the data out of NTPD in a way that is handy for such a mechanism is. Separate block-log file as I proposed is probably better than only a syslog file, as it removes the need to parse syslog for matching blocks, but rather can focus on changes in a dedicated file. Cheers, Magnus ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Thoughts on KOD
On 2014-07-05 15:40, Harlan Stenn wrote: Folks, I was chatting with PHK about: http://support.ntp.org/bin/view/Dev/NtpProtocolResponseMatrix http://bugs.ntp.org/show_bug.cgi?id=2367 and how we probably want to extend KOD coverage to more than just the limited case. I was assuming folks would want finer-grained control over this behavior, and thought about being able to choose any of kod-limited, kod-noserve, and kod-query. PHK suggested that we consider going the other way - KOD would mean Send KODs whenever appropriate. I wonder what the costs/benefits will be when weighing the extra complexity of multiple choices against when the defaults change and we get new behavior that we can't tune, that costs us in X and Y. This gets a bit more complicated when taking into consideration: - we'll get more traffic from a NAT gateway - - do we need to be able to configure a threshhold for this case? - we should pay attention to how a client, whom we find to be abusive, reacts to: - - getting no response - - getting a KOD response and adapt accordingly. Discussion appreciated. Add exponential backoff to KOD responses to each source address such that every time you get another packet within the threshold, you increase the timeout during which you ignore incoming packets, before you again send a KOD response: maybe use limit*count or leak^count for the repeat offenders. Avoid logging DoS possibilities by logging only when more than maxburst packets have been received, and increase that count each time logging occurs: log only each time a power of maxburst is exceeded: 8, 64, 512, ... Have the MRUlist manage itself such that it recycles entries only when they are more than minpoll seconds old, or the list has reached its size limit. Avoid memory and time issues by preallocating the desired MRUlist size at startup, and if that fails, retry with half the number of entries until it succeeds. Log a count of entries recycled sooner than minpool every hour (add to systats?) and log the MRUlist size allocated at startup. Ignore the NAT gateway issue: the NAT gateways will certainly ignore NTP just as they ignore BCP 38: no benefit until their clients complain and it costs them! ;^ -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
Jaap, You can skim over these past few months on the time-nuts list. There's lots of threads with discussion on ARM, Beaglebone, Rasberry Pi, etc... for GPS based NTP servers... http://www.febo.com/pipermail/time-nuts/2014-March/date.html http://www.febo.com/pipermail/time-nuts/2014-April/date.html http://www.febo.com/pipermail/time-nuts/2014-May/date.html I currently have about eight GPS based Soekris Net4501's running. Using either UT+ or M12+T GPS modules... Everything was sourced from eBay for cheap. I run NanoBSD on a CF card (It's a slimmed down FreeBSD 7)... I've never bothered with trying to tinker with newer hardware, I figure why try to reinvent the wheel. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Thoughts on KOD
On Sun, 06 Jul 2014 16:29:27 +, Magnus Danielson wrote: Detha, On 07/06/2014 03:23 PM, detha wrote: On Sun, 06 Jul 2014 12:28:09 +, Magnus Danielson wrote: For cases like that, KOD won't help at all. All the state table/KOD/filter rules mitigation approaches I have seen so far are limited to one server. Maybe time to take a look at a DNSBL-type approach for abusive clients; that way, once a client is labeled 'abusive', it will stop working with any of the pool servers that use the blacklist. Policies (for how long to auto-blacklist, how to prevent DoS by blacklisting the competition, how to 'promise to behave and express-delist' etc.) to be defined. Maybe. For the moment I think it is sufficient if we provide a mechanism by which offenders gets reported to *some* system. We *could* also provide a method by which white/black-list can be dynamically set from an external source, so enough hooks exists, but I do not think that NTPD should be burned with the rest of that system. Agreed, not core functionality for ntpd; but it would be nice to have a hook where one can 'vet' an incoming IP address, much like the RBL hooks are implemented in mail agents. Once NTPD can report it feels offended by a source, and beyond KODing it also report to some external mechanism that could potentially block it by any external means, NTPD does not have to do much more. My point being with this line of thinking is that KOD in itself makes assumptions on the offending source actually respects it, and while KOD rules probably can be improved, it does not provide a very effective means of protection with sources not respecting KOD, and thus we also needs to think i broader terms. In my mind, the defenses is according to these lines: 0) NTPD tolerates a source, packet approval checks 1) NTPD does not tolerate a source, fires of KOD, source is expected to shut up 2) NTPD admin does not tolerate a source, blacklist it, NTPD will drop the traffic 3) NTPD admin does not tolerate a source, filters in in box firewall, box firewall drops the traffic 4) NTPD admin does not tolerate a source, filters in network firewall, network firewall drops the traffic Notice how step 2-4 moves the traffic load further away from NTPD process, interface and eventually subnetwork. What I proposed would allow for automation of these steps. It is reasonable that escalation should be done when a source does not respect KOD and keeps transmitting requests. It is also resonable that blocking times out, such that blocking is removed after some reasonable time, as offenders can be on dynamic addresses, and usually works over limited time when intentional. How to automate step 2-4 is however not a core concern for NTPD, but feeding the data out of NTPD in a way that is handy for such a mechanism is. Separate block-log file as I proposed is probably better than only a syslog file, as it removes the need to parse syslog for matching blocks, but rather can focus on changes in a dedicated file. More logfiles that fill up disks. This is one time where KOD packets come in handy: it should be easy to construct a snort/whatever IDS signature for KOD packets, and let the IDS take care of firewalling off the offender as per site policy. Cheers, Magnus ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Thoughts on KOD
detha de...@foad.co.za wrote: Maybe. For the moment I think it is sufficient if we provide a mechanism by which offenders gets reported to *some* system. We *could* also provide a method by which white/black-list can be dynamically set from an external source, so enough hooks exists, but I do not think that NTPD should be burned with the rest of that system. Agreed, not core functionality for ntpd; but it would be nice to have a hook where one can 'vet' an incoming IP address, much like the RBL hooks are implemented in mail agents. The problem is that source addresses can be spoofed. There is the BCP38 document that recommends providers to implement countermeasures against that, but it is not widely followed, mostly because there is no financial gain for those that do it. This reminds me of the situation with open SMTP relays. Those once were common practice (and even had a function), and when it became apparent that they had to be closed because of the abuse, there also was a large number of providers that did not want to cooperate. There were forced to do so by an RBL system that started to refuse mail from systems that were not appropriately configured. Probably the only way to get BCP38 implemented is to develop a similar system that just rejects traffic orginating at providers who don't do source address filtering. Without that, NTP server operators are really helpless against attacks, both of their servers and backscatter attacks against innocent victims. But of course it is outside the scope of NTP to do this, it just happens that NTP is a recent victim of this wide misconfiguration problem. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Thoughts on KOD
On Sun, 06 Jul 2014 18:51:16 +, Rob wrote: detha de...@foad.co.za wrote: Maybe. For the moment I think it is sufficient if we provide a mechanism by which offenders gets reported to *some* system. We *could* also provide a method by which white/black-list can be dynamically set from an external source, so enough hooks exists, but I do not think that NTPD should be burned with the rest of that system. Agreed, not core functionality for ntpd; but it would be nice to have a hook where one can 'vet' an incoming IP address, much like the RBL hooks are implemented in mail agents. The problem is that source addresses can be spoofed. There is the BCP38 document that recommends providers to implement countermeasures against that, but it is not widely followed, mostly because there is no financial gain for those that do it. Not such a big problem; if the source address is spoofed, chances are 99.99% that the packet is part of some DDoS attack, and blacklisting that IP will frustrate that attack (which is why a 'central' place where abusers are logged would help against NTP reflection attacks: once triggered, a lot of potential reflectors become useless to the attacker). The 0.01% where the purpose of the spoofed IP was to get someone's IP blacklisted will have to be handled somehow, either with timeouts or express whitelisting. This reminds me of the situation with open SMTP relays. Those once were common practice (and even had a function), and when it became apparent that they had to be closed because of the abuse, there also was a large number of providers that did not want to cooperate. There were forced to do so by an RBL system that started to refuse mail from systems that were not appropriately configured. Probably the only way to get BCP38 implemented is to develop a similar system that just rejects traffic orginating at providers who don't do source address filtering. There are some differences between open SMTP relays and networks not implementing BCP38. TCP versus UDP, and to quote Paul Vixie from https://queue.acm.org/detail.cfm?id=2578510 ] ... but the big reason why SAV isn't the default is: SAV benefits only ] other people's customers, not an operator's own customers. ] ] There is no way to audit a network from outside to determine if it ] practices SAV. Any kind of compliance testing for SAV has to be done by ] a device that's inside the network whose compliance is in question. That ] means the same network operator who has no incentive in the first place ] to deploy SAV at all is the only party who can tell whether SAV is deployed. That, and mis-configured NTP servers, is why we still have reflection attacks. Without that, NTP server operators are really helpless against attacks, both of their servers and backscatter attacks against innocent victims. But of course it is outside the scope of NTP to do this, it just happens that NTP is a recent victim of this wide misconfiguration problem. The biggest problem with NTP is the amplification factor. With a 1:1 or even 1:1.5 amplification factor, the attacker won't bother, and move to the next target - SNMP is a good candidate. With a 1:12 or better ratio, the attacker is happy. One way to weed out misconfigured servers would be to take a page from the mail operators book about 10 years ago, probe the source of incoming NTP requests for a misconfigured server (supports monlist on the public side etc.) and blacklist that source. Draconian? Yes. Effective? Maybe. -d ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Thoughts on KOD
On -10.01.-28163 20:59, Harlan Stenn wrote: This gets a bit more complicated when taking into consideration: - we'll get more traffic from a NAT gateway - - do we need to be able to configure a threshhold for this case? Can't say much about KOD as-is, but here's my .02 on the net-behind-NAT scenario: If -- you want to fine-tune limits according to the number of actual clients behind the NAT, *or* -- want to keep providing service to genuine clients behind a NAT gateway while defending against co-located noncooperative bad apples then you have an interest to make the NATed clients identifiable (beyond what OS fingerprinting can do already). The straightforward approach to doing so would be to send out not plain go DIAFs, but messages along the lines of I'm willing to service your further requests *if* you label them with this random ID (and behave). Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
