Re: Ukraine request yikes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There's no need for Ukraine to engage ICAAN to achieve its goals. Pretty much every nation has existing telecommunications laws with power for regulation to require telecommunications providers not to provide service to particular nation-states. Law written in an era where Russia military deployment and expansionary policy was front of mind. It's really up to each national leadership to decide if they wish to support the intent of Ukraine's request by issuing regulation. Much as nations are currently doing for the finance sector. - -glen -BEGIN PGP SIGNATURE- iF0EARECAB0WIQTe/Jmxd43ni8odCHCd+sN+Fh/aDwUCYiAIsgAKCRCd+sN+Fh/a DyJLAJ4tV31b2CmgavcUURWDcfj6uQFxPwCggKQmgp4lxjDe16t45Q6bPxYKGdQ= =FRhj -END PGP SIGNATURE-
Re: SFP oraganizers / storage recommendations
Hi Matthew There's a typical 10*SFP tray and less common 20* tray. Flexoptix, Fiberstore and others retail these (as well as use them to protect their transceivers in transit) or AliBaba gives lots of hits. Use a tray per transceiver part number and keep them vertical in an appropriately-sized box. If you have a lot of transceivers then use distinct boxes for SMF/MMF, 1G/10G/40G/100G, etc. If you're careful in your tray choice then the trays will also hold 4*XFP, 4*QSFP, etc. Using a small post-it note *on the inside* of the transparent cover is a convenient way to label the tray with the part number of the SFPs inside. Best wishes, glen
Re: SNMP syslocation field for GPS coordinates, and use with automation tools
Eric Kuhnke wrote: > Has anyone out there standardized on putting GPS coordinates in this > field [SNMP sysLocation] See also: the LOC record type in DNS. -glen
Re: MACsec SFP
On 30 Jun 2014, at 3:47 pm, Saku Ytti s...@ytti.fi wrote: On (2014-06-30 13:28 +0930), Glen Turner wrote: After the SFF Committee specifies the registers the operating system vendors or vendors of devices would then add commands to support to toggle the I2C needed to program those registers with MACsec keys, etc. This is what I tried to tackle, this creates chicken/egg scenario, no one is buying optic, because you can't program it from your router, and you can't program it in your router, as no one is using the optic and vendor won't put development hours on it. If instead there would be standardized (DHCP option like) system to code arbitrary value to arbitrary location, you could code the feature, without router understanding what it is, after a while, syntactic sugar might be added for convenience. What you really want isn’t DHCP-like, but simple AND-mask OR-set register handling. You’d provide your customers with the magic numbers. interface … gbic-register [if REGISTER AND-MASK VALUE]… [set REGISTER AND-MASK OR-VALUE]… gbic-register … Assuming that the GBIC programming doesn’t change PHY requirements you are done. -- Glen Turner http://www.gdt.id.au/~gdt/
Re: MACsec SFP
Perhaps such lag could be avoided in future if we'd specify some 'host to SFP' high level protocol, perhaps in much the same way as DHCP 'option' handling? The SFF Committee specifies GBIC registers. They’d be the appropriate group to add registers for features such as MACsec, Ethernet OAM and the like. I’d also encourage a common SFF Committee feature to query and update GBIC firmware and encourage SFP vendors to make firmware freely redistributable so that SFPs can be updated by the operating system as needed to avoid security exposures (and such a feature is problematic, as it would have to be written in such a way as to prevent it being used as another mechanism resellers can use to ‘lock’ SFP sales to their equipment sales). The Committee have already specified registers for tuneable SFPs. After the SFF Committee specifies the registers the operating system vendors or vendors of devices would then add commands to support to toggle the I2C needed to program those registers with MACsec keys, etc. You should not be able to set the MACsec key from the optical side. That feature is not only cryptographically dubious but it also requires that the 'forwarding plane' (which might otherwise be entirely hardware) be connected to the SFP’s management plane. That’s not desirable from a design or security point of view. Note carefully that I’m not discouraging a self-keying mode where GBICs don’t verify their partners but are proof against receive-only optical taps (and in that case I’d encourage the SFF Committee to specify that implementations print their fingerprint and the fingerprint of the partner GBIC, so that people can verify after the fact that the partner expected is the one encountered). -- Glen Turner http://www.gdt.id.au/~gdt/
Re: Requirements for IPv6 Firewalls
Fernando, Perhaps the document should have opened with a disclaimer that it is impossible to describe the full customer requirements for a firewall and thus a customer can reasonably add additional requirements. Then everyone knows where they stand and we avoid stupid (perhaps contractual) arguments that a firewall is acceptable solely because it meets this IETF publication. The document varies between specification and advice. My view is that it that as it stands the document is too specific to a particular type of firewall in a particular type of network to be anything other than advice, and should remove words such as specify. My view is that there is scope for a different document -- or a much later revision of this document -- which actually specifies the minimum acceptable behaviour of a IPv6 network boundary firewall. You need an copyeditor. Expressions such as but at times has also meant that a number of important/basic features have remained unimplemented by major firewall vendors, or that aforementioned features have not behaved as expected. are simply a poor use of the language. REQ GEN-5. Benchmarking is far too vague. Replace with a list of tests. REQ GEN-10 This is a requirement for the author of this specification. You should take that requirement and implement it throughout the document, and have a corresponding SNMP MIB which SHOULD be implemented. Counters we can't retrieve are pointless. REQ GEN-20 Define basic access control list. Is that drop-and-count on destination address prefix? That would be the understanding based on the use of that term in Cisco IOS for IPv4. REQ GEN-30 Which transport layers are required for stateless inspection? TCP? UDP? OSPF? REQ GEN-50 This should not be a general requirement at all. There are good reasons not to use TCP proxying, not the least of which is the load on the firewall. REQ GEN-70 Doesn't allowing ACLs meet the uRPF requirement for non-routers? Is a vendor which supports ACLs automatically compliant? If not, state so. REQ GEN-80 Redirection of HTTPS traffic independent of other traffic is a specific feature for content providers not justifying a MUST for all firewalls. REQ SPC-10 This requirement squibs the most important single statement you can make about a IPv6 firewall: defining ICMP types which SHOULD be forwarded and those which SHOULD NOT when crossing a network boundary. This was a major issue for IPv4 and requires greater depth for IPv6 then is given here. REQ SPC-20 List the extension headers which SHOULD and SHOULD NOT be filtered by default when crossing a network boundary. REQ SPC-30: List the routing headers which SHOULD and SHOULD NOT be filtered by default when crossing a network boundary. REQ SPC-40 List the options which SHOULD and SHOULD NOT be filtered by default when crossing a network boundary. REQ SPC-50 This requirement need much more work, as the specification is handwaving. REQ SPC-70 Cannot be implemented in anything but a simplistic network. ICMPv6 errors can come from anywhere on the forwarding path between the firewall and the host. The firewall cannot tell if a ICMPv6 from an unknown address is on the forwarding path for a connection. All it can do is validate uRPF, which is already a requirement. REQ SPC-80 Duplicate requirement REQ SPC-90 Poorly expressed. Rephrase in terms of packet parsing. REQ SPC-100 Rewriting Hop Limit? If you are going to proceed with the requirement then *reducing* Hop Limit is the only safe behaviour, and the only which a firewall SHOULD be required to support. If you are doing this to hide topology then the firewall manufacturer can reduce Hop Limit to the next lowest in a predefined set of values. Setting Hop Limit to an arbitrary value MAY be possible, and that should be accompanied by a note pointing out that this can lead to network failure unless all topologies containing the firewall are loop-free at all times. Why should a firewall support VPNs at all? Maybe you need to be clearer about the applicability of each section to a product. Do you mean that if a firewall implemented VPNs it must do so meeting these requirements? REQ VPN-20 is dynamic multipoint VPNs really a MUST for all VPN servers? You are saying that is it not possible for their to be a valid VPN design which does not include dynamic multipoint VPN. You'll excuse my doubt on that point. REQ VPN-60 needs more work. Some environments require certificates and keys to be manually altered. DOS. There are a lot of must be able to protect against which is handwaving. REQ DoS-70. This introduces a new requirement for filtering on VLAN or MPLS. That requirement needs to be higher in the document, not hidden. REQ DoS-80. I contest the MUST participate in blackhole infrastructure. There seems to be an assumption in this document that all valid IP firewalls designs are for use on Internet-connected networks. Ditto REQ DoS-85. REQ DoS-100. Underspecified. Or is detected the limit of
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
Jason Iannone wrote: I can't cite chapter and verse but I seem to remember this zeroing problem was solved decades ago by just introducing a bit which said this chunk of memory or disk is new (to this process) and not zeroed but if there's any attempt to actually access it then read it back as if it were filled with zeros, or alternatively zero it. That's true of virtual memory pages which are new to the process. But that isn't what malloc() usually returns, otherwise all malloc()ed allocations would require a 4KB virtual memory page. Rather malloc() and free() in the C library manage a pool of allocations and when that pool empties more virtual memory is allocated by using the brk() system call to ask the operating system for a new 4KB page of virtual memory -- which the operating system does set to zero, using the hardware to (perhaps lazily) set the page to zero if such a hardware feature is available. As a result the memory returned by malloc() often isn't zeroed and may contain data previously used by the process. Therefore a process can leak information between a program and its use of libraries. Because there is no inter-process information leakage this isn't seen as a problem in the traditional Unix view of security. You may have differing views if your program is a daemon servicing a multitude of networked users. Thus the interest in alternative malloc() and free() implementations. -- Glen Turner http://www.gdt.id.au/~gdt/
Re: BGP attributes through IGP
Saku Ytti wrote: It's essentially abusing (some what well-defined and interoperable abuse) 32b tag field for this purpose. That's pretty much what the OSPF tag and the BGP's synchronisation with OSPF were originally intended for. However it's pretty much a design misfeature and you'd be happier with iBGP over a tunnel -glen
Re: TWC (AS11351) blocking all NTP?
On 4 Feb 2014, at 9:28 am, Christopher Morrow morrowc.li...@gmail.com wrote: wait, so the whole of the thread is about stopping participants in the attack, and you're suggesting that removing/changing end-system switch/routing gear and doing something more complex than: deny udp any 123 any deny udp any 123 any 123 permit ip any any Which just pushes NTP to some other port, making control harder. We’ve already pushed all ‘interesting' traffic to port 80 on TCP, which has made traffic control very expensive. Let’s not repeat that history. -- Glen Turner http://www.gdt.id.au/~gdt/
Re: How big is the Internet?
Perhaps more interesting than bytes on backbones would be the median distance to an Internet-connected device. -glen
Re: Security over SONET/SDH
Link encryption isn't to protect the contents of the user's communication. There is no reason for users to trust their ISP more than a national institution full of people vetted to the highest level. What link encryption gets the user is protection from traffic analysis from parties other than the ISP. You've seen in the NSA documents how highly they regard this traffic analysis. I'd fully expect the NSA to collect it by other means. -glen -- Glen Turner http://www.gdt.id.au/~gdt/
Re: Security over SONET/SDH
On 23/06/2013, at 1:21 PM, William Allen Simpson wrote: What security protocols are folks using to protect SONET/SDH? At what speeds? Excuse me NSA, can I have export approval for one KG-530 SDH encryptor? What are the odds :-) And how would we know that the export model isn't simply providing a more convenient backdoor for the NSA? -glen
Re: IPv6 Netowrk Device Numbering BP
I have always been kind of partial to the idea of taking advantage IPv6 features and letting hosts set their own addresses with EUI-64 interface numbers. That's all fine and dandy until the NIC card is swapped out for a new one. It's best to use fixed IPv6 addresses for services (and have the service bind() to those) and use the EUI-64 address for machine-related tasks (ssh, backups, etc). You can use the same EUI-64 network for both, as the EUI-64 space is sparse and there are lots of never will be autoconfed address, conveniently including those with lots of zeroes. The router(s) interface addresses should be hardcoded within that EUI-64 subnet, and …::1/64, …::2/64 are the obvious choices. There's an issue of address exhaustion is you use /64 for router-router links, and the best suggestion I've seen there is to use /126, as that makes the last octet consistently …1 or …2 for each end of a point-to-point link, which is operationally nicer than stuffing about with binary in your head to determine which address to ping (i.e., you take your interface's address and replace the last hexnumeral with 1 or 2 to get your neighbours address). The exception to router link addressing would be links with eBGP neighbours, where using the ASN of the networks is just so convenient. You don't care much for correspondence between IPv4 and IPv6 addresses, except in the case of router loopback interfaces where it is very operationally convenient to be able to mentally determine is this the same router which I just saw in IPv4. Since you'll be typing those most often they are the obvious candidate for subnet zero so that :: reduces the typing to the minimum. The obvious thing to do is to reserve the entire …:00:00:00:00::/64 and use the bottom N bits of that to match the binary IPv4 address of the loopback. N could be 32 bits if you like excessive typing or have a really big network. I've seen a few schemes which try to decimal numerals of the IPv4 address in the IPv6 address, but I don't find any of them compelling. If you really, really think you want that, then putting the top 16b in hex numerals and the lower 16b in decimal numerals will do what you want without excessive address consumption. This sounds difficult to use, but operationally you soon get used to the hex prefix and only notice when it isn't one of the common ones. -- Glen Turner http://www.gdt.id.au/~gdt/
Re: VRF/MPLS on Linux
On Tue, 2011-08-23 at 13:45 +, na...@rhemasound.org wrote: While I have found some information on a project called linux-mpls I am having a hard time finding any solid VRF framework for Linux. The Linux kernel as shipped by Linus supports multiple routing tables and allows you to forward traffic from interfaces to differing tables -- that is, can implement VRF. The abstraction is better than on most routers, with policy routing allowing the selection of the routing table (to implement a VRF the policy is a simple if received on interface X then use realm N). Searching realms or running man ip will get you started. The Linus kernel does not have support for MPLS. You could patch the kernel, and then use Quagga as the router to populate the MPLS forwarding table. But personally, if you have a MPLS-speaking router upstream I'd simply bridge each MPLS tunnel into a VLAN to the Linux computer. Then you can use a stock vendor kernel, with its lack of maintenance hassles. -- Glen Turner http://www.gdt.id.au/~gdt/
Re: NANOG48 HD streams now active
7pm appears to be a bad time to tune in if you're in the UK... The streaming is very appreciated. A clock visible to the camera would save the hassle of translating local time to agenda time. -- Glen Turner http://www.gdt.id.au/~gdt/
Re: Using /126 for IPv6 router links
On 24/01/10 12:54, Owen DeLong wrote: Use the /64... It's OK... IPv6 was designed with that in mind. I'd suggest using a /126. For two reasons. 1) Using EUI-64 addresses on router-router links is an error, the consequences of which you encounter the first time you replace some faulty hardware.[1] I have made this error :-( If you are not using EUI-64 then assigning a non-autoconf /64 is no less or more work than assigning a non-autoconf /126. 2) Having a block of addresses for router-router links (and other blocks for other infrastructure such as loopbacks and unicast) makes ACLs much simpler. Using a /126 means that this block can last for a long, long time, reducing configuration maintenance. Cheers, Glen [1] Basically, interface addresses end up scattered through the router's configuration (some manufacturers are better than others in this regard). Tracking down all the references to an address and changing the config merely as the result of a hardware swap is painful and adds complexity at a time when it is not desired. -- Glen Turner http://www.gdt.id.au/~gdt/ Network Engineer Australia's Academic Research Network http://www.aarnet.edu.au/
Re: What DNS Is Not
On 10/11/09 01:58, Jack Bates wrote: And different CDN's behave differently, depending on how they deliver content, support provider interconnects, etc. I'd hardly call many of them DNS lies, as they do resolve you to the appropriate IP, and if that IP disappears, try and quickly get you to another appropriate IP. It depends what you mean by appropriate. It may not be least cost or closest, and that can be a rude shock when the CDN traffic suddenly costs you A$5/GB (delivered from the US by undersea cable) rather than $0 (delivered from an in-country peer). DNS is the wrong answer, simply because there's no way for the user to express *their* policy. But since there no CDN support in HTTP. -- Glen Turner http://www.gdt.id.au/~gdt/
Re: OT: Bringing Cisco equipment to US
On 30/06/09 07:59, John Edwards wrote: The courier will likely charge you less than a customs broker will for a single item - the brokers are mainly used for large transactions. While you're legally entitled to bring this equipment in carry-on luggage, proving and authenticating your right can be a costly and timely exercise. The other problem is that an import implies a change of ownership from an overseas company to a US company. Setting up a US holding company to own your imported US assets is a major pain and best avoided where possible. Especially as that company may be a a foreign telecommunications carrier and the US has rather wonderful laws covering those. I've done a lot of Australia-US import/export, and I'd very much suggest building a good relationship with a customs broker. That's hardly an expense you want for two switches, so buying the switches in the US (where they come with a valid warranty and correct power leads) is a good idea. I wouldn't recommend importing the switches through your luggage. The few times I've tried that arranging all of the documentation prior to travel has really sucked. As a trivial example of what can go wrong, if you unknowingly choose an airport where customs works 9am-5pm and your flight arrives at 2am, then you've got a rather long wait in the walkway between Immigration and Customs. So long a wait that you're likely to encounter some other difficulty from the airport authorities. -- Glen Turner http://www.gdt.id.au/~gdt/
Re: Dynamic IP log retention = 0?
William Allen Simpson wrote: Port scanning is rather common, and shouldn't be considered attacking -- unless it's taking a significant amount of bandwidth. Attempting to gain unauthorised access to a computing system is a crime in most countries. Port scanning is a tool used to gain unauthorised access. (Yes, port scanning can be used for other things, but it's difficult to argue for those when scanning someone else's machines.) A telecommunications carrier releasing a customer's details without their permission, to a non-investigatory third party, without a court order. Hmmm. It's certainly illegal here in Australia. And last I checked wasn't the US firm Hewlett Packard in trouble for hiring people to do just that? So your basic problem is that you have a law enforcement problem, and the law enforcers don't give this priority. Which leads to one of those vicious circle thingies, where the ISPs don't give a stuff about their customers running scans, since they aren't seeing any hassle from Mr Plod, those customers aren't seeing any consequences, and so the amount of scanning increases, to the extent where people believe it is normal and acceptable. Why not contact the FBI. Not because it will help. But because if even 1% of the libraries in the country do that then the FBI will take the path of least resistance, which is to hassle ISPs with enough warrants until the ISPs find it economic to clean up their act, at least with regard to their own customers. -- Glen Turner http://www.gdt.id.au/~gdt/
Re: Avg. Packet Size - Again?
[EMAIL PROTECTED] wrote: On Tue, 15 Jul 2008 16:44:48 PDT, Sean Hafeez said: I would be interested in find out what the average packet size people are seeing on their backbones is at this point and time? I predict that if you graph it, there's a ton of packets that are right around the MTU of the network. almost equal number of tiny packets carrying the ACK's of the mobygrams, and then a small noise level of everything else. Our network also shows peaks at the ethernet MTU (our MTU is higher than that) and the DNS packet size. -- Glen Turner http://www.gdt.id.au/~gdt/ Tel: 0416 295 857 or +61 416 295 857
Re: Cable Colors - A Standard
George Imburgia wrote: There's a standard; ANSI/TIA/EIA 606A http://www.flexcomm.com/library/606aguide.pdf Here in Australia there's no standard for colours of data communications patch cables. But there are some non-data communications standards for fixed cable colours. In particular, fire system sensors must use red; the use of cream is reserved for telephony; and fixed electrical cables must be white. To minimise error I avoid those colours for patch cables (ie, non-fixed cables). This is prudent anyway, as under the Wiring Rules simply tying down a patch lead with a cable tie is enough to turn it into a fixed cable. I've found that it's more important to have a ready supply of cable lengths (say 0.5m increments) and labels than to have colours. That avoids a mess developing in the first place that might need colour coding to sort out. We use blue, simply because it's the most readily available colour. The only cable which really needs a special colour is one which doesn't connect all eight pins in sequence. To avoid stocking many lengths of cross-over cables, we use a 0.6m crossover cable and a Cat6 joiner. We colour these pink -- it's noticeable and Real Men sysadmins don't steal them. A useful tool is a audio cable tracer. When disconnecting a PC you attach the signal injector. You then use the other half of the tool to identify the cable (it buzzes when near). This allows the patch cables to be pulled with certainty rather than left in the rack just in case it attached to some other host and you fear causing an unplanned outage. Also I've found that many cabling messes occur because the installer had no alternative. There was simply no cableway that wasn't congested. For high-density routers I've found that about 1/3rd of the rack is given over to cable patch panels and ring runs. About two racks in ten (ie, one optical, one UTP) need to be given over to just inter-rack patching and I'd encourage a specialist-built patch rack for that purpose. A rack full of PCs requires about 0.8m of available tray down the side of the rack to tie down the patch leads and other cables. Again, that huge amount of tray isn't usually provided, can't be added afterwards, and the installer has no choice but to do poor work if there's nothing to tie cables to. We ban non-fixed cabling between our racks, which means that patch cables only run within a rack. This simplifies things considerably. Fortunately, we've got the fiber density to racks to justify that design. I've noticed a considerable fall in the price of pre-assembled optical patch panels, so it's well worth looking at the prices even at low densities of cables to see if they fallen enough to make a fixed cabling system worthwhile. It's not like alternative -- those gutters used to pull optical patch leads between racks -- are cheap so I've expect the prices to cross at some stage in the next few years. Cheers, glen
Re: [NANOG] Microsoft.com PMTUD black hole?
Nathan Anderson/FSR wrote: A member of Microsoft's GNS network escalations team saw my postings on NANOG about this issue and took offense at my use of this forum to raise this issue with them, and criticized me as being unprofessional and lacking in business acumen. Hang on a tick. Aren't you one of their customers...looking through mail spool... As I pointed out in my post earlier today timestamped at 2:29PM, I was using an XP SP3 host to perform my tests with... ...why yes, you are. I can't think of any other supplier that would be so unprofessional and so lacking in business acumen as to say that their customer was UALIBI. Amazing. A fine case study of a person in customer contact undoing the work of millions of dollars in PR. Whatever you say about Steve Ballmer he's a great sales person at heart. He must despair at some of his staff. -- Glen Turner ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
