Re: Sign-On Letter to the Court in the FCC's Net Neutrality Case

[Hammani Benaouich]

Snbbb

Sent from my Porsche Design P´9982 smartphone from BlackBerry.
  Original Message  
From: Rich Kulawiec
Sent: Friday, September 18, 2015 6:25 PM
To: nanog@nanog.org
Subject: Re: Sign-On Letter to the Court in the FCC's Net Neutrality Case

On Thu, Sep 17, 2015 at 11:41:52AM -0400, Miles Fidelman wrote:
> Me too. Be sure to actually read the Amicus brief - it's incredibly
> well written and informative.

I've signed on as well and strongly concur with Miles' recommendation.

---rsk

RE: SMS Gateway

[frnkblk]

With earlier releases I did see our unit "lock up", in the sense they
wouldn't send messages.  A reboot resolved those issues.  The last two or
three releases from Multitech for iSMS have been solid, none of those issues
anymore.

Frank

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Nick Nauwelaerts
Sent: Tuesday, September 15, 2015 3:10 AM
To: Graham Johnston ; 'nanog@nanog.org'

Subject: RE: SMS Gateway

The multitech multimodems I run seem to like rebooting an awful lot, they do
it at least daily.

At another position I did like the SMS FoxBox ( http://www.smsfoxbox.it/ ),
which had a simple http put command (amongst other interfaces) which allowed
you to send text messages. The do seem to have gone up in price a bit since
2008 however, but they did never fail on me over the 6years they were in
service (sample size was 2 units, so not the best indicator).

// nick



-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Graham Johnston
Sent: Monday, September 14, 2015 16:54
To: 'nanog@nanog.org' 
Subject: SMS Gateway

Today we use a product from MultiTech Systems call MultiModem iSMS to send
SMS text messages from our monitoring system to our on call staff.  This is
a 2G product and we need to replace it soon. I know there are more generic
cellular modems that can do texting if you are willing to put in the effort,
the product we use currently though has a simple HTTP based API specifically
to send SMS. Is anybody out there using something similar that can work on
3G or 4G networks?





Volg Aquafin op Facebook |
Twitter |
YouTube | LinkedIN

Disclaimer: zie www.aquafin.be   P Denk aan het
milieu. Druk deze mail niet onnodig af.

[http://www.chap-eau.be/chapeau-banner.jpg] 

Re: Segment Routing for L2VPN?

[Mohan Nanduri]

No, it works with L2VPNs also. Outer label is going to be SR label and
inner label is your L2VPN label.

Cheers,
-Mohan


On Sun, Sep 20, 2015 at 3:23 PM, Jason Lixfeld  wrote:
> Hello!
>
> I've been doing some reading recently on Segment Routing.  By all accounts, 
> it seems that the (only?) implementation for SR supports L3VPN.  Am I dumb 
> and just missing the L2VPN bits, or is L3VPN simply the extent of the first 
> generation?
>
> Sent from my iPhone

Segment Routing for L2VPN?

[Jason Lixfeld]

Hello!

I've been doing some reading recently on Segment Routing.  By all accounts, it 
seems that the (only?) implementation for SR supports L3VPN.  Am I dumb and 
just missing the L2VPN bits, or is L3VPN simply the extent of the first 
generation?

Sent from my iPhone

Re: DDoS auto-mitigation best practices (for eyeball networks)

[alvin nanog]

On 09/19/15 at 02:54pm, Frank Bulk wrote:
> Could the community share some DDoS auto-mitigation best practices for
> eyeball networks, where the target is a residential broadband subscriber?

o kie dough kie

> I'm not asking so much about the customer communication as much as
> configuration of any thresholds or settings, such as:
> - minimum traffic volume before responding (for volumetric attacks)

i prefer zero tolerance ...

i tarpit all incoming tco-based attacks and probes that was
not allowed incoming tcp traffic to port 25 or port 80 or port blah

example iptables rules ... linux and iptables  + tarpits is free
# IPtables-BlackList.net/Howto
- ingress filters
- allow established 
- check for blacklist
- limit udp and icmp reply ( tough problem to solve )
- allow to port 80 ( keep webserver separate from dns, smtp, etc )
- tarpit all new tcp incoming connections
- drop all other new incoming connections

- there is no need log millions of ddos attack pacekets
per second unless you want to fill up your disk which
helps the ddos attacks to be a successful attack

- for icmp and udp ... you will need your ISP to help block it

  limiting incoming icmp/udp is sorta pointless since those
  packets already come down the wire

  however, you still do NOT want to respond to those packets either
  so you will have to limit to just a handful per second, little more
  per hour, and higher limit per day

  for icmp ... turn off broadcast ping responses on all devices

  for udp ... make sure the apps are properly configured
dns, snmp, ntp, nfs, x11, etc uses udp

your dns servers might need to be accessible from outside
all other udp-based servers should be internal only

- to protect against arp-based attacks  
build/patch/configure your hardware/routers/switches properly

- install monitoring tools to watch for whatever you're paranoid about
- man-in-the-middle .. trivial to detect and prevent
- sniffers ( hard to detect )

> - minimum time to wait before responding

zero wait ...

> - filter percentage: 100% of the traffic toward target (or if volumetric,
> just a certain percentage)?

you will always, 100% fail volumetric attacks 

> - time before mitigation is automatically removed

you can have iptables remove a particular ddos attacker automatically
or manually

i prefer manually so i can see what it's doing

> - and if the attack should recur shortly thereafter, time to respond and
> remove again

zero wait time  .. zero tolerance per example iptables rules above

> - use of an upstream provider(s) mitigation services versus one's own
> mitigation tools

i haven't found too many ISP willing to allow customers to put
a customer firewall in their facility just before it comes down to 
the wire to customers bldg

this is required if customers want to properly mitigate icmp-based 
and udp-based ddos attacks

> - network placement of mitigation (presumably upstream as possible)
> - and anything else

mitigation solutions should be a gateway firewall and host-based mitigation

if you can install another firewall at the ISP, thats good too
and you still need a gateway firewall and the host based firewall

> I ask about best practice for broadband subscribers on eyeball networks
> because it's different environment than data center and hosting environments
> or when one's network is being used to DDoS a target.

add corp environment, hospitality environment, govt environment, 
etc etc to the list too
- free wifi, hotel based wifi or hardwire is probably
the easiest way to send the unsuspecting victim home 
with a trojan that will phone home ( the attacker )
when the victim plugs the cracked box into the secure
corp network

nah ddos attacks are ddos attacks ... usually harmless ...
it probably doesn't matter to the attackers what they're attacking 

you are constantly under 24x7x365 low level ddos attacks

if you are being targeted by somebody that wants to get you,
you'd have a problem if they're better at attacking than you 
are at defending your servers ...

they're done if they have a bigger budget to pay for all the 
necessary bandwidth needed to take your servers offline

  - if you know who they are, call the ISP and the cops

-

other "basic best practices"
- have a good security policy ... even if just for yourself
hide the laptop in your trunk using a brown bag
and NOT an obvious laptop bag 
- always use encrypted services... never clear text
- use ssh, openssl, smtps, pop3s, imap3s 

- dozens of other best practices security rules
- always have a incremental daily backup that is kept
for months
- always have a hot swap backup just in case
 etc .. etc ...



you should also keep track of who is attacking your servers
so that law enforcement can followup