Re: Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[Cameron Byrne]

On Nov 14, 2011 9:22 PM,  wrote:
>
> On Mon, 14 Nov 2011 19:06:13 EST, William Herrin said:
>
> > Using two firewalls in serial from two different vendors doubles the
> > complexity. Yet it almost always improves security: fat fingers on one
> > firewall rarely repeat the same way on the second and a rogue packet
> > must pass both.
>

Complexity equals downtime. I know at least one definition of security
includes availability .

> Fat fingers are actually not the biggest issue - a far bigger problem are
brain
> failures.  If you thought opening port 197 was a good idea, you will have
done
> it on both firewalls.  And it doesn't even help to run automated config
> checkers - because you'll have marked port 197 as "good" in there as
well. ;)
>
> And it doesn't even help with fat-finger issues anyhow, because you
*know* that
> if your firewall admin is any good, they'll just write a script that
loads both
> firewalls from a master config file - and then proceed to fat-finger said
> config file.

And, stateful firewalls are a very common dos vector.  Attacking firewall
sessions per second capacity and blowing up a session table can bring a
service down real quick. Furthermore, firewalls are frequently installed at
a choke point ... Which makes them a topological single point of
failure So, they are deployed in pairs  And therefore have a nice
cascading failure behavior when hit with a dos.

Cb

Re: Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[Valdis . Kletnieks]

On Mon, 14 Nov 2011 19:06:13 EST, William Herrin said:

> Using two firewalls in serial from two different vendors doubles the
> complexity. Yet it almost always improves security: fat fingers on one
> firewall rarely repeat the same way on the second and a rogue packet
> must pass both.

Fat fingers are actually not the biggest issue - a far bigger problem are brain
failures.  If you thought opening port 197 was a good idea, you will have done
it on both firewalls.  And it doesn't even help to run automated config
checkers - because you'll have marked port 197 as "good" in there as well. ;)

And it doesn't even help with fat-finger issues anyhow, because you *know* that
if your firewall admin is any good, they'll just write a script that loads both
firewalls from a master config file - and then proceed to fat-finger said
config file.



pgpkw7PimHs7X.pgp
Description: PGP signature

Re: Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[Jimmy Hess]

On Mon, Nov 14, 2011 at 2:55 PM, Jay Ashworth  wrote:

> The basic assertion made by proponents of this theory, when analyzed,
> amounts to "the probability that a firewall between a publicly routable
> internal network and the internet will fail in such a fashion as to pass
> packets addressed to internal machines is of the same close order as the
> probability that a DNAT router will fail in such a fashion as to allow
> people outside it to address packets to *arbitrary* internal machine IP
> addresses (assuming they have any way to determine what those are)."
[snip]

There is really no sound argument made that the probability is
inherently any different.
When we are referring to security devices failing to do what they are
supposed to do,
by definition,  the correct level of protection has been lost,  and
you have a serious
problem if this happens,  regardless of whether your firewall is a NAT
device or not.

What will be most important is you have solid layers of defense behind
the firewall,
such as host security,  IDS units,  monitoring, and scanning regimes
to detect the failure
of the firewall function.

The security appliance has failed, and all bets may be off.
It should be noted, that  "detecting"  a failed simple firewall with a
straight port scan
is a much simpler more easily automatable process than detecting a
failed 1:many
NAT firewall.

The ease of detecting the problem lowers the chance that you have a problem.


The potential security failure modes of a 1:many NAT firewall are much
more complicated
than "simply pass packets it's not supposed to pass";   the quirks of
the flaw mean that
with a NAT firewall, it is likely the failure of the firewall function
will go undetected by the
security admin,  resulting in a situation where you have an insidious problem...

that is, a problem that is not obvious,  but definitely exploitable to
a determined attacker.


Failure modes such as a "an intruder compromised the firewall"  and
injected a trojanned
firmware  result in equal risks regardless of whether NAT is implemented or not.


--
-JH

Re: airgap / negligent homicide charge

[James Downs]

On Nov 14, 2011, at 5:15 PM, Steven Bellovin wrote:

> And here's a quote from a legal textbook:

>   in this area of the law to those of the public.  In other
>   words, society may require of a person not to be awkward

If only that were more generally true.

-j

Re: airgap / negligent homicide charge

[Steven Bellovin]

Here's a quote from a famous court case (T.J. Hooper) on liability and industry
standards:

Indeed in most cases reasonable prudence is in face common prudence; but
strictly it is never its measure; a whole calling may have unduly lagged
in the adoption of new and available devices.  It may never set its own
tests, however persuasive be its usages.  Courts must in the end say what
is required; there are precautions so imperative that even their universal
disregard will not excuse their omission. 

And here's a quote from a legal textbook:

The standard of conduct imposed by the law is an external
one, based upon what society demands generally of its
members, rather than upon the actors personal morality or
individual sense of right and wrong.  A failure to conform
to the standard is negligence, therefore, even if it is due
to clumsiness, stupidity, forgetfulness, an excitable
temperament, or even sheer ignorance.  An honest blunder,
or a mistaken belief that no damage will result, may absolve
the actor from moral blame, but the harm to others is still
as great, and the actors individual standards must give way
in this area of the law to those of the public.  In other
words, society may require of a person not to be awkward
or a fool.

In other words, get real legal advice on the standard of care you should
observe.


On Nov 14, 2011, at 10:25 AM, Mickey Fox wrote:

> The determination of whether a failure rises to the level of negligent
> homicide will require a review of industry standards, company standards and
> sometimes straight common-sence.
> 
> If the industry standard is airgap re security you are probably okay so
> long as you review and address the very concerns and questions you are
> raising in a responsible fashion that does not rely solely on expediency,
> cost, etc., but looks to real-world scenarios and emergency / backup
> procedures, equipment, testing and training.
> 
> Mickey Fox
> CMK Consulting Services
> On Nov 14, 2011 9:00 AM,  wrote:
> 
>> Send NANOG mailing list submissions to
>>   nanog@nanog.org
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>   https://mailman.nanog.org/mailman/listinfo/nanog
>> or, via email, send a message with subject or body 'help' to
>>   nanog-requ...@nanog.org
>> 
>> You can reach the person managing the list at
>>   nanog-ow...@nanog.org
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of NANOG digest..."
>> 
>> 
>> Today's Topics:
>> 
>>  1. Re: Arguing against using public IP space
>> (valdis.kletni...@vt.edu)
>>  2. Re: Arguing against using public IP space (Joel jaeggli)
>>  3. Re: Arguing against using public IP space (Jimmy Hess)
>>  4. Re: Arguing against using public IP space (Owen DeLong)
>>  5. Re: Arguing against using public IP space (Dobbins, Roland)
>>  6. Cable standards question (Sam (Walter) Gailey)
>>  7. Re: Cable standards question (Daniel Seagraves)
>>  8. Re: Arguing against using public IP space (Joe Greco)
>>  9. Re: Arguing against using public IP space (Ray Soucy)
>> 
>> 
>> --
>> 
>> Message: 1
>> Date: Sun, 13 Nov 2011 21:43:32 -0500
>> From: valdis.kletni...@vt.edu
>> To: Brett Frankenberger 
>> Cc: NANOG 
>> Subject: Re: Arguing against using public IP space
>> Message-ID: <81357.1321238...@turing-police.cc.vt.edu>
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> On Sun, 13 Nov 2011 19:14:59 CST, Brett Frankenberger said:
>> 
>>> What if you air-gap the SCADA network of which you are in
>>> administrative control, and then there's a failure on it, and the people
>>> responsible for troubleshooting it can't do it remotely (because of the
>>> air gap), so the trouble continues for an extra hour while they drive
>>> to the office, and that extra hour of failure causes someone to die.
>>> Should that result in a homicide charge?
>> 
>> If you designed a life-critical airgapped network that didn't have a
>> trained
>> warm body at the NOC 24/7 with an airgapped management console, and hot
>> (or at
>> least warm) spares for both console and console monkey, yes, you *do*
>> deserve
>> that negligent homicide charge.
>> 
>> 
>> -- next part --
>> A non-text attachment was scrubbed...
>> Name: not available
>> Type: application/pgp-signature
>> Size: 227 bytes
>> Desc: not available
>> URL: <
>> http://mailman.nanog.org/pipermail/nanog/attachments/2013/247b47fe/attachment-0001.bin
>>> 
>> 
>> --
>> 
>> Message: 2
>> Date: Mon, 14 Nov 2011 10:59:45 +0800
>> From: Joel jaeggli 
>> To: Joe Greco 
>> Cc: NANOG 
>> Subject: Re: Arguing against using public IP space
>> Message-ID: <4ec08421.80...@bogus.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>> 
>> On 11/14/11 10:24 , Joe Greco wrote:
 Sure, anytime there's an attack or failure on 

equinix sv3 provider recommendations

[Jon Heise]

I'm setting up internet connectivity in the equinix SV3 datacenter, we are
already a level3 customer what other providers have been reliable from sv3.

Re: Arguing against using public IP space

[Jeroen van Aart]

William Herrin wrote:

If your machine is addressed with a globally routable IP, a trivial
failure of your security apparatus leaves your machine addressable
from any other host in the entire world which wishes to send it


Isn't that the case with IPv6? That the IP is addressable from any host 
in the entire (IPv6) world? And isn't that considered a good thing?


I don't think that being addressable from anywhere is a security hole in 
and of itself. It's how you implement and (mis)configure your firewall 
and related things that is the (potential) security hole. Whether the IP 
is world addressable or not



with all your stuff. Yet when you forget to throw the deadbolt, it
does stop an intruder from simply turning the knob and wandering in.


Personally I prefer car analogies when it comes to explaining (complex) 
computer matters. ;-)


Greetings,
Jeroen

--
Earthquake Magnitude: 5.2
Date: Monday, November 14, 2011 22:08:15 UTC
Location: eastern Turkey
Latitude: 38.6644; Longitude: 43.0993
Depth: 10.00 km

Re: Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[Jeff Kell]

On 11/14/2011 4:21 PM, Rubens Kuhl wrote:
> For the common good it doesn't matter if the "NAT is good" guys are
> right or the "NAT is useless" guys are right, as they both fail to
> decrease the numbers of their opposing parts. We must get IPv6 done
> for both of them.

Hehehe...  depending on your ISPs / transit providers / border
technology level, putting critical infrastructure on IPv6[only] might be
the safest most unreachable network of all :)

Jeff

Re: packet loss out of Texas on Cogent and GlobalCrossing

[McDonald Richards]

I take multiple services from Global Crossing in San Jose and have had
reports of packet loss from Cogent users in Chicago and London (and been
able to reproduce).

In all cases it appears to be after wherever Cogents' "mci01" location is.

 10.|-- te0-3-0-3.mpd21.mci01.atl  0.0%   100  205.7 205.2 204.5 207.7   0.7

 11.|-- te0-5-0-4.mpd21.ord01.atl  7.0%   100  238.4 235.6 230.4 239.1   2.0

 12.|-- te0-0-0-5.ccr21.bos01.atl  4.0%   100  315.1 315.0 314.6 316.7   0.3

 13.|-- te0-0-0-2.mpd21.lon13.atl 10.0%   100  323.7 323.7 321.6 325.7   0.7

 14.|-- te2-1.ccr01.lon01.atlas.c  6.0%   100  324.6 332.8 314.9 523.0  38.5

 15.|-- te1-2.mpd01.lon01.atlas.c  9.0%   100  326.3 339.3 324.9 506.0  39.5


10.|-- te0-4-0-3.mpd21.mci01.atl  0.0%   100  206.1 208.9 204.6 225.8   5.3

 11.|-- te0-4-0-3.mpd21.ord01.atl  3.0%   100  239.2 237.0 228.7 239.5   1.9

 12.|-- te0-0-0-1.ccr21.ord03.atl  4.0%   100  239.1 237.4 228.3 240.9   2.0

 13.|-- te2-1.mpd02.ord03.atlas.c  4.0%   100  228.0 235.2 227.0 350.2  23.9


McDonald


On Tue, Nov 15, 2011 at 7:52 AM, Charles Gagnon wrote:

> Good point, I can't seem to reproduce with the looking glass
> interfaces out there. They either don't use enough packets in sequence
> or don't through the problem hops. On this path:
>
> Send ICMP echos to 24.227.216.194, timeout is 2 seconds,  maximum hops
> are 32,1   0ms 1ms 0ms 74.201.153.2212   143ms
> 10ms0ms 216.52.95.893   1ms 1ms 1ms
> 77.67.70.974   1ms 1ms 1ms 213.200.66.2105   3ms
>   1ms 2ms 66.198.111.976   19ms7ms 7ms
> 216.6.87.97   7ms 7ms 7ms 216.6.87.28   6ms
> 7ms 7ms 66.198.154.149   6ms 7ms 6ms
> 107.14.19.13210  107ms   108ms   113ms   66.109.10.  118ms
>   144ms   120ms   107.14.17.13912  119ms   120ms   120ms
> 72.179.205.5913  115ms   115ms   114ms   24.73.240.19514
> 115ms   115ms   115ms   24.73.240.252
> I re-tested and using 100 msg counts, I get 3-6% packet loss on
> anything after 10. On hops 1-10, I'm all clean. That 66.109.10.11
> address is inside TimeWarner/RR so I'll keep trying to contact them.
>
>
> On Mon, Nov 14, 2011 at 2:23 PM, Eric Tykwinski 
> wrote:
> > Have you check the relevant looking glass sites?
> >
> > http://www.cogentco.com/en/network/looking-glass
> > http://www.globalcrossing.com/network/network_looking_glass.aspx
> >
> > We are connected to both providers, so everything is looking clean for
> us.
> >
> > Sincerely,
> >
> > Eric Tykwinski
> > TrueNet, Inc.
> > P: 610-429-8300
> > F: 610-429-3222
> >
> > -Original Message-
> > From: Charles Gagnon [mailto:charl...@unixrealm.com]
> > Sent: Monday, November 14, 2011 2:11 PM
> > To: nanog@nanog.org
> > Subject: packet loss out of Texas on Cogent and GlobalCrossing
> >
> > I need the Nanog intellect,
> >
> > We are seeing packet loss in certain scenarios only on traffic to and
> from
> > Austin, TX. The local provider is Time Warner and they are not having
> > (obvious) problems. We ran tests from NY and NJ over Internap and
> AboveNet
> > connections.We only see problems when the traffic goes over gblx or
> cogent.
> > Has anyone heard of problem with these carriers out of Texas?
> > --
> > Charles Gagnon
> > charlesg at unixrealm.com
> >
> >
> >
>
>
>
> --
> Charles Gagnon
> charlesg at unixrealm.com
>
>

Re: Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[William Herrin]

On Mon, Nov 14, 2011 at 6:01 PM, Lyndon Nerenberg  wrote:
> But a NAT implementation adds thousands of lines of code to the path the
> packets take, and any time you introduce complexity you decrease the overall
> security of the system.  And the complexity extends beyond the NAT box.
>  Hacking on IPsec, SIP, and lord knows what else to work around address
> rewriting adds even more opportunities for something to screw up.
>
> If you want security, you have to DEcrease the number of lines of code in
> the switching path, not add to it.

Hi Lyndon,

Counterpoint:

Using two firewalls in serial from two different vendors doubles the
complexity. Yet it almost always improves security: fat fingers on one
firewall rarely repeat the same way on the second and a rogue packet
must pass both.

The same two firewalls in parallel surely reduces security.


Is complexity the enemy of security? In general principle yes, but as
with many things IT DEPENDS.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[Michael Painter]

Jay Ashworth wrote:

- Original Message -

From: "Valdis Kletnieks" 



On the other hand, since a firewall's job is to stop packets you
don't want,


One of Marcus Ranum's "5 Stupidest Security Blunders" - "enumerating
badness".
A firewall's job isn't to stop unwanted packets, it's to pass only
wanted packets.


From 30,000ft those are equivalent.



Speaking of 30,000 ft., saw this on Dave Farber's IP list:

https://plus.google.com/u/0/110897184785831382163/posts/5qsNxFEaiML

Re: Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[Lyndon Nerenberg]

There really is no winner or "right way" on this thread. In IPv4 as a 
security guy we have often implemented NAT as an extra layer of obfuscation.


It's worse than just obfuscation.  The 'security' side effect of NAT can 
typically be implemented by four or five rules in a traditional firewall.


But a NAT implementation adds thousands of lines of code to the path the 
packets take, and any time you introduce complexity you decrease the 
overall security of the system.  And the complexity extends beyond the NAT 
box.  Hacking on IPsec, SIP, and lord knows what else to work around 
address rewriting adds even more opportunities for something to screw up.


If you want security, you have to DEcrease the number of lines of code in 
the switching path, not add to it.


Complexity is evil.  It's a shame this is no longer taught in computing 
courses. And I mean taught as a philosophy, not as a function of line 
count or any other bean-counter metrics.


--lyndon

RE: Cable standards question

[Sam (Walter) Gailey]

First off, thanks to everyone who has replied, both on and off list, I've 
gotten some very good information on this, raising things I hadn't considered, 
particularly involving testing and warranties.

Daniel Seagraves wrote:


Getting an installation that doesn't suck is indeed the core of the matter. 
However, "doesn't suck" is a rather vague concept as a point of law in case you 
have to sue your vendor for having installed something that sucks. That's why I 
was looking for a set of standards that I can point to and say (as an example)  
"your installation sucks, and it sucks because you didn't follow X standard, 
and ran unshielded fiber at a 90 degree angle over a knife edge."

< Maybe there should be a legal definition of the concept of suck, so that 
suckage could be contractually minimized.>

Unfortunately vendors install suckage all the time. Our own particular horror 
story was one of our schools where half the school was experiencing 
intermittent issues of crosstalk, lag, unexplained packet loss, etc. Some days 
it was fine, others it wasn't and it took us some time to find out that the 
cabling vendor had connected the two network closets via plain old cat 5 cable, 
a run that was considerably longer than 300 feet. You wouldn't normally expect 
to have to specify to telecommunications vendors that you don't exceed the 
maximum cable length, but there it was. We replaced that link with multimode, 
and the problems immediately vanished. I'm sure others have similar stories. 

A number of people have asked for more details on the project and I 
deliberately didn't put those in because I was looking more for a standard 
that, if followed, produces acceptable link no matter what the project details 
are. For the curious, it's a simple point-to-point link involving an existing 
building and new construction that are about a mile apart . It will be 
singlemode, we will provide the racks on both ends, and we're specifying SC 
terminations. Whether we own or lease the fiber, lit or dark, depends on the 
economics of the quotes that come back to us. It's not a complicated project, 
but I shouldn't have to re-write a cabling spec as part of the RFP just to keep 
the vendors honest. A number of good references have been sent to me so I think 
I'm all set. Thanks, NANOG! :)

---Sam 



-Original Message-
From: Daniel Seagraves [mailto:dseag...@humancapitaldev.com] 
Sent: Monday, November 14, 2011 9:58 AM
To: nanog@nanog.org
Subject: Re: Cable standards question


On Nov 14, 2011, at 8:42 AM, Sam (Walter) Gailey wrote:

> "The vendor will provide fiber connectivity between (building A) and 
> (building B). Vendor will be responsible for all building penetrations and 
> terminations. When  installing the fiber-optic cable the vendor will follow 
> the appropriate TIA/EIA 568 standards for fiber-optic cabling."
> 
> Any suggestions or examples of language would be very appreciated. Offlist 
> contact is probably best.

Is it appropriate to just say "When installing fiber-optic cable the vendor 
will ensure the resulting installation does not suck."?
That would seem to me to be the most direct solution to the problem. I mean, 
standards are all well and good, but what if the standard sucks?
Then you'd be up a creek.

Maybe there should be a legal definition of the concept of suck, so that 
suckage could be contractually minimized.

Re: Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[Mark Andrews]

Firewalls and NATs are "warm fuzzy feeling" devices.  The best way
to keep secure is to run up to date software and to only provide
services you need.

Firewalls and NAT both inhibit inventions.  Both really do very little
with modern operating systems that have been designed to be connected
without a firewall in front of them to the Internet.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[Michael Hallgren]

Le lundi 14 novembre 2011 à 15:43 -0600, -Hammer- a écrit :
> There really is no winner or "right way" on this thread. In IPv4 as a 
> security guy we have often implemented NAT as an extra layer of 
> obfuscation. In IPv6, that option really isn't there. So it's a cultural 
> change for me. I'm not shedding any tears. We've talked to our FW 
> vendors about various 6to6 and 4to6/6to4 options and we may consider it 
> but given the push in the IPv6 community for native addressing I really 
> am hesitant to add NAT functionality given that no one really knows what 
> the IPv6 future holds.

I consider that a good way of looking a things. ;)

Cheers,
mh

> 
> -Hammer-
> 
> "I was a normal American nerd"
> -Jack Herer
> 
> 
> 
> On 11/14/2011 02:55 PM, Jay Ashworth wrote:
> > Kill this subject if you're sick of it.
> >
> > - Original Message -
> >
> >> From: "Gabriel McCall"
> >>  
> >
> >> If your firewall is working
> >> properly, then having public addresses behind it is no less secure
> >> than private. And if your firewall is not working properly, then
> >> having private addresses behind it is no more secure than public.
> >>  
> > This assertion is frequently made -- it was made a couple other times
> > this morning -- but I continue to think that it doesn't hold much water,
> > primarly because it doesn't take into account *the probability of various
> > potential failure modes in a firewall*.
> >
> > The basic assertion made by proponents of this theory, when analyzed,
> > amounts to "the probability that a firewall between a publicly routable
> > internal network and the internet will fail in such a fashion as to pass
> > packets addressed to internal machines is of the same close order as the
> > probability that a DNAT router will fail in such a fashion as to allow
> > people outside it to address packets to *arbitrary* internal machine IP
> > addresses (assuming they have any way to determine what those are)."
> >
> > Hopefully, my rephrasing makes it clearer why those of us who believe that
> > there is, in fact, *some* extra security contributed by RFC 1918 and DNAT
> > in the over all stack tend not to buy the arguments of those who say that
> > in fact, it contributes none: they never show their work, so we cannot
> > evaluate their assertions.
> >
> > But in fact, as someone pointed out this morning in the original thread:
> > even if you happen to *know* the internal 1918 IP of the NATted target,
> > the default failure mode of the NAT box is "stop forwarding packets into
> > private network at all".
> >
> > Certainly, individual NAT boxes can have other failure modes, but each of
> > those extra layers adds at least another 0 to the probability p-number,
> > in my not-a-mathematician estimation.
> >
> > On the other hand, since a firewall's job is to stop packets you don't want,
> > if it stops doing it's just as a firewall, it's likely to keep on doing it's
> > other job: passing packets.  It certainly depends on the fundamental design
> > of the firewall, which I can't speak to generally... but you proponents of
> > "NAT contributes no security" can't, either.
> >
> >
> >> That makes sense, but I'm wondering if that should be considered correct
> >> behavior. Obviously a non-consumer grade router can have rules defining
> >> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
> >> everything coming from the outside in to either a) match up with
> >> something in the translation table, b) be a service the router itself is 
> >> hosting
> >> (http, etc), or c) be a port it explicitly forwards to the same inside
> >> host.
> >>  
> >
> >> Anything not matching one of those 3 categories you'd think could be
> >> dropped. Routing without translating ports and addresses seems like
> >> the root of the issue.
> >>  
> > It is.  And IME, the people who think NAT provides no security rarely if
> > ever seem to address that aspect of the issue.
> >
> > And, for what it's worth, I'm discussing the common case: 1-to-many incoming
> > DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on
> > other ports.
> >
> > Cheers,
> > -- jra
> >

Re: Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[Jay Ashworth]

- Original Message -
> From: "Valdis Kletnieks" 

> > On the other hand, since a firewall's job is to stop packets you
> > don't want,
> 
> One of Marcus Ranum's "5 Stupidest Security Blunders" - "enumerating
> badness".
> A firewall's job isn't to stop unwanted packets, it's to pass only
> wanted packets.

>From 30,000ft those are equivalent. 

When you get down below 5000ft, it starts to matter which approach you
take to it.

There are lots and lots of people, though, whose exposure to firewalls is
"a set of rules you drop over a router" -- in consequence of which there are
a lot of *firewalls* that are designed that way.

You're correct in implying that that's strategically bad, but both components
of that paragraph impact the issue.

> > if it stops doing it's just as a firewall, it's likely to keep on
> > doing it's other job: passing packets.
> 
> As a result, a firewall that fails open rather than closed is
> mis-designed.
> 
> And if you're deploying a firewall and don't know if the failure mode
> is open or closed, you probably get what you deserve when it fails.

Can't argue with that at all.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[-Hammer-]

There really is no winner or "right way" on this thread. In IPv4 as a 
security guy we have often implemented NAT as an extra layer of 
obfuscation. In IPv6, that option really isn't there. So it's a cultural 
change for me. I'm not shedding any tears. We've talked to our FW 
vendors about various 6to6 and 4to6/6to4 options and we may consider it 
but given the push in the IPv6 community for native addressing I really 
am hesitant to add NAT functionality given that no one really knows what 
the IPv6 future holds.


-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/14/2011 02:55 PM, Jay Ashworth wrote:

Kill this subject if you're sick of it.

- Original Message -
   

From: "Gabriel McCall"
 
   

If your firewall is working
properly, then having public addresses behind it is no less secure
than private. And if your firewall is not working properly, then
having private addresses behind it is no more secure than public.
 

This assertion is frequently made -- it was made a couple other times
this morning -- but I continue to think that it doesn't hold much water,
primarly because it doesn't take into account *the probability of various
potential failure modes in a firewall*.

The basic assertion made by proponents of this theory, when analyzed,
amounts to "the probability that a firewall between a publicly routable
internal network and the internet will fail in such a fashion as to pass
packets addressed to internal machines is of the same close order as the
probability that a DNAT router will fail in such a fashion as to allow
people outside it to address packets to *arbitrary* internal machine IP
addresses (assuming they have any way to determine what those are)."

Hopefully, my rephrasing makes it clearer why those of us who believe that
there is, in fact, *some* extra security contributed by RFC 1918 and DNAT
in the over all stack tend not to buy the arguments of those who say that
in fact, it contributes none: they never show their work, so we cannot
evaluate their assertions.

But in fact, as someone pointed out this morning in the original thread:
even if you happen to *know* the internal 1918 IP of the NATted target,
the default failure mode of the NAT box is "stop forwarding packets into
private network at all".

Certainly, individual NAT boxes can have other failure modes, but each of
those extra layers adds at least another 0 to the probability p-number,
in my not-a-mathematician estimation.

On the other hand, since a firewall's job is to stop packets you don't want,
if it stops doing it's just as a firewall, it's likely to keep on doing it's
other job: passing packets.  It certainly depends on the fundamental design
of the firewall, which I can't speak to generally... but you proponents of
"NAT contributes no security" can't, either.

   

That makes sense, but I'm wondering if that should be considered correct
behavior. Obviously a non-consumer grade router can have rules defining
what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
everything coming from the outside in to either a) match up with
something in the translation table, b) be a service the router itself is hosting
(http, etc), or c) be a port it explicitly forwards to the same inside
host.
 
   

Anything not matching one of those 3 categories you'd think could be
dropped. Routing without translating ports and addresses seems like
the root of the issue.
 

It is.  And IME, the people who think NAT provides no security rarely if
ever seem to address that aspect of the issue.

And, for what it's worth, I'm discussing the common case: 1-to-many incoming
DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on
other ports.

Cheers,
-- jra
   

Re: Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[Rubens Kuhl]

For the common good it doesn't matter if the "NAT is good" guys are
right or the "NAT is useless" guys are right, as they both fail to
decrease the numbers of their opposing parts. We must get IPv6 done
for both of them.

It seems that application reverse-proxies can make "NAT is good" guys
happy, so let's get it or some other solution on the market (both
commercial and open-source) and move on with what really matters,
getting v6 done.


Rubens


On Mon, Nov 14, 2011 at 6:55 PM, Jay Ashworth  wrote:
> Kill this subject if you're sick of it.
>
> - Original Message -
>> From: "Gabriel McCall" 
>
>>                                        If your firewall is working
>> properly, then having public addresses behind it is no less secure
>> than private. And if your firewall is not working properly, then
>> having private addresses behind it is no more secure than public.
>
> This assertion is frequently made -- it was made a couple other times
> this morning -- but I continue to think that it doesn't hold much water,
> primarly because it doesn't take into account *the probability of various
> potential failure modes in a firewall*.
>
> The basic assertion made by proponents of this theory, when analyzed,
> amounts to "the probability that a firewall between a publicly routable
> internal network and the internet will fail in such a fashion as to pass
> packets addressed to internal machines is of the same close order as the
> probability that a DNAT router will fail in such a fashion as to allow
> people outside it to address packets to *arbitrary* internal machine IP
> addresses (assuming they have any way to determine what those are)."
>
> Hopefully, my rephrasing makes it clearer why those of us who believe that
> there is, in fact, *some* extra security contributed by RFC 1918 and DNAT
> in the over all stack tend not to buy the arguments of those who say that
> in fact, it contributes none: they never show their work, so we cannot
> evaluate their assertions.
>
> But in fact, as someone pointed out this morning in the original thread:
> even if you happen to *know* the internal 1918 IP of the NATted target,
> the default failure mode of the NAT box is "stop forwarding packets into
> private network at all".
>
> Certainly, individual NAT boxes can have other failure modes, but each of
> those extra layers adds at least another 0 to the probability p-number,
> in my not-a-mathematician estimation.
>
> On the other hand, since a firewall's job is to stop packets you don't want,
> if it stops doing it's just as a firewall, it's likely to keep on doing it's
> other job: passing packets.  It certainly depends on the fundamental design
> of the firewall, which I can't speak to generally... but you proponents of
> "NAT contributes no security" can't, either.
>
>> That makes sense, but I'm wondering if that should be considered correct
>> behavior. Obviously a non-consumer grade router can have rules defining
>> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
>> everything coming from the outside in to either a) match up with
>> something in the translation table, b) be a service the router itself is 
>> hosting
>> (http, etc), or c) be a port it explicitly forwards to the same inside
>> host.
>
>> Anything not matching one of those 3 categories you'd think could be
>> dropped. Routing without translating ports and addresses seems like
>> the root of the issue.
>
> It is.  And IME, the people who think NAT provides no security rarely if
> ever seem to address that aspect of the issue.
>
> And, for what it's worth, I'm discussing the common case: 1-to-many incoming
> DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on
> other ports.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth                  Baylink                       
> j...@baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
>
>

Re: Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[Valdis . Kletnieks]

On Mon, 14 Nov 2011 15:55:14 EST, Jay Ashworth said:

> On the other hand, since a firewall's job is to stop packets you don't want,

One of Marcus Ranum's "5 Stupidest Security Blunders" - "enumerating badness".
A firewall's job isn't to stop unwanted packets, it's to pass only wanted 
packets.

> if it stops doing it's just as a firewall, it's likely to keep on doing it's
> other job: passing packets.

As a result, a firewall that fails open rather than closed is mis-designed.

And if you're deploying a firewall and don't know if the failure mode is open or
closed, you probably get what you deserve when it fails.


pgpgOteEtq8ss.pgp
Description: PGP signature

Ok; let's have the "Does DNAT contribute to Security" argument one more time...

[Jay Ashworth]

Kill this subject if you're sick of it.

- Original Message -
> From: "Gabriel McCall" 

>If your firewall is working
> properly, then having public addresses behind it is no less secure
> than private. And if your firewall is not working properly, then
> having private addresses behind it is no more secure than public.

This assertion is frequently made -- it was made a couple other times
this morning -- but I continue to think that it doesn't hold much water,
primarly because it doesn't take into account *the probability of various
potential failure modes in a firewall*.

The basic assertion made by proponents of this theory, when analyzed,
amounts to "the probability that a firewall between a publicly routable 
internal network and the internet will fail in such a fashion as to pass
packets addressed to internal machines is of the same close order as the
probability that a DNAT router will fail in such a fashion as to allow
people outside it to address packets to *arbitrary* internal machine IP
addresses (assuming they have any way to determine what those are)."

Hopefully, my rephrasing makes it clearer why those of us who believe that
there is, in fact, *some* extra security contributed by RFC 1918 and DNAT
in the over all stack tend not to buy the arguments of those who say that
in fact, it contributes none: they never show their work, so we cannot 
evaluate their assertions.

But in fact, as someone pointed out this morning in the original thread:
even if you happen to *know* the internal 1918 IP of the NATted target, 
the default failure mode of the NAT box is "stop forwarding packets into
private network at all".

Certainly, individual NAT boxes can have other failure modes, but each of
those extra layers adds at least another 0 to the probability p-number,
in my not-a-mathematician estimation.

On the other hand, since a firewall's job is to stop packets you don't want,
if it stops doing it's just as a firewall, it's likely to keep on doing it's
other job: passing packets.  It certainly depends on the fundamental design
of the firewall, which I can't speak to generally... but you proponents of
"NAT contributes no security" can't, either.

> That makes sense, but I'm wondering if that should be considered correct
> behavior. Obviously a non-consumer grade router can have rules defining
> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
> everything coming from the outside in to either a) match up with
> something in the translation table, b) be a service the router itself is 
> hosting
> (http, etc), or c) be a port it explicitly forwards to the same inside
> host.

> Anything not matching one of those 3 categories you'd think could be
> dropped. Routing without translating ports and addresses seems like
> the root of the issue.

It is.  And IME, the people who think NAT provides no security rarely if
ever seem to address that aspect of the issue. 

And, for what it's worth, I'm discussing the common case: 1-to-many incoming
DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on
other ports.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: packet loss out of Texas on Cogent and GlobalCrossing

[Charles Gagnon]

Good point, I can't seem to reproduce with the looking glass
interfaces out there. They either don't use enough packets in sequence
or don't through the problem hops. On this path:

Send ICMP echos to 24.227.216.194, timeout is 2 seconds,  maximum hops
are 32,1       0ms     1ms     0ms     74.201.153.2212       143ms
10ms    0ms     216.52.95.893       1ms     1ms     1ms
77.67.70.974       1ms     1ms     1ms     213.200.66.2105       3ms
  1ms     2ms     66.198.111.976       19ms    7ms     7ms
216.6.87.97       7ms     7ms     7ms     216.6.87.28       6ms
7ms     7ms     66.198.154.149       6ms     7ms     6ms
107.14.19.13210      107ms   108ms   113ms   66.109.10.      118ms
  144ms   120ms   107.14.17.13912      119ms   120ms   120ms
72.179.205.5913      115ms   115ms   114ms   24.73.240.19514
115ms   115ms   115ms   24.73.240.252
I re-tested and using 100 msg counts, I get 3-6% packet loss on
anything after 10. On hops 1-10, I'm all clean. That 66.109.10.11
address is inside TimeWarner/RR so I'll keep trying to contact them.


On Mon, Nov 14, 2011 at 2:23 PM, Eric Tykwinski  wrote:
> Have you check the relevant looking glass sites?
>
> http://www.cogentco.com/en/network/looking-glass
> http://www.globalcrossing.com/network/network_looking_glass.aspx
>
> We are connected to both providers, so everything is looking clean for us.
>
> Sincerely,
>
> Eric Tykwinski
> TrueNet, Inc.
> P: 610-429-8300
> F: 610-429-3222
>
> -Original Message-
> From: Charles Gagnon [mailto:charl...@unixrealm.com]
> Sent: Monday, November 14, 2011 2:11 PM
> To: nanog@nanog.org
> Subject: packet loss out of Texas on Cogent and GlobalCrossing
>
> I need the Nanog intellect,
>
> We are seeing packet loss in certain scenarios only on traffic to and from
> Austin, TX. The local provider is Time Warner and they are not having
> (obvious) problems. We ran tests from NY and NJ over Internap and AboveNet
> connections.We only see problems when the traffic goes over gblx or cogent.
> Has anyone heard of problem with these carriers out of Texas?
> --
> Charles Gagnon
> charlesg at unixrealm.com
>
>
>



-- 
Charles Gagnon
charlesg at unixrealm.com

Re: Cable standards question

[Jay Ashworth]

- Original Message -
> From: "Jason Gurtz" 

> For instance, we ended up with a 23" telco rack filled with 19" equipment
> and 23" to 19" converter panels. General tidiness; a contractor left a
> large splice-box laying on the floor in the midst of a slack-spool instead
> of wall or rack mounting. Another contractor developed a spider's nest of
> wiring in our server room instead of structured cabling. Specifying exact
> rack sizes, specific cable management, mounting locations, etc... would
> have helped a lot. Photos of the specific areas would have helped
> immensely.

This seems like an altogether excellent time for me to remind people about

  http://bestpractices.wikia.com

and volunteer it[1] as a place in which to capture these sorts of, among other
things, pictures of installs, both good and bad -- along with notes as to
*why* they are specifically good and/or bad.

Cheers,
-- jra
[1]Yes, it's gotten a bit spammed up; I'll clean it out if you'll use it.  ;-)
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: Arguing against using public IP space

[William Herrin]

On Mon, Nov 14, 2011 at 1:50 PM, McCall, Gabriel
 wrote:
> Chuck, you're right that this should not happen- but
> the reason it should not happen is because you have
> a properly functioning stateful firewall, not because
> you're using NAT. If your firewall is working properly,
> then having public addresses behind it is no less secure
> than private. And if your firewall is not working properly,
> then having private addresses behind it is no
> more secure than public. In either case, NAT gains
> you nothing over what you'd have with a firewalled
> public-address subnet.
>
> The fact that consumer cpe's typically do both nat
> and stateful firewalling does not mean that those
> functions are inseparable.

Gabriel,

This is not accurate.

First, many:1 NAT (sometimes also called PAT) is not separable from a
stateful firewall. You can build a stateful firewall without
many-to-one NAT but the reverse is not possible.

Second, while a security benefit from RFC 1918 addressing combined
with 1:1 NAT is dubious at best, the same is not true for the much
more commonly implemented many:1 NAT.

With RFC1918 plus many:1 NAT, most if not all functions of the
interior of the network are not addressable from far locations outside
the network, regardless of the correct or incorrect operation of the
security apparatus. This is an additional boundary which must be
bypassed in order to gain access to the network interior. While there
are a variety of techniques for circumventing this boundary no
combination of them guarantees successful breach. Hence it provides a
security benefit all on its own.

You would not rely on NAT+RFC1918 alone to secure a network and
neither would I. However, that's far from meaning that the use of
RFC1918 is never (or even rarely) operative in a network's security
process.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

packet loss out of Texas on Cogent and GlobalCrossing

[Charles Gagnon]

I need the Nanog intellect,

We are seeing packet loss in certain scenarios only on traffic to and
from Austin, TX. The local provider is Time Warner and they are not
having (obvious) problems. We ran tests from NY and NJ over Internap
and AboveNet connections.We only see problems when the traffic goes
over gblx or cogent. Has anyone heard of problem with these carriers
out of Texas?
-- 
Charles Gagnon
charlesg at unixrealm.com

RE: Arguing against using public IP space

[McCall, Gabriel]

Chuck, you're right that this should not happen- but the reason it should not 
happen is because you have a properly functioning stateful firewall, not 
because you're using NAT. If your firewall is working properly, then having 
public addresses behind it is no less secure than private. And if your firewall 
is not working properly, then having private addresses behind it is no more 
secure than public. In either case, NAT gains you nothing over what you'd have 
with a firewalled public-address subnet.

The fact that consumer cpe's typically do both nat and stateful firewalling 
does not mean that those functions are inseparable.


-Original message-
From: Chuck Church 
To: 'Phil Regnauld' 
Cc: "nanog@nanog.org" 
Sent: Sun, Nov 13, 2011 23:53:19 GMT+00:00
Subject: RE: Arguing against using public IP space

-Original Message-
From: Phil Regnauld [mailto:regna...@nsrc.org]


> PAT (overload) will have ports open listening for return traffic,
> on the external IP that's being "overloaded".

> What happens if you initiate traffic directed at the RFC1918
> network itself, and send that to the MAC address of the NAT device ?

> In many cases, it just works. That's how IP forwarding works, after
> all :)
>
> inside net --[NAT]---{ext net}[attacker]
> 192.168.0.0/24 .254 1.2.3.4 1.2.3.5

> S:1.2.3.5 D:192.168.0.1 next hop: 1.2.3.4
>
> Now, on the way back *out* from the inside net, traffic from
> 192.168.0.1 back to 1.2.3.4 might get translated - it depends if
> what the NAT is programmed to do if it sees, say, a S/A packet
> with no corresponding SYN, on its way out. It might just get
> dropped. UDP would in some cases get natted, but since you
> know your destination port on 1.2.3.5, you know what to expect,
> and you can build an asymmetric connection since you control the
> attacking host.
>
> Either way, you've still injected traffic into the inside net.
>

That makes sense, but I'm wondering if that should be considered correct
behavior. Obviously a non-consumer grade router can have rules defining
what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect
everything coming from the outside in to either a) match up with something
in the translation table, b) be a service the router itself is hosting
(http, etc), or c) be a port it explicitly forwards to the same inside host.
Anything not matching one of those 3 categories you'd think could be
dropped. Routing without translating ports and addresses seems like the
root of the issue.

Chuck

Copper not dead for super-fast broadband, says BT | Networking | ZDNet UK

[Network IP Dog]

http://www.zdnet.co.uk/news/networking/2011/11/11/copper-not-dead-for-super-
fast-broadband-says-bt-40094401/?ps=twitter

RE: Cable standards question

[Holmes,David A]

Formal construction contract bids use the Construction Specification Institute 
(CSI) format. There are 2 versions, I am familiar with and use the 1998 
version. The 1998 CSI format is broken up into 16 divisions (mechanical, civil, 
electrical, architectural, etc.). Electrical, where network cabling specs 
reside in the CSI 1998 version, are located in Division 16. The standard fiber 
optic spec is Division 16 16745. A web search on "fiber optic 16745 spec" will 
turn up various examples from real fiber optic construction bids, usually 
government contracts for large-scale construction projects such as highways, 
University campuses, municipal fiber builds, etc.

My suggestion is to look at existing 16745 specs, and modify them to your 
requirements.

-Original Message-
From: Sam (Walter) Gailey [mailto:gaile...@mansfieldct.org]
Sent: Monday, November 14, 2011 6:43 AM
To: nanog@nanog.org
Subject: Cable standards question

Hello, newbie question of the morning time, but hopefully not too off-topic...

I run a small town network. A new building is being built that the town wants 
fiber access to. I have to specify for vendors what it is that the town expects 
in the cabling. I am (obviously) not a fiber expert, and I'm having trouble 
phrasing the language of the RFP so that we are assured a quality installation.

My question is this; Is there an appropriate standard to specify for 
fiber-optic cabling that if it is followed the fiber will be installed 
correctly? Would specifying TIA/EIA 568-C.3, for example, be correct?

I'm envisioning something like;

"The vendor will provide fiber connectivity between (building A) and (building 
B). Vendor will be responsible for all building penetrations and terminations. 
When  installing the fiber-optic cable the vendor will follow the appropriate 
TIA/EIA 568 standards for fiber-optic cabling."

Any suggestions or examples of language would be very appreciated. Offlist 
contact is probably best.

Many thanks,

---Sam

This communication, together with any attachments or embedded links, is for the 
sole use of the intended recipient(s) and may contain information that is 
confidential or legally protected. If you are not the intended recipient, you 
are hereby notified that any review, disclosure, copying, dissemination, 
distribution or use of this communication is strictly prohibited. If you have 
received this communication in error, please notify the sender immediately by 
return e-mail message and delete the original and all copies of the 
communication, along with any attachments or embedded links, from your system.

RE: Cable standards question

[Jason Gurtz]

> How you phrase the requirements depends on what you want the end result
> to be.  Sorry to start this off with a wishy-washy statement, but when
> dealing with contractors, you have to be very specific with what you
> want, and stay involved during the project, to be sure the results are
> what you want.

This is *really* great advice. Standards are good, but it pays to have
due-diligence done about specific products and methods.

To the OP:

I witnessed a municipal fiber build-out, managed by someone in another
department who had essentially zero networking experience. His
consultants' all seemed experienced in conceptual layout, but not so much
the specific physical details. While this project was basically a success,
99% of the difficulties had to do with physical access details, site
remediation (power, racks, site-local cabling), and the specific fiber
related equipment such as splice boxes and patch panels.

For instance, we ended up with a 23" telco rack filled with 19" equipment
and 23" to 19" converter panels. General tidiness; a contractor left a
large splice-box laying on the floor in the midst of a slack-spool instead
of wall or rack mounting. Another contractor developed a spider's nest of
wiring in our server room instead of structured cabling. Specifying exact
rack sizes, specific cable management, mounting locations, etc... would
have helped a lot. Photos of the specific areas would have helped
immensely.

Some of the delivered patch panels were of low quality (many of the
connectors were faulty, requiring extra labor to clean and re-polish).
Caveat emptor! Find what the good brands are and specify (maybe others can
comment here). Go take a look at vendor websites like Middle Atlantic and
see what options are out there. Some things are just easier and more
convenient to use. The devil is in the details.

A building-to-building connection is clearly easier than lighting up a
city but you will still be stuck with what you get. You can never plan
enough.

~JasonG

Re: Cable standards question

[Justin M. Streiner]

On Mon, 14 Nov 2011, Sam (Walter) Gailey wrote:

My question is this; Is there an appropriate standard to specify for 
fiber-optic cabling that if it is followed the fiber will be installed 
correctly? Would specifying TIA/EIA 568-C.3, for example, be correct?


I'm envisioning something like;

"The vendor will provide fiber connectivity between (building A) and 
(building B). Vendor will be responsible for all building penetrations 
and terminations. When  installing the fiber-optic cable the vendor will 
follow the appropriate TIA/EIA 568 standards for fiber-optic cabling."


How you phrase the requirements depends on what you want the end result to 
be.  Sorry to start this off with a wishy-washy statement, but when 
dealing with contractors, you have to be very specific with what you want, 
and stay involved during the project, to be sure the results are what you 
want.


It's a good idea to define very clearly what is "in scope" and "out of 
scope" for the contractor up front.  This can include things like the 
contractor being responsible for submitting any one-call requests 
per your localities' guidelines for any work that requires digging, or 
restoring any items that have to be removed (landscaping, sidewalks, 
paved roadways, etc) to facilitate digging.


For example, do the buildings in question already have usable entrance 
facilities for communications (aerial/underground entrances, suitable 
demarc locations in each building, cable pathways from the exterior 
penetrations to the demarc point)?  If not, you will generally need to 
spell out exactly what the fiber contractor (or a sub-contractor) is 
expected to provide (conduits from comms manhole/utility vault/pole/etc). 
Typically you will need to define a place in each building where the 
fiber will land, which will either be in a rack or on a wall.


Also, at a minimum, the contractor should 1. test all strands at the 
appropriate wavelengths, 2. provide you with documentation of the test 
results, and 3. general fit-and-finish/workmanship items such as making 
sure all connectors have dust caps and any required labeling of the 
termination bays.


Where I work, we have detailed construction / installation standards that 
get added to the bid package of any new construction or major renovation 
on our campus.  If you want, I can send you a copy (off-list) of the 
relevant pieces of our Division 27 specs that go out to contractors as 
part of our construction bid packages.


jms

RE: Cable standards question

[Kenneth M. Chipps Ph.D.]

BICSI has a sample RFQ for this purpose. You can use the whole thing or just
pull out the cabling phrase. You will need to update the standard names to
the current ones.

https://www.bicsi.org/single.aspx?l=1866

Kenneth M. Chipps Ph.D.

-Original Message-
From: Sam (Walter) Gailey [mailto:gaile...@mansfieldct.org] 
Sent: Monday, November 14, 2011 8:43 AM
To: nanog@nanog.org
Subject: Cable standards question

Hello, newbie question of the morning time, but hopefully not too
off-topic...

I run a small town network. A new building is being built that the town
wants fiber access to. I have to specify for vendors what it is that the
town expects in the cabling. I am (obviously) not a fiber expert, and I'm
having trouble phrasing the language of the RFP so that we are assured a
quality installation.

My question is this; Is there an appropriate standard to specify for
fiber-optic cabling that if it is followed the fiber will be installed
correctly? Would specifying TIA/EIA 568-C.3, for example, be correct?

I'm envisioning something like;

"The vendor will provide fiber connectivity between (building A) and
(building B). Vendor will be responsible for all building penetrations and
terminations. When  installing the fiber-optic cable the vendor will follow
the appropriate TIA/EIA 568 standards for fiber-optic cabling."

Any suggestions or examples of language would be very appreciated. Offlist
contact is probably best.

Many thanks,

---Sam

Re: Cable standards question

[Jay Ashworth]

- Original Message -
> From: "Jonathan Lassoff" 

> I'd agree with this. I wouldn't worry about the standard so much as the
> practical aspects of a run. Once you have an idea of the approximate
> distance of the run, you can figure out which optics you plan on
> using. This will determine what physical connectors you'll need and what your
> approximate link budget will be.
> 
> Based on that information, you can figure out which type to ask for
> (9um/125um single-mode, most likely), a range of path loss that you're
> comfortable with, and the physical termination you'd like at either
> end.

You Jon people[1] are, as near as I can tell, answering a question the OP didn't
actually ask.  It may in fact be that he didn't realize he should spec the 
design down to that level, but it sounded to me like what he was looking for
was "what language should I put in there to constrain the quality of the
implementation?"

Cheers,
-- jra
[1] :-)
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: Cable standards question

[Jonathan Lassoff]

On Mon, Nov 14, 2011 at 7:12 AM, Jon Lewis  wrote:

> On Mon, 14 Nov 2011, Sam (Walter) Gailey wrote:
>
>  My question is this; Is there an appropriate standard to specify for
>> fiber-optic cabling that if it is followed the fiber will be installed
>> correctly? Would specifying TIA/EIA 568-C.3, for example, be correct?
>>
>> I'm envisioning something like;
>>
>> "The vendor will provide fiber connectivity between (building A) and
>> (building B). Vendor will be responsible for all building penetrations and
>> terminations. When installing the fiber-optic cable the vendor will follow
>> the appropriate TIA/EIA 568 standards for fiber-optic cabling."
>>
>
> At minimum, I think you should probably specify the type and number of
> fibers you want.  i.e. Based on the distance and gear you'll be using, do
> you need single-mode, or will multi-mode do (as well as the core/cladding
> diameter)?  Generally, but not always, fiber uses one strand for transmit
> and another for receive, so a typical fiber run is done using duplex fiber.
>  Some optics can transmit and receive over one strand using different
> wavelengths.  You might even specify how you want the fiber terminated (SC,
> LC, cables hanging from the wall, fiber patch panel, etc.).
>

I'd agree with this. I wouldn't worry about the standard so much as the
practical aspects of a run. Once you have an idea of the approximate
distance of the run, you can figure out which optics you plan on using.
This will determine what physical connectors you'll need and what your
approximate link budget will be.

Based on that information, you can figure out which type to ask for
(9um/125um single-mode, most likely), a range of path loss that you're
comfortable with, and the physical termination you'd like at either end.

Cheers,
jof

Re: airgap / negligent homicide charge

[Mickey Fox]

The determination of whether a failure rises to the level of negligent
homicide will require a review of industry standards, company standards and
sometimes straight common-sence.

If the industry standard is airgap re security you are probably okay so
long as you review and address the very concerns and questions you are
raising in a responsible fashion that does not rely solely on expediency,
cost, etc., but looks to real-world scenarios and emergency / backup
procedures, equipment, testing and training.

Mickey Fox
CMK Consulting Services
On Nov 14, 2011 9:00 AM,  wrote:

> Send NANOG mailing list submissions to
>nanog@nanog.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>https://mailman.nanog.org/mailman/listinfo/nanog
> or, via email, send a message with subject or body 'help' to
>nanog-requ...@nanog.org
>
> You can reach the person managing the list at
>nanog-ow...@nanog.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of NANOG digest..."
>
>
> Today's Topics:
>
>   1. Re: Arguing against using public IP space
>  (valdis.kletni...@vt.edu)
>   2. Re: Arguing against using public IP space (Joel jaeggli)
>   3. Re: Arguing against using public IP space (Jimmy Hess)
>   4. Re: Arguing against using public IP space (Owen DeLong)
>   5. Re: Arguing against using public IP space (Dobbins, Roland)
>   6. Cable standards question (Sam (Walter) Gailey)
>   7. Re: Cable standards question (Daniel Seagraves)
>   8. Re: Arguing against using public IP space (Joe Greco)
>   9. Re: Arguing against using public IP space (Ray Soucy)
>
>
> --
>
> Message: 1
> Date: Sun, 13 Nov 2011 21:43:32 -0500
> From: valdis.kletni...@vt.edu
> To: Brett Frankenberger 
> Cc: NANOG 
> Subject: Re: Arguing against using public IP space
> Message-ID: <81357.1321238...@turing-police.cc.vt.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> On Sun, 13 Nov 2011 19:14:59 CST, Brett Frankenberger said:
>
> > What if you air-gap the SCADA network of which you are in
> > administrative control, and then there's a failure on it, and the people
> > responsible for troubleshooting it can't do it remotely (because of the
> > air gap), so the trouble continues for an extra hour while they drive
> > to the office, and that extra hour of failure causes someone to die.
> > Should that result in a homicide charge?
>
> If you designed a life-critical airgapped network that didn't have a
> trained
> warm body at the NOC 24/7 with an airgapped management console, and hot
> (or at
> least warm) spares for both console and console monkey, yes, you *do*
> deserve
> that negligent homicide charge.
>
>
> -- next part --
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 227 bytes
> Desc: not available
> URL: <
> http://mailman.nanog.org/pipermail/nanog/attachments/2013/247b47fe/attachment-0001.bin
> >
>
> --
>
> Message: 2
> Date: Mon, 14 Nov 2011 10:59:45 +0800
> From: Joel jaeggli 
> To: Joe Greco 
> Cc: NANOG 
> Subject: Re: Arguing against using public IP space
> Message-ID: <4ec08421.80...@bogus.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 11/14/11 10:24 , Joe Greco wrote:
> >> Sure, anytime there's an attack or failure on a SCADA network that
> >> wouldn't have occurred had it been air-gapped, it's easy for people to
> >> knee-jerk a "SCADA networks should be airgapped" response.  But that's
> >> not really intelligent commentary unless you carefully consider what
> >> risks are associated with air-gapping the network.
> >
> > Not to mention that it's not the only way for these things to get
> > infected.  Getting fixated on air-gapping is unrealistically ignoring
> > the other threats out there.
> >
> > There needs to be a whole lot more security work done on SCADA nets.
>
> Stuxnet should provide a fairly illustrative example.
>
> It doesn't really matter how well isolated from direct access it is if
> it has a soft gooey center and a willing attacker.
>
> > ... JG
>
>
>
>
> --
>
> Message: 3
> Date: Sun, 13 Nov 2011 21:48:01 -0600
> From: Jimmy Hess 
> To: David Walker 
> Cc: nanog@nanog.org
> Subject: Re: Arguing against using public IP space
> Message-ID:
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, Nov 13, 2011 at 3:03 PM, David Walker 
> wrote:
> > On 14/11/2011, Jimmy Hess  wrote:
> > A packet addressed to an endpoint that doesn't serve anything or have
> > a client listening will be ignered (whatever) as a matter of course.
> > Firewall or no firewall.
> It will not go to a listening application,  neither will it be
> completely ignored --
> the receiving machine's  TCP stack will have a look at the packet.
> On common operating systems there  are frequently unsafe applications
> listening on ports;

Re: Cable standards question

[Jon Lewis]

On Mon, 14 Nov 2011, Sam (Walter) Gailey wrote:


My question is this; Is there an appropriate standard to specify for 
fiber-optic cabling that if it is followed the fiber will be installed 
correctly? Would specifying TIA/EIA 568-C.3, for example, be correct?

I'm envisioning something like;

"The vendor will provide fiber connectivity between (building A) and 
(building B). Vendor will be responsible for all building penetrations 
and terminations. When installing the fiber-optic cable the vendor will 
follow the appropriate TIA/EIA 568 standards for fiber-optic cabling."


At minimum, I think you should probably specify the type and number of 
fibers you want.  i.e. Based on the distance and gear you'll be using, do 
you need single-mode, or will multi-mode do (as well as the core/cladding 
diameter)?  Generally, but not always, fiber uses one strand for transmit 
and another for receive, so a typical fiber run is done using duplex 
fiber.  Some optics can transmit and receive over one strand using 
different wavelengths.  You might even specify how you want the fiber 
terminated (SC, LC, cables hanging from the wall, fiber patch panel, 
etc.).


--
 Jon Lewis, MCP :)   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Arguing against using public IP space

[Joe Greco]

> On Nov 14, 2011, at 9:24 AM, Joe Greco wrote:
> > Getting fixated on air-gapping is unrealistically ignoring the other thre=
> ats out there.
> 
> I don't think anyone in this thread is 'fixated' on the idea of airgapping;=

No, but it's clear that there are many designers out there who feel this
is the way to go.  That's why it's a good idea to cover the ground anyways.

>  but it's generally a good idea whenever possible, and as restrictive a com=
> munications policy as is possible is definitely called for, amongst all the=
>  other things one ought to be doing.

I think the part people forget about is that last part, "amongst all the
other things one ought to be doing."

> It's also important to note that it's often impossible to *completely* airg=
> ap things, these days, due to various interdependencies, admin requirements=
>  (mentioned before), and so forth; perhaps bastioning is a more apt term.

If it didn't turn into a situation where everyone's bastardizing^Wbastioning
your network in insecure ways.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Arguing against using public IP space

[Ray Soucy]

As far as I can see Red Tiger Security is Jonathan Pollet; and even
though they list Houston, Dubai, Milan, and Sydney as offices it looks
like Houston is the only one.  Is that right?  Seems a little
misleading.

It actually reminds me of a 16 year old kid I know who runs a web
hosting "company" that you'd think was a Fortune 500 by the way the
website reads, and he's more than happy to take your credit card
information and store it without being PCI compliant.

Credibility of the company aside,

At first I wanted to cut Jonathan some slack.  If he was going to
point to the use of public IPs as evidence that a firewall may not be
in use and then went on to discuss the potential risks of not having
any security, then that would have been appropriate.  But instead he
goes on about explaining what a public vs. private address is (poorly)
and proceeds to associate the security of the system with the use of
private IPs.

I just don't see him as credible in the security field after reading it.

Then again, he does have that interview on Fox News posted on his
website where he talks about terrorist plots to compromise the
integrity of nuclear power plants...

Honestly, people post stuff like this time and time again.  It's been
debunked so many times that a quick Google will probably give you what
you need to figure it out on your own.

On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis  wrote:
> I don't want to start a flame war, but this article seems flawed to
> me.  It seems an IP is an IP.
>
> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html
>
> I think I could announce private IP space, so doesn't that make this
> argument invalid?  I've always looked at private IP space as more of a
> resource and management choice and not a security feature.
>
>



--
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Re: Arguing against using public IP space

[Joe Greco]

> On 11/14/11 10:24 , Joe Greco wrote:
> >> Sure, anytime there's an attack or failure on a SCADA network that
> >> wouldn't have occurred had it been air-gapped, it's easy for people to
> >> knee-jerk a "SCADA networks should be airgapped" response.  But that's
> >> not really intelligent commentary unless you carefully consider what
> >> risks are associated with air-gapping the network.
> > 
> > Not to mention that it's not the only way for these things to get
> > infected.  Getting fixated on air-gapping is unrealistically ignoring
> > the other threats out there.
> > 
> > There needs to be a whole lot more security work done on SCADA nets.
> 
> Stuxnet should provide a fairly illustrative example.
> 
> It doesn't really matter how well isolated from direct access it is if
> it has a soft gooey center and a willing attacker.

That's basically the case for so many things.

I was reading, recently, two articles on Ars Technica ("Die, VPN" and
"Live, VPN") which made it exceedingly clear that these sorts of designs
are still the rule for most companies.  I mean, I already knew that, but
it was *depressing* to read.

We've been very successful for many years designing things as though they
were going to be deployed on the public Internet, even if we do still put
them behind a firewall.  That's just belt-and-suspenders common sense.

We do run a VPN service, which I use heavily, but it really has little
to do with granting magical access to resources - the VPN endpoint is
actually outside any firewall.  I've so frequently found, over the years,
that some "free" Internet connection offering is crippled in some stupid
manner (transparent proxying with ad injection!), that the value added
is mostly just that of getting an Internet connection with no interference
by third parties.  The fact that third parties cannot do any meaningful
snooping is nice too.

I also recall a fairly surreal discussion with a NANOG'er who was
absolutely convinced that SSH key based access to other servers was
more secure than password based access along with some ACL's and
something like sshguard; my point was that compromise of the magic
host with the magic key would tend to be worse (because you've suddenly
got access to all the other servers) while having different secure
passwords for each host, along with some ACL's and sshguard, allow you
to retain some isolation within the network from an infected node.  It's
dependent on design and forethought, of course...  

Basically, getting access to some point in the network shouldn't really
allow you to go on a rampage through the rest of the network.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Cable standards question

[Daniel Seagraves]

On Nov 14, 2011, at 8:42 AM, Sam (Walter) Gailey wrote:

> "The vendor will provide fiber connectivity between (building A) and 
> (building B). Vendor will be responsible for all building penetrations and 
> terminations. When  installing the fiber-optic cable the vendor will follow 
> the appropriate TIA/EIA 568 standards for fiber-optic cabling."
> 
> Any suggestions or examples of language would be very appreciated. Offlist 
> contact is probably best.

Is it appropriate to just say "When installing fiber-optic cable the vendor 
will ensure the resulting installation does not suck."?
That would seem to me to be the most direct solution to the problem. I mean, 
standards are all well and good, but what if the standard sucks?
Then you'd be up a creek.

Maybe there should be a legal definition of the concept of suck, so that 
suckage could be contractually minimized.

Cable standards question

[Sam (Walter) Gailey]

Hello, newbie question of the morning time, but hopefully not too off-topic...

I run a small town network. A new building is being built that the town wants 
fiber access to. I have to specify for vendors what it is that the town expects 
in the cabling. I am (obviously) not a fiber expert, and I'm having trouble 
phrasing the language of the RFP so that we are assured a quality installation.

My question is this; Is there an appropriate standard to specify for 
fiber-optic cabling that if it is followed the fiber will be installed 
correctly? Would specifying TIA/EIA 568-C.3, for example, be correct?

I'm envisioning something like;

"The vendor will provide fiber connectivity between (building A) and (building 
B). Vendor will be responsible for all building penetrations and terminations. 
When  installing the fiber-optic cable the vendor will follow the appropriate 
TIA/EIA 568 standards for fiber-optic cabling."

Any suggestions or examples of language would be very appreciated. Offlist 
contact is probably best.

Many thanks,

---Sam