Re: JunOS/FRR/Nokia et al BGP critical issue

[Eugeniu Patrascu]

On Fri, Sep 1, 2023 at 12:56 PM Bjørn Mork  wrote:

> Nick Hilliard  writes:
> > Bjørn Mork wrote on 01/09/2023 08:17:
> >> Sounds familiar.
> >>
> https://supportportal.juniper.net/s/article/BGP-Malformed-AS-4-Byte-Transitive-Attributes-Drop-BGP-Sessions?language=en_US
> >> You'd think a lot of thought has gone into error handling for
> >> optional
> >> transitive attributes since then, but...
> >
> > A good deal of thought has gone into the problem, and this is where
> > rfc7606 came from. Treat-as-withdraw for the NLRI in question is the
> > default option with this approach, and should be deployed universally.
>
> Yes.
>
> But there's obviously not been enough thought applied to realize that
> optional transitive attributes must be considered evil by default. They
> can only be used after extremely careful parsing.
>

Yeah, no.
The logic is that if you understand them, you treat them according to
whatever routing policy you have and then pass them along. If you don't,
you just pass them along and that's it. Nothing more, nothing less.


>
> This is the BGP version of
>
>  select * from mytable where field = $unvalidated_user_input;
>

No here as well. Because passing along a transitive attribute you don't
understand does not affect you in any way.

-e

Re: JunOS/FRR/Nokia et al BGP critical issue

[Eugeniu Patrascu]

On Wed, Aug 30, 2023 at 4:04 PM William Herrin  wrote:

> On Wed, Aug 30, 2023 at 4:50 AM Mike Lyon  wrote:
> > Ran across this article today and haven't seen posts about it so i
> > figured I would share:
> >
> > https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling
>
> Can you imagine, as the origin of a route, troubleshooting a
> connectivity issue in which Internet BGP routers far from your control
> have trouble with attributes attached by their peers and then "did
> their best" with your route instead of dropping the session and
> essentially demanding intervention by the network operator?
>
> Dumping the session may seem extreme, but there's a good reason for it.


Or do the sensible thing and just drop the announcement and log the
problem.
This might be a problem in a DFZ environment, but albeit a small one.
Or, drop the invalid attribute and treat the announcement as a regular one.

Re: A multi-tenant firewall for an MSSP

[Eugeniu Patrascu]

On Mon, Aug 17, 2015 at 7:46 AM, Ramy Hashish 
wrote:

> Hello All,
>
> We are planning to implement a multi-tenant FW/UTM and start providing
> security as a service, I would like to hear if anybody had experience on
> this, and if there are any recommendations for the UTM's vendor.
>

Check Point VS might be a good fit. Also there is McAfee NGFW that can be
used as a multi-tenant solution.

Other solutions are Fortigate (what you mentioned), ASA w/ contexts (not
sure about UTM support in contexts though).


> People/customers here are more familiar with the Fortigate, however, we
> need to build a well-rounded solution that suits wide range of enterprises'
> business needs.
>

I think that you first define what the most wanted needs of your clients
are and work from that.

Re: World's Fastest Internet™ in Canadaland

[Eugeniu Patrascu]

>
> > On Jun 26, 2015, at 2:41 PM, Rafael Possamai  wrote:
> >
> > How does one fully utilize a gigabit link for home use? For a single
> person
> > it is overkill. Similar to the concept of price elasticity in economics,
> > going from 50mbps to 1gbps doesn't necessarily increase your average
> > transfer rate, at least I don't think it would for me. Anyone care to
> > comment? Just really curious, as to me it's more of a marketing push than
> > anything else, even though gigabit to the home sounds really cool.
>

You don't run it hot all day long, it's just that you don't wait forever
for things to download when you need something from the Internet.

Re: eBay is looking for network heavies...

[Eugeniu Patrascu]

On Sun, Jun 7, 2015 at 6:57 PM, Peter Kristolaitis 
wrote:

> In many ways, certification tracks are something like getting a PhD.
> Completely useless information (and very few skills) to anything you'll do
> in the "real world", but if it makes your clock tick, go for it.  Just
> don't expect me to be impressed when I'm interviewing you, because it has
> no direct relationship with your ability to do this job.
>
>
Certs are a good way to get selected by the HR people and have your CV
forwarded to the people that will actually do the interviewing part. Some
companies actually put out job listings with required mandatory
certifications so from their point of view, you only qualify if you have a
piece of paper saying that you know X,Y,Z.


> My favourite question to ask candidates during an interview is "Tell me
> about a cool technology project you've done outside of work."   I don't
> even really care what the answer is, it's more about "do they get revved up
> while they're talking about it?"
>

Cool idea, never thought of this type of questions when gauging peoples
interest in motivation and the desire to learn.

Eugeniu

Re: Rasberry pi - high density

[Eugeniu Patrascu]

On Sat, May 9, 2015 at 9:55 PM, Barry Shein  wrote:

>
> On May 9, 2015 at 00:24 char...@thefnf.org (char...@thefnf.org) wrote:
>  >
>  >
>  > So I just crunched the numbers. How many pies could I cram in a rack?
>
> For another list I just estimated how many M.2 SSD modules one could
> cram into a 3.5" disk case. Around 40 w/ some room to spare (assuming
> heat and connection routing aren't problems), at 500GB/each that's
> 20TB in a standard 3.5" case.
>
> It's getting weird out there.
>
>
I think the next logical step in servers would be to remove the traditional
hard drive cages and put SSD module slots that can be hot swapped. Imagine
inserting small SSD modules on the front side of the servers and directly
connect them via PCIe to the motherboard. No more bottlenecks and a
software RAID of some sorts would actually make a lot more sense than the
current controller based solutions.

Re: Voip encryption

[Eugeniu Patrascu]

On Thu, Apr 9, 2015 at 1:21 PM, Simon Brilus 
wrote:

> Hi - I have a PCIDSs requirement to encrypt VoIP over a 3rd party VPLS
> network. Has anyone dealt with this. I'd really not use VPN's over the VPLS
> so am looking at hardware WAN encrypters.
>
>
SafeNet and Thales sell L2 WAN encryptors for sure.
There is AEP and SINA which also do hardware WAN encryption, but I do not
know if they do Layer2.

Eugeniu

Re: Dynamic routing on firewalls.

[Eugeniu Patrascu]

On Mon, Feb 9, 2015 at 10:59 AM, Rich Kulawiec  wrote:

> On Sun, Feb 08, 2015 at 11:40:56AM -0200, BPNoC Group wrote:
> > Firewalls are firewalls. Routers are routers. Routers should do some very
> > basic filtering (stateles, ACLs, data plane protection...) and firewalls
> > should do basic static routing. And things should not go far beyond that.
>
> This is, at a network level, an echo of the "Software Tools" philosophy
> that has served us exceedingly well for decades.  Tools should do one
> thing, they should do it well, and if/when we need to do more than one
> thing, we should use tools in combination.
>

And then reality comes and disagrees with you :)
I am a fan of the "use the right tool for the right job", but it is not
always possible due to economical/technical/political reasons.

I had situations where running dynamic routing on firewalls was the way to
go to allow for geographic distribution of traffic without having to touch
routers and/or firewalls when adding/deleting subnets. Devices would just
learn routes and if permitted by the firewalls, traffic would pass.



> There's another advantage to this: if firewalls and routers &etc
> are not the same system, then they can run different software on
> different operating systems on different architectures -- providing
> a significant measure of insulation against attacks unique to one
> particular combination.
>
>
This is a bit of a fallacy, because considering all things equal, a router
looks at only Layer 3/4 headers to route a packet, whereby a firewall will
look more deeper up the stack (considering a simple scenario, not
considering MPLS stuff). Even if they run the same OS but with different
functions enabled, a firewall having a vulnerability because it mishandles
TCP packets with SYN/RST flags set, it does not mean it will be vulnerable
as a router.

I know companies running firewall back to back from different vendors just
to make sure that they are secure if someone "hacks" one of the firewalls.

My point is that:

1) you can run dynamic routing on a firewall without issues
2) it depends on the situation if it advisable to do so
3) there is no size fits all scenario whereby it is verboten to have
anything else than static routes on a firewall
4) you have to consider the pros/cons about doing it or not doing it

Re: Dynamic routing on firewalls.

[Eugeniu Patrascu]

On Thu, Feb 5, 2015 at 4:10 PM, David Jansen  wrote:

> Hi,
>
> We have used dynamic routing on firewall in the old days. We did
> experience several severe outages due to this setup (OSPF en Cisco). As you
> will understand i’m not eager to go back to this solution but I am curious
> about your point of views.
>
> Is it advisory to so these days?
>
>
Any specific firewall in mind? As this depends from vendor to vendor.

I've had some issues with OSPF and CheckPoint firewalls when the firewalls
would be overloaded and started dropping packets at the interface level
causing adjacencies to go down, but I solved this by using BGP instead and
the routing issues went away.

On Juniper things tend work OK.

Other than this, make sure you don't run into asymmetric routing as
connections might get dropped because the firewall does not know about them
or packets arrive out of order and the firewall cannot reassemble all of
them.

Re: Checkpoint IPS

[Eugeniu Patrascu]

On Tue, Feb 3, 2015 at 5:41 PM, Michael Hallgren  wrote:

>  Le 03/02/2015 16:21, Eugeniu Patrascu a écrit :
>
> On Mon, Feb 2, 2015 at 2:53 PM, Michael Hallgren 
> wrote:
>
>> Hi,
>>
>> Someone has positive or negative experience running
>> Checkpoint IPS cluster over ``long distance'' synch.
>> network? Real life limitations? Alternatives? Timers?
>>
>>
>  You can do "stretched" with Check Point as long as the network delay is
> less than around 70-100 msec RTT or so. If you do this, run your firewalls
> in Active/Standby modes.
>
>
> Thanks Eugeniu, I see what you mean. The specific case I'm looking at is
> about asymmetric routing, though.
>

Firewalls/IPS and asymmetric routing don't play nice. Try to change your
setup/design so that traffic enters/leaves your network segments through
the same security device.

Re: Checkpoint IPS

[Eugeniu Patrascu]

On Mon, Feb 2, 2015 at 2:53 PM, Michael Hallgren  wrote:

> Hi,
>
> Someone has positive or negative experience running
> Checkpoint IPS cluster over ``long distance'' synch.
> network? Real life limitations? Alternatives? Timers?
>
>
You can do "stretched" with Check Point as long as the network delay is
less than around 70-100 msec RTT or so. If you do this, run your firewalls
in Active/Standby modes.

Re: Kind of sad

[Eugeniu Patrascu]

On Tue, Nov 11, 2014 at 1:58 AM, Mike Hale 
wrote:

> That's a far, far cry from hacking...


Remember that CFAA has a very vague definition of "unauthorized computer
access".

Re: Tech Laptop with DB9

[Eugeniu Patrascu]

On Mon, Nov 10, 2014 at 10:39 PM, Max Clark  wrote:

> Hi all,
>
> DB9 ports seem to be a nearly extinct feature on laptops. Any suggestions
> on a cheap laptop for use in field support (with an onboard DB9)?
>

You can look at older Dell Latitudes such as D620 or any Prolific based
USB-to-Serial adapter (If running those on Windows, you can set the driver
so that it will report the same COM port even if it's plugged in different
USB ports).

Re: Linux: concerns over systemd adoption and Debian's decision to switch

[Eugeniu Patrascu]

On Tue, Oct 21, 2014 at 4:40 PM,  wrote:

>
> http://www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ
>
> When your init system is worrying about cursor rendering, you have truly
> fallen victim to severe feature bloat.  I guess Jamie Zawinski was right:
> "Every program attempts to expand until it can read mail."
>

I think systemd wants to become the next Emacs ;))

Re: Muni Fiber and Politics

[Eugeniu Patrascu]

On Tue, Aug 5, 2014 at 9:26 PM, William Herrin  wrote:

>
> Hi Eugeniu,
>
> The word you're searching for is "microduct."
>

That's it, I wasn't sure about it.


> I'm a big fan of Microduct. There's even some wicked cool equipment
> which will force the core out of in-place coax plant, converting it to
> microduct suitable for a fiber installation. But here are some of the
> places you may run in to trouble using it for a municipal fiber
> installation:
>
>
> 1. 10 miles of fiber optic cable is expensive (from a consumer
> perspective) even when you're able to float it through a series of
> ducts instead of having to trench. Who covers the cost? If the service
> provider amortizes it for the consumer (instead of the municipal
> infrastructure provider) then you're right back to the consumer
> lock-in that damages competition.
>

For business connections, the customer pays the cost from the nearest PoP
to its premises as a one time installation fee and then the yearly cost of
"renting" is spread out over 12 months. This is what one of my ISPs told
me. But the price is pretty much negligible to rent this compared to what
you pay for the actual "Internet" connection.

For residential areas I'm not sure, but being predominantly apartment
blocks, I think the ISP takes the "hit" as at least my bills haven't gone
up.


>
> 2. While microduct supports 12 or 24 fibers in a single duct, it does
> not support adding or removing fibers from a duct. To install a
> different quantity, you have to remove all the existing fiber and then
> blow a completely new set of fibers. Obviously service provider A is
> not motivated to install extra fibers that service provider B can
> subsequently sell you service on. Only a bare infrastructure provider
> would have that motivation.
>

Each ISP has a microduct. I've seen "output/breakout" boxes in the street
with several microducts labeled with different ISP names, so no worries
here. I'm not sure how many are installed by default, but probably it
depends on the area, maybe 12 in residential areas and 24 in crowded areas.
I really don't know. Also, one ISP can have (I think) as many microducts as
they can buy.


> 3. Structure is good. It facilitates reuse. If you permit the fiber to
> be run between arbitrary points you end up with the same cruft as an
> office without structured cabling. Even if you use microduct,
> future-proofing requires central cross-connect points where folks
> patch.
>
>
There are a lot of manholes for this stuff, some bigger and some a little
bit smaller. I've never been into one to see how they are organized.

Yes, you can get a lot of cruft, but installing OMMRs in the middle of the
street tends to be expensive (even if you can somehow burry a room
underneath the street to house them) so I guess the current method works
best given the conditions.


> 4. I'm not sure how far you can float fiber down a microduct but I'm
> pretty sure you don't do it miles at a stretch. So, if you build your
> system with microduct and fiber-blown-later, you'll have a *lot* of
> points where the ducts have to be joined.
>
>
I also have no idea about the length, but it seems to be working so far.
Also, splicing fibers is done so fast by qualified technicians that it
doesn't add a significant amount of time to get a circuit ready - I think
it's around 5 minutes for a pair of fibres.

Eugeniu

Re: Muni Fiber and Politics

[Eugeniu Patrascu]

On Tue, Aug 5, 2014 at 8:26 PM, Owen DeLong  wrote:

>
> >>
> >> This one is a bad idea cause you have lots of people pushing fiber
> through
> >> pipes with active fiber in them... and their incentives not to screw up
> >> other people's glass are... unclear?  :-)
> >
> > Not really, if one company starts making mistakes, the other will also
> > mistake their cables. It's like a working mexican standoff :)
> >
> >
>
> In reality, Mexican standoffs are often fatal.
>
>
If you blink.


> >> Oh, wait: the conduit installer isn't a contractor, they're a monopoly?
> > The people pushing fiber through the conduits are contractors. There are
> a
> > handful of companies licensed to operate this.
>
> May be workable, but seems more expensive than operating cross connects in
> a serving wire center with little or no plausible benefit.
>
>
So how is blowing microfibre in some tubes more expensive? You pay a one
off installation fee and then a small monthly rate for the circuit (payable
yearly).

The really nice and geeky part is that you can actually choose how your
fiber will run, so if you want diverse paths to a location you can achieve
that with certainty.


> >
> >
> >> No, that's even worse.
> >
> >
> > It's not perfect, but it works.
>
> People say that about windows. I don't use it, either.
>

:) It works because it's very cheap to get high speed internet into all
kinds of areas, especially residential ones.

Re: Muni Fiber and Politics

[Eugeniu Patrascu]

On Tue, Aug 5, 2014 at 2:15 AM, Jay Ashworth  wrote:

> - Original Message -
> > From: "Eugeniu Patrascu" 
>
> > In my neck of the woods, the city hall decided that no more fiber cables
> > running all over the poles in the city and somehow combined with some EU
> > regulations that communication links need to be buried, they created a
> > project whereby a 3rd party company would dig the whole city, put in some
> > tubes in which microfibres would be installed by ISPs that reach every
> > street number and ISP would pay per the kilometer from point A to point B
> > (where point A was either a PoP or ISP HQ or whatever; point B is the
> > customer).
> >
> > To be clear, this is single-mode dark fiber so the ISPs can run it at
> > whatever speeds they like between two points.
> >
> > The only drawback is that the 3rd party company has a monopoly on the
> > prices for the leasing of the tubes, but from my understanding this is
> > kept under control by regulation.
>
> This one is a bad idea cause you have lots of people pushing fiber through
> pipes with active fiber in them... and their incentives not to screw up
> other people's glass are... unclear?  :-)
>

Not really, if one company starts making mistakes, the other will also
mistake their cables. It's like a working mexican standoff :)


>
> Oh, wait: the conduit installer isn't a contractor, they're a monopoly?
>
>
The people pushing fiber through the conduits are contractors. There are a
handful of companies licensed to operate this.


> No, that's even worse.


It's not perfect, but it works.

Re: Muni Fiber and Politics

[Eugeniu Patrascu]

On Tue, Jul 22, 2014 at 11:05 PM, Owen DeLong  wrote:
>
>
> OTOH, if the municipality provides only L1 concentration (dragging L1
> facilities
> back to centralized locations where access providers can connect to large
> numbers of customers), then access providers have to compete to deliver
> what consumers actually want. They can't ignore the need for newer L2
> technologies because their competitor(s) will leap frog them and take away
> their customers. This is what we, as consumers, want, isn't it?


In my neck of the woods, the city hall decided that no more fiber cables
running all over the poles in the city and somehow combined with some EU
regulations that communication links need to be buried, they created a
project whereby a 3rd party company would dig the whole city, put in some
tubes in which microfibres would be installed by ISPs that reach every
street number and ISP would pay per the kilometer from point A to point B
(where point A was either a PoP or ISP HQ or whatever; point B is the
customer).

To be clear, this is single-mode dark fiber so the ISPs can run it at
whatever speeds they like between two points.

The only drawback is that the 3rd party company has a monopoly on the
prices for the leasing of the tubes, but from my understanding this is kept
under control by regulation.

Eugeniu

Re: Access hardware for small FTTP deployment

[Eugeniu Patrascu]

On Fri, May 16, 2014 at 6:18 AM, Chris  wrote:

> Hi all,
>
> We are looking at doing a small FTTP deployment in a community of about 30
> homes and I'm searching for options regarding access layer hardware.
>
> Initially we thought of a simple point-to-point ethernet setup with
> 1000Base-BX to each premises and a 48-port access switch. However, finding
> an appropriate piece of hardware has proven challenging because of our
> requirement of a 60+ degrees Celcius operating temperature (due to outdoor
> cabinet placement).
>
> The only one I found that meets the temperature requirement was Cisco's ME
> 2600X with 44 SFP ports, 4 SFP+ and 65degC max, but it's a bit pricey for
> our liking. Other offerings from HP (5800-24G-SFP), Juniper (EX4550),
> Brocade (CES-2048F) were nice, but all only had 40-45degC max operating
> temp.
>
> I'm interested to see what other people are doing for these types of small
> setups. Does anyone know of any other reasonably priced access switches,
> 32+ SFP ports, and able to withstand 60degC or higher operating
> temperature?
>
> We are also considering GPON, but given that we would only need one
> interface for such a small deployment, most of the hardware out there seems
> like overkill. Are there good small OLTs?
>
>
For your particular case, you might want to look at industrial ethernet
switches with IP67 enclosure specs.

>From Cisco you can look at IE3000 series. They can do VLANs, routing, have
SFP ports for uplinks.

Another option would be the OCTOPUS series from Belden, they claim -40C to
+70C degrees operating temperature.

Regards,
Eugeniu

Re: Best practices IPv4/IPv6 BGP (dual stack)

[Eugeniu Patrascu]

On Fri, May 2, 2014 at 10:44 PM, Deepak Jain  wrote:

>
> Between peering routers on a dual-stacked network, is it considered best
> practices to have two BGP sessions (one for v4 and one for v6) between
> them? Or is it better to put v4 in the v6 session or v6 in the v4 session?
>
> According to docs, obviously all of these are supported and if both sides
> are dual stacked, even the next-hops don't need to be overwritten.
>
>
I've done it separately. IPv4 with IPv4, IPv6 with IPv6. From my point of
view it's a cleaner configuration to have things decoupled completely:
management, debugging.


> Is there any community-approach to best practices here? Any FIB weirdness
> (e.g. IPv4 routes suddenly start sucking up IPv6 TCAM space, etc)  that
> results with one solution over the other?
>
>
None that I've noticed.

Re: Requirements for IPv6 Firewalls

[Eugeniu Patrascu]

On Sun, Apr 20, 2014 at 4:27 AM, Dobbins, Roland  wrote:

>
> On Apr 20, 2014, at 2:32 AM, George William Herbert <
> george.herb...@gmail.com> wrote:
>
> > I have 20-30,000 counterexamples in mind that I worked with directly in
> the last decade.
>
> People do stupid things all the time - but generally, it's hard to do them
> at scale.
>

Just go watch government at work :)

Re: Requirements for IPv6 Firewalls

[Eugeniu Patrascu]

On Sat, Apr 19, 2014 at 5:04 AM, Jeff Kell  wrote:

> On 4/18/2014 9:53 PM, Dobbins, Roland wrote:
> > On Apr 19, 2014, at 1:20 AM, William Herrin  wrote:
> >
> >> There isn't much a firewall can do to break it.
> > As someone who sees firewalls break the Internet all the time for those
> whose packets have the misfortune to traverse one, I must respectfully
> disagree.
>
> If end-to-end connectivity is your idea of "the Internet", then a
> firewall's primary purpose is to break the Internet.  It's how we
> provide access control.
>
> If a firewall blocks "legitimate, authorized" access then perhaps it
> adds to breakage (PMTU, ICMP, other blocking) but otherwise it works.
>
> 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: Do not disclose private IP addresses and routing information to
unauthorized parties.
Note: Methods to obscure IP addressing may include, but are not limited to:
- Network Address Translation (NAT)
- Placing servers containing cardholder data behind proxy servers/firewalls
or content caches
- Removal or filtering of route advertisements for private networks that
employ registered addressing
- Internal use of RFC1918 address space instead of registered addresses.

>From what I see in the requirement it says "don't let people on the outside
know that your webserver has 192.168.100.200 as an IP address", not that
you should NAT everything.

Also if you are lucky enough to have lots of IPv4 addresses and assign them
to all your servers/devices in your PCI compliant infrastructure this
requirement (1.3.8) will not even apply to you.

Eugeniu

Re: Requirements for IPv6 Firewalls

[Eugeniu Patrascu]

On Sat, Apr 19, 2014 at 2:03 AM, Matthew Kaufman  wrote:

> Ignoring security, A is superior because I can change it to DNAT to the
> new server, or DNAT to the load balancer now that said server needs 10
> replicas, etc.
>
> B requires re-numbering the server or *if* I am lucky enough that it is
> reached by DNS name and I can change that DNS promptly, assigning a new
> address and adding another firewall rule that didn't exist.
>
>
What you're describing is how to set up infrastructure to handle rapidly
changing environments in cases where the whole setup not thought out in
it's entirety to account for that.

My point with IPv6 is that we get the chance to clear up all the mess that
happened with IPv4 (or the lack of addresses in IPv4) with NATs and NATs
over even more NAT.

I'm not arguing against NAT completely in IPv6, I'm arguing against
applying IPv4 style thinking applied to IPv6.

Eugeniu

Re: Requirements for IPv6 Firewalls

[Eugeniu Patrascu]

On Fri, Apr 18, 2014 at 10:49 PM, Jim Clausing  wrote:

> And maybe I'm just dense, but ho one has been able to tell me how I
> accomplish this in IPv6 without NAT, I have the requirement in certain
> circumstances to transparently redirect all outbound DNS (well, on TCP or
> UDP port 53) and/or SMTP (TCP ports 25 and 587) to my own servers.  No,
> simply blocking it at the firewall and making the user "fix" the problem is
> not an option (especially when the problem is created by malware).  It is a
> simple rule in IPTABLES for IPv4, but how do I accomplish it in IPv6? Not
> flaming or anything, but I really want to know how I'm supposed to
> accomplish that in the ideal IPv6 world with no NAT?
>
>
Nothing stops you from using NAT :)

This discussion got a bit off track. I'm not saying NAT should be banned
completely, I'm saying that with IPv6 we can actually simplify things a lot
get rid of all hacks we had to do in the network do get services up and
running (e.g. using a firewall's public ip address to hide several distinct
services behind it on different hosts, like web, dns, smtp etc).

I believe in simplicity, and now IPv6 for me makes things simple: I can
have all the IP addresses I want and do not need to use hacks to get things
working because no one would give 2048 IPv4 addresses just to do stuff with
them and run lots of servers with "public" IP addresses.

Re: Requirements for IPv6 Firewalls

[Eugeniu Patrascu]

On Fri, Apr 18, 2014 at 6:02 PM, William Herrin  wrote:

> On Fri, Apr 18, 2014 at 3:31 AM, Eugeniu Patrascu 
> wrote:
> > On Thu, Apr 17, 2014 at 11:45 PM, George Herbert <
> george.herb...@gmail.com>
> > wrote:
> >> You are missing the point.
> >>
> >> Granted, anyone who is IPv6 aware doing a green-field enterprise
> firewall
> >> design today should probably choose another way than NAT.
> >>
> >
> > That's why you have gazzilions of IP addresses in IPv6, so you don't
> need to
> > NAT anything (among other things). I don't understand why people cling to
> > NAT stuff when you can just route.
>
> 4. Defense in depth is a core principle of all security, network and
> physical. If you don't practice it, your security is weak. Equipment
> which is not externally addressable (due to address-overloaded NAT)
> has an additional obstruction an adversary must bypass versus an
> identical system where the equipment is externally addressable (1:1
> NAT, static port translation and simple routing). This constrains the
> kinds of attacks an adversary may employ.
>
>
Let's make it simple:

Scenario (A) w/ IPv4
[Internet] -> Firewall Public IP :80/TCP -> DNAT to Internal IP Address
:80/TCP

Scenario (B) w/ IPv6
[Internet] -> FIrewall -> Host w/ Routable IP Address :80/TCP


In scenario (A) I hide a server behind a firewall and to a simple
destination NAT (most common setup found in all companies).
In scenario (B) I have a firewall rule that only allows port 80 to a
machine in my network.


Explain to me how from a security standpoint Scenario (A) is better than
scenario (B).


Defense in depth, to my knowledge - and feel free to correct me, is to have
defenses at every point in the network and at the host level to protect
against different attack vectors that are possible at those points. For
example a firewall that understands traffic at the protocol level, a
hardened application server, a hardened application, secure coding
practices and so on depending of the complexity of the network and the
security requirements.


> Feel free to refute all four points. No doubt you have arguments you
> personally find compelling. Your arguments will fall on deaf ears. At
> best the arguments propose theory that runs contrary to decades of
> many folks' experience. More likely the arguments are simply wrong.
>
>
Just because some people have decades of experience, it doesn't mean they
are right or know what they are doing.


Eugeniu

Re: Requirements for IPv6 Firewalls

[Eugeniu Patrascu]

On Thu, Apr 17, 2014 at 11:45 PM, George Herbert
wrote:

>
>
>
> On Thu, Apr 17, 2014 at 11:32 AM, Eugeniu Patrascu wrote:
>
>> ...
>> It's a bigger risk to think that NAT somehow magically protects you
>> against
>> stuff on the Internet.
>> Also, if your problem is that someone can screw up firewalls rules, then
>> you have bigger issue in your organization than IPv6.
>
>
>
>> There's a fair argument to be made which says that kind of NAT is
>> > unhealthy. If its proponents are correct, they'll win that argument
>> > later on with NAT-incompatible technology that enterprises want. After
>> > all, enterprise security folk didn't want the Internet in the
>> > corporate network at all, but having a web browser on every desk is
>> > just too darn useful. Where they won't win that argument is in the
>> > stretch of maximum risk for the enterprise security folk.
>> >
>> >
>> Any technology has associated risks, it's a matter of how you
>> reduce/mitigate them.
>> This paranoia thingie about IPv6 is getting a bit old.
>> Just because you don't (seem to) understand how it works, it doesn't mean
>> no one else should use it.
>
>
>
> You are missing the point.
>

> Granted, anyone who is IPv6 aware doing a green-field enterprise firewall
> design today should probably choose another way than NAT.
>
>
That's why you have gazzilions of IP addresses in IPv6, so you don't need
to NAT anything (among other things). I don't understand why people cling
to NAT stuff when you can just route.



> What you are failing is that "redesign firewall rules and approach from
> scratch along with the IPv6 implementation" usually is not the chosen path,
> versus "re-implement the same v4 firewall rules and technologies in IPv6
> for the IPv6 implementation", because all the IPv6 aware net admins are
> having too much to do dealing with all the other conversion issues, vendor
> readiness all across the stack, etc.
>
>
You treat IPv6 like the only protocol running and design the implementation
taking that into consideration. Where necessary you publish  records
and so only devices/services that are IPv6 aware will be accessed over
IPv6, all others can stay on IPv4 until they are migrated. It works
wonderful.

This idea of matching IPv4 1:1 to IPv6 is not the way to go.


> Variations on this theme are part of why it's 2014 and IPv6 hasn't already
> taken over the world.  The more rabid IPv6 proponents have in fact shot the
> transition in the legs repeatedly, and those of us who have been on the
> front lines would like you all to please shut up and get out of the way so
> we can actually finish effecting v6 deployment and move on to mopping up
> things like NAT later.
>


I don't get this paragraph. From my perspective, if you want IPv6 you can
do it. From all the organizations I get in contact and ask about IPv6 is
the lack of knowledge and interest that puts a stop to the deployment,
nothing else.

Eugeniu

Re: Requirements for IPv6 Firewalls

[Eugeniu Patrascu]

On Thu, Apr 17, 2014 at 9:05 PM, William Herrin  wrote:

>
> Here's the drill: From an enterprise security perspective, deploying
> IPv6 is high risk. I have to re-implement every rule I set on my IPv4
> addresses all over again with my IPv6 addresses and hope I don't screw
> it up in a way that lets an adversary wander right in. That risk is
> compounded exponentially if the _initial_ deployment can't follow an
> identical security posture to the IPv4 system. Without availability of
> the kind of NAT present in the IPv4 deployment, I have a problem whose
> solution is: sorry network team, return when the technology is mature.
>
>
It's a bigger risk to think that NAT somehow magically protects you against
stuff on the Internet.
Also, if your problem is that someone can screw up firewalls rules, then
you have bigger issue in your organization than IPv6.

There's a fair argument to be made which says that kind of NAT is
> unhealthy. If its proponents are correct, they'll win that argument
> later on with NAT-incompatible technology that enterprises want. After
> all, enterprise security folk didn't want the Internet in the
> corporate network at all, but having a web browser on every desk is
> just too darn useful. Where they won't win that argument is in the
> stretch of maximum risk for the enterprise security folk.
>
>
Any technology has associated risks, it's a matter of how you
reduce/mitigate them.
This paranoia thingie about IPv6 is getting a bit old.
Just because you don't (seem to) understand how it works, it doesn't mean
no one else should use it.

Eugeniu

Re: VMware Training

[Eugeniu Patrascu]

On Fri, Feb 21, 2014 at 7:37 PM, Phil Gardner wrote:

> On 02/19/2014 01:14 PM, Phil Gardner wrote:
>
>> Not sure if this list is the best place, but it is probably the only
>> list that I'm on that won't give me a bunch of grief about the chosen
>> technology.
>>
>> I looked at VMware's site, and there are a ton of options. I'm wondering
>> if anyone has some basic suggestions or experiences.
>>
>> I'm a Linux admin by trade (RH based), with "ok" networking ability. I'm
>> sufficiently versed in deploying scripted ESXi (including 5.x)
>> installations for a specific environment, including vswitches/SAN config
>> (but only with NFS datastores backed by a NetApp, unfortunately, no
>> blockbased stores).
>>
>> I'd like to get experience deploying VCenter clusters, down to DRS/HA
>> config, other block based storage, and anything else a large environment
>> needs.
>>
>> Thoughts or experiences?
>>
>>
> Thanks for the responses everyone. I will be petitioning my manager for
> the vShpere: Install, Configure, Manage v5.5 course.
>

As a note to this, if you get it approved, make sure that the trainer has
(a lot of) real life experience implementing vSphere. It makes a big
difference when you run into trouble with the labs or when you have
questions that are related to best practices.

Eugeniu

Re: VMware Training

[Eugeniu Patrascu]

On Thu, Feb 20, 2014 at 9:49 PM, Dan Shoop  wrote:

>
> On Feb 20, 2014, at 1:48 PM, Jimmy Hess  wrote:
>
> > The locking restrictions are for your own protection. If the filesystem
> > inside your virtual disks is not a clustered filesystem;
> > two instances of a VM  simultaneously  mounting the same NTFS volume and
> > writing some things, is an absolute disaster.
> >
> >
> > Under normal circumstances,  two applications should never be writing to
> > the same file.  This is true on clustered filesystems.
> > This is true when running multiple applications on a single computer.
>
> Why should "two applications should never be writing to the same file"? In
> a real clustered *file*system this is exactly what you want. The same
> logical volume mounted across host cluster members, perhaps geodistantly
> located, each having access at the record level to the data. This permits
> HA and for the application to be distributed across cluster nodes. If a
> host node is lost then the application stays running. If the physical
> volume is unavailable then logically shadowing the volume across node
> members or storage controllers / SANs permits fault tolerance. You don't
> need to "fail disks over" (really logical volumes) as they are resilient
> from the start, they just don't fail. When the shadow members return they
> replay journals or resilver if the journals are lost.
>


There is a lot of misunderstanding here about how ESXi works in a multiple
host environment.


There are a lot of abstraction layers.
Physical disk -> VMFS -> VMDK files that represent the VM HDD -> VM -> VM
filesystem (NTFS, ext3/4, xfs etc).

The physical disk can be whatever device a controller presents (like a 4
way FC connection for the same LUN).

What we are discussing here is the VMFS capabilities.

Also, what I am saying is that the VM will be very upset when it's HDD
contents are changed without notice. This is why ESXi has a lock per VM
that notifies other ESXi hosts trying to access a particular VM folder that
"hey, it's in use, leave it alone".

And speaking of clustered filesystems, while you may read/write on the at
the same time, except for file storage I do not know of any application
that has no objections that the files it works with have their contents
modified - think database systems.



>
> I'd note that this can be accomplished just so long as you have a common
> disk format across the OS nodes.
>
> These problems were all resolved 40 years ago in mainframe and supermini
> systems. They're not new. VMware has been slowly reinventing -- more
> accurately rediscovering -- well known HA techniques as it's trying to
> mature. And it still has a lot of catching up to do. It's the same tale
> that microcomputers have been doing for decades as they've come into use as
> servers.
>
>
Depending on the use case you may be right or wrong :)


> However I'm not sure what all of this has to do with network operations. ;)


 What, you want political discussions instead? :)

Re: VMware Training

[Eugeniu Patrascu]

On Thu, Feb 20, 2014 at 8:16 PM, Jay Ashworth  wrote:

> - Original Message -
> > From: "Eugeniu Patrascu" 
>
> > On Wed, Feb 19, 2014 at 10:06 PM, Jay Ashworth 
> > wrote:
> >
> > > - Original Message -
> > > My understanding of "cluster-aware filesystem" was "can be mounted at
> the
> > > physical block level by multiple operating system instances with
> complete
> > > safety". That seems to conflict with what you suggest, Eugeniu; am I
> > > missing something (as I often do)?
> >
> > What you are saying is true and from VMware's point of view, an ISCSI
> > volume is a physical disk.
> > And you can mount the same ISCSI disk on many VMware hosts. Just write
> > into different directories on the disk.
> >
> > Am I missing something in your question ?
>
> I guess.  You and Jimmy seem to be asserting that, in fact, you *cannot*
> mount a given physical volume, with a clustering FS in its partition,
> onto multiple running OS images at the same time... at which point, why
> bother using a clustering FS?
>
>
OK, let me give it another try:

You have a machine that exports an ISCSI disk (such as a SAN or a plain
Linux box).

You have 2-3-5-X machines (hosts) that run ESXi.

You can mount that ISCSI disk on all ESXi hosts at the same time and use it
as a datastore for VMs and run the VMs from there.

What I said (and maybe this caused some confusion) is that you should not
access the same files from different hosts at the same time, but you can
run VM1 on host1, VM2 on host2 and so on without any issues from the same
ISCSI target.



> The point of clustering FSs (like Gluster, say), as I understood it,
> was that they could be mounted by multiple machines simultaneously: that
> there was no presumed state between the physical blocks and the FS driver
> inside each OS, which would cause things to Fail Spectacularly if more
> than one machine was simultaneously using them in realtime.
>
>
In the scenario described above and how VMware ESXi works in general, only
VMware accesses the filesystem (the filesystem is called VMFS). The hard
drives for the virtual machines are actually represented by files on the
VMFS and so the virtual machines does not touch the filesystem on the ESXi
hosts directly.



> You and Jimmy seem to be suggesting that multiple OSs need to be
> semaphored.
>
>
He says that multiple ESXi hosts need to be semaphored when they update the
metadata on the VMFS.
I don't have any opinion on this as no matter how much I abused VMware, the
filesystem stayed intact.


> One of three understandings here is wrong.  :-)
>
>
I hope I cleared up some of the confusion.

Eugeniu

Re: VMware Training

[Eugeniu Patrascu]

On Wed, Feb 19, 2014 at 10:06 PM, Jay Ashworth  wrote:

> - Original Message -
> > From: "Eugeniu Patrascu" 
>
> > If you want block storage, just export an iSCSI device to the ESXi
> machines
> > (tgtadm on RedHat is all you need and a few gigs of free space). VMFS is
> > cluster aware so you can export the same volume to independent ESXi hosts
> > and as long you don't access the same files, you're good to go.
>
> My understanding of "cluster-aware filesystem" was "can be mounted at the
> physical block level by multiple operating system instances with complete
> safety".  That seems to conflict with what you suggest, Eugeniu; am I
> missing something (as I often do)?
>
>
What you are saying is true and from VMware's point of view, an ISCSI
volume is a physical disk.
And you can mount the same ISCSI disk on many VMware hosts. Just write into
different directories on the disk.

Am I missing something in your question ?

Eugeniu




> Cheers,
> -- jra
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
>
>

Re: VMware Training

[Eugeniu Patrascu]

On Wed, Feb 19, 2014 at 8:14 PM, Phil Gardner wrote:

> Not sure if this list is the best place, but it is probably the only list
> that I'm on that won't give me a bunch of grief about the chosen technology.
>
> I looked at VMware's site, and there are a ton of options. I'm wondering
> if anyone has some basic suggestions or experiences.
>
> I'm a Linux admin by trade (RH based), with "ok" networking ability. I'm
> sufficiently versed in deploying scripted ESXi (including 5.x)
> installations for a specific environment, including vswitches/SAN config
> (but only with NFS datastores backed by a NetApp, unfortunately, no
> blockbased stores).
>

If you want block storage, just export an iSCSI device to the ESXi machines
(tgtadm on RedHat is all you need and a few gigs of free space). VMFS is
cluster aware so you can export the same volume to independent ESXi hosts
and as long you don't access the same files, you're good to go.


>
> I'd like to get experience deploying VCenter clusters, down to DRS/HA
> config, other block based storage, and anything else a large environment
> needs.
>
>
All you need is licenses (Enterprise Plus to get all the nice features) and
a vCenter server. If you already have it, just create a new cluster and
follow the prompts in the wizards and play with all the options.


> Thoughts or experiences?
>
>
When I first started with this it seemed like rocket science, but once you
create a cluster and do DRS/HA/dvSwitch/etc it's all pretty basic:
- HA in VMware means that if a host fails, the VMs will be restarted on a
different host.
- DRS it means automated live migration of virtual machines based on load.
- dvSwitch is a distributed virtual switch whereby you have a consistent
configuration across the hosts that you configure from the vCenter server.

If you know RedHat, than from experience in a few days you can learn the
ins/outs of how a VMware cluster works.

With ESXi 5.1+ you can run ESXi inside an ESXi host so if you have a lot of
memory on a host you can create your own little lab with all the features
and experiment with them.

If you want to certify, than official training is a mandatory requirement.

HTH,
Eugeniu

Re: NSA able to compromise Cisco, Juniper, Huawei switches

[Eugeniu Patrascu]

On Thu, Jan 2, 2014 at 10:01 AM, Saku Ytti  wrote:

> On (2014-01-01 23:51 +0200), Eugeniu Patrascu wrote:
>
> > > Is this legal? Can NSA walk in to US based company and legally coerce
> to
> > > install such backdoor? If not, what is the incentive for private
> company to
> > > cooperate?
> > >
> >
> > As you might have seen from the beginning of time, people in power assume
> > anything can go until proven otherwise.
>
> This is mostly academic, as being legal or not being legal it's not
> appealing
> attack vector due to difficulties containing the information.
> But what I implied is, if it is legal, you'd have paper trail, like legal
> document from court.
>
>
I can't speak for NSA practices, but for example FBI asserted that they are
entitled to put GPS trackers on cars owned by people they suspected of
something without a court order. And they fought to the death in courts
when the suspects brought suits against them for violating their rights
with these practices.

It would assume that other agencies employ the same tactics and strong-arm
companies into doing their bidding with minimal paperwork. Let's not forget
that NSA vets all the security vendors and products that the USG uses and
it would be pretty easy for them to stop recommending SecurID tokens (main
RSA business is authentication) for government use.

The above presumption would have sounded crazy six months ago, but now...

Re: NSA able to compromise Cisco, Juniper, Huawei switches

[Eugeniu Patrascu]

On Wed, Jan 1, 2014 at 11:55 AM, Saku Ytti  wrote:

> On (2013-12-31 23:04 +), Warren Bailey wrote:
>
> > that RSA had a check cut for their participation (sell outs..), would it
> > be out of the realm of possibility cisco knowingly placed this into their
> > product line? And would it be their mistake to come out with a “we had no
> > idea!” rather than “guys with badges and court orders made us do it!”?
>
> Is this legal? Can NSA walk in to US based company and legally coerce to
> install such backdoor? If not, what is the incentive for private company to
> cooperate?
>

As you might have seen from the beginning of time, people in power assume
anything can go until proven otherwise.

Re: Juniper SSL VPN

[Eugeniu Patrascu]

On Tue, Dec 31, 2013 at 11:19 PM,  wrote:

> On Tue, 31 Dec 2013 23:09:58 +0200, Eugeniu Patrascu said:
>
> > > We need an emergency fix because a piece of software unexpectedly hit
> > > an end-of-life date?  Didn't we learn anything 14 years ago??!?
> > >
> > >
> > Juniper just posted a technical note saying the issue is fixed and a new
> > ESAP package is out.
>
> Right. The question is why it's coming out on the last day of December,
> rather than the last day of November, or even October...
>

>From what I understood from the tech note, they had no clue this would
happen on the 31st of December :)

Re: Juniper SSL VPN

[Eugeniu Patrascu]

On Tue, Dec 31, 2013 at 7:31 PM,  wrote:

> On Tue, 31 Dec 2013 10:43:02 -0500, Jamie Gwatkin said:
> > Could be related to this?
> > http://kb.juniper.net/InfoCenter/index?page=content&id=TSB16290
>
> Do I want to ask why *THIS*?
>
> "Estimated Fix Date:
> Juniper engineering has root caused this issue is working to build and
> release
> a ESAP fix as soon as possible. The initial estimated release date for the
> fix
> is between 12/31/2013 (PST) and 1/3/2014 (PST). We will update this message
> regularly with the current status until we resolve this issue."
>
> We need an emergency fix because a piece of software unexpectedly hit
> an end-of-life date?  Didn't we learn anything 14 years ago??!?
>
>
Juniper just posted a technical note saying the issue is fixed and a new
ESAP package is out.

Re: NSA able to compromise Cisco, Juniper, Huawei switches

[Eugeniu Patrascu]

On Tue, Dec 31, 2013 at 5:38 AM, Sabri Berisha wrote:

> Hi Roland.
>
> > I don't know much about Juniper
> > gear, but it appears that the Juniper boxes listed are similar in nature,
> > albeit running FreeBSD underneath (correction welcome).
>
> With most Juniper gear, it is actually quite difficult to achieve
> wire-tapping on a large scale using something as simple as a backdoor in
> the BIOS.
>
>
You would just need an entry-point into the system, nothing fancy at first.


> Assuming M/MX/T series, you are correct that the foundation of the
> control-plane is a FreeBSD-based kernel. However, that control-plane talks
> to a forwarding-plane (PFE). The PFE runs Juniper designed ASICs (which
> differ per platform and sometimes per line-card). In general,
> transit-traffic (traffic that enters the PFE and is not destined to the
> router itself), will not be forwarded via the control-plane. This means
> that whatever the backdoor is designed to do, simply can not touch the
> traffic. There are a few exceptions, such as a carefully crafted backdoor
> capable of altering the next-hop database (the PFEs forwarding table) and
> mirroring traffic. This however, would mean that the network would already
> have to be compromised. Another option would be to duplicate target traffic
> into a tunnel (GRE or IPIP based for example), but that would certainly
> have a noticeable affect on the performance, if it is possible to perform
> those operations at all on the target chipset.
>
>
>From my experience with Juniper, you can actually tell the PFEs to do quite
a lot to the packets that flow through the router, I would imagine that
programmatically you can tell the router to mirror packets which match a
certain criteria (source, destination, ports, protocol) to a chosen
destination and it would not get noticed by the NOC monitoring systems (it
may not even blip on the throughput graphs)


> However, attempting any of the limited attacks that I can think of would
> require expert-level knowledge of not just the overall architecture, but
> also of the microcode that runs on the specific PFE that the attacker would
> target, as well as the ability to partially rewrite that. Furthermore, to
> embed such a sophisticated attack in a BIOS would seem impossible to me
> with the first reason being the limited amount of storage available on the
> EEPROM to store all that binary code.
>
>
All you need is a hook into the system and load your code, the main payload
can be easily downloaded from the internet.


> An attack based on corrupted firmware loaded post-manufacturing would also
> be difficult due to the signed binaries and microcode. If someone were to
> embed a backdoor it is extremely difficult without Juniper's cooperation.
> And the last time I looked at the code (I left Juniper a few months ago), I
> saw nothing that would indicate a backdoor of any kind.
>
>
Who checks the binaries when they are loaded when the OS boots up ? :)

Re: The Making of a Router

[Eugeniu Patrascu]

On Fri, Dec 27, 2013 at 10:00 PM, Baldur Norddahl  wrote:

> On Fri, Dec 27, 2013 at 4:18 PM, Jon Sands  wrote:
>
> > On Dec 27, 2013 10:08 AM, "Baldur Norddahl" 
> > wrote:
> >
> > > We are an upstart and just buying the fancy Juniper switch times two
> > would burn half of my seed capital.
> >
> > Then you didn't ask for nearly enough capital.
> >
>
> Another told Nick Cameo that if he can afford a 10G link, he can afford
> Juniper. You could not be more wrong. The 10G uplink goes for $0 in initial
> fee and less than $4k / month with unlimited traffic. The Juniper gear is
> $100k up front for two routers able to handle the 10G links.
>
>
What you should understand is not the fact that a 10G interface is
expensive, but what you can do with that interface tends to get very
expensive.
If you want to move traffic from one interface to another, you can achieve
this today with two physical interfaces on a Linux box. How many PPS ?
Well, that's another story. You then want shaping, Q-in-Q and other stuff
which consume a lot of resources even on dedicated hardware.


> What I get from you guys is that in your opinion it is not possible to set
> up a small ISP without spending a ton on Juniper or Cisco. I am not buying
> that. Even if I did not have a clear limit on my capital, I would be
> looking at avoiding paying that kind of money, because in the end the money
> comes out of my own pocket.
>
>
You can build your ISP without getting big routers but you need to cut back
a little bit on your expectations about what you can in terms of features:
- Do pool NAT for your users if they accept this. You can easily squeeze a
lot of users on a single IP address. Downside is that if one of them does
something bad, that IP might get blackholed on some providers and the rest
will suffer. Also, you might want to take into consideration regulatory
requirements like to know what users used what port to what destination for
a certain number of months (in Europe regulations vary, but the smallest
period is 6 months).
- If you give them VoIP/IPTV then assign a VLAN for VOIP and another for
IPTV and run it to all your users to their STBs and make use of IGMP
snooping for Multicast traffic on all your switches
- You can run full table BGP with Quagga on Linux (it worked for me when
the DFZ was at around 270k prefixes, I assume it will work with 480k
prefixes today) - also, do you really need full tables ?. Your IGP, if you
don't run anything fancy should be a few tens of routes, that can be
achieved with modest L3 switches that do 64/128 routes in hardware.


> Everybody have critical services running on servers. DHCP, DNS, Radius and
> so on are all on servers and you will be down if these services are down.
> What is with the knee jerk reaction for suggesting that the BGP daemon
> could also be run on a server? There seems to be many advantages of doing
> it this way, and not all of them are related to cost.
>
>
For the sake of a good night sleep, you would want to separate all the
services on different physical machines for redundancy/availability and
load sharing.

Once you grow, you can move to more powerful and dedicated hardware for
your networking needs.

Eugeniu

Re: The Making of a Router

[Eugeniu Patrascu]

On Fri, Dec 27, 2013 at 3:05 PM, Baldur Norddahl
wrote:

> On the topic of building a software router for an ISP, has anyone tried it
> using OpenFlow? The idea is to have a Linux server run BGP and a hardware
> switch to move the packets. The switch would be programmed by the Linux
> server using the OpenFlow protocol.
>
> I am looking at the HP 5400 zl switches as the hardware platform and
> RouteFlow https://sites.google.com/site/routeflow/ to program the BGP
> rules.
>
> One issue is that the HP switch will only allow a limited amount of rules
> to be processed in hardware (about 4096 rules I believe). Will this be
> enough to cover most of the traffic of a FTTH ISP on the fast path?
>

You want to use the switch for what ? To connect last-mile customers ? For
L3 aggregation ? You want to run the switch as an edge router with limited
BGP ? What's the exact use case you are thinking about ?

Eugeniu

Re: Juniper MAG/SA question - re: split tunneling policy and use of JSAM/WSAM

[Eugeniu Patrascu]

On Tue, Dec 24, 2013 at 7:50 PM, Herro91  wrote:

> Hello J-NSP and Nanog members
>
> Hopefully this is the right forum for this discussion - if not my apologies
> for further clogging your inbox.
>
> Here it goes:
>
> Would you consider use of JSAM/WSAM to selectively proxy and tunnel certain
> applications a form of split tunneling? The traditional concept of split
> tunnels looks at all traffic Layer 3 and above, versus JSAM/WSAM which
> looks at application traffic at Layer 7.
>
>
It's still Layer3, but it looks at the application name which sends the
traffic in order to selectively tunnel specific destination networks and
ports.

I wouldn't call it split tunneling, but it depends on how your security
policy classifies this kind of traffic.
It's also worth looking at what risks this may bring to your exposed
services as it check for process name, not necessarily for it to be valid
(you can always create an outlook.exe app that tries to crash the Exchange
CAS or something similar).


> The context for all of this is from a previous question I put out regarding
> split tunneling policy on government networks.
>
>
>

Re: ddos attacks

[Eugeniu Patrascu]

On Thu, Dec 19, 2013 at 10:30 PM, den...@justipit.com
wrote:

> Just about every security, network and ADC vendor out there is claiming
> anti-dos capabilities.  Be careful when going that route and do your own
> validation.  I suggest looking at Radware and Arbor (both leaders in the
> market). To successfully mitigate an attack the ideal solutions will weed
> out the attack and allow legitimate traffic to continue.  Many of the
> solutions in the commercial market are not much more than rate limiters and
> are not very forgiving.  Just as important realize while spoofed udp floods
> are popular they are oftened only the first vector, if successfully
> mitigated attackers quickly adjust and follow with more complex vectors
> such as application attacks toward http, ssl, dns query floods, etc..
> Remember their goal is to bring you down, , divert your attention while
> they steal your data or perhaps transfer funds.  They will go to far
> lengths to achieve their end result.  As you can imagine it's much harder
> to identify the attack characteristics or for that matter the attacker in
> these more complex cases.  In summary, I'm a firm believer in a hybrid
> approach with combination of infrastructure acls, rtbh, qos, URPF, tcp
> stack hardening, local anti-ddos appliances for application attacks and
> network floods under link capacity to allow you to stay up while deciding
> to shift routes into cloud band ability to swing up stream to cloud
> scrubbing center (in house or third party).
>

I know a bit about Radware, and what they do is to learn a traffic pattern
from where traffic usually comes and when in case of exceeding a certain
threshold, they start dropping traffic from new sources never seen before
and then drop some seen before traffic. This works if you are a company
with a very localized visitor base (like banking site for certain national
or local bank, e-shop and so on) but it kind of doesn't scale that much
when it comes to we have people all over the place and we get DDoS-ed with
legitimate requests that only consume server resources.


What providers do in some regions is to blackhole your subnet if you reach
a certain number of packets per second. It sucks, but hey, they also have
infrastructure to protect.

Eugeniu

Re: ddos attacks

[Eugeniu Patrascu]

Hi,

You can also take a look at http://www.packetdam.com/ for DDoS protection.

Eugeniu


On Thu, Dec 19, 2013 at 10:53 AM, Tore Anderson  wrote:

> * James Braunegg
>
> > Of course for any form of Anti DDoS hardware to be functional you
> > need to make sure your network can route and pass the traffic so you
> > can absorb the bad traffic to give you a chance cleaning the
> > traffic.
>
> So in order for an Anti-DDoS appliance to be functional the network
> needs to be able to withstand the DDoS on its own. How terribly useful.
>
> Tore
>
>

Re: Someone’s Been Siphoning Data Through a Huge Security Hole in the Internet

[Eugeniu Patrascu]

On Sun, Dec 8, 2013 at 11:46 PM, Merike Kaeo
wrote:

>
> On Dec 6, 2013, at 11:55 AM, Eugeniu Patrascu  wrote:
>
> > On Fri, Dec 6, 2013 at 9:48 PM, Jared Mauch 
> wrote:
> >
> >>
> >> On Dec 6, 2013, at 1:39 PM, Brandon Galbraith <
> brandon.galbra...@gmail.com>
> >> wrote:
> >>
> >>> If your flows are a target, or your data is of an extremely sensitive
> >>> nature (diplomatic, etc), why aren't you moving those bits over
> >>> something more private than IP (point to point L2, MPLS)? This doesn't
> >>> work for the VoIP target mentioned, but foreign ministries should most
> >>> definitely not be trusting encryption alone.
> >>
> >> I will ruin someones weekend here, but:
> >>
> >> MPLS != Encryption.  MPLS VPN = "Stick a label before the still
> >> unencrypted IP packet".
> >> MPLS doesn't secure your data, you are responsible for keeping it secure
> >> on the wire.
> >>
> >>
> > It's always interesting to watch someone's expression when they hear that
> > MPLS VPN, even if it says VPN in the name is not encrypted. Priceless
> every
> > time :)
>
> So, just to raise the bar…I had someone once tell me they encrypted
> everything since they
> were using IPsec.  Since I only trust configurations, lo and behold the
> configuration was
> IPsec AH.  As exercise to reader….determine why using IPsec does not
> automagically equate to
> encrypted traffic.
>
>
Interesting, as it's particularly hard to enable only AH instead of ESP.


> This was only 2 years ago while doing a security assessment for someone.
>
> I greatly dislike the term 'VPN'…..always have and always will.
> Marketechture is awesome!
>
>
I think you probably dislike all the people that grossly misunderstand what
a VPN is and what are its use cases :)

Re: Someone’s Been Siphoning Data Through a Huge Security Hole in the Internet

[Eugeniu Patrascu]

On Fri, Dec 6, 2013 at 9:48 PM, Jared Mauch  wrote:

>
> On Dec 6, 2013, at 1:39 PM, Brandon Galbraith 
> wrote:
>
> > If your flows are a target, or your data is of an extremely sensitive
> > nature (diplomatic, etc), why aren't you moving those bits over
> > something more private than IP (point to point L2, MPLS)? This doesn't
> > work for the VoIP target mentioned, but foreign ministries should most
> > definitely not be trusting encryption alone.
>
> I will ruin someones weekend here, but:
>
> MPLS != Encryption.  MPLS VPN = "Stick a label before the still
> unencrypted IP packet".
> MPLS doesn't secure your data, you are responsible for keeping it secure
> on the wire.
>
>
It's always interesting to watch someone's expression when they hear that
MPLS VPN, even if it says VPN in the name is not encrypted. Priceless every
time :)

Re: [c-nsp] Cisco ScanSafe, aka Cisco Cloud Web Security

[Eugeniu Patrascu]

Helllo Pui,

Thanks for the pointers but I think you misunderstood my question. I know
how to set up a captive portal for WiFi access.

What I wanted to know is how are users logging into captive portals when
the browser has a proxy set and it tries to send all requests to the proxy
server which until they authenticate to the captive portal they cannot
reach ?

Eugeniu


On Fri, Dec 6, 2013 at 9:47 AM, Pui Edylie  wrote:

> Hi Eugeniu,
>
> You could use the inexpensive Mikrotik User Manager
>
> http://wiki.mikrotik.com/wiki/User_Manager/Introduction
>
> http://wiki.mikrotik.com/wiki/Manual:User_Manager
>
> http://wiki.mikrotik.com/wiki/User_Manager/Getting_started
>
> http://www.youtube.com/watch?v=blEGv5i-aO4
>
> Good Luck :)
>
> Edy
>
> On 12/6/2013 3:14 PM, Eugeniu Patrascu wrote:
>
>> Hi,
>>
>> How do you handle captive portals in hotels and other venues where you
>> first have to login into the portal and then have Internet access ?
>>
>> This is my biggest woe right now in this regards with any kind of proxy
>> settings I can push to users.
>>
>> Thanks,
>> Eugeniu
>>
>>
>> On Thu, Dec 5, 2013 at 10:05 PM, Scott Voll  wrote:
>>
>>  We currently use CCWS (previously ScanSafe) with the Anyconnect client.
>>>   Nice solution.  Whether your in the office or remoting from a
>>> Starbucks,
>>> the traffic is always proxied.  We went with the solution because of a
>>> couple reasons:
>>>
>>> 1. with multiple egress points on the corporate network, we didn't want
>>> to
>>> be down if we lost a proxy server.
>>>
>>> 2. corporate laptops whether in the office or at Starbucks would still be
>>> proxied.  This helps limit our virus and malware infections.  and
>>> provides
>>> HR reports.
>>>
>>> 3 split tunneling would be an option because the traffic doesn't have to
>>> come back to your internal proxy.
>>>
>>> 4. our remote home office bandwidth is very limited, so using the cloud
>>> it
>>> provided for better use of that bandwidth.
>>>
>>> all and all it's a good solution.  I'm not going to tell you that we have
>>> not had any issues, but with any new solution, there will be a couple
>>> bruises along the way.
>>>
>>> YMMV
>>>
>>> Scott
>>>
>>>
>>>
>>> On Wed, Dec 4, 2013 at 7:53 AM, Herro91  wrote:
>>>
>>>  Hi,
>>>>
>>>> I'm doing some research on the Cisco Cloud Web Security offering, also
>>>> known as ScanSafe.
>>>>
>>>> Has anyone on the lists explored Cisco's ScanSafe SaaS offering, now
>>>>
>>> called
>>>
>>>> Cisco Cloud Web Security - as a means of providing protection in the
>>>>
>>> cloud
>>>
>>>> that would potentially negate the requirement to have a full tunnel
>>>> (i.e.
>>>> allow split tunneling) for teleworkers?
>>>>
>>>>
>>>> Thanks!
>>>>
>>>>  ___
>>> cisco-nsp mailing list  cisco-...@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>>
>
>

Re: [c-nsp] Cisco ScanSafe, aka Cisco Cloud Web Security

[Eugeniu Patrascu]

Hi,

How do you handle captive portals in hotels and other venues where you
first have to login into the portal and then have Internet access ?

This is my biggest woe right now in this regards with any kind of proxy
settings I can push to users.

Thanks,
Eugeniu


On Thu, Dec 5, 2013 at 10:05 PM, Scott Voll  wrote:

> We currently use CCWS (previously ScanSafe) with the Anyconnect client.
>  Nice solution.  Whether your in the office or remoting from a Starbucks,
> the traffic is always proxied.  We went with the solution because of a
> couple reasons:
>
> 1. with multiple egress points on the corporate network, we didn't want to
> be down if we lost a proxy server.
>
> 2. corporate laptops whether in the office or at Starbucks would still be
> proxied.  This helps limit our virus and malware infections.  and provides
> HR reports.
>
> 3 split tunneling would be an option because the traffic doesn't have to
> come back to your internal proxy.
>
> 4. our remote home office bandwidth is very limited, so using the cloud it
> provided for better use of that bandwidth.
>
> all and all it's a good solution.  I'm not going to tell you that we have
> not had any issues, but with any new solution, there will be a couple
> bruises along the way.
>
> YMMV
>
> Scott
>
>
>
> On Wed, Dec 4, 2013 at 7:53 AM, Herro91  wrote:
>
> > Hi,
> >
> > I'm doing some research on the Cisco Cloud Web Security offering, also
> > known as ScanSafe.
> >
> > Has anyone on the lists explored Cisco's ScanSafe SaaS offering, now
> called
> > Cisco Cloud Web Security - as a means of providing protection in the
> cloud
> > that would potentially negate the requirement to have a full tunnel (i.e.
> > allow split tunneling) for teleworkers?
> >
> >
> > Thanks!
> >
> ___
> cisco-nsp mailing list  cisco-...@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

Re: Anyone competent within AT&T Uverse?

[Eugeniu Patrascu]

On Wed, Dec 4, 2013 at 7:57 PM, John Kreno  wrote:

> One wonders if this is an industry trend.
>
>
Outsourcing the outsourcers to other outsourcers... and at the end of the
day everyone is congratulating everyone that the SLAs have been met :))

Re: Cisco ScanSafe, aka Cisco Cloud Web Security

[Eugeniu Patrascu]

On Wed, Dec 4, 2013 at 5:53 PM, Herro91  wrote:

> Hi,
>
> I'm doing some research on the Cisco Cloud Web Security offering, also
> known as ScanSafe.
>
> Has anyone on the lists explored Cisco's ScanSafe SaaS offering, now called
> Cisco Cloud Web Security - as a means of providing protection in the cloud
> that would potentially negate the requirement to have a full tunnel (i.e.
> allow split tunneling) for teleworkers?
>

First of all, why are you allowing or disallowing split tunnel networks ?

The only case I see when you want to route all traffic through the gateway
is when you have a big network that changes constantly and you don't want
to update ACLs all day to make sure a teleworker can reach certain
equipment no matter what.

Other than that, when the laptop is not connected to the VPN and the user
can browse whatever site on the internet and from a security standpoint
there is no benefit.

There is always the risk that he/she may get infected with some malware
that your antivirus does not recognize and it spreads through the internet
network when the user VPNs to the corporate network.

Even with a malware cloud service, you still have security gaps and
opportunity windows for attackers to get to you. One thing is that it not
always feasible to have a proxy set up in your browser all the time as for
example it would be impossible to connect to the internet when you are at a
hotel that has a captive portal. And in order to get access you will have
to disable the proxy, log into the captive portal, pay (optionally), accept
the terms and reactive the proxy settings in the browser. And fi you forget
to do this... well, you're on your own and hope for the best and that the
locally installed AV and anti-malware solution is "good enough".

What I would suggest is that you only allow access to some jump hosts
(linux/windows/etc) that are being protected by adequate security measures
such an IPS. This also assumes that the same level of protection exists
between your user network and server network, otherwise it's pretty much
game over once the user is back in the office with full network access.

Regards,
Eugeniu

Re: Policy-based routing is evil? Discuss.

[Eugeniu Patrascu]

On Mon, Nov 25, 2013 at 9:43 AM, Michael Smith  wrote:

>
> On Nov 24, 2013, at 10:36 PM, Eugeniu Patrascu  wrote:
>
> On Fri, Oct 11, 2013 at 8:27 PM, William Waites  >wrote:
>
> I'm having a discussion with a small network in a part of the world
> where bandwidth is scarce and multiple DSL lines are often used for
> upstream links. The topic is policy-based routing, which is being
> described as "load balancing" where end-user traffic is assigned to a
> line according to source address.
>
> In my opinion the main problems with this are:
>
>  - It's brittle, when a line fails, traffic doesn't re-route
>
>
> You can always know what IPs are on the other end of the link, add static
> routes for them to make sure they're reachable and based on ping results
> use the link or not. It works fairly well if 1-2 minutes of downtime is not
> an issue. I've done this using Linux and a bash script and it worked to
> balance traffic across two links with up/down detection. iproute2 does
> wonders.
>
> Or you could run FreeBSD with PF and ifstated and it would be an almost
> instantaneous failover.
>
>
 Cool toy for scripting. I had no ideea as I'm not very familiar with *BSD.

>
>  - None of the usual debugging tools work properly
>
>
> As long as you don't have asymmetric routing in place, debugging will be
> the same. Even so, you can (at least on Linux) do a "tcpdump -i any" and
> see what goes in/out of your box :)
>
>
> Asymmetric routing is a fact of life and is fairly common.
>

If you have asymmetric routing, you may run into other issues, but still
you can get stuff working. Just saying that with a little care you can get
away without it.


>
>  - Adding a new user is complicated because it has to be done in (at
>least) two places
>
>
> I agree it's not scaleable, but for when all you have are DSL lines or low
> capacity lines over which you cannot run an IGP, you'll have make it work
> with what you have :)
>
>
> But I'm having a distinct lack of success locating rants and diatribes
> or even well-reasoned articles supporting this opinion.
>
>
> I would go for the "right tools for the right job" idea and say that PBR in
> the case you're mentioning of a valid use and probably the most effective
> way of doing business for them.
>
> Also take into consideration that in many parts of the world, the effort of
> configuring and maintaining a setup like this fall in the the day to day
> job of one or several network admins. Also, most of the time is cheaper to
> hire more people than go and buy let's say professional networking
> equipment.
>
>
> Hmm, really?  The professional networking equipment required for this type
> of thing would be in the ~10k new and significantly cheaper used.  That's
> not a lot of salary.
>
>
I'm pretty sure there are places that even 6K can be one man's salary for a
year or more, so yeah, really it's cheaper to have some one do manual stuff
than buy something professional. But I'm veering a bit off-topic with this
one.


> Mike
>

Eugeniu

Re: Policy-based routing is evil? Discuss.

[Eugeniu Patrascu]

On Fri, Oct 11, 2013 at 8:27 PM, William Waites wrote:

> I'm having a discussion with a small network in a part of the world
> where bandwidth is scarce and multiple DSL lines are often used for
> upstream links. The topic is policy-based routing, which is being
> described as "load balancing" where end-user traffic is assigned to a
> line according to source address.
>
> In my opinion the main problems with this are:
>
>   - It's brittle, when a line fails, traffic doesn't re-route
>

You can always know what IPs are on the other end of the link, add static
routes for them to make sure they're reachable and based on ping results
use the link or not. It works fairly well if 1-2 minutes of downtime is not
an issue. I've done this using Linux and a bash script and it worked to
balance traffic across two links with up/down detection. iproute2 does
wonders.


>   - None of the usual debugging tools work properly
>

As long as you don't have asymmetric routing in place, debugging will be
the same. Even so, you can (at least on Linux) do a "tcpdump -i any" and
see what goes in/out of your box :)


>   - Adding a new user is complicated because it has to be done in (at
> least) two places
>
>
I agree it's not scaleable, but for when all you have are DSL lines or low
capacity lines over which you cannot run an IGP, you'll have make it work
with what you have :)


> But I'm having a distinct lack of success locating rants and diatribes
> or even well-reasoned articles supporting this opinion.
>
>
I would go for the "right tools for the right job" idea and say that PBR in
the case you're mentioning of a valid use and probably the most effective
way of doing business for them.

Also take into consideration that in many parts of the world, the effort of
configuring and maintaining a setup like this fall in the the day to day
job of one or several network admins. Also, most of the time is cheaper to
hire more people than go and buy let's say professional networking
equipment.

Regards,
Eugeniu

Re: will ISP peer with 2 local WAN routers?

[Eugeniu Patrascu]

A bit late to the discussion, but we use a stack of EX switches which
terminate L2 connections from the providers and two routers which have BGP
sessions with them.
Each switch has ports provisioned so that in case one switch fails, we just
simply move the ethernet cable to the working switch and everything is fine.

Eugeniu


On Sat, Aug 17, 2013 at 12:47 AM, Adam Greene wrote:

> Pete,
>
> Good point, thanks. Yes, in this case, there is some cause to believe that
> the switches will prove more reliable than the routers. They're older
> 7200VXR's and have had some lockups in the past, possibly due to PA card /
> IOS incompatibilities.
>
> But you're right, we are also considering accepting full or partial routes
> from both providers, one provider per router, and then doing iBGP between
> them to balance the load. We're thinking of deploying default routes and
> HSRP to stacked 3750's for round-robin load balancing on the LAN side.
>
> Thanks for the help!
>
> Adam
>
>
> -Original Message-
> From: Peter Kristolaitis [mailto:alte...@alter3d.ca]
> Sent: Friday, August 16, 2013 5:30 PM
> To: nanog@nanog.org
> Subject: Re: will ISP peer with 2 local WAN routers?
>
> But the switches themselves are a single point of failure, so if a switch
> dies you still only have a single provider (assuming one switch per
> provider).  ;)
>
> All you're doing is moving the your single point of failure from the
> routers
> to the switches, with arguably very little increase in actual reliability
> (if any, depending on whether you think switches are less likely to fail
> than routers).
>
> - Pete
>
>
>
> On 08/16/2013 05:21 PM, Adam Greene wrote:
> > Thanks, Justin. Yes, we considered that option, too. But then if one
> > WAN router goes down, the customer will only have connectivity through
> > a single upstream provider. We'd prefer to maintain connectivity to
> > both even if a router fails. Switches in front of the routers is no
> problem.
> >
> > -Original Message-
> > From: Justin Vocke [mailto:justin.vo...@gmail.com]
> > Sent: Friday, August 16, 2013 4:47 PM
> > To: Adam Greene
> > Cc: 
> > Subject: Re: will ISP peer with 2 local WAN routers?
> >
> > The gotcha with that is then you need a switch in front of the
> > routers. I'd just setup a carrier on each router and run ibgp between.
> >
> > Sent from my iPhone
> >
> > On Aug 16, 2013, at 3:35 PM, "Adam Greene" 
> wrote:
> >
> >> Hi guys,
> >>
> >>
> >>
> >> I have a customer who peers via eBGP with Lightpath aka Cablevision
> >> (AS
> >> 6128) and Level3 (AS 3356) and wants to do some dual-WAN router
> > redundancy.
> >>
> >>
> >> I have heard that carriers will sometimes agree to set up a /29 WAN
> >> subnet for a customer and peer with (2) customer routers.
> >>
> >>
> >>
> >> The customer is delaying on providing me with the proper circuit ID &
> >> contact information to be able to call Lightpath and Level3 directly
> >> and find out if they will do this, so I thought of asking this list.
> >>
> >>
> >>
> >> Is anyone aware if Lightpath and Level3 will agree to something like
> this?
> >>
> >>
> >> Thanks,
> >>
> >> Adam
> >>
> >>
> >>
> >>
> >>
> >
>
>
>
>
>

Re: Office 365..? how Microsoft handed the NSA access to encrypted messages

[Eugeniu Patrascu]

Dropping everything at once may dilute the debate as I am sure your
government and every other government that may be proved to be involved
will try to focus the discussion on small and less damaging issues until
the bigger ones are forgotten.

Reveal something, wait a few weeks/months, reveal something else may keep
the debate open for longer time and at some point maybe enough critical
mass is attained where something can be achieved.




On Mon, Jul 15, 2013 at 7:17 PM, Warren Bailey <
wbai...@satelliteintelligencegroup.com> wrote:

> I don't think the conversation is based around the method by which
> information is intercepted. I hope the conversation is aligned with its
> reasoning for disclosure - the American people stopping a government who is
> known for abusing it's power. Obviously this does not mean physically
> stopping them, but I imagine most people know what motivates their state
> and national political officials. I still wonder why Mr. Snowden hasn't
> dropped more damaging information, it would seem his sworn enemy has made
> their feelings somewhat clear.
>
>
> Sent from my Mobile Device.
>
>
>  Original message 
> From: Christopher Morrow 
> Date: 07/15/2013 7:34 AM (GMT-08:00)
> To: Valdis Kletnieks 
> Cc: nanog list 
> Subject: Re: Office 365..? how Microsoft handed the NSA access to
> encrypted messages
>
>
> On Mon, Jul 15, 2013 at 10:11 AM,   wrote:
> > On Sun, 14 Jul 2013 15:45:26 -0500, Aaron Wendel said:
> >
> >> We (ISPs) are all compelled to provide information from time to time
> >> under a court order. The PRISM program is voluntary.
> >
> > Ask the ex-CEO of Qwest how "voluntary" that sort of stuff is.
>
> it REALLY depends on what 'prisim' is... seen in one light, the
> program is 'just' isp/asp people who agree to permit FISA requests to
> be satisfied via: "scp files from fisa.isp.net with key fingerprint
> 0xasdasdasd"
>
> of course, the other way to read it (as the news would like us to
> believe) is as: "plug nsa ethernet into eth1 of all servers and
> routers, kthxbi!"
>
> more details would certainly make this whole conversation less alamist
> and more rational.
> -chris
>
>

Re: Office 365..? how Microsoft handed the NSA access to encrypted messages

[Eugeniu Patrascu]

Maybe people will now start turning on their encryption functions on any
device capable of doing it :)


On Sat, Jul 13, 2013 at 11:57 AM, Warren Bailey <
wbai...@satelliteintelligencegroup.com> wrote:

> The entire idea of prism is hitting tier 1 providers and mass
> communications providers. If they haven't rooted your exchange gear, they
> don't need to - your upstream providers entire stream is being copied. I
> can't think of many providers that couldn't be intercepted. When new
> transportation mediums arrive, who cares.. You already have a copy from
> their provider or peer.
>
>
> Sent from my Mobile Device.
>
>
>  Original message 
> From: ryang...@gmail.com
> Date: 07/12/2013 8:52 PM (GMT-08:00)
> To:
> Cc: nanog@nanog.org
> Subject: Re: Office 365..? how Microsoft handed the NSA access to
> encrypted messages
>
>
> It wouldn't be. When the endpoint in question is compromised, there isn't
> any amount of tunneling or obscurity between point a and point b that will
> resolve it. Only thing you can do is change to a solution that you have
> more control over.
> Sent on the TELUS Mobility network with BlackBerry
>
> -Original Message-
> From: Warren Bailey 
> Date: Sat, 13 Jul 2013 00:12:37
> To: Nick Khamis; Justin M. Streiner<
> strei...@cluebyfour.org>
> Reply-To: Warren Bailey 
> Cc: nanog@nanog.org
> Subject: Re: Office 365..? how Microsoft handed the NSA access to encrypted
>  messages
>
> That doesn't sound like it would be effective in this instance?
>
>
> Sent from my Mobile Device.
>
>
>  Original message 
> From: Nick Khamis 
> Date: 07/12/2013 1:06 PM (GMT-08:00)
> To: "Justin M. Streiner" 
> Cc: nanog@nanog.org
> Subject: Re: Office 365..? how Microsoft handed the NSA access to
> encrypted messages
>
>
> We are currently working on something right now where all connections
> are doing over an encrypted vpn. We are bringing SIP, email, search,
> and cloud to the tunnel.
>
> You can contact me off list if you would like to know more.
>
> Nick Khamis
>
>

Re: WW: Bruce Schneier on why security can't work

[Eugeniu Patrascu]

The US law enforcement is getting closer and closer at being able to
be DDoS-ed very effectively because of all of their advisories about
"see something, say something" and all other scare tactics crap they
come up with.
I mean it's bad some guy shot up a lot of people in a theater or in a
school, but now it's sufficient to call 911 and say you saw a guy with
what looks like an assault riffle in a theater or school campus and
the just grab a bucket of popcorn and see everyone panic and SWAT
teams with guns blazing canvasing the objective.
Do it in a coordinated fashion on a daily basis and bam: DDoS at it's
finest. No one would take a chance to treat the calls as pranks
because if they get it wrong only once, they will be in a very big
s***storm.
Not to talk about economic losses because once a day a mall gets
evacuated for a few hours. The cost of pulling it off: none. 911 calls
are free :))

Today, tomorrow, someone else will shoot up a mall. What are you going
to do ? Install TSA scanners at mall entrances ? No problem, you can
shoot people in a subway station ? What, TSA at every subway station
entrance in the country ? At every bus station ? Blackwater security
with metal detectors every conference held in a hotel ?
Or just play it cool and live normally with the chance that the next
disgruntled person with a gun will not choose the same place you
happen to be at at any particular time.

The "disgruntled person with a gun" can be replaced with your favorite
type of bad guy (bio-terrorist, suicide bomber etc).

It's not a secret that people do stupid things when they're scared and
all of the world's governments know this and never loose the chance to
pass more restrictive laws whenever a tragedy happens and people would
support anything that they believe would stop another incident.

What people need is more common sense and not be get scared and
panicked by whatever scare the media throws at at them. They would
twist  stories to get ratings in unimaginable ways.

Statistically speaking, everyone of us has a chance everyday to die in
an accident (get hit by a car, bus, metro, train whatever). This does
not mean that everyone should stay home and do nothing. Even at home
you can cat yourself very bad with a knife making dinner :))

Minimize the big threats using intelligence services effectively, and
smaller ones if you can in a non-intrusive way. Perfect security will
never be something that can be attained. Even from North Korea people
escape from time to time, and they are surveilled like crazy.


On Fri, Mar 15, 2013 at 3:53 PM, Owen DeLong  wrote:
>> And there you have it :)
>>
>> Security obviously works  thus far,   in the sense, that so far,
>> government has been preserved -- there is not total chaos, in at least
>> most of the world,  and people do not doubt if their life or property
>> will still exist the next day.
>>
>
> I'm not sure I would even put "government has been preserved" on the list of 
> considerations for the success or failure of security.
>
> I would put "law and order", "governance and/or the process of governance" on 
> the list, but especially in a post-911 world, the US Government has departed 
> from those ideals to varying degrees.
>
> Do not get me wrong, I am not advocating radical revolution or saying that we 
> should tear down the existing institutions. Merely that we should be careful 
> in our default use of terminology and focus on what we really want to 
> preserve. Ideally, we can restore the US government to its proper (and 
> limited) function. (That does not mean eliminating government services and 
> making it small enough to fit in our bedrooms, either.)
>
> I'm not supporting any of the current Washington agendas and parties. I'm fed 
> up with all of them at this point and unless they start working on solving 
> problems instead of posturing all the time, I won't be supporting ANY 
> incumbents.
>
>> Abusing new technology faster doesn't trump the extreme smallness of
>> the numbers of truly bad actors,  who have irrational thinking,  would
>> like to end civilization,  and the intersection between those and
>> those who have a viable method that would work + the right
>> resources/skill  available,  and a reasonable chance of success
>> astronomically small
>
> The bottom line is that any system of laws and/or governance depends entirely 
> on voluntary compliance by the majority of the actors.
>
>> If in a few decades,  there is a  0.1%chance per decade of a
>> script kiddie ending civilization,   I think we've got few reasonable
>> alternatives but to accept that risk and hope for the best :)
>
> On the other hand, I will hold up the U.S.A.P.A.T.R.I.O.T. act and the T.S.A. 
> as proof that we are rather adept at exploring and sometimes acting on the 
> unreasonable alternatives.
>
> Owen
>
>
>

Re: Comcast NOC Contact

[Eugeniu Patrascu]

My comment was more or less directed to the person that said "losts of
people want to send traffic to comcast, but no one wants to send money". I
find it very dangerous and provocative, and somewhat on the same line with
others that believe in the "sender party pays" crap they're trying to force
onto the market.


On Thu, Mar 7, 2013 at 4:13 PM, Jamie Bowden  wrote:

> > From: Eugeniu Patrascu [mailto:eu...@imacandi.net]
>
>
> > Comcast's customers send money to Comcast in order to receive whatever
> > they
> > want from other networks. With that money, Comcast should invest in
> > infrastructure so that it's network is not saturated anymore. Isn't this
> > how IPSs work ? :)
>
> In competitive markets, that's the theory.  That would require one to test
> with...
>
> Jamie
>

Re: Comcast NOC Contact

[Eugeniu Patrascu]

Comcast's customers send money to Comcast in order to receive whatever they
want from other networks. With that money, Comcast should invest in
infrastructure so that it's network is not saturated anymore. Isn't this
how IPSs work ? :)


On Sat, Mar 2, 2013 at 8:07 PM, Vinod K  wrote:

>
> Rob:
>
> Comcast engineers are on the NANOG list.  If you reply with IP and
> traceroute they can help u.
>
> I hear there are networks at capacity b/c of ratios.  Everybody wants to
> send Comcast traffic, but noone wants to send money.
>
> V
>
> > From: wingc...@hotmail.com
> > To: nanog@nanog.org
> > Subject: Comcast NOC Contact
> > Date: Sat, 2 Mar 2013 04:17:04 -0500
> >
> > Could someone from Comcast's NOC contact me off-list? We're seeing some
> traffic take a strange route on its way back to some Comcast prefixes from
> several of our systems. Thank you!
> > -Rob
>
>

Re: IPV6 in enterprise best practices/white papaers

[Eugeniu Patrascu]

On Mon, Jan 28, 2013 at 9:54 PM, Owen DeLong  wrote:
>
> On Jan 28, 2013, at 10:03 , Joe Maimon  wrote:
>
>>
>>
>> Eugeniu Patrascu wrote:
>>> On Sat, Jan 26, 2013 at 11:26 AM, Pavel Dimow  wrote:
>>
>>> As being personally involved deploying IPv6 on an enterprise network,
>>> here's how I did it (keeping in mind the fact that we have our own
>>> ASN):
>>>
>>
>> I suggest this be step 0
>>
>
> Yes.
>
>>> - get a /48 PI from the local LIR
>>
>> And this be step 1
>>
>
> No, this is step 2 and /48 is not necessarily the right answer.
>
> Step 1 is to evaluate your network and figure out your addressing needs.
>
> If you have a single corporate office and are not an ISP, then /48 is fine.
>
> If you have multiple locations, then a /48 per location is more appropriate.
>

Yes, I know this is the rule, but right now we only have one location,
so I got only a /48.

One thing that I missed in my first e-mail, was to say that for each
subnet I allocated a /64 as it works with most equipment and no funky
netmasks.

One of my ISPs is running /126 netmask on the border links and the
other runs /64 - probably a matter of preference by their network
admins.

Eugeniu

Re: IPV6 in enterprise best practices/white papaers

[Eugeniu Patrascu]

On Mon, Jan 28, 2013 at 8:58 PM, Doug Barton  wrote:
> On 1/28/2013 7:27 AM, Eugeniu Patrascu wrote:
>>
>> - configure IPv6 firewall rules (mostly a mirror of the IPv4 rulesets)
>
>
> Hopefully that did not included filtering ICMPv6? :)

No, of course not :)
I did a bit (actually very little) of reading about IPv6 before doing
all that, but nothing compares to the actual implementation when you
discover the quirks each vendor has in that regard :))

Eugeniu

Re: IPV6 in enterprise best practices/white papaers

[Eugeniu Patrascu]

On Mon, Jan 28, 2013 at 6:45 PM, Mukom Akong T.  wrote:
>
> On Mon, Jan 28, 2013 at 7:27 PM, Eugeniu Patrascu 
> wrote:
>>
>> I thought about running pure IPv6 inside and do 6to4, but it's too
>> much of a headache,
>
>
> Nice call (skipping 6to4)
>
>>
>> not to mention that not all the internal equipment
>> knows about IPv6 - L2 switches, some terminal servers and so on.
>
>
> Does an L2 switch really care about IPv6? (except for stuff like DHCPv6
> snooping, etc?)

It doesn't, I was talking about management IP addresses (for example
HP2510 only uses IPv4 management addresses).

Eugeniu

Re: IPV6 in enterprise best practices/white papaers

[Eugeniu Patrascu]

On Sat, Jan 26, 2013 at 11:26 AM, Pavel Dimow  wrote:
> Hi,
>
> I have read many of those ipv6 documents and they are great but I
> still luck to find something like "real word" scenario.
> What I mean is that for example I want to start implementation of ipv6
> in my enterprise according to mu knowledge so far
> my first step is to create address plan, then implement security on
> routers/switches then on hosts, and after that I can start to create
>  record and PTR recors in DNS and after that I should configure my
> dhcp servers and after all has been done I can test ipv6 in LAN and
> after that I can start configure bgp with ISP.
> Is this correct procedure? Any thoughts? If all is correct I have a
> few questions..
>
> Regarding DNS, if I give a /64 to host using SLAAC or DHCP how do I
> maintain PTR for this /64? I should use DDNS?
> What do you use in your enterprise SLAAC or DHCP? If SLAAC why not DHCP?
> Any other hints/tips?
>

As being personally involved deploying IPv6 on an enterprise network,
here's how I did it (keeping in mind the fact that we have our own
ASN):

- get a /48 PI from the local LIR
- configure the border routers to announce the prefix and do
connectivity tests (ping Google/Facebook addresses using an IPv6
address from our own /48 - loopback on the router)
- configure IPv6 addresses on internal router and do connectivity tests again
- configure firewall interfaces with IPv6 addresses and again connectivity tests
- configure IPv6 firewall rules (mostly a mirror of the IPv4 rulesets)
- configure IPv6 address on DMZ servers (actually the first one
configured were the DNS servers)
- do connectivity tests again
- publish IPv6 records for the DNS servers and for the domain and run
ping/telnet 80 tests from another ipv6 enabled network to check that
everything is OK.
- publish  records for all the hosts in the DMZ and making sure
all the services available on IPv4 were also available on IPv6
- did the same for the servers in the "Server network"
- last stept was to enable IPv6 on the nework that served the users
using RA with the stateful configuration bit set on the firewall and
DHCPv6 to serve up DNS servers for IPv6

Yes, I know there are a lot of connectivity tests but it allowed me to
check that routing was working and ports were open on the firewall as
expected as I got deeper and deeper down the rabbit hole :)

PTRs are only enabled/published for servers and user networks, but
it's not announced on the internet.

It's working fine since August-September of 2011 without issues in a
dual stack environment.
I thought about running pure IPv6 inside and do 6to4, but it's too
much of a headache, not to mention that not all the internal equipment
knows about IPv6 - L2 switches, some terminal servers and so on.

If you're not sure about things, do it on the equipment with the
lowest operational impact and see how that goes.

Eugeniu

Re: Notice: Fradulent RIPE ASNs

[Eugeniu Patrascu]

On Tue, Jan 15, 2013 at 12:49 AM, Ronald F. Guilmette
 wrote:
>
> After a careful investigation, I am of the opinion that each of the
> following 18 ASNs was registered (via RIPE) with fradulent information
> purporting to represent the identity of the true registrant, and that
> in fact, all 18 of these ASNs were registered by a single party,
> apparently as part of a larger scheme to provide IP space to various
> snowshoe spammers.
>
> Evidence I have in hand strongly links this scheme and these ASNs and
> their associated IPv4 route announcements to Jump Network Services,
> aka JUMP.RO.  Furthermore, all of these ASNs are apparently peering
> with exactly and only the same two other ASNs in all cases, i.e.
> GTS Telecom SRL (AS5606) and Net Vision Telecom SRL (AS39737).  These
> peers and the fradulent ASNs listed below are all apparently originated
> out of Romania.

Jump.ro is a very active LIR and domain registry on the Romanian
market and is "selling" ASNs to whomever is interested and facilitates
allocations of PI netblocks to those who can justify them. It might
come as a surprise to you, but in Romania there are a lot of companies
(even very small ones) with their own ASN and PI netblocks. This setup
makes it extremely easy to switch ISPs with virtually no impact on
network operations.

If I'm not mistaken, companies use Netvision for cheap internet
access. GTS is more expensive, but theoretically is providing high
quality internet access with good SLAs.

>
> AS16011 (fiberwelders.ro)
> AS28822 (creativitaterpm.ro)
> AS48118 (telecomhosting.ro)
> AS49210 (rom-access.ro)
> AS50659 (grandnethost.com)
> AS57131 (speedconnecting.ro)
> AS57133 (nordhost.ro)
> AS57135 (fastcable.ro)
> AS57176 (bucovinanetwork.ro)
> AS57184 (kaboomhost.ro)
> AS57415 (highwayinternet.ro)
> AS57695 (effidata.ro)
> AS57724 (id-trafic.ro)
> AS57738 (mclick.ro)
> AS57786 (hosting-www.ro)
> AS57837 (romtechinnovation.ro)
> AS57906 (momy.ro)
> AS57917 (nature-design.ro)

from all those websites it looks like they are all hosting companies.
have you tried calling the numbers listed on the WHOIS registrant
information on the ASN and you couldn't get to any one ?

>
> At present, the above 18 ASNs are currently announcing routes for a total
> amount of IP space equal to 1,022 /24s, which is the rough equivalent of
> an entire /14 block.  These IPv4 route announcements are listed below,
> sorted by IPv4 (32-bit) start address.

If you really believe that all those ASNs listed by you above are only
used to host spammers, then by all means please contact
ale...@cert-ro.eu - that is the Romanian CERT as they are active and
will investigate the allegations you make.

>
> Additional potentially relevant background information:
>
> 
> http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-spam-122109
> 
> http://www.spamhaus.org/rokso/evidence/ROK9107/world-company-register-eu-business-register/rogue-ases-as43332-as44414-as44520-as49173-as49643
> http://www.spamhaus.org/sbl/listings/jump.ro
>

So far I do not know a single web hosting company that it's customers
never spammed anyone :)

Re: why haven't ethernet connectors changed?

[Eugeniu Patrascu]

You should give Apple a hint about designing a new Ethernet connector
:)) They'll give you few tens of million users wanting new network
equipment :))

Re: Looking for recommendation on 10G Ethernet switch

[Eugeniu Patrascu]

On Fri, Nov 2, 2012 at 5:13 PM, Eric Germann  wrote:
> Colleagues,
>
> I'm looking for a recommendation on a smallish 10G Ethernet switch for a
> small virtualization/SAN implementation (4-5 hosts, 2 SAN boxes) over
> iSCSI with some legacy boxes on GigE.
>
> Preferably
>
> - 8-16 10G ports
> - several GigE ports for legacy GigE hosts or cross connect to a legacy
> GigE  switch
> - preferably not a large chassis based solution with blades
>
> The hosts aren't going to be driving full line rate, nor the SAN boxes
> providing full line rate, but their offered loads will definitely exceed
> 1Gbps.   Assessing whether it is better to go 10G now vs. multi-pathing
> with quad GigE cards.  Trying to find the best solution for > 1G on a
> trunk and < $50K per box.

You can look ar Brocade TurboIron 24. It has 24 ports of 1/10G
depending on the SFP you put in.

Re: IPv6 Netowrk Device Numbering BP

[Eugeniu Patrascu]

On Sat, Nov 3, 2012 at 8:28 AM, Karl Auer  wrote:
> - if you need to remember an IP address, you are doing it wrong

Because DNS always works flawlessly and you never need to remember IP
addresses, right ?

> - cultural sensitivity and plain good sense suggest that many words or
> combinations might not be a good idea. How do your female techs feel
> about "BAD:BABE"? Only marginally better than they feel about
> "B16:B00B:EEZ", probably. Your markets in India, with its 900 million
> Hindus, might take a dim view of "DEAD:BEEF". Etc.

I think you're looking for problems where there are none. I see
nothing wrong with BAD:BABE or with DEAD:BEEF. Your thinking suggests
that there are only good babes and live beef, which is wrong on so
many levels. Positive discrimination is as bad as discrimination and
it creates more problems than it solves.

In India you can have beef steak at restaurants, so I see no problem
with the term.

>
> - clever addresses are guessable addresses for scanners, and highly
> identifiable in data as probably attached to high-value targets

What is a clever IP address ?

Re: IPv6 Netowrk Device Numbering BP

[Eugeniu Patrascu]

On Thu, Nov 1, 2012 at 7:31 AM, Crist J. Clark  wrote:
> We're working out our dual stacked IPv4-IPv6 network. One
> issue that recently has arisen is how to number the management
> interfaces on the network devices themselves.
>
> I have always been kind of partial to the idea of taking advantage
> IPv6 features and letting hosts set their own addresses with EUI-64
> interface numbers. For the management interface on a network device,
> it's more like a "normal" host. I'd just as well tell the device its
> prefix, and let it build the address itself. For IPv6, my opinion is
> that I'm not even going to try to remember 128-bit addresses. It's
> not something reasonable to expect humans to do. I'm going to depend
> on some name-to-number service (DNS or a hosts file), and as far as
> a computer goes, 2001:db8::80:abff:fe45:6789 is just as easy to
> remember as, 2001:db8::12:34.
>
> The other approach is to assign addresses. To me, that's more of
> a hold over from IPv4 thinking, but there are legitimate reasons
> I can think of. It's nice to have the IPv6 address tied to the
> configuration rather than the hardware. If you need to drop in
> a replacement device, you copy the configuration and no addresses
> change. But OTOH, others might consider it a feature that the IP
> follows the device rather than the role. And the real reason I think
> people want to do it is that they want to be able to memorize IP
> addresses of "important" hosts like these.

For simplicity and a wish to keep a mapping to our IPv4 addresses,
each device (router/server/firewall) has a static IPv6 address that
has the same last digits as the IPv4 address, only the subnet is
changed.
You can say it's a IPv4 thinking model, but it's easier to remember
that if the fileserver it's at 192.168.10.10 then it's IPv6
counterpart address would be 2001:abcd::192:168:10:10 (each subnet
being a /64)



>
> Another option would be to do both. Assign a fixed address and also
> let it chose EUI-64. However, I see that leading to confusion. Not
> sure what good it would do.
>
> Is there anything like a standard, best practice for this (yet)?
> What are other people doing and their reasons? Anyone have operational
> experience with what works and what does not (and the "what does
> not" is probably really of more interest)?

Letting the host choose it's own IP can be very tricky and has
operational hurdles along the way as it's not that easy to copy
configurations across devices during upgrades and maintenance swap
outs.

Re: Fair Use Policy

[Eugeniu Patrascu]

On Thu, Aug 23, 2012 at 9:21 AM, Shahab Vahabzadeh
 wrote:
> Thanks about every ones speech in this topic but I think I can not describe
> my problem clearly, let me explain it some how more:
> You know I have two kind of ADSL services, Limited and Unlimited.
> Limited Like:
> 512Kb-4GB-3Month
> 1024Kb-4GB-3Month
> 2048Kb-6GB-3Month
> 4096Kb-8GB-3Month
>
> Unlimited Like:
> 128Kb-1Month
> 256Kb-1Month
>
> and etc. But when a customer is in our sales department they do not know he
> will download more or he will have a normal usage? Is he heavy peer-to-peer
> service downloader or not he is a doctor that he want to check his emails
> only, and he want this service always.
> Our problem cause midnights because in the middle of the night in 2:00 AM
> till 8:00 AM and at this time we do not have any traffic counting for users.
> Means they can download free at this time, and if we buy more bandwidth
> only for this time for users it will be unusable in other times like
> mornings.
> I want a logical way to solve this problem technically or sales techniques,
> We must control users usage and I can not do any thing to them they love
> free-times and they want to download, but they are going to make me ran out
> of bandwidth that time, so what about that doctor? and his emails?
> You know no manager will accept increasing bw only for nights :D

You can put the paying ones with a data cap in a guaranteed queue with
precedence, and leave the rest to download as much as possible in
another queue without any guarantees but with fair queuing enabled so
that everyone gets access more or less equally.
When your management or sales department chose the "all you can
download between 02:00-08:00" they should have thought about what
happens to the rest of the customers in this time interval. Or should
have brought you in to hear your technical point of view and the
possible problems this scheme may induce.

my 2 eurocents :)

Re: next hop packet loss

[Eugeniu Patrascu]

On Tue, Aug 7, 2012 at 4:12 PM, Jim Ray  wrote:
> Sorry, I do not give verbose responses via iPhone on that small device
> with my tired old eyes. I ran Wireshark this morning.
>
> Without sniffing packets, the layman's description of problem is "I
> can't get to vendor web site, http://www.CheckPoint.com, on Time Warner
> Business Class network I use." Hence, http is blocked in addition to
> ICMP.
>

Yesterday, Check Point's website was unreachable from other parts of
the world for some time with intermittent access for around an hour or
so I believe.

Eugeniu

Re: enterprise 802.11

[Eugeniu Patrascu]

On Sun, Jan 15, 2012 at 21:30, Ken King  wrote:
> I need to choose a wireless solution for a new office.
>
> up to 600 devices will connect.  most devices are mac books and mobile phones.
>
> we can see hundreds of access points in close proximity to our new office 
> space.
>
> what are the thoughts these days on the best enterprise solution/vendor?
>

You may want to look at Ruckus Wireless. They are extremely easy to
setup and they just work.


Eugeniu

Re: Access and Session Control System?

[Eugeniu Patrascu]

If you also want to control where they go from the jump box, you might
want to look at http://www.xceedium.com/en/index.php as they claim to
add rules to what a remotely logged in user can do.

Juniper SA is very nice and get's intuitive after you familiriaze
yourself with it's workflow which is a pain if you're new to the box.

On Fri, Sep 2, 2011 at 15:21, John Peach  wrote:
> On Thu, 1 Sep 2011 17:45:55 -0400
> Rafael Rodriguez  wrote:
>
>> I recommend you look into the Juniper SSL VPN products (SA Series). Very 
>> power boxes, intuitive admin interface (web driven) and are perfect for the 
>> "Vendor Access" type of applications.
>
> They work fine (mostly), but your definition of intuitive obviously does
> not coincide with mine.
>
>>
>> Sent from my iPhone
>>
>> On Sep 1, 2011, at 16:30, "Jones, Barry"  wrote:
>>
>> >
>> > Hello all.
>> > I am looking at a variety of systems/methods to provide (vendor, employee) 
>> > access into my dmz's. I want to reduce the FW rule sets and connections to 
>> > as minimal as possible. And I want the accessing party to only get to the 
>> > destination I define (like a fw rule).
>> >
>> > When I refer to access, I'm referring to the ability of a vendor or 
>> > employee to perform maintenance tasks on a server(s). The server(s) will 
>> > be running apps for doing different tasks - such as Shavlik, etc..,  
>> > (patching, reports, logging, etc..), so I am envisioning allowing an 
>> > outside vendor/employee (from the internet or corp. net) to RDP or SSH to 
>> > a given Windows or Unix based machines, then perform their application 
>> > work from that jumping off point - kind of like a terminal server; but I'd 
>> > like to control and audit the sessions as well.
>> >
>> > Overall, I can allow a host/port through the FW to a single host, but I 
>> > wanted to be able to do the session management and endpoint controls. FW's 
>> > are ok, but you know as well as I that I now deal with lots of rules sets. 
>> > And I need to also authenticate the user.
>> >
>> > We are a couple smaller facilities (150 hosts each) and I need to be able 
>> > to control and audit the sessions when requested. I have considered doing 
>> > a meetingplace server, then providing escorted access for them, or doing 
>> > just the FW and a "jump" host - but need the endpoint and session 
>> > solution, or just using VPN - but don't want to install a host on the 
>> > vendor machines. I also have looked at a product called EDMZ - wondered if 
>> > anyone had experience with it?
>> >
>> > And did I say I wanted to keep it as simple as possible? :-) It's been a 
>> > few years since I've done hands-on networking work, so excuse the 
>> > long-winded letter. Feel free to email me directly too.
>> >
>> > Sincerely
>> > Barry Jones
>> > CISSP, GSNA
>>
>
>
>
> --
> john
>
>

Re: Yup; the Internet is screwed up.

[Eugeniu Patrascu]

On Sun, Jun 12, 2011 at 22:48, Chris Adams  wrote:
> Once upon a time, Eugeniu Patrascu  said:
>> I need 100Mbs at home because I want to see a streamed movie NOW, not
>> in a month because someone considers broadband a luxury :)
>> Pretty simple usage scenario I might say.
>
> The top profile for Blu-Ray is 36 megabits per second, and that is
> not used on most titles.  Over-the-air HDTV is 19 megabits or less.
> Cable HD channels are often only 12-15 megabits per second.  OTA and
> cable HD is typically MPEG2, and MPEG4 can reach similar quality in half
> the bandwidth, which means TV quality HD can be 6-10 megabits per
> second.

Even though, my point stands. I don't want to wait forever for stuff
to load just because a dialup should be enough for browsing :)

Re: Yup; the Internet is screwed up.

[Eugeniu Patrascu]

On Sun, Jun 12, 2011 at 01:16, Jeroen van Aart  wrote:
> Randy Bush wrote:
>>
>> some of us try to get work done from home.  and anyone who has worked
>> and/or lived in a first world country thinks american 'broadband' speeds
>> are a joke, even for a home network.
>
> I understand, but I was referring to the average home internet connection.
> But even for work 100Mbps seems a bit overkill for most purposes. Whole
> offices work fine with a "mere" bonded T1 at 10Mbps. Admitted it's
> symmetrical and is more stable. But regarding speed it's quite a bit slower
> than the mentioned 100Mbps home internet.

I need 100Mbs at home because I want to see a streamed movie NOW, not
in a month because someone considers broadband a luxury :)
Pretty simple usage scenario I might say.

Re: IPv6 Routing table will be bloated?

[Eugeniu Patrascu]

On Tue, Oct 26, 2010 at 21:19, Sven Olaf Kamphuis  wrote:
> On Tue, 26 Oct 2010, Randy Carpenter wrote:
>
>> - Original Message -
>>>
>>> On 10/26/2010 12:04 PM, Nick Hilliard wrote:

 In practice, the RIRs are implementing sparse allocation which makes
 it
 possible to aggregate subsequent allocations. I.e. not as bad as it
 may
 seem.

>>>
>>> Except, if you are given bare minimums, and you are assigning out to
>>> subtending ISPs bare minimums, those subtending ISPs will end up with
>>> multiple networks. Some of them are BGP speakers. I can't use sparse
>>> allocation because I was given minimum space and not the HD-Ratio
>>> threshold space.
>>
>> Wait... If you are issuing space to ISPs that are multihomed, they should
>> be getting their own addresses. Even if they aren't multihomed, they should
>> probably be getting their own addresses. Why would you be supplying them
>> with address space if they are an ISP?
>>
>> -Randy
>
> to my knowledge, RIPE still does not issue ipv6 PI space.
> so giving them their own space, is "problematic" to say the least.

I got a /48 PI from RIPE a few months back.
Maybe your knowledge needs to be a little bit refreshed regarding RIPE
allocation policies :)

Re: tool to wrangle config file changes

[Eugeniu Patrascu]

On Thu, Aug 19, 2010 at 03:16, Rogelio  wrote:
> Long story short, a really crappy vendor is being shoved down our
> NOC's throat.  They have a horrid CLI (if you can call it that).
> People don't understand it (it's non-intuitive) and are screwing up
> things all the time.

Would be so kind to name the vendor so that other people would have an
advance warning ?

Re: Layer 2 vs. Layer 3 to TOR

[Eugeniu Patrascu]

On Wed, Nov 18, 2009 at 4:04 PM, Kinkie  wrote:
> On Thu, Nov 12, 2009 at 9:40 PM, Bulger, Tim  wrote:
>> If you use stackable switches, you can stack across cabinets (up to 3 with 1 
>> meter Cisco 3750 Stackwise), and uplink on the ends.  It's a pretty solid 
>> layout if you plan your port needs properly based on NIC density and cabinet 
>> size, plus you can cable cleanly to an adjacent cabinet's switch if 
>> necessary.
>
>
>
> Juniper claims their switches can do clustering using ethernet
> cabling, yet a cluster behaves as a single-system-image
> configuration-wise. Should allow for very flexible cabling and
> operations-wise for TOR switches. I have never tried it however.
>

The Ex4200 can be stacked by the ethernet expansion ports, either 4 x
1G or 2 x 10G.
And yes, it behaves as single switch with multiple line cards.

Re:

[Eugeniu Patrascu]

Devangnp wrote:

Does Juniper firewall has same issue?
Nope. Just that you need to get an ISG 1000 or ISG 2000 to be able to 
virtualize nowadays, as the old lower model NetScreen boxes are no 
longer up for sale.

Re: Dutch ISPs to collaborate and take responsibility for bottedclients

[Eugeniu Patrascu]

Gadi Evron wrote:

Barton F Bruce wrote:
Stopping the abuse is fine, but cutting service to the point that a 
family
using VOIP only for their phone service can't call 911 and several 
children
burn to death could bring all sorts of undesirable regulation let 
alone the

bad press and legal expenses.


While a legitimate concern it's also a red herring, as it's a 
technical problem looking for a technical solution.


Gadi.

I think the need for someone being able to call 911 from their VoIP 
outweighs your right to claim that they should be disconnected from the 
Internet.



Besides, if that provider wants to help out, he might setup a captive 
portal or something with information regarding tools to clean their 
computer.

Re: Do we still need Gi Firewall for 3G/UMTS/HSPA network ?

[Eugeniu Patrascu]

Roland Dobbins wrote:


On Apr 9, 2009, at 11:48 PM, Lee, Steven (NSG Malaysia) wrote:


Please share your thought and thanks in advance :)


No, IMHO.  Most broadband operators don't insert firewalls inline in 
front of their subscribers, and wireless broadband is no different.
Some operators put firewalls to NAT their subscribers into smaller IP 
address pools (I have put some for a particular one).


The infrastructure itself must be protected via iACLs, the various 
vendor-specific control-plane protection mechanisms, and so forth, but 
inserting additional state in the middle of everything doesn't buy 
anything, and introduces additional constraints and concerns.




Yes.

Re: Are we really this helpless? (Re: isprime DOS in progress)

[Eugeniu Patrascu]

Jon Kibler wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

valdis.kletni...@vt.edu wrote:

  

Well, we *could* hunt down the perpetrators, pool some $$, and hire 3 or 4
baseball-bat wielding professional explainers to go explain our position to
them.  Figuring out how to do so without breaking any laws is the tough part...




But if they were in eastern Europe or Russia, wouldn't that solution be
considered standard business practice and thus be legal?
  
As an eastern european, I can tell you that you're watching way too much 
TV :)
We also have law enforcement that can take down rogue cracker networks. 
The only problem police has in this matters is somewhat lack of 
experience and lack of resources. Otherwise they don't have a problem 
knocking down doors to catch bad guys.

Re: Are we really this helpless? (Re: isprime DOS in progress)

[Eugeniu Patrascu]

valdis.kletni...@vt.edu wrote:

On Fri, 23 Jan 2009 18:33:14 PST, Seth Mattinen said:

  

Back to my original question: is there really not a better solution?



Well, we *could* hunt down the perpetrators, pool some $$, and hire 3 or 4
baseball-bat wielding professional explainers to go explain our position to
them.  Figuring out how to do so without breaking any laws is the tough part...
  
Or better yet, how Marsellus Wallace said it in Pulp Fiction: " I'ma 
call a coupla hard, pipe-hittin' niggers, who'll go to work on the homes 
here with a pair of pliers and a blow torch."
Now that would be fun and actually send a strong message across the 
board :))

Re: Gigabit Linux Routers

[Eugeniu Patrascu]

Ingo Flaschberger wrote:

OS:
Freebsd:
pros: very stable, quagge runs very well, fastforwarding support,
simple traffic shaping, interrupt less polling supported
cons: only 1 route for each network, vrrp failover is not easy to
implement with quagga and ospf, no multipath routing
Linux:
pros: more than 1 route for each network possible,
interrupt less polling should be supported?
fastforwarding ?
cons: no multipath routing


	Are you sure ? Because there is an option in the kernel, under advanced 
routing setup to enable multipath routing.
	And also, with iproute2, you can add multiple gateways with 
different/equal weights for a specific prefix

Re: Gigabit Linux Routers

[Eugeniu Patrascu]

Chris wrote:



Now to look at very affordable layer 2, Gigabit 3com switches with good pps.


You should take a look at HP. They have very good gigabit switches and 
also offer lifetime guarantee on them.


HP actually has a CLI to configure the switch, not the crap 3Com has.

Re: Gigabit Linux Routers

[Eugeniu Patrascu]

Chris wrote:



Eugeniu: That's very useful. The Intel dual port NICs mentioned aren't any
good then I presume (please see my comment to David).


Actually it depends on the motherboard chipset. Some chipsets allocate 
an interrupt per slot, and when you have lot's a traffic between two 
ports on a dual port card the will increase dramatically, but should get 
you at 1Gbps, at higer speeds... depends.


It's adviseable to use a 2.6 kernel as the network stack, compared to 
2.4, is way better and you can achieve higher speeds.

Re: Gigabit Linux Routers

[Eugeniu Patrascu]

Florian Weimer wrote:

* Eugeniu Patrascu:


You can also use a kernel with LC-Trie as route hashing algorithm to
improve FIB lookups.


Do you know if it's possible to switch of the route cache?  Based on
my past experience, it was a major source of routing performance
dependency on traffic patterns (it's basically flow-based forwarding).


I don't understand your question.

In kernel, when you compile it, you have two options:
- hash based route algorithm
- lc-trie based route algorithm

From what I've read on the internet about the latter algorithm, it's 
supposed to be faster regarding route lookups with large routing tables 
(like a global routing table).





Anyway, with very few flows, we get quite decent performance (several
hundred megabits five-minute peak, and we haven't bothered tuning
yet), running on mid-range single-socket server boards and Intel NICs
(PCI-X, this is all 2006 hardware).  We use a router-on-a-stick
configuration with VLAN separation between all hosts to get a decent
number of ports.


In that configuration you'll split available bandwidth on the NIC and 
also have less throughput because server NICs are not optimized for 
"same interface switching".




My concern with PC routing (in the WAN area) is a lack of WAN NICs
with properly maintained kernel drivers.



Usually it's better to get a dedicated router for that kind of stuff 
than bother with PC WAN cards.

Re: Gigabit Linux Routers

[Eugeniu Patrascu]

Chris wrote:

Hi All,
Sorry if this is a repeat topic. I've done a fair bit of trawling but can't
find anything concrete to base decisions on.

I'm hoping someone can offer some advice on suitable hardware and kernel
tweaks for using Linux as a router running bgpd via Quagga. We do this at
the moment and our box manages under the 100Mbps level very effectively.
Over the next year however we expect to push about 250Mbps outbound traffic
with very little inbound (50Mbps simultaneously) and I'm seeing differing
suggestions of what to do in order to move up to the 1Gbps level.


Any recent hardware can do do 1Gbps of routing from one NIC to another 
without issues. What you would need is PCI-Express cards, each with it's 
own slot (try avoiding dual/quad port cards for I/O intensive tasks).


Quagga with one full view and two feeds of about 5000 prefixes each 
consumes around 50MB of RAM. Putting alot of RAM in the box will not 
help you with increasing performance.


You can also use a kernel with LC-Trie as route hashing algorithm to 
improve FIB lookups.





It seems even a dual core box with expensive NICs and some kernel tweaks
will accomplish this but we can't afford to get the hardware purchases
wrong. We'd be looking to buy one live and one standby box within the next
month or so. They will only run Quagga primarily with 'tc' for shaping.
We're in the UK if it makes any difference.


Regarding tc, make sure you use a scalable algorithm like HTB/HSFQ and 
tweak your rules so that a packet will spend the least amount of time in 
 matching and classifying routines.




Any help massively appreciated, ideally from those doing the same in
production environments.


At 100Mbps FDX full load (routing traffic from one NIC to another) on 
2.53 GHz Celeron box with 512Mbps of traffic, the load is between 0.00 
and 0.01-0.02

Re: e300 vs mx240 for border router ?

[Eugeniu Patrascu]

ubaidali_abdul_raz...@3com.com wrote:

Have you tried 3Com's 6040 / MSR-50 routers?


No offense / no flame, but really, do you actually compare 3Com with 
Juniper ?

Re: NAT66 and the subscriber prefix length

[Eugeniu Patrascu]

[EMAIL PROTECTED] wrote:
My gripe was that I wanted to get an IPv6 allocation from 
RIPE to start 
testing how IPv6 would fit in the company that I work for and build a 
dual stack network so that when the time comes, just switch 
on IPv6 BGP 
neighbors and update the DNS.


But at almost 10.000 EUR per year it's an experiment I can't afford.


That is not an experiment.


I was hoping to do it in one step with my own IPv6 PI space and do the 
allocation and routing on the servers/routers/firewalls, see how that 
goes and when the time was right, just announce my prefix to the world :)



An experiment is where you go to ,
generate your own unique RFC 4193 prefix, and then implement your IPv6
network using that. When you are ready to switch on BGP peering with the
rest of the world, get a /32 from your RIR, and renumber the network
leaving
the interface IDs the same.


Thanks for the URL, I was not aware of it. I guess I'll have to 
experiment with prefixes from that and see hot it goes.




If you are concerned that renumbering will be hard, go back and generate
another ULA, and renumber your network as part of your experiment. 



I'll probably do that also.

Thanks.

Re: NAT66 and the subscriber prefix length

[Eugeniu Patrascu]

Joe Abley wrote:

But surely he's not an end-user. He's an ISP, which means he's 
(potentially) an LIR.




My gripe was that I wanted to get an IPv6 allocation from RIPE to start 
testing how IPv6 would fit in the company that I work for and build a 
dual stack network so that when the time comes, just switch on IPv6 BGP 
neighbors and update the DNS.


But at almost 10.000 EUR per year it's an experiment I can't afford.

Re: NAT66 and the subscriber prefix length

[Eugeniu Patrascu]

[EMAIL PROTECTED] wrote:
We have also started offering residential Internet to those 
living on campus, which has been very popular (no suprise.) 


You've started your own ISP. ISP's get a /32 from ARIN.
Case closed.

In fact, you are better off treating your non-ISP networks
as a customer of your ISP and assigning a /48 to each of
your non-ISP sites. This is an area where IPv4 and IPv6 differ.


Too bad in Europe RIPE wants 3000EUR per month membership fees to give 
you PI IPv6 if you're an end user.

Re: routing around Sprint's depeering damage

[Eugeniu Patrascu]

Florian Weimer wrote:

* Seth Mattinen:


4. Multihome.


Or get upstream from someone who does, and who is small enough to be
able to get additional upstream upon short notice.  I know that this
solution isn't always cost-effective. 8-/

(Multihoming alone isn't a solution because it's hard to figure out
how independent your peering partners are.)



That's the easy part in the US: multihome with Verizon, Level3, Cogent, 
Sprint and AT&T :))

Re: Alaska DNS

[Eugeniu Patrascu]

JoeSox wrote:

Thanks for everyone's help on and offlist.

acsalaska.net told me  just before I left the office 4 hours ago they
have corrected the issues and time to clear cache.



Why was it an issue that they had no A records for the domain name ?

Re: InterCage, Inc. (NOT Atrivo)

[Eugeniu Patrascu]

Gadi Evron wrote:

On Mon, 8 Sep 2008, Scott Weeks wrote:



--- [EMAIL PROTECTED] wrote:
I am sure if I looked into it more I could find some exploits related
to the sites.
-


"Why software piracy might actually be good for companies."

Folks should clean their own house before pointing fingers at others...


My house may not be clean right now, but the cleaner is coming 
tomorrow. However, filth from their house is making my house smell. I 
am very happy they are willing to clean up, but it still smells for 
some reason.


Enough with analogies, you are making this discussion into a hostile 
environment for them to reply in.


What are you afraid of, anyway? Are you running a bullet-proof hosting 
farm?
Why should an ISP provide proof of the good behavior of their clients ? 
Or in your conuntry you're considered guilty until proven otherwise ?

Re: ingress SMTP

[Eugeniu Patrascu]

On Sep 8, 2008, at 12:31 AM, Michael Thomas wrote:


Eugeniu Patrascu wrote:


On Sep 3, 2008, at 8:08 PM, Winders, Timothy A wrote:



Yes, setting up a 587 submit server internally would be best, but  
man power

is at a premium and it hasn't happened.



I don't know what SMTP server you're using, but on Postfix you just  
need to uncomment one line in master.cf, do a reload and that's it.  
it takes less than a minute to do it on server. YMMV.

Would that it were so easy :) You also have the more daunting task
of hooking up your auth/aaa infrastructure with your MTA's, and all
of the care and feeding that entails.

IIRC the OP said that he was already doing AUTH on port 25, and this  
was the basis for my email stating it's quite easy.

Re: ingress SMTP

[Eugeniu Patrascu]

On Sep 3, 2008, at 8:08 PM, Winders, Timothy A wrote:



Yes, setting up a 587 submit server internally would be best, but  
man power

is at a premium and it hasn't happened.



I don't know what SMTP server you're using, but on Postfix you just  
need to uncomment one line in master.cf, do a reload and that's it. it  
takes less than a minute to do it on server. YMMV.

Re: ingress SMTP

[Eugeniu Patrascu]

On Sep 3, 2008, at 6:52 PM, Tim Sanderson wrote:

Anybody not wanting to use their ISP email would notice it. I see  
filtering 25 FROM the customer as something that is not likely to  
happen because of this. When a customer buys bandwidth, they want to  
be able to use it for whatever they choose. This would be just one  
more restriction giving competitive advantage to any ISP not doing  
the filtering.




In my country, some ISPs block outbound SMTP for home users and they  
require those users to use the ISPs SMTP server for outgoing which  
happen to do antivirus and antispam filtering.


They will unblock port 25 if you provide  good and rational  
explanation why you need it open and that you understand that in case  
of problems you will be held responsible.


Eugen.

Re: Software router state of the art

[Eugeniu Patrascu]

Aaron Glenn wrote:

On 7/28/08, Seth Mattinen <[EMAIL PROTECTED]> wrote:
  

Junpier's J-series is a BSD based platform as far as I understand it.
ImageStream is *much* more affordable for me, but is Linux-based, and I fear


...snip...

AFAIK, none of Juniper's Juniper kit rocks BSD outside of the
management interfaces and control plane (not even sure about the
latter, tbh).

someone feel free to correct me...
  
In the M/T series, control plan is handled by the RE, and the forwarding 
by the ASICs on each PIC.
in the J series, the control and forwarding plane are controlled by the 
RE, although the forwarding plane has a real time thread in the BSD 
kernel (or so Juniper says it does).

Re: Software router state of the art

[Eugeniu Patrascu]

Rubens Kuhl Jr. wrote:

You can use Linux without conntrack. You can either do "rmmod
ip_conntrack" (unload the module), rm /var/lib/modules/ip_conntrack
(or something like that to erase the file) or use the RAW queue to
forward some packets without connection tracking (-j NOTRACK) and some
others with conntrack (proxy redirection, captive portal and thinks
like that requires stateful forwarding in any platform).

I would be more worried about the prefix match and route cache done by
the operating system you are considering for use as a router. That
cannot be circunverted by turning off conntrack, pf or anything that
might do more with the packet that plain simple routing.
  

Hi,

As of 2.6.x kernel version (at least on 2.6.17) there is a FIB 
implementation called LC_Trie which supposedly does an O(1) route lookup 
which is very fast.
Where I live there are a lot of linux boxes deployed as routers pushing 
line rate GE for hundreds to thousand nodes computer networks while also 
deliverying QoS for each and every node.
From what I see in this thread you're more worried about T3/E3 
linecards than the actual Linux performance as a router.


As a personal example, I use a celeron 2.53Ghz with 512Mb of ram to push 
line rate 3 x 100Mbps cards wihout any discernable load reported either 
by top or uptime and that on top of Quagga with about ~ 5k prefixes.
Also, as an experiment I loaded a full routing table from one of my 
peers and besides of the increased RAM usage by Quagga to about 50MB the 
machine forwarded at the same rate, _maybe_ 1% incresed load.