Re: Requirements for IPv6 Firewalls
Hi, Brandon, On 04/17/2014 08:20 PM, Brandon Ross wrote: On Thu, 17 Apr 2014, Sander Steffann wrote: Also, I note your draft is entitled Requirements for IPv6 Enterprise Firewalls. Frankly, no enterprise firewall will be taken seriously without address-overloaded NAT. I realize that's a controversial statement in the IPv6 world but until you get past it you're basically wasting your time on a document which won't be useful to industry. I disagree. While there certainly will be organisations that want such a 'feature' it is certainly not a requirement for every (I hope most, but I might be optimistic) enterprises. And I not only agree with Sander, but would also argue for a definitive statement in a document like this SPECIFICALLY to help educate the enterprise networking community on how to implement a secure border for IPv6 without the need for NAT. Having a document to point at that has been blessed by the IETF/community is key to helping recover the end-to-end principle. Such a document may or may not be totally in scope for a firewall document, but should talk about concepts like default-deny inbound traffic, stateful inspection and the use of address space that is not announced to the Internet and/or is completely blocked at borders for all traffic. Are you argung against of e.g. default-deny inbound traffic? Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Requirements for IPv6 Firewalls
On 4/18/14 10:16 PM, Matt Palmer mpal...@hezmatt.org wrote: On Fri, Apr 18, 2014 at 10:04:35PM -0400, Jeff Kell wrote: As to address the other argument in this threat on NAT / private addressing, PCI requirement 1.3.8 pretty much requires RFC1918 addressing of the computers in scope... has anyone hinted at PCI for IPv6? 1.3.8 lists use of RFC1918 address space as one of four possible implementations, immediately after the phrase may include, but are not limited to. I don't interpret that as pretty much requires RFC1918. It's not clear whether those are alternatives or should all be employed. An auditor will tend to recommend all of them. Now, if you'd like to claim that 1.3.8 is completely useless, I won't argue with you -- it's security-by-obscurity of the worst possible form. But don't blame PCI compliance for any inability to deploy IPv6, because it just ain't true. Methods used to meet the intent of this requirement may vary depending on the specific networking technology being used. For example, the controls used to meet this requirement may be different for IPv4 networks than for IPv6 networks. https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf Based on my experience with compliance auditors, they won't understand many of the words in this sentence, and will assume NAT and RFC1918. They can often (but not always) be taught, but you have to take the time to explain how IPv6 works, and how you prevent a reconnaissance attack. Many enterprise network administrators are not up to this task, unfortunately. ULA + NPT66 should be pretty easy to explain, both technically, and as a method of demonstrating compliance. However, preventing outbound route leaks of more-specifics, and blocking inbound recon attacks/probes *should* be equally compliant. Lee
Re: Requirements for IPv6 Firewalls
From: George Herbert george.herb...@gmail.com Date: Friday, April 18, 2014 7:11 PM To: Lee Howard l...@asgard.org Cc: Eugeniu Patrascu eu...@imacandi.net, draft-gont-opsec-ipv6-firewall-r...@tools.ietf.org draft-gont-opsec-ipv6-firewall-r...@tools.ietf.org, nanog@nanog.org nanog@nanog.org Subject: Re: Requirements for IPv6 Firewalls Lee Howard: So, yeah, you have to give your firewall administrator time to walk through the rules and figure out what they ought to be in IPv6. Your firewall administrator has been wanting to clean up the rules for the last two years, anyway. The arrogance in this assertion is amazing. What arrogance? I think I assert that IPv6 is time-consuming. There is no deploy IPv6 button. fwiw, I do have enterprise network experience. You're describing best practice. Yes, of course, you should have well documented technical and business needs for what's open and what's closed in firewalls, and should have traceability from the rules in place to the requirements, and be able to walk the rules and understand them and reinterpret them from v4 to v6, to a new firewall vendor, etc etc. Yes. Any publicly-traded company will have this because their auditors require it. I would think that companies without this documentation are probably not ready to deploy a new protocol. I concede that tracing the rules to the requirements is a hard one in practice (and a PITA in operational practice), but I don't think it's required to be able to map IPv4 rules to IPv6 rules. Again - THE INERTIA IN REAL ENTERPRISE ENVIRONMENTS SAYS OTHERWISE. To clarify: are you asserting that IPv6 uptake in enterprises is slow, which is a sign of inertia, and the reason is that firewalls are poorly documented and therefore we must have IPv6 NAT? Maybe lack of (perceived) business need is the reason more enterprises don't have IPv6. Again - policy community blinders on understanding what real systems are like out in the world has repeatedly shot the conversion in the legs. If you're going to start floating standards for this kind of stuff, then listen to feedback on why things are failing. I don't agree that things are failing. I would absolutely like to see enterprises adopt IPv6. Maybe at this stage enterprises with no firewall documentation are not good candidates for dual-stack. Those do seem to me to be the kind of clients who are likely to blame IPv6 for any problem, and insist it be turned off before any other troubleshooting. Lee
Re: Requirements for IPv6 Firewalls
On Mon, 21 Apr 2014, Fernando Gont wrote: Are you argung against of e.g. default-deny inbound traffic? Absolutely not, default deny of traffic should most certainly be one of the tools in the toolbox. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Skype: brandonross Schedule a meeting: http://www.doodle.com/bross
Re: Requirements for IPv6 Firewalls
On Mon, 21 Apr 2014 12:10:31 -0400, Lee Howard said: Methods used to meet the intent of this requirement may vary depending on the specific networking technology being used. For example, the controls used to meet this requirement may be different for IPv4 networks than for IPv6 networks. https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf Based on my experience with compliance auditors, they won't understand many of the words in this sentence, and will assume NAT and RFC1918. So there's the *real* problem in a nutshell. People think we're supposed to hobble our networks with crap design just because the auditors can't get their industry's shit together. pgpwrH2YJtFCI.pgp Description: PGP signature
Pluggable Coherent DWDM 10Gig
Anyone know if pluggable coherent DWDM 10Gig optics exist? (I'm finding no such thing.) How about narrow-band/filtered receive 10Gig optics? (Inline FBG filter receive side might be doable?) -- Tim: p.s. Before you ask, DTAG Terastream has got me thinking...
Re: Pluggable Coherent DWDM 10Gig
As a follow up, I did not miss a zero. TenGig. If you want to know why: https://ripe67.ripe.net/presentations/131-ripe2-2.pdf (I'll take 100Gig once I can get the optics for less than the cost of a v.nice sports car...) On Mon, Apr 21, 2014 at 2:42 PM, Tim Durack tdur...@gmail.com wrote: Anyone know if pluggable coherent DWDM 10Gig optics exist? (I'm finding no such thing.) How about narrow-band/filtered receive 10Gig optics? (Inline FBG filter receive side might be doable?) -- Tim: p.s. Before you ask, DTAG Terastream has got me thinking... -- Tim:
Re: Requirements for IPv6 Firewalls
On Mon, Apr 21, 2014 at 9:32 AM, Lee Howard l...@asgard.org wrote: You're describing best practice. Yes, of course, you should have well documented technical and business needs for what's open and what's closed in firewalls, and should have traceability from the rules in place to the requirements, and be able to walk the rules and understand them and reinterpret them from v4 to v6, to a new firewall vendor, etc etc. Yes. Any publicly-traded company will have this because their auditors require it. I would think that companies without this documentation are probably not ready to deploy a new protocol. I concede that tracing the rules to the requirements is a hard one in practice (and a PITA in operational practice), but I don't think it's required to be able to map IPv4 rules to IPv6 rules. You would think that any publicly-traded or sufficiently large or high profile company would have that because their auditors should require that. Yes, that's a reasonable assertion and hope. I regret to inform the discussion that it's a forlorn hope in a number of actual real world organizations. I'm not making noise to be remembered on the lists as a pissed off troublemaker. I've been doing enterprise IT consulting since the early 1990s, and am relaying what the state of reality is, and attempting to get people at various levels to deal with that rather than assume higher levels of competence than are really out there... -- -george william herbert george.herb...@gmail.com
Re: Pluggable Coherent DWDM 10Gig
You can get 100G-LR4 CFP for ~10k from good vendors. You can get them sub-10k from china what i'm hearing, but those failure rates are higher.. - Jared On Apr 21, 2014, at 2:57 PM, Tim Durack tdur...@gmail.com wrote: As a follow up, I did not miss a zero. TenGig. If you want to know why: https://ripe67.ripe.net/presentations/131-ripe2-2.pdf (I'll take 100Gig once I can get the optics for less than the cost of a v.nice sports car...) On Mon, Apr 21, 2014 at 2:42 PM, Tim Durack tdur...@gmail.com wrote: Anyone know if pluggable coherent DWDM 10Gig optics exist? (I'm finding no such thing.) How about narrow-band/filtered receive 10Gig optics? (Inline FBG filter receive side might be doable?) -- Tim: p.s. Before you ask, DTAG Terastream has got me thinking... -- Tim:
Re: DMARC - CERT?
* Christopher Morrow: I sort of wonder if this is really just yahoo trying to use a stick to motivate people to do the right thing? But what is the right thing here? Do we really want that *all* mailing lists must not provider reply to sender option to all their users? Will this list make the change? Probably not.
Re: Pluggable Coherent DWDM 10Gig
On Mon, Apr 21, 2014 at 2:57 PM, Tim Durack tdur...@gmail.com wrote: On Mon, Apr 21, 2014 at 2:42 PM, Tim Durack tdur...@gmail.com wrote: Anyone know if pluggable coherent DWDM 10Gig optics exist? (I'm finding no such thing.) How about narrow-band/filtered receive 10Gig optics? (Inline FBG filter receive side might be doable?) -- Tim: p.s. Before you ask, DTAG Terastream has got me thinking... As a follow up, I did not miss a zero. TenGig. If you want to know why: https://ripe67.ripe.net/presentations/131-ripe2-2.pdf (I'll take 100Gig once I can get the optics for less than the cost of a v.nice sports car...) As another follow-up, coherent 'cos I want tuned receive as well as transmit, so the WDM system can be truly colorless and directionless, plus the nice high CD limit would be great. Maybe I should ask for a pony too? :-) -- Tim:
Call for Presenations: NANOG 61 Data Center Track
Hi Everyone, We are soliciting presentation proposals for a 30m time slot during the Data Center Track being held at NANOG 61 in Bellevue, WA. See http://bit.ly/1rg4eyn for dates/location. The topics that we'd like to hear from you on are: - Data Center Infrastructure Management DCIM (use cases, design, benefits) - Medium Voltage (use, requirements, distribution technology, substations, benefits) - High Power and Dense Deployments (examples, u's, kW metrics, challenges, benefits) Presenter should be the subject matter expert related to the topic that you are submitting for consideration i.e. designer, developer, implementer, operator. We will be selecting one presentation. In order to be considered, we need your proposal and completed abstract no later than May 1, 2014. Contact us with your proposal or questions at: - Dan Golding dgold...@gmail.com - Martin Hannigan hanni...@gmail.com Best Regards, -M
Re: OT: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Fri, Apr 18, 2014 at 03:47:25PM -0700, Scott Weeks wrote: :: There being no cable between the Hawaiian Islands :: and the mainland at the time Wait...what? https://en.wikipedia.org/wiki/Submarine_communications_cable#Submarine_cables_across_the_Pacific The first trans-pacific cables were completed in 1902-03, linking the US mainland to Hawaii in 1902 and Guam to the Philippines in 1903. Canada, Australia, New Zealand and Fiji were also linked in 1902. Thanks! I slouch (really comfy chair) corrected. But the War Dept. didn't have the cable sent by cable. And I really am grateful for the information. -- Mike Andrews, W5EGO mi...@mikea.ath.cx Tired old sysadmin
Re: OT:[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years
--- mi...@mikea.ath.cx wrote: From: Mike A mi...@mikea.ath.cx On Fri, Apr 18, 2014 at 03:47:25PM -0700, Scott Weeks wrote: :: There being no cable between the Hawaiian Islands :: and the mainland at the time Wait...what? https://en.wikipedia.org/wiki/Submarine_communications_cable#Submarine_cables_across_the_Pacific The first trans-pacific cables were completed in 1902-03, linking the US mainland to Hawaii in 1902 and Guam to the Philippines in 1903. Canada, Australia, New Zealand and Fiji were also linked in 1902. Thanks! I slouch (really comfy chair) corrected. But the War Dept. didn't have the cable sent by cable. And I really am grateful for the information. --- No problem and no biggie. I have a picture of the guys in the ceremony for the first official message sent to the US mainland on my wall here because I have always been interested in the history of communications here in Hawaii since I first found out about ALOHAnet. :-) http://atlantic-cable.com//Article/1902-JournElec/1902-CPC-08.jpg http://atlantic-cable.com//Article/1902-JournElec scott
[Infowarrior] - FYI ~ attrition.org uses an invalid security certificate for mailing list sign-up
FYI... Say it isn't so In today's Heartbleed state of affairs... attrition.org uses an invalid security certificate. The certificate is not trusted because it is self-signed. The certificate is only valid for Lyger The certificate expired on 12/21/2012 1:44 PM. The current time is 4/21/2014 6:18 PM. (Error code: sec_error_expired_issuer_certificate) Ruff, Ruff...! Network IPdog Ephesians 4:32Cheers!!! A password is like a... toothbrush ;^) Choose a good one, change it regularly and don't share it. -Original Message- From: Scott Weeks [mailto:sur...@mauigateway.com] Sent: Friday, April 18, 2014 3:47 PM To: nanog@nanog.org Subject: OT: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] :: There being no cable between the Hawaiian Islands :: and the mainland at the time Wait...what? https://en.wikipedia.org/wiki/Submarine_communications_cable#Submarine_cables_across_the_Pacific The first trans-pacific cables were completed in 1902-03, linking the US mainland to Hawaii in 1902 and Guam to the Philippines in 1903. Canada, Australia, New Zealand and Fiji were also linked in 1902. scott --- mi...@mikea.ath.cx wrote: From: Mike A mi...@mikea.ath.cx On Mon, Apr 14, 2014 at 10:09:14PM +, Matthew Black wrote: IIRC, the message was sent via courier instead of cable or telephone to prevent interception. Did the military not even trust its own cryptographic methods? Or did they not think withdrawal of the Japanese ambassador was not very critical? The message was sent by Western Union. There being no cable between the Hawaiian Islands and the mainland at the time, the message went by commercial radio, in plaintext, and thence by civilian bicycle messenger (of Japanese ancestry, as it happened) to Fort Shafter, where it was read while the attack was in progress. David Kahn's fine book, _The Codebreakers_, discusses this in rather more detail. I recommend the original version; the paperback and later hardback editions contain rather less meat. -- Mike Andrews, W5EGO mi...@mikea.ath.cx Tired old sysadmin
Re: ATT / Verizon DNS Flush?
The default TTL should be 300 secs, esp with everyone switching A records to cloud providers, imho. That way, who ever is the SOA and the zone master, can update it based on design scale or sla of that provider. DNS needs a protocol refresh anyways. Dennis B. On Apr 16, 2014 7:30 PM, John Peach john-na...@peachfamily.net wrote: Looks to be godaddy. No surprise then. On Wed, 16 Apr 2014 12:56:59 -0400 valdis.kletni...@vt.edu wrote: On Wed, 16 Apr 2014 10:21:34 -0600, Steven Briggs said: Yeah...I know. Unfortunately, the domain was mishandled by our registrar, who imposed their own TTLs on our zone, THEN turned it back over to us with a 48HR TTL. Which is very bad. That's almost calling for a name-and-shame.
