February 2014 - Test - lists.nanog.org

Re: Need trusted NTP Sources
by Alexander Maassen 06 Feb '14

06 Feb '14

www.pool.ntp.org -------- Oorspronkelijk bericht -------- Van: Notify Me <notify.sina(a)gmail.com> Datum: Aan: "nanog(a)nanog.org list" <nanog(a)nanog.org>,afnog(a)afnog.org Onderwerp: Need trusted NTP Sources Hi ! I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, I'm not very knowledgeable about trusted sources therein. Please can anyone help with sources that wouldn't mind letting us sync from them? Thanks a lot!

4 3

Re: Need trusted NTP Sources
by Larry Sheldon 06 Feb '14

06 Feb '14

On 2/6/2014 8:24 PM, Jay Ashworth wrote: > Mailing lists aren't *supposed* to set Reply-To, Larry; your mail client is > supposed to have a Reply To List command. It does. And does not light up for most of the lists I am on (including one I "own"). I am apparently not bright enough to notice when it does light up. Most "consumer" MUAs, of course, > don't. > > Reply-All is a (usually) winked-upon subterfuge, or you can do like I > do and just manually readjust the To header when you reply to the list. The later apparently requiring even more brain power than I able to bring to bear on the problem. A FB community I am part of has several people in it that work in the same company--much flapping about a message sent to all--including people on continents who have no capability of being interested. Much don't send replies to "all"--sent to "all". > Just don't do what I do and accidentally set it to NANOG when you're > replying to a different list's message. :-) I was mildly chastised yesterday about a lengthy thread that I started about GPSs on MTRA when I could swear that I started on MTR. Old age has not been kind to me. > Cheers, > -- jra And I did consider sending this just to Jay, but decided the public humbling would be good. You need not bother everybody to tell me I was wrong. Again. It will get warm again someday. I'm pretty sure. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

1 0

Re: Need trusted NTP Sources
by Larry Sheldon 06 Feb '14

06 Feb '14

After all these years I still can not get used to the non-standard NANOG response to "reply". I wonder if there is a way for ne to fix that locally. On 2/6/2014 8:49 AM, Larry Sheldon wrote: > On 2/6/2014 4:43 AM, Nick Hilliard wrote: >> On 06/02/2014 10:03, Notify Me wrote: >>> I'm trying to help a company I work for to pass an audit, and we've >>> been told we need trusted NTP sources (RedHat doesn't cut it). >> >> So presuming that your company is using RH or Fedora or CentOS something, >> the auditors are claiming that Red Hat, Inc is trusted enough to >> provide a >> precompiled based operating system with no feasible means of proving its >> reliability, but that they're not trustworthy enough to provide a clock >> synchronisation service? >> >> My head spins. >> >> Get new auditors. Your current ones are stupid. > > It has been a while since I have done anything with NTP, but I would > start with ntp.org (which didn't exist when I WAS working with it) which > I am led to believe has the stuff that used to be at U. Delaware, like > the public servers lists: > > http://support.ntp.org/bin/view/Servers/WebHome > > -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

2 1

RE: Need trusted NTP Sources
by Martin Hotze 06 Feb '14

06 Feb '14

> I'm trying to help a company I work for to pass an audit, and we've > been told we need trusted NTP sources (RedHat doesn't cut it). Being > located in Nigeria, Africa, I'm not very knowledgeable about trusted > sources therein. > > Please can anyone help with sources that wouldn't mind letting us sync > from them? given that you trust the US-government (well, ...) you might use your own stratum 1 server using a Raspberry Pi with GPS. here is a well done how-to: http://open.konspyre.org/blog/2012/10/18/raspberry-pi-time-server/ I still need some spare time to get it running, all parts are here, but within my office location I have a bad GPS signal reception, so I have to do it at home. So build your own stratum 1 server (maybe a second one with DCF77 or whatever you can use for redundancy), off from these servers build 2 or more stratum 2 timeservers for redistribution to offload your stratum 1 servers. http://clepsydratime.com/Products/Time-Server-NTS3000 is a cool alternative. They are located in Poland, IIRC. And this box sells for less than 2,000 euros (this price is 2 years old). And it gives you GPS (USA), Glonass (Russia) and DCF77 (land based). One of the best Timeservers are sold by meinberg.de just my 2 euro-cents. #m

7 6

FW: Trusted Community Representation for Root KSK
by Leo Vegoda 06 Feb '14

06 Feb '14

Hi, People on this list might also want to submit responses. Regards, Leo From: dns-operations-bounces(a)mail.dns-oarc.net [mailto:dns-operations-bounces@mail.dns-oarc.net] On Behalf Of Kim Davies Sent: Thursday, February 06, 2014 12:38 PM To: DNS Operations Subject: [dns-operations] Trusted Community Representation for Root KSK Hi folks, ICANN is currently performing a consultation on how to evolve the participation of Trusted Community Representatives in the management of the root key signing key. I think this consultation is of particular interest to this group as ultimately these TCRs are there to instill trust in the DNS operations community that the KSK is being managed in a proper fashion. I'd encourage you to provide feedback to this consultation - available at http://www.icann.org/en/news/public-comment/tcr-dnssec-key-signing-21jan 14-en.htm - by 11th February. It is important we have a model of TCR participation that is satisfactory to the community. For convenience, here are the terms of reference replicated: Background Since July 2010, the DNS Root Zone has been secured using DNSSEC[1]. The model of using DNSSEC in the DNS Root Zone revolves around a "key signing key" (KSK) that is managed by ICANN in two secure facilities. Four times a year, a ceremony is conducted at these facilities to perform operations involving the KSK. As a key part of this process, a minimum of three from a pool of 21 trusted community representatives (TCRs) attend each ceremony to enable access to the secure materials, to witness the procedure, and to attest that the ceremony was conducted properly[2]. Each ceremony is attended by ICANN staff, the TCRs, representatives of the Root Zone Maintainer (Verisign), representatives of an independent audit firm retained by ICANN to monitor the process, and often additional external witnesses. Ceremonies are recorded by three audit cameras and webcast online. A typical ceremony lasts approximately four hours, and involves a process of temporarily removing the key signing key from a safe and performing key-signing operations in a secure manner following a formal script. The script is designed to perform each operation in a transparent manner to ensure the key signing key is only used for its proper purpose, and there is no ability for its contents to be disclosed for other purposes. Materials from each ceremony - such as the scripts, video recordings, and system output - are posted online[3]. De-briefings and discussions are conducted post-ceremony, where participants discuss how to improve future ceremonies. This feedback helps inform the evolution of the KSK ceremony to be both efficient and effective, while ensuring maximum trust in how ceremonies are performed. The TCRs were selected[4] from the global community based on a number of criteria[5]. These selection criteria relate to the volunteers ability to travel to ceremonies, conscientiously oversee the process, ensure transparency in its operation, and ultimately contribute to the broader community's trust that the private component of the key signing key has not been compromised. The TCRs are privately funded volunteers who are not reimbursed or compensated by ICANN for their participation nor their expenses. The original TCR proposal was silent on the length of service of individual TCRs. Of the 21 TCRs, seven are credentialed as "crypto officers" (COs) for each of the two facilities, and the remaining seven act as "recovery key shareholders" who only participate in ceremonies in the event the requisite number of COs are unable to participate or there is a need to rebuild the KSK following an unforeseen event. Of the seven COs for each facility, ICANN aims to have four attend each ceremony, with an absolute minimum of three required to successfully perform a ceremony. Each facility hosts two ceremonies per year, approximately once every six months. In practice, a TCR will attend at minimum one ceremony per year, and some will attend two in order to ensure sufficient attendance. Of the initial pool of 21 TCRs, one has resigned and been replaced from the pool of recovery key shareholders. No TCR has been removed owing to the other three criteria for replacement in the TCR selection document, relating to lack of integrity or trustworthiness; assumption of a conflicting role within a root management organization; or being unable to serve in their position. Based on feedback from the current TCRs and our experience from the first 14 ceremonies, we are reviewing what changes, if any, should be made to the current model of TCR participation. Comments Comments are welcome on any aspect of the consultation, and specifically on the following questions: 1. Is the current TCR model effectively performing its function of ensuring trust in the KSK management process? 2. Is the current size of the TCR pool appropriate to ensure sufficient participation in the ceremonies, while not overburdening the availability of specific volunteers? 3. Should there be a minimum level of participation required of a TCR in order to be considered to be successfully discharging their duties? 4. There is no standard provision to refresh the list of TCRs except when they are replaced due to inability to effectively perform their function. Should there be a process to renew the pool of TCRs, such as using term limits or another rotation mechanism? 5. The current model does not compensate TCRs for their services in order to ensure their independence from ICANN. a. Should the model of TCRs paying the costs of their participation be retained? b. Would some form of compensation to offset the expenses incurred by the TCRs detract from their independence in performing the role? c. If you support compensating TCRs for their expenses, are there requirements or limitations on whom the funding organization should be? Please send your comments to comments-tcr-dnssec-key-signing-21jan14(a)icann.org <mailto:comments-tcr-dnssec-key-signing-21jan14@icann.org> References [1] http://www.root-dnssec.org [2] https://www.iana.org/dnssec/icann-dps.txt [3] http://data.iana.org/ksk-ceremony/ [4] http://www.root-dnssec.org/tcr/selection-2010/ [5] http://www.root-dnssec.org/wp-content/uploads/2010/04/ICANN-TCR-Proposal -20100408.pdf kim

1 0

AT&T Security
by Justin Wilson 06 Feb '14

06 Feb '14

Anyone have a contact for AT&T security? I have a Denial of service attack going on for a customer with an AT&T Fiber Circuit. I called AT&T and they gave me an 888 number which is some security contractor. Justin -- Justin Wilson <j2sw(a)mtin.net> MTCNA CCNA MTCRE MTCWE - COMTRAIN Aol & Yahoo IM: j2sw http://www.mtin.net/blog xISP News http://www.zigwireless.com High Speed Internet Options http://www.thebrotherswisp.com The Brothers Wisp

1 0

Need trusted NTP Sources
by Notify Me 06 Feb '14

06 Feb '14

Hi ! I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, I'm not very knowledgeable about trusted sources therein. Please can anyone help with sources that wouldn't mind letting us sync from them? Thanks a lot!

4 5

RE: carrier comparison
by Martin Hotze 06 Feb '14

06 Feb '14

> My questions are: > > - Will we be sacrificing quality if we spring for Cogent? > (yesterday's Cogent/Verizon thread provided some cold chills for my spine) Jehova! Popcorn! :-) We used Cogent for some time. We dropped them, but not for poor quality (au contraire) but for other more complex reasons. IMHO, Cogent is far better than many say (any many of them only from 'knowledge' from word of mouth), Cogent has some oddities that you have to deal with, yust like with almost all other transit providers. Having said that: I don't want to be single homed again. hth, martin

1 0

Route Server Filters at IXPs and 4-byte ASNs
by Sebastian Spies 06 Feb '14

06 Feb '14

Hi there, as 2-byte ASNs are close to depletion (see NRO announcement this week), we have come across a topic, that might influence the adoption of 4-byte ASNs. First of all, we have no data or experience about 4-byte ASN adoption and are therefore unable to evaluate, if we should rush for the last available numbers. So here's the thing: IXPs usually implement N:M filtering based on standard community strings. As standard BGP communities support only 4 bytes, this only works for IXPs with 2-byte ASNs and peers with 2-byte ASNs. Extended communities to the rescue? We are not sure: While RFC4260 (Extended Communities) allows for <Global Admin,2bytes>:<Local Admin, 4bytes> community strings (3.1 Two-Octet AS Specific Extended Community), this works as long as the IXP itself uses a 2-byte ASN. What happens, if the IXP uses a 4-byte ASN? RFC5668 (4-Octet AS Specific BGP Extended Community) defines <Global Admin,4bytes>:<Local Admin, 2bytes>. I have been asking some IXP operators, about their practice and their reply was "4-byte ASNs are supported by our RS". What's your experience? Did you see IXPs, that do not support them? Do you think, the IXP operators are aware of this limitation? Have you seen IXPs with 4-byte ASNs or do RIRs reserve 2-byte ASNs for future IXPs? What other operational problems did you experience while using 4-byte ASNs? A lot of questions. I am very curious about your answers. Cheers, Sebastian -- SEBASTIAN SPIES lnked.in/sspies

10 15

Re: Need trusted NTP Sources
by Larry Sheldon 06 Feb '14

06 Feb '14

On 2/6/2014 9:02 AM, Nick Hilliard wrote: > On 06/02/2014 14:57, Larry Sheldon wrote: >> http://support.ntp.org/bin/view/Servers/PublicTimeServer000079 > > bear in mind that due to the vagaries of african peering weirdness, the > actual path from there to the OP's network could be over multiple satellite > links and peered in Asia, Europe or the US. The Internet in africa can be > ... odd. If it was me (having made a living getting with auditors who had no idea what they were doing) I would look for some close-by reliable (my judgement) 1- and 2- level sources (including, usually) the router at the ISP that I talk-to to get good service then add one or two the auditor likes. Larry (long time responder-to-audits that demanded that my UNIVAC and HP hardware and software look like IBM) -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

1 0