Re: nexus N3K-C3064PQ vs juniper ex4500 in order to protect against ddos

[joel jaeggli]

On 9/30/16 12:42 PM, Pedro wrote:
> 
> Hello,
> 
> I have some idea to put switch before bgp router in order to terminate
> isp 10G uplinks on switch, not router. Main reason is that could be some
> kind of 1st level of defence against ddos, second reason, less
> important, save cost of router ports, do many port mirrors.

The distinction on cost of ports is somewhat germain when dealing with
things like span ports. maybe strictly speaking if the router platform
can handle line rate forwarding at minimum packet size it is just as
performant as the switch at both forwarding and probably acl application
(there are of course exceptions).  in general these switches has
substantially smaller port buffers then a router or high end l3 switch
platform (qfx10k or ptx for example) would have when spanning ports or
doing some statistical multiplexing. Which can be a liability.

A number of us no doubt use layer2/3 switches as customer aggregation or
indeed peering platforms. and suitability for such may depend on the mix
of hardware  and software features available as well as non-forwarding
attributes such as the amount of memory available. i have boxes for
example that have a full table rib but only default route for
non-customer routes. the prospects for gettting away with that sort of
thing with only 2GB of ram are growing increasingly dire.

So i would say this sort thing does work, and with some familiarity with
the platforms you become more comfortable with their limitations, but
it's not automatically the best route, and the additional bump in the
forwarding path is not free of costs or complexity.

> I think about N3K-C3064PQ or Juniper ex4500 because there are quite
> cheap and a lot of on Ebay.
> 
> I would like on nexus or juniper try use some feature:
> 
> -  limit udp, icmp, bum packets (bandwith,pps) at ingress tagged port or
> vlan
> -  create counters: passed and dropped packets, best way to get this
> counters via snmp oid, sent snmp traps, syslog etc in order to monitor
> or even as a action shut down port
> -  port mirror from many ports/vlans to multiple port (other anty ddos
> solutions)
> -  limited bgp but with flowspec to comunicate with another anty ddos
> devices
> 
> I'm also wondering how this feature above impact on cpu/whole switch. It
> can be some performance degradation ot all of this feature are done in
> hardware, with wirespeeed ? Which model will better to do this ?
> 
> Thanks for any advice,
> Pedro
> 
> ---
> Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie
> antywirusowe Avast.
> https://www.avast.com/antivirus
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: ARIN legacy block transfer process

[John Curran]

On 30 Sep 2016, at 1:34 PM, Bryan Fields  wrote:
> 
> On 9/30/16 1:22 PM, William Herrin wrote:
>> Note that you can't sell the block as an "owned asset" and have ARIN
>> recognize the change. ARIN does not recognize ownership of IP address
>> blocks, they only recognize registration and authorized agents.
> 
> This would seem to be in violation of what the NSF has said about this space.
> I thought ARIN was slapped hard once before about this very thing?

NSF’s Chief Counsel provided his views on the matter, but had to subsequently
clarify that his views were based on NSF’s historic role and noted that he did 
not
speak for the USG on such matters (as they were now properly within the remit
of the US Department of Commerce/NTIA…  oops!) - 


The agency with actual authority in these matters (NTIA) subsequently issued a 
statement of the the US Government’s Internet Protocol Numbering Principles, 
which noted that “the American Registry for Internet Numbers (ARIN) is the RIR
for Canada, many Caribbean and North Atlantic islands, and the United States 
and furthermore that the USG “participates in the development of and is 
supportive 
of the policies, processes, and procedures agreed upon by the Internet 
technical 
community through ARIN.” 


i.e. ARIN continues to enforce the community-developed policies on all resources
in the registry, and including legal undertakings where necessary to that end. 

FYI,
/John

John Curran
President and CEO
ARIN

p.s. Note that all organizations may use ARIN Online to update their ARIN IP 
number 
   resource records. Organizations that received number resources directly 
from 
   ARIN have ARIN Online access via their Registration Services Agreement. 
   For organizations that received resources before ARIN’s formation in 
December 
   1997 (i.e. “Legacy Resource Holders”), ARIN has been providing, without 
any 
   fee or registration services agreement, access to ARIN Online as well as 
the 
   basic IP registration services in place at the time of ARIN’s formation; 
this does
   include the ability to submit tickets to transfer an IP address block to 
another party.

   Legacy Resource Holder organizations that wish to receive these basic 
registration 
   services under a formal agreement, or wish to utilize additional 
services (such as 
   resource certification, i.e. RPKI), and/or desire a written statement of 
their rights to 
   their IP number resources must enter into a Registration Services 
Agreement.

Re: ARIN legacy block transfer process

[John Curran]

On 30 Sep 2016, at 1:42 PM, Jim Mercer  wrote:
> 
> On Fri, Sep 30, 2016 at 01:22:19PM -0400, William Herrin wrote:
>> 1. Buyer gets approved by ARIN for a specified transfer in the amount
>> to be purchased. Signs RSA.
>> 2. Legacy registrant (seller) signs the LRSA, proves identity and
>> authority to ARIN, places legacy block under the LRSA.
> 
> i don't recall having to sign an LRSA, but they certainly do need proof that
> you are the entity that holds the block.

That’s correct Jim. 

>> 3. Buyer requests specified transfer from ARIN, seller authorizes it.
>> 4. ARIN transfers registration to buyer, now under the RSA.
> 
> if you are a legacy holder, and you want a dead simple way to sell off your
> rights to blocks, register for the STLS, and get your blocks added to the
> list.
> https://www.arin.net/public/secure/downloads/index.xhtml
> (at the bottom)
> 
> this is also a good place to go if you want to buy rights to a block.
> 
> you can also solicit offers to buy from anyone on the list.

Also correct - ARIN runs the Specified Transfer Listing Service (STLS) so
that parties that wish to be vetted by ARIN may do so in advance, and also
optionally be listed as “interested in offers” from others using the STLS 
service.
Also, potential recipients may have their IP address need verified in advance,
therefore making them a qualified recipient in the ARIN region.  It’s completely
optional, but available for those who wish to validate their half of a transfer
(whether as a source or recipient) in advance. 

> works well, and less dodgy-ness, since everyone on the list has been
> vetted (to some degree) by ARIN.

I’m glad you like the STLS service; it does work well for straightforward 
transfers among parties.  There are some cases (complex corporate 
changes, long absent or incorrect registration information, etc.) where
parties may find the support and guidance of one of the brokers helpful;
it doesn’t matter to ARIN either way nor does it change the criteria that
we apply - all transfers follow the same policy.

Thanks!
/John

John Curran
President and CEO
ARIN

Re: ARIN legacy block transfer process

[John Curran]

On 30 Sep 2016, at 1:47 PM, Enno Rey  wrote:
> ...
> Note also there's voices recommending not to sign an RSA for legacy space (in 
> certain situations, at least), see 
> http://ipv4marketgroup.com/dont-sign-an-rsa-during-your-82-ipv4-transfer/.


Probably best to talk to a variety of IP brokers (including the one
publishing the above blog) for more current information, as this 
has been a fairly rapidly changing area and the referenced blog
contains both inaccuracies and statements that lack context. 

For example, there is a suggestion not to undertake a “NRPM 
8.2 Merger and Acquisition IPV4 transfer” due to the need to 
sign an RSA in the process.  The advice may be applicable to 
some who are adverse to the RSA, but is specifically about only
one type of transfer, i.e. transfer via merger and acquisition, not
an specified IP address block sale as most people consider…

Another example is the assertion that "ARIN says it will then not 
allow transfers from ARIN to RIPE, once inter-RIR transfers are 
allowed by RIPE, because there is no “like” needs based policy.”
While that might have been correct at one point in time, RIPE 
did adopt a rather generous needs-based policy that is indeed
compatible with ARIN’s inter-RIR transfer policy, and we’ve done
many transfers to the RIPE region since that time.

The combination of inaccuracies and outdated information dilute
the value of historical blog posts, so caveat emptor when revisiting
such… 

FYI,
/John

John Curran
President and CEO
ARIN

Re: ARIN legacy block transfer process

[John Curran]

On 30 Sep 2016, at 12:49 PM, Bryan Fields  wrote:
> 
> I'm trying to find a place on ARIN's website where this is addressed, but
> coming up short.  I'm not the seller or buyer in this, but basically someone
> has a legacy block allocated by Postel and wants to sell the block as it's an
> owned asset.
> 
> What's the process to get ARIN to move the admin/ownership of this?  Do they
> only need to see a valid asset purchase agreement?  There is no legacy RSA for
> this.

Bryan - 

It is not required (but if they were presently under LRSA, then the transfer 
would 
indeed be faster since the organization and IP address block would not have to 
be revalidated…)

> I'm thinking of referring both parties to an experienced broker as well.

That certainly works - there is a list of several brokers available here 

and many of them are very experienced in facilitating transfers under
a wide variety of circumstances. 

> Does anyone have current process experience with this?

Yes, I seem to have some experience with these processes… 

The legacy resource holder has to be validated by ARIN.  This can be
accomplished by simply making sure that the seller is a point-of-contact 
on the organization which hold rights to the IP address block (and is 
smart thing to do in any case, since they can then update the contacts, 
correct reverse DNS servers, etc.) 

You can have the source (i.e. the legacy resource holder) contact ARIN’s
hostmaster (Hostmaster Arin ), or have them call us
Monday through Friday, 7:00 AM to 7:00 PM ET, Phone: +1.703.227.0660
and we’ll walk them through the organization recovery process. 

Once the legacy holder has control of the organization and IP address block,
they can submit a transfer ticket at any time.  ARIN will seek documentation
behind the transfer, and will confirm that the recipient is valid.  For a 
recipient
in another region, we seek concurrence from the serving RIR that the recipient
is valid. 

If you need any additional assistance, feel free to reach out to myself or 
the ARIN registration services helpdesk.

Thanks,
/John

John Curran
President and CEO
ARIN

p.s. Apologies for the delay in getting you this response - it has been a bit 
hectic 
   these last 48 hours... 

Re: Request for comment -- BCP38

[Jay Hennigan]

On 9/26/16 9:37 AM, Hugo Slabbert wrote:


On Mon 2016-Sep-26 12:25:58 -0400, John R. Levine  wrote:


I gather the usual customer response to this is "if you don't want our
$50K/mo, I'm sure we can find another ISP who does."



I myself am talking about the latter and included the option of PI
space to cover that (although I guess at some point this can be made
fly with PA space from another provider if both providers are willing
enough to play ball), though from the $50/mo figure John listed, I'm
assuming he's talking about the latter.


Who said $50/mo?


Apparently I need even more caffeine that I first imagined...

If we're talking about networks with that kind of MRC, is it really that
far of a stretch to require PI space for this?  Then again:  If we're
talking about that kind of MRC, then I'm assuming ISP A can be coaxed to
allow explicit and well-defined exceptions on the customer's links.

This discussion started wrt to COTS dual-ISP routers though, as
mentioned in Ken Chase's message, no?  Where I'm assuming we're talking
about mom-and-pop operations rather than a $50K/mo business account.


This is getting insanely silly, especially for this list.

A $50K/mo customer should have PI space and announce via BGP to both 
(all) upstreams. He isn't going to do this with a COTS Belkin "router".



A mom-and-pop with said Belkin router who ties to source its /29 or 
dynamic /32 from ISP A out ISP B isn't going to get very far with it. 
The COTS "router" isn't going to NAT the traffic out the wrong interface 
in the first place.


In any case, ISP B will never see the return traffic. The rest of the 
Net isn't going to accept its /29 and /32 random advertisements, period.


--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

Re: Request for comment -- BCP38

[Stephen Satchell]

On 10/01/2016 06:39 PM, Jay R. Ashworth wrote:

You *can* do BCP38 egress filtering on your network, but that filter
would *be in control of the Bad Guys* whom we're trying to kill off.


I don't see how you arrive at this conclusion.  For an aggregating 
router, the Bad Guys(tm) don't get anywhere near the control plane of 
the thing.  Besides, my security training (such as it is) demands that 
one implement defence in depth.  Specifically, if the Bad Guys(tm) find 
a way around my ingress filtering, the egress filtering will bump 'em off.


Where egress filtering really makes sense is with tunnels over SSH.  I 
haven't found where I can "hook into" a SSH tunnel with Linux.  I can 
turn off shell (and do), but the inbound packets look like local 
origination to the NetFilter.  And (at this early time) The Rules(sm) 
say that you always ACCEPT packets to and from "lo".  I've learned from 
hard experience that violating that rule breaks a lot of stuff.


Then there is the web server case.  The Bad Guys(tm) have access to PHP, 
or Perl, or even a user-level shell, but again NO ACCESS TO THE CONTROL 
PLANE.  Do we really want web-generated packets to get a bye?


(I want to put BGP egress filters on my mail servers, my FTP servers, my 
time servers, my *anything* servers.  It's easy, and it means the 
defence gets as close to the source as I can get it.)



The filtering needs to be on the other side of the administrative
span of control fence.


No reason NOT to have filtering on BOTH sides of that fence...

Re: Request for comment -- BCP38

[Florian Weimer]

* Jay R. Ashworth:

> - Original Message -
>> From: "Florian Weimer" 
>
>> * Jason Iannone:
>
>>> Are urpf and bcp38 interchangeable terms in this discussion?  It seems
>>> impractical and operationally risky to implement two unique ways to dos
>>> customers.  What are the lessons learned by operators doing static output
>>> filters, strict urpf, or loose/feasible urpf?
>> 
>> Historically (in 1998, when RFC 2267 was released), BCP 38 was an
>> egress filter applied at the AS boundary.
>
> You meant ingress, no?

It's a bit murky.  Section 4 suggests that it's not possible to apply
ingress filters on dialup access concnetrators.

> The control of the address space allocation resides with the upstream,
> as must control of the filtering.

That's not really true for customers who maintain their own routes and
IP assignments/allocations.

> You *can* do BCP38 egress filtering on your network, but that filter
> would *be in control of the Bad Guys* whom we're trying to kill off.

If you can't do ingress filtering (e.g. you do not give customers
dedicated physical ports, or the equipment does not allow tying ports
to specific IP addresses), egress filtering is surely better than
nothing at all.

In theory, it would not matter because the other side should have a
matching ingress filter.  In practice, egress filtering would make a
significant difference in traceability of attacks.  Any additional
filtering would do so.

Again, the goal should not be to deploy specific techonology in a
certain way, but to reduce spoofing and attacks which cannot be traced
back to the packet sources.

Re: Request for comment -- BCP38

[Octavio Alvarez]

On 09/26/2016 08:47 AM, Laszlo Hanyecz wrote:
>> If you have links from both ISP A and ISP B and decide to send traffic
>> out ISP A's link sourced from addresses ISP B allocated to you, ISP A
>> *should* drop that traffic on the floor.  There is no automated or
>> scalable way for ISP A to distinguish this "legitimate" use from
>> spoofing; unless you consider it scalable for ISP A to maintain
>> thousands if not more "exception" ACLs to uRPF and BCP38 egress
>> filters to cover all of the cases of customers X, Y, and Z sourcing
>> traffic into ISP A's network using IPs allocated to them by other ISPs?
>>
> 
> This is a legitimate and interesting use case that is broken by BCP38. 
> The effectiveness of BCP38 at reducing abuse is dubious, but the
> benefits of asymmetric routing are well understood.  Why should everyone
> have to go out of their way to break this.. it works fine if you just
> don't mess with it.

This is really wrong.

Any ISP reserves the right to drop irrelevant traffic, traffic that does
not belong to its network (read: dropping traffic that is not required
to fulfill or is preventing the fulfillment of its contractual and
technical requirements).

BCP38 does not get in the way of the above and provides some potential
benefits like avoiding blacklists in some cases, detecting attacks and
hacked computers and contributing to the greater good of the community
(yes, some ISPs choose to be good netizens as much as possible, and this
is good).

This means that applying BCP38 is just natural for those that wish to
adopt it. Furthermore, being against it means being against the right to
drop irrelevant traffic.

In turn, this means that whenever a technical problem comes in conflict
with BCP38, it is just a sign that there is some underlying technical
flaw in the global Internet structure that should be addressed. I see
this as a feature of BCP38.

BCP38 does not break anything that it is not already broken, like the
PD-addressing multihoming problem. The problem is not BCP38.

Octavio.

Re: Kudos to Rogers Wireless on IPv6 deployment

[Theodore Baschak]

I'm also seeing IPv6 on Rogers 4g/LTE on an Android in Winnipeg!
Looks like I'm part of 2605:8d80:400::/38

Theodore Baschak - AS395089 - Hextet Systems
https://ciscodude.net/ - https://hextet.systems/
http://mbix.ca/

> On Oct 1, 2016, at 10:37 PM, Hugo Slabbert  wrote:
> 
> So frequently on this list we hear people asking/begging their providers for 
> IPv6 roadmaps or chastising them for the lack of same, that I thought it 
> might be nice to actually give props to a provider actually moving the needle.
> 
> I was pleasantly surprised today to notice an IPv6 address on my Android 
> smartphone on the Rogers Wireless LTE network.  I had to do a double-take and 
> poke through test-ipv6.com to make sure something wasn't amiss, but there it 
> was: honest-to-$deity dual stack service on a Canadian mobile provider, with 
> a dual-stack resolver and everything! ;)
> 
> So, kudos, Rogers Wireless!
> 
> So that's Rogers on the wireless side (with Telus Mobility at last check 
> being in early stages but not yet fully rolled out), and basically Rogers, 
> Telus and a bunch of smaller or regional ISPs that have deployed IPv6 on 
> residential and/or business wired service.  Shaw?  Bell?  (FYI Bell, your 
> IPv6 Starter Kit linked from http://ipv6.bell.ca/ currently hits a 404.
> 
> -- 
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal
>