Re: emily postnews

[Michael Hallgren]

You sure :-)^oo
mh

28 octobre 2023 19:32 "Jay R. Ashworth"  a écrit:

> - Original Message -
> 
>> From: "Randy Bush" 
>> 
>> another old dog doing a search wrote to tell me they really appreciated
>> that i still had some antique advice up. i had long forgotten this one.
>> but found it amusing and still more relevant than i might wish.
>> 
>> https://psg.com/emily.html
> 
> I would bet many dollars green American that the venn diagram of "people who
> need that advice these days" and "people who can tell that it is sarcasm/
> satire" is two disjoint circles...
> 
> 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: The role of Internet governance in sanctions

[Michael Hallgren]

+1
mh

10 mars 2022 16:34 "jim deleskie" mailto:deles...@gmail.com?to=%22jim%20deleskie%22%20)> a 
écrit:
 I respect the people and goals here, but strongly echo Mel's statement. This 
is a much larger hammer then mail filtering lists.  -jim  
 On Thu, Mar 10, 2022, 11:26 AM Mel Beckman mailto:m...@beckman.org)> wrote: In my view, there is a core problematic 
statement in this document:

“Military and propaganda agencies and their information infrastructure are 
potential targets of sanctions.”

What is a “propaganda agency”. A political party? An incumbent candidate for 
re-election? The IRS? Anyone the “majority” disagrees with?

Propaganda is in the eye of the beholder, and we’ve seen both sides of the 
political aisle sling this term in recent elections and legislative debates.

I think it is a colossal mistake to weaponize the Internet. The potential for 
unintended consequences is huge, as is the potential for intended, 
politically-driven consequences

-mel beckman

> On Mar 10, 2022, at 5:03 AM, Randy Bush  (mailto:ra...@psg.com)> wrote:
>
> maybe it is just that i am sufficiently anti-authoritarian that i try
> not to have the hubris to set myself up as the authority. maybe that
> in itself is hubris.
>
> as i was raised by someone who was a conscious objector in ww2, i can
> not bring myself to contribute to weapons etc. so i have donated to
> folk such as https://razomforukraine.org/ (https://razomforukraine.org/) 
> which is focused on medical
> support.
>
> randy

Re: Telecommunications network drafting software

[Michael Hallgren]

TikZ ? 
mh

De : Etienne-Victor Depasquale via NANOG 
Envoyé : mercredi 1 septembre 2021 20:30
À : NANOG
Objet : Telecommunications network drafting software

Hello folks,

Would you care to share some pointers to drafting software which you use to 
draw up architectural drafts (for telecoms networks, including cable operators' 
networks) ?

I've found Visio to be a bit weak in this respect, even after adding third 
party stencils.

One product I'm exploring is ConceptDraw's "diagram" product, but I'd like to 
hear about anything you can share with me.

Cheers,

Etienne

-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale

Re: Perhaps it's not time to think about enhancements to the NANOG list...?

[Michael Hallgren]

I agree.
mh

20 mars 2021 19:57 "John Levine"  a écrit:

> It appears that Mike Hammett  said:
> 
>> -=-=-=-=-=-
>> 
>> That seems like a reasonable proposal. NANOG-OffTopic, NANOG-Discuss, 
>> NANOG-BizDev, NANOG-xyz,
>> something (more more than one something).
> 
> Having been around this barn a few times, I can promise you that won't work, 
> because threads
> will never stay on the appropriate list.
> 
> Mailman topics might work better but I've never seen a list that used them 
> successfully.
> 
> For once, I'm with Randy. The volume from NANOG at its chattiest is not huge, 
> and if you
> have trouble keeping up with it, perhaps you could consider a better mail 
> program.
> 
> R's,
> John

Re: cloud automation BGP

[Michael Hallgren]

Hi

Shared appreciation!! (and observation).

Cheers,

mh

29 septembre 2020 17:16 "Simon Leinen"  a écrit:

> Randy Bush writes:
> 
>> have folk looked at https://github.com/nttgin/BGPalerter
> 
> We use it, and have it configured to send alerts to the NOC team's chat
> tool (Mattermost). Seems pretty nice and stable. Kudos to Massimo and
> NTT for making it available and for maintaining it!
> 
> The one issue we see is that the server often logs disconnections from
> the RIS service (to its logfile, fortunately not generating alerts).
> --
> Simon.

Re: Centurylink having a bad morning?

[Michael Hallgren]

While conserving connectivity? 😂



De : Shawn L via NANOG 
Envoyé : mercredi 2 septembre 2020 13:15
À : nanog
Objet : Re: Centurylink having a bad morning?

We once moved a 3u server 30 miles between data centers this way.  Plug 
redundant psu into a ups and 2 people carried it out and put them in a vehicle. 
 


Sent from my iPhone 

> On Sep 1, 2020, at 11:58 PM, Christopher Morrow  
> wrote: 
> 
> On Tue, Sep 1, 2020 at 11:53 PM Alain Hebert  wrote: 
>> 
>>    As a coincidence...  I was *thinking* of moving a 90TB SAN (with 
>>mechanical's) to another rack that way...  skateboard, long fibers and long 
>>power cords =D 
>> 
> 
> well, what you REALLY need is one of these: 
>  https://www.cru-inc.com/products/wiebetech/hotplug_field_kit_product/ 
> 
> and 2-3 UPS... swap to the UPS, then just roll the stack over, plug to 
> utility and done. (minus network transfer) 

Re: Bgpmon alternatives?

[Michael Hallgren]

RIS Live API is a choice for this.

mh

Le 16 juin 2019 à 13:21, à 13:21, Brian Kantor  a écrit:
>That would be wonderful.  Thank you!
>   - Brian
>
>
>On Sun, Jun 16, 2019 at 03:59:29AM -0700, Mike Leber wrote:
>> I'm sure if it doesn't do exactly that already, we can add it
>shortly.
>>
>> Some of planned functionality for hijack detection is already live. 
>> That's one of the main reasons for creating this service.
>>
>> Mike.
>>
>> On 6/16/19 2:48 AM, Brian Kantor wrote:
>> > On Sun, Jun 16, 2019 at 02:25:40AM -0700, Mike Leber wrote:
>> >> As a beta service you can try out rt-bgp.he.net.  This is a real
>time
>> >> bgp monitoring service we are developing.
>> > It's interesting, but I don't see any way to do what I primarily
>> > use the existing BGPMon for: watch for hijacks.
>> >
>> > That is, set up one or more prefixes to be continuously monitored
>> > and have the monitor send me an email alert when that prefix or a
>> > subnet of it begins to be announced by someone new.
>> >
>> > For example, if I have told it to monitor 44.0.0.0/8 and someone
>> > somewhere begins announcing it, or perhaps 44.1.0.0/16, I'd very
>> > much like to know about that, along with details of who and where.
>> >
>> > Then if that announcement is authorized, I can tell the monitoring
>> > service that this new entry is NOT a hijack, and it won't bug me
>> > about it again.
>> >
>> > Can it be persuaded to do this?
>> >- Brian

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Michael Hallgren]

Le 2019-02-26 11:04, Sander Steffann a écrit :
Op 26 feb. 2019, om 10:56 heeft Bill Woodcock  het 
volgende geschreven:


We need to get switched over to DANE as quickly as possible, and stop 
wasting effort trying to keep the CA system alive with ever-hackier 
band-aids.


+1
Sander

+1
mh

Re: AT&T/as7018 now drops invalid prefixes from peers

[Michael Hallgren]

Le 2019-02-12 20:56, Nick Hilliard a écrit :

Matthew Walster wrote on 12/02/2019 19:27:
I'm actually of the opinion that the whole "PKI" part of RPKI is the 
bit that really needs to die.


I'll claim a de-facto godwin if anyone mentions the word "blockchain".

Nick


https://www.google.fr/search?q=blockchain+for+BGP+routing+security&oq=blockchain+for+BGP+routing+security&aqs=chrome..69i57.18977j0j7&sourceid=chrome&ie=UTF-8

:-)
mh

Re: Best practices on logical separation of abuse@ vs dmca@ role inboxes

[Michael Hallgren]

Le 2018-08-06 16:03, Jérôme Nicolle a écrit :

Hi Jack,

Le 05/08/2018 à 21:51, na...@jack.fr.eu.org a écrit :

By "appropriate place", you mean "the trash bin" ?


Nope, that would eat-up storage and IOs. The proper destination is
/dev/null, unless they provide you with the required informations to
send a bill.


Straight to unless, right ;-)

mh



Best regards,

Re: Impacts of Encryption Everywhere (any solution?)

[Michael Hallgren]

Le 2018-06-17 12:40, na...@jack.fr.eu.org a écrit :

Well, yes, there is, you simply have to break the end to end encryption


Yes, (or) deny service by Policy (remains to evaluate who's happy with 
that).


Cheers,
mh



On 06/17/2018 03:09 AM, Matthew Petach wrote:

Except that if websites are set to HTTPS only, there's no option for
disabling encryption on the client side.

Matt


On Sat, Jun 16, 2018, 14:47  wrote:


On 06/16/2018 10:13 PM, Mike Hammett wrote:
Sadly, it's just falling on deaf ears. Silicon Valley will continue 
to
think they know better than everyone else and people outside of that 
bubble

will continue to be disadvantaged.

What, again ?
Encryption is what is best for the most people.
The few that will not use it can disable it.

No issue then.

Re: Impacts of Encryption Everywhere (any solution?)

[Michael Hallgren]

Morocco... Sure? Data points?

mh

Le 2018-05-29 20:00, Owen DeLong a écrit :

It was a convenient example with which I had experience near Eritrea.

My statement would apply equally for say, Zambia or Morocco.

Owen



On May 29, 2018, at 10:58 , Eric Kuhnke  wrote:

Ethiopia is significantly different and unique, in its own unusual 
way, because of the government monopoly telecom. Other people can 
correct me if I'm wrong, but unless the situation has changed in the 
past two years, all small to medium sized ISPs in Ethiopia are 
mandated by law to be downstream of the government run telecom ASN. 
Also the government owned national telecom has a monopoly on all 
international fiber connections to neighboring countries (at OSI layer 
1), and for things like STM/SDH or 1/10/ Gbps Ethernet L2 transport 
services to any location outside of Ethiopia.


The Ethiopian Internet is also subject to significant censorship and 
attempted blockage of VPN and VoIP services.


https://www.google.com/search?q=ethiopia+internet+censorship&oq=ethiopia+internet+censorship&aqs=chrome.0.0j69i57.2857j0j7&sourceid=chrome&ie=UTF-8 







On Tue, May 29, 2018 at 10:21 AM, Owen DeLong > wrote:

>
> The Internet in Indonesia is the very same Internet in Eritrea, as it is
> in Canada. We can't quite split that…

I admit that I haven’t been to Eritrea or Indonesia, but using 
Ethiopia
and Malaysia as stand-ins (which I have been to), I can say that while 
they
are the same internet, the level of development, the payment systems 
which
are usable via said internet, and other aspects of the daily use and 
capabilities
which can be utilized on the internet in those countries does vary 
greatly.


For example, Apple Pay is somewhat ubiquitous in Canada. It’s 
virtually unheard
of in Ethiopia. My travels to Malaysia were not recent enough for me 
to comment

accurately on the current state of things.

M-Pesa is widely accepted in Kenya, but not at all in the US or 
Canada.


PayPal is popular in the US, but not so much in most of the rest of 
the world.


YMMV.

IPv6 is readily available on almost every mobile phone in the US. Less 
so in

Kenya or Tanzania, Eritrea, Canada, or Indonesia.

While all connected networks are part of the same big I Internet, not 
all networks
are created or maintained equal and not all services on those networks 
are

ubiquitously available to all users of the big I Internet.

Owen

Re: Opinions on intent-based networking

[Michael Hallgren]

BGP? :-)

mh

Le 2018-05-29 20:32, LF OD a écrit :

Been following the articles on "intent-based" networking from Cisco
and other vendors for a couple years now, and I have a basic grasp of
the concept of "define your goals/outcomes and automation will make it
so", but I do not know the practical applications of it or how you are
supposed to convey your "intent". However, $dayjob is a medium-sized
enterprise and looking at a potential refresh in the upcoming budget.


So... do any of you at ISPs, Cloud Providers, or Enterprises have any
hands-on experience with "intent-based" networking products? If so,
could you please provide some info on what caused you to look at it,
who did you look at, why did you choose whoever you chose, and is it
working out for you?


If you looked at it very closely and decided not to bother with it,
I'd also be interested on your take. At $dayjob we have been adopting
automation at the application and workload level, but there hasn't
been much need for it at the infrastructure level. However, if we can
improve the services we offer while refreshing that infrastructure, it
wouldn't hurt - depending on cost of course.


Thanks in advance.

LF0D

Re: list blockchain

[Michael Hallgren]

:-)

mh

Le 2018-01-28 05:52, Randy Bush a écrit :

why is no one exploring converting this mailing list to a blockchain?
major missed opportunity.  

randy

Re: IPv4 smaller than /24 leasing?

[Michael Hallgren]

Le 2018-01-05 00:07, Mike Hammett a écrit :

No. ARIN is out of IPv4 other than IXes, critical infrastructure and
IPv6 transition.



Thanks. Good argument for going IPv6. :-)

mh





-
Mike Hammett
Intelligent Computing Solutions

Midwest Internet Exchange

The Brothers WISP

- Original Message -

From: "Michael Hallgren" 
To: "William Herrin" 
Cc: "NANOG" 
Sent: Thursday, January 4, 2018 4:56:21 PM
Subject: Re: IPv4 smaller than /24 leasing?

By the way, RIPE still seems to provide fresh /22s to new LIRs. Same
in the ARIN region?
mh

Le 4 janv. 2018 à 23:50, à 23:50, William Herrin  a 
écrit:

On Thu, Jan 4, 2018 at 5:40 PM, Justin Wilson  wrote:


I know of dozens, if not hundreds of small ISPs that can’t

participate in

BGP because they don’t have big enough blocks.



Hi Justin,

Not much of an ISP if they can't get a /24. We're talking about a
one-time
market purchase under $5000 and the ARIN justification for that small 
a

block almost writes itself.

Regards,
Bill Herrin


--
William Herrin  her...@dirtside.com b...@herrin.us
Dirtside Systems . Web: <http://www.dirtside.com/>

Re: IPv4 smaller than /24 leasing?

[Michael Hallgren]

By the way, RIPE still seems to provide fresh /22s to new LIRs. Same in the 
ARIN region?
mh

Le 4 janv. 2018 à 23:50, à 23:50, William Herrin  a écrit:
>On Thu, Jan 4, 2018 at 5:40 PM, Justin Wilson  wrote:
>
>> I know of dozens, if not hundreds of small ISPs that can’t
>participate in
>> BGP because they don’t have big enough blocks.
>
>
>Hi Justin,
>
>Not much of an ISP if they can't get a /24. We're talking about a
>one-time
>market purchase under $5000 and the ARIN justification for that small a
>block almost writes itself.
>
>Regards,
>Bill Herrin
>
>
>--
>William Herrin  her...@dirtside.com  b...@herrin.us
>Dirtside Systems . Web: 

Re: IPv4 smaller than /24 leasing?

[Michael Hallgren]

Thanks Bill. Kinda ugly, but OK I see... Prefer v6 ;-)
mh

Le 4 janv. 2018 à 23:17, à 23:17, William Herrin  a écrit:
>On Thu, Jan 4, 2018 at 5:07 PM, Michael Hallgren  wrote:
>
>> Am I missing something? What's the trigger for doing tunneling here?
>>
>
>With "IP address leasing" you aren't connected to the network which
>holds
>the address registration.
>
>For leasing less than a /24, they need a plan other than "advertise to
>your
>peers with BGP" because even if your peer accepts a /27, most of their
>peers will not.
>
>Regards,
>Bill Herrin
>
>
>
>--
>William Herrin  her...@dirtside.com  b...@herrin.us
>Dirtside Systems . Web: <http://www.dirtside.com/>

Re: IPv4 smaller than /24 leasing?

[Michael Hallgren]

Le 2018-01-04 20:16, Job Snijders a écrit :

On Thu, 4 Jan 2018 at 20:13, Filip Hruska  wrote:

I have stumbled upon this site [1] which seems to offer /27 IPv4 
leasing.
They also claim "All of our IPv4 address space can be used on any 
network

in any location."

I thought that the smallest prefix size one could get routed globally 
is

/24?



Yes

So how does this work?



Probably with GRE, IPIP or OpenVPN tunnels.

Kind regards,

Job


IPv4 /24 is commonly the minimal chunk advertised to (and accepted by) 
neighbors. If I run a global (or regional) network, I may advertise this 
/24 -- or rather an aggregate covering it -- over my diverse 
interconnection with neighbors, your /27 being part of the chunk and 
routed to you internally (if you're va customer)-- no need for 
encapsulation efforts. Similar scenario may be multi-upstream, subject 
to acceptance of "punching holes in aggregates"... Am I missing 
something? What's the trigger for doing tunneling here?


Happy New Year '18, by the way !

mh

Re: IPv4 smaller than /24 leasing?

[Michael Hallgren]

Le 2018-01-04 20:27, Harald Koch a écrit :

"IPv6 available upon request. "

LOL.

+1 :-)
mh

Re: What's the point of prepend communities?

[Michael Hallgren]

Yes, sometimes very much so, and often nice to combine with local-pref settings 
based on upstream's "geo-community-values" when available.

Cheers, 
mh

Le 1 nov. 2017 à 18:59, à 18:59, Leo Bicknell  a écrit:
>In a message written on Mon, Oct 30, 2017 at 07:56:43PM +0100, Michael
>Hallgren wrote:
>> But keep in mind that 'prepend communities' are fragile: I decide by
>local preference whereto I send my traffic.
>
>Absolutely, but they are still very useful in many situations.
>
>--
>Leo Bicknell - bickn...@ufp.org
>PGP keys at http://www.ufp.org/~bicknell/

Re: What's the point of prepend communities?

[Michael Hallgren]

Hi guys,

But keep in mind that 'prepend communities' are fragile: I decide by local 
preference whereto I send my traffic.

Cheers,
mh

Le 30 oct. 2017 à 18:25, à 18:25, Leo Bicknell  a écrit:
>In a message written on Thu, Oct 26, 2017 at 01:54:17PM -0600, Clinton
>Work wrote:
>> I believe that Jason is asking about an ISP BGP community to prepend
>> their AS when the BGP routes are received from the customer (not when
>
>Yeah, I typoed my example, should have been:
>
>There are paths:
>
>1 2 3 5
>1 2 4 5
>
>If you prepend your ASN, you get:
>
>1 1 2 3 5
>1 1 2 4 5
>
>No difference.  If you send the ISP a prepend community for 3, you get:
>
>1 2 2 3 5
>1 2 4 5
>
>And you just forced all traffic to the second, shorter path.  For only
>customers that are dual homed to 3 & 4 without affecting other traffic.
>
>--
>Leo Bicknell - bickn...@ufp.org
>PGP keys at http://www.ufp.org/~bicknell/

Re: IPv6 migration steps for mid-scale isp

[Michael Hallgren]

Le 16/09/2017 à 10:39, Youssef Bengelloun-Zahr a écrit :
> Hi,
>
> My advice is not to mix IGPs. If you are already running ISIS, then go for 
> multi-topology and dual-stack it.
>
> I've done that several times, running different backbones, works like a 
> charm. Less overhead as you'd only be running one IGP.
>
> My 2 cents.

Adding few cents of €. ;-)

mh

>
>
>
>> Le 16 sept. 2017 à 10:09, Fredrik Sallinen  a 
>> écrit :
>>
>> Thank you all for your Ideas. AFAIK one of the main decisions for IPv6
>> transition and deployment is the choice of IPv6 IGP. I read somewhere
>> that its a good practice to use different IGP protocol for IPv6 and
>> IPv4. For example if IGP for IPv4 is IS-IS then use OSPFv3 for IPv6.
>> any comments on this?
>> Additionally I will appreciate it if you share your suggestions on
>> products and their performance? For example If I go for NAT64+DNS64 to
>> handle IPv4 traffic, What sort of carrier grade products are you
>> recommending and can you share your experience on their
>> performance/pitfalls? currently we have ~150Gbps of IPv4 traffic, so
>> we need a solution to
>> support such scale and future growth.
>>
>>
>> Regards,
>>
>>> On Thu, Sep 14, 2017 at 9:35 PM, Mikael Abrahamsson  
>>> wrote:
 On Wed, 13 Sep 2017, Fredrik Sallinen wrote:

 Hello,

 Recently we have decided to start IPv6 migration in our network. We
 have ~1K BNGs and connecting our customers to network using PPPoE.
 I'd be interested in hearing from the technical community about their
 experiences and recommendations on this process. I'm wondering:

 Shall I go for IPv6-only deployment or dual stack?
>>>
>>> For PPPoE with existing IPv4, go dual stack.
>>>
 Where to start with IPv6? (core, edge or ...)
>>>
>>> Core, peering, work outwards towards end users.
>>>
 What are the best practices for ISPs?
 What are the costs and return on investment?
 How to identify address CPE and legacy application issues?
>>>
>>> There is a lot written and presented about IPv6 deployment. People have been
>>> doing this in volume since around 2010, and if you search for IPv6
>>> deployment experience you'll find lots of presentations.
>>>
>>> Some I found that seem relevant:
>>>
>>> https://www.nanog.org/meetings/nanog51/presentations/Monday/aronson-pierantozzi-level3-ipv6.pdf
>>> https://www.ietf.org/proceedings/54/slides/plenary-15.pdf
>>> https://www.apnic.net/community/ipv6-program/ipv6-stories/
>>> https://www.ipv6council.be/experiences-de-deploiements-ipv6/
>>>
>>> If you prefer video form, there are lots of presentations from conferences,
>>> available on youtube as well.
>>>
>>> --
>>> Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Moving fibre trunks: interruptions?

[Michael Hallgren]

Le 02/09/2017 à 21:25, Baldur Norddahl a écrit :
> That depends on the country. Here in Denmark it is not possible to get
> rights to put up any aerial at all. The cost difference is irrelevant when
> you have no option but to put it in the ground.
>
> Not only is there no new aerial installations here but the old ones are
> taken down. Very little is left by now and in a few years it will all be
> gone. The municipalities want it pretty and wires in the air is ugly.
>
> One advantage however is that buried stuff usually survives storms better.

Right. Here in France it (aerial running along with copper) happens
even close to metropoles (like Paris).
mh
>
> Den 1. sep. 2017 21.53 skrev "Rod Beck" :
>
> I don't think there is virtually any aerial in Europe. So given the cost
> difference why is virtually all fiber buried on this side of the Atlantic?

Re: Moving fibre trunks: interruptions?

[Michael Hallgren]

Aerial's not that rare in Europe (rural areas, sometimes even close to
metro).

Cheers,
mh

Le 01/09/2017 à 21:52, Rod Beck a écrit :
> I don't think there is virtually any aerial in Europe. So given the cost 
> difference why is virtually all fiber buried on this side of the Atlantic?
>
>
> 
> From: NANOG  on behalf of Jared Mauch 
> 
> Sent: Friday, September 1, 2017 9:37 PM
> To: Michael Loftis
> Cc: Nanog@nanog.org
> Subject: Re: Moving fibre trunks: interruptions?
>
>
>
>> On Sep 1, 2017, at 3:32 PM, Michael Loftis  wrote:
>>
>> If it is in the railroad RoW they may be restricted to daylight working
>> only. Check with your provider or OSP crew.
>>
>
> Yup.  Railroad work is complex just because you have to coordinate with the 
> railroad owner and they have to be onsite for all work.  The cost of going 
> underground vs aerial is also astronomical in many cases.
>
> - Jared

Re: OSPF vs ISIS - Which do you prefer & why?

[Michael Hallgren]

Hi,

What IGP features do you need, and for what reason?

Cheers,
mh⁣​Le 10 nov. 2016, à 23:04, Josh Reynolds  a écrit:

I didn't "trash talk" a vendor. If I did, it would be a multi-thousand line
hate fueled rant with examples and enough colorful language to make
submarine crews blush.

Cisco has been pushing EIGRP and IS-IS as part of their "showing" for
decades. During that same time frame, the majority of the other vendors and
the open source daemons have been using OSPF as their IGP offering. In the
mean time, Cisco found a need to introduce more and more vendor specific
features into their IS-IS offering - no different than any other vendor
would do in their situation to promote the business case (better scaling,
vendor lock-in, other bits).

If you go looking for cross vendor compatibility with as many devices
(routers, switches, servers, etc) as possible, you're going to end up with
OSPF [or BGP, for the data center types that run it to edge nodes]. You
will find a handful, as some have mentioned, of vendors that have adopted
the open version of the protocol and have tried to add
comparable/compatible features to close the gap.

Since the last time I looked, I could not get the same feature sets running
IS-IS in a multi-vendor environment as I could running OSPF. This was my
experience at the time, based on my research and discussions with the
vendors.

On Nov 10, 2016 3:49 PM, "Nick Hilliard"  wrote:

Josh Reynolds wrote:

I'm sure a lot has changed with Juniper as of 2011 in regard to IS-IS
support, which was the last time *I* looked.

No, I do not have a list sitting ready, that catalogs in details
between product lines and specific firmware versions and subversions
between multiple vendors what one supports and what one does not as of
Nov 11, 2016.

What I can do is point you at the vendor list where you can make a
comparison of that vendor to others, for the features that you need in
your environment - as I'm not getting paid to maintain such lists, and
they are.


So what you're saying is that you can't even provide a single missing
feature to justify trash-talking a vendor the way you did? Not even one??

Nick

Le 10 nov. 2016 23:04, à 23:04, Josh Reynolds  a écrit:
>I didn't "trash talk" a vendor. If I did, it would be a multi-thousand
>line
>hate fueled rant with examples and enough colorful language to make
>submarine crews blush.
>
>Cisco has been pushing EIGRP and IS-IS as part of their "showing" for
>decades. During that same time frame, the majority of the other vendors
>and
>the open source daemons have been using OSPF as their IGP offering. In
>the
>mean time, Cisco found a need to introduce more and more vendor
>specific
>features into their IS-IS offering - no different than any other vendor
>would do in their situation to promote the business case (better
>scaling,
>vendor lock-in, other bits).
>
>If you go looking for cross vendor compatibility with as many devices
>(routers, switches, servers, etc) as possible, you're going to end up
>with
>OSPF [or BGP, for the data center types that run it to edge nodes]. You
>will find a handful, as some have mentioned, of vendors that have
>adopted
>the open version of the protocol and have tried to add
>comparable/compatible features to close the gap.
>
>Since the last time I looked, I could not get the same feature sets
>running
>IS-IS in a multi-vendor environment as I could running OSPF. This was
>my
>experience at the time, based on my research and discussions with the
>vendors.
>
>On Nov 10, 2016 3:49 PM, "Nick Hilliard"  wrote:
>
>> Josh Reynolds wrote:
>> > I'm sure a lot has changed with Juniper as of 2011 in regard to
>IS-IS
>> > support, which was the last time *I* looked.
>> >
>> > No, I do not have a list sitting ready, that catalogs in details
>> > between product lines and specific firmware versions and
>subversions
>> > between multiple vendors what one supports and what one does not as
>of
>> > Nov 11, 2016.
>> >
>> > What I can do is point you at the vendor list where you can make a
>> > comparison of that vendor to others, for the features that you need
>in
>> > your environment - as I'm not getting paid to maintain such lists,
>and
>> > they are.
>>
>> So what you're saying is that you can't even provide a single missing
>> feature to justify trash-talking a vendor the way you did?  Not even
>one??
>>
>> Nick
>>
>>

Re: nested prefixes in Internet

[Michael Hallgren]

Hi Martin,

What do you want to do? Move from A to B or add A to B?

Cheers,
mh



Le 27 sept. 2016 17:52, à 17:52, Mel Beckman  a écrit:
>Precisely. This is how it's done by providers I've worked with. 
>
> -mel beckman
>
>> On Sep 27, 2016, at 7:06 AM, Roy  wrote:
>> 
>> 
>> 
>> Option 3?
>> 
>> ISP A announces the /19 and the /24 while ISP B does just the /24
>> 
>>> On 9/27/2016 4:20 AM, Martin T wrote:
>>> Hi,
>>> 
>>> let's assume that there is an ISP "A" operating in Europe region who
>>> has /19 IPv4 allocation from RIPE. From this /19 they have leased
>/24
>>> to ISP "B" who is multi-homed. This means that ISP "B" would like to
>>> announce this /24 prefix to ISP "A" and also to ISP "C". AFAIK this
>>> gives two possibilities:
>>> 
>>> 1) Deaggregate /19 in ISP "A" network and create "inetnum" and
>"route"
>>> objects for all those networks to RIPE database. This means that ISP
>>> "A" announces around dozen IPv4 prefixes to Internet except this /24
>>> and ISP "B" announces this specific /24 to Internet.
>>> 
>>> 2) ISP "A" continues to announce this /19 to Internet and at the
>same
>>> time ISP "B" starts to announce /24 to Internet. As this /24 is
>>> more-specific than /19, then traffic to hosts in this /24 will end
>up
>>> in ISP "B" network.
>>> 
>>> 
>>> Which approach is better? To me the second one seems to be better
>>> because it keeps the IPv4 routing-table smaller and requires ISP "A"
>>> to make no deaggregation related configuration changes. Only bit
>weird
>>> behavior I can see with the second option is that if ISP "B" stops
>for
>>> some reason announcing this /24 network to Internet, then traffic to
>>> hosts in this /24 gets to ISP "A" network and is blackholed there.
>>> 
>>> 
>>> thanks,
>>> Martin
>> 

Re: Inferring the location points of traffic exchange between two networks

[Michael Hallgren]

Le 13/01/2016 18:36, Reza Motamedi a écrit :
> Hi NANOG,
>
> I am researcher at the University of Oregon and my question is rather
> primitive. My research background is in networked systems and Internet
> measurement so I know how things work in theory.
>
> My question is about BGP and what can be inferred from the output of
> different "show" commands, regarding the point of traffic exchange of two
> networks with different ASNs. I tried going through the some samples on
> Juniper and Cisco documentations but I did not get my answer.
>
> Consider the following scenario; Say the point of traffic exchange between
> AS_a and AS_b is in San Francisco and we run "show bgp summary" and "show
> ip bgp "on a BGP router of AS_a in LA. Do we see the peering
> between AS_a and AS_b in San Francisco using any of the two commands. If
> yes is there a way to infer that in fact the traffic is not exchanged
> locally in LA? I think there should be a flag to differentiate records
> showing iBGP vs eBGP.
>
> On the same note, if we issue the commands on a router other than the
> border router in San Fran, is there any difference in the output of show
> commands?
>
> Now how are things different if we actually run the commands on that
> gateway router in SF?


Hi Reza,

A reasonably recent paper discussing AS relationships:
http://arxiv.org/abs/1106.2417.

Cheers,

mh

>
> Best Regards
> Reza Motamedi (R.M)
> Graduate Research Fellow
> Oregon Network Research Group
> Computer and Information Science
> University of Oregon

Re: Verizon Policy Statement on Net Neutrality

[Michael Hallgren]

Le 27/02/2015 23:19, Owen DeLong a écrit :
> Any website which does not violate the law.
>
> In other words, if a lawful takedown order

So, subject to legal control rather than simply administrative. Right?

mh

>  has been applied to a website, this code can’t be used to force an ISP to 
> provide illegal access to said site.
>
> Owen
>
>> On Feb 27, 2015, at 11:14 , Jim Richardson  wrote:
>>
>>> From 47CFR§8.5b
>> (b) A person engaged in the provision of mobile broadband Internet
>> access service, insofar as such person is so engaged, shall not block
>> consumers from accessing lawful Web sites, subject to reasonable
>> network management; nor shall such person block applications that
>> compete with the provider's voice or video telephony services, subject
>> to reasonable network management.
>>
>> What's a "lawful" web site?
>>
>>
>> On Fri, Feb 27, 2015 at 10:28 AM, Lamar Owen  wrote:
>>> On 02/27/2015 01:19 PM, Rob McEwen wrote:
 We're solving an almost non-existing problem.. by over-empowering an
 already out of control US government, with powers that we can't even begin
 to understand the extend of how they could be abused... to "fix" an 
 industry
 that has done amazingly good things for consumers in recent years.

>>> You really should read 47CFR§8.  It won't take you more than an hour or so,
>>> as it's only about 8 pages.
>>>
>>> The procedure for filing a complaint is pretty interesting, and requires the
>>> complainant to do some pretty involved things. (47CFR§8.14 for the complaint
>>> procedure, 47CFR§8.13 for the requirements for the pleading, etc).  Note
>>> that the definitions found in 47CFR§8.11(a) and (b) are pretty specific in
>>> who is actually covered by 'net neutrality.'
>>>

Re: Checkpoint IPS

[Michael Hallgren]

Le 05/02/2015 14:28, Terry Baranski a écrit :
> On 5 Feb 2015, at 08:13, Michael Hallgren wrote:
>> Sure they will give you pretty graphs of script-kiddie attempts but 
>> that's just the noise in which the skilled attack will get lost.

No, Terry, I didn't write that ! :-)

Cheers,
mh

> Sorry but this is not even in the neighborhood of what a
> properly-implemented IPS does. 
>
> I can certainly see why you think they're worthless though. :-)
>
> -Terry
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Michael O Holstein
> Sent: Thursday, February 05, 2015 8:13 AM
> To: nanog@nanog.org
> Subject: Re: Checkpoint IPS
>
>
>>> `` 'IPS' devices require artificially-engineered topological symmetry-
>>> can have a negative impact on resiliency via path diversity.''
>> Dang, I thought this quote was from an April 1st RFC when I first read it.
>>
>> I hate to be the bearer of bad news, but everything we do is "artificial".
>> There are no routers in nature, no IP packets, no fiber optics. There is no
>> such thing as "natural engineering" -- engineering is "artificial" by
>> definition.
> You're forgetting that such things are rarely read (in time) by the people
> that actually implement and use such a product .. that language is targeted
> at the pointy-haired crowd.
> Salespeople *hate* it when they get a technical resource instead of a
> management one because "it's magic, it's artificial intelligence, etc." just
> doesn't fly with us.
>
> Personally I'm of the belief that *all* IPS systems are equally worthless,
> unless the goal is to just check a box on a form. Sure they will give you
> pretty graphs of script-kiddie attempts but that's just the noise in which
> the skilled attack will get lost. You have to do everything else right, you
> can't just plug the "magic box" inline and expect to relax.
>
> My 0.02.
>
> Michael Holstein
> Cleveland State University
> 2=
>

Re: Checkpoint IPS

[Michael Hallgren]

Le 05/02/2015 14:15, jim deleskie a écrit :
> mh,

Hi there Jim :-)

>
>  you know that forcing traffic to be symmetrical is evil,

Voilà !

> and while backbone traffic and inspection don't play nice, there are
> very legit reasons why, in many cases edge traffic must be open for
> inspection.

Yes, right, often some such `control' is on wish-lists.

>   I'm on my way to the office, feel free to ping me if you want to
> discuss.  Or maybe I could use it as a reason to come visit  its been
> a while since we've had a chance to vis-a-vis :)

With pleasure! Yes, too long time... TTYS,

mh
>
>
> -jim
>
> On Thu, Feb 5, 2015 at 8:57 AM, Terry Baranski
> mailto:terry.baranski.l...@gmail.com>>
> wrote:
>
> On 5 Feb 2015, at 01:56, Michael Hallgren wrote:
> > Le 04/02/2015 17:19, Roland Dobbins a écrit :
> >>
> >> Real life limitations?
> >> https://app.box.com/s/a3oqqlgwe15j8svojvzl
> >
> > Right ;-) Among many other nice ones, I like:
> >
> > `` ‘IPS’ devices require artificially-engineered topological
> symmetry-
> > can have a negative impact on resiliency via path diversity.''
>
> Dang, I thought this quote was from an April 1st RFC when I first
> read it.
>
> I hate to be the bearer of bad news, but everything we do is
> "artificial".
> There are no routers in nature, no IP packets, no fiber optics.
> There is no
> such thing as "natural engineering" -- engineering is "artificial" by
> definition.
>
> So when you're configuring artificially-engineered protocols on your
> artificially-engineered router so that your
> artificially-engineered network
> can transmit artificially-engineered packets, adding some extra
> artificially-engineered logic to enforce symmetry won't break the
> bank, I
> promise. And when done properly it has absolutely no impact on
> resilience
> and path diversity, and will do you all the good in the world from a
> troubleshooting perspective (those of you who operate networks).
>
> The whole presentation is frankly just odd to me. It looks at one
> specific
> CND thread (DDoS), and attempts to address it by throwing out the
> baby with
> the bathwater. It says to eliminate state at all costs, but then
> at the end
> advocates for reverse proxies -- which are stateful, and which
> therefore
> create the same "problems" as firewalls and IPSs.
>
> The idea of ripping out firewall/IPS devices and replacing them
> with router
> ACLs is something that, if I were an attacker, I would definitely
> encourage
> all of my targets to do. Firewalls aren't so much the big issue --
> one can
> theoretically use router ACLs for basic L3/L4 blocks, though they
> scale
> horribly from an O&M perspective, are more prone to configuration
> errors,
> and their manageability is poor. But there's no overstating the
> usefulness
> of a properly-tuned IPS for attack prevention, and the comment in
> the brief
>     comparing an IPS to "[Having] your email client set to alert you
> to incoming
> mail" is so bizarre that I wouldn't even know how to counter it.
>
> (I know you're out there Roland and my intention isn't to get into
> a big
> thing with you. But the artificial-engineering thing gave me a
> chuckle.)
>
> On 5 Feb 2015, at 02:49, Michael Hallgren wrote:
> > Le 05/02/2015 08:01, Roland Dobbins a écrit :
> >>
> >> The real question is, why 'inspect', at all?
> >
> > Yes, that's an even more interesting discussion!
>
> Only if your assets aren't targets. :-)
>
> -Terry
>
>
>

Re: Checkpoint IPS

[Michael Hallgren]

Le 05/02/2015 13:57, Terry Baranski a écrit :
> On 5 Feb 2015, at 01:56, Michael Hallgren wrote:
>> Le 04/02/2015 17:19, Roland Dobbins a écrit :
>>> Real life limitations?
>>> https://app.box.com/s/a3oqqlgwe15j8svojvzl
>> Right ;-) Among many other nice ones, I like:
>>
>> `` ‘IPS’ devices require artificially-engineered topological symmetry-
>> can have a negative impact on resiliency via path diversity.''
> Dang, I thought this quote was from an April 1st RFC when I first read it. 
>
> I hate to be the bearer of bad news, but everything we do is "artificial".
> There are no routers in nature, no IP packets, no fiber optics. There is no
> such thing as "natural engineering" -- engineering is "artificial" by
> definition.
>
> So when you're configuring artificially-engineered protocols on your
> artificially-engineered router so that your artificially-engineered network
> can transmit artificially-engineered packets, adding some extra
> artificially-engineered logic to enforce symmetry won't break the bank, I
> promise. And when done properly it has absolutely no impact on resilience
> and path diversity, and will do you all the good in the world from a
> troubleshooting perspective (those of you who operate networks).

Depends on the underlying physical network... (which may be quite
costly to ``fix'').

mh

>
> The whole presentation is frankly just odd to me. It looks at one specific
> CND thread (DDoS), and attempts to address it by throwing out the baby with
> the bathwater. It says to eliminate state at all costs, but then at the end
> advocates for reverse proxies -- which are stateful, and which therefore
> create the same "problems" as firewalls and IPSs.
>
> The idea of ripping out firewall/IPS devices and replacing them with router
> ACLs is something that, if I were an attacker, I would definitely encourage
> all of my targets to do. Firewalls aren't so much the big issue -- one can
> theoretically use router ACLs for basic L3/L4 blocks, though they scale
> horribly from an O&M perspective, are more prone to configuration errors,
> and their manageability is poor. But there's no overstating the usefulness
> of a properly-tuned IPS for attack prevention, and the comment in the brief
> comparing an IPS to "[Having] your email client set to alert you to incoming
> mail" is so bizarre that I wouldn't even know how to counter it.
>
> (I know you're out there Roland and my intention isn't to get into a big
> thing with you. But the artificial-engineering thing gave me a chuckle.)
>
> On 5 Feb 2015, at 02:49, Michael Hallgren wrote:
>> Le 05/02/2015 08:01, Roland Dobbins a écrit :
>>> The real question is, why 'inspect', at all? 
>> Yes, that's an even more interesting discussion!
> Only if your assets aren't targets. :-)
>
> -Terry
>
>

Re: Checkpoint IPS

[Michael Hallgren]

Le 05/02/2015 08:01, Roland Dobbins a écrit :
> On 5 Feb 2015, at 13:51, Michael Hallgren wrote:
>
>> So, need another inspection strategy I think.
> The real question is, why 'inspect', at all? 

Yes, that's an even more interesting discussion!

mh

>
> ---
> Roland Dobbins 

Re: Checkpoint IPS

[Michael Hallgren]

Le 04/02/2015 17:19, Roland Dobbins a écrit :
> On 2 Feb 2015, at 19:53, Michael Hallgren wrote:
>
>> Real life limitations?
> <https://app.box.com/s/a3oqqlgwe15j8svojvzl>

Right ;-) Among many other nice ones, I like:

`` ‘IPS’ devices require artificially-engineered topological symmetry-
can have a
 negative impact on resiliency via path diversity.''

Cheers,

mh

>
> ---
> Roland Dobbins 

Re: Checkpoint IPS

[Michael Hallgren]

Le 04/02/2015 17:07, Eugeniu Patrascu a écrit :
> On Tue, Feb 3, 2015 at 5:41 PM, Michael Hallgren  <mailto:m.hallg...@free.fr>> wrote:
>
> Le 03/02/2015 16:21, Eugeniu Patrascu a écrit :
>> On Mon, Feb 2, 2015 at 2:53 PM, Michael Hallgren
>> mailto:m.hallg...@free.fr>> 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.

I know. However, I fail to see symmetric traffic flow as ``natural'',
apart from maybe at the extreme edge of a network. So, need another
inspection strategy I think.

Thanks,

mh

Re: Checkpoint IPS

[Michael Hallgren]

Le 03/02/2015 16:21, Eugeniu Patrascu a écrit :
> On Mon, Feb 2, 2015 at 2:53 PM, Michael Hallgren  <mailto:m.hallg...@free.fr>> 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.


Cheers,

mh

Checkpoint IPS

[Michael Hallgren]

Hi,

Someone has positive or negative experience running
Checkpoint IPS cluster over ``long distance'' synch.
network? Real life limitations? Alternatives? Timers?

Cheers,

mh

Re: DDOS solution recommendation

[Michael Hallgren]

Le 11/01/2015 14:50, Patrick W. Gilmore a écrit :
> I agree with lots said here.
>
> But I've said for years (despite some people saying I am confused) that BCP38 
> is the single most important thing we can do to cut DDoS.
>
> No spoofed source means no amplification. It also stops things like Kaminsky 
> DNS attacks.
>
> There is no silver bullet. Security is a series of steps ("layers" as one 
> highly respected security professional has in his .sig). But the most 
> important layer, the biggest bang for the buck we can do today, is eliminated 
> spoofed source.
>
> Push on your providers. Stop paying for transit from networks that do not 
> filter ingress, put it in your RFPs, and reward those who do with contracts. 
> Make it economically advantageous to fix the problem, and people will.

+1
mh
>

Re: DDOS solution recommendation

[Michael Hallgren]

Le 11/01/2015 14:50, Patrick W. Gilmore a écrit :
> I agree with lots said here.
>
> But I've said for years (despite some people saying I am confused) that BCP38 
> is the single most important thing we can do to cut DDoS.
>
> No spoofed source means no amplification. It also stops things like Kaminsky 
> DNS attacks.
>
> There is no silver bullet. Security is a series of steps ("layers" as one 
> highly respected security professional has in his .sig). But the most 
> important layer, the biggest bang for the buck we can do today, is eliminated 
> spoofed source.
>
> Push on your providers. Stop paying for transit from networks that do not 
> filter ingress, put it in your RFPs, and reward those who do with contracts. 
> Make it economically advantageous to fix the problem, and people will.

+1
mh
>

Re: Anyone else having trouble reaching thepiratebay.se? AS39138

[Michael Hallgren]

Le 26/11/2014 18:51, Dominik Bay a écrit :
> On 11/26/2014 06:41 PM, Javier J wrote:
>> Its reachable from some places and not others.
> Maybe a partial outage.
>From France:

mh@home:~$ mtr --report thepiratebay.org
Start: Wed Nov 26 23:09:31 2014
HOST: homeLoss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.254  0.0%100.3   0.3   0.3   0.4   0.0

 29.|-- sl-st20-sj-0-0-0.sprintli 10.0%10  215.3 216.2 213.1 219.6   2.3
 30.|-- sl-china6-192107-0.sprint 10.0%10  455.9 461.0 455.9 464.5   3.0
mh@home:~$ 

Cheers,

mh

Re: Multicast Internet Route table.

[Michael Hallgren]

Le 02/09/2014 18:05, Mikael Abrahamsson a écrit :
> On Tue, 2 Sep 2014, Octavio Alvarez wrote:
>
>> I have never used interdomain multicast but I imagine the global
>> m-routing table would quickly become large.
>
> I have set up interdomain routing connecting both to a few peers and a
> Tier1 transit provider. Not many non-research networks to be seen.
>
> Also, since we didn't use it it kept breaking and I had to fix it
> every two years or so, where it probably had been down for months.
>
> I don't believe in Internet-wide multicast happening in current
> incarnation, it's just too fragile and too few people are using it. It
> wouldn't scale either due to all the state that needs to be kept.
>
Been there as well. Now, IPv6 mcast? ;-)

Cheers,
mh

Re: Urgent

[Michael Hallgren]

Le 19/08/2014 16:08, William Herrin a écrit :
> On Mon, Aug 18, 2014 at 3:57 PM, Michael Hallgren  wrote:
>> Le 18/08/2014 20:38, Jeroen van Aart a écrit :
>>>>>> -Original Message-
>>>>>> Contact for God, please reach out to me offlist.
>>>>>>
>>>>>> Regards,
>>>>>>  -AS666 NOC
>>>> --
>>> OP is a troll,
>> Sure? :-)
> Definitely.
>
> The message may _also_ have a forged sender. ;)

Yep, was joke/irony :-)

Cheers,
mh

>
> -Bill

Re: Urgent

[Michael Hallgren]

Le 18/08/2014 20:38, Jeroen van Aart a écrit :
> Scott Weeks wrote:
>>
 -Original Message-
 Contact for God, please reach out to me offlist.

 Regards,
  -AS666 NOC
>> --
>>
>>
>> ASN 666 is the US army.  I was curious a long time ago and looked it
>> up...  ;-)
>>
>> scott
>
> OP is a troll, 

Sure? :-)

mh


> best to ignore and block:
>
>
> Received: from sewer.dizum.com (sewer.dizum.com [194.109.206.211])
>  by mail.nanog.org (Postfix) with ESMTP id B38322D429D
>  for ; Mon, 18 Aug 2014 17:00:30 + (UTC)
> Received: by sewer.dizum.com (Postfix, from userid 1001)
>  id 2A28B6087A; Mon, 18 Aug 2014 19:00:29 +0200 (CEST)
> Comments: This message did not originate from the Sender address above.
>  It was remailed automatically by anonymizing remailer software.
>  Please report problems or inappropriate use to the
>  remailer administrator at .
>
>

Re: Muni Fiber and Politics - ENDGAME

[Michael Hallgren]

Le 22/07/2014 20:34, Mikael Abrahamsson a écrit :
> On Tue, 22 Jul 2014, Jay Ashworth wrote:
>
>> You can assume $8-1200 per passing, if you fiber the entire town at
>> once (my example was 12000 passings, 3-pr, in 2.3 sqmi).  Then you're
>> going to have to operate the core, which will take power and at least
>> 5 people to man it 24/7.  And finally, figure on at least 4-6
>> multi-10GE uplinks, and those things don't exactly grow on trees --
>> there's no sense in providing 1G/1G if people can't actually use it.
>
> We only want them to run the L1 network, not L2.
>
>> And where's that money come from?  Yup: local taxes, mostly property.
>
> Stockholm municipal fiber (L1 only) has been operating fiber network
> since 1994, they're doing ~20MUSD profit on ~100MUSD turnover per year.

;-)

mh

Re: Net Neutrality...

[Michael Hallgren]

Le 16/07/2014 17:45, Eric Brunner-Williams a écrit :
> On 7/16/14 7:50 AM, Fred Baker (fred) wrote:
>> Relevant article by former FCC Chair
>>
>> http://www.washingtonpost.com/posteverything/wp/2014/07/14/this-is-why-the-government-should-never-control-the-internet/
>>
>
> It reads like a hit piece (by a Republican "free markets" ideologue)
> on a (Progressive) Democratic primary candidate for Lt. Governor of
> New York, not like a reasoned case by an informed policy analyst.
>
> YMMV, of course.

I tend to agree ;-) Now, what's the ops content of this discussion?
Might be a better choice to reroute this discussion
to a suitable ISOC forum? I don't judge, but I think the debate is of
great value, but not necessarily ``here'', but rather
``there''?---see you there? ;-)

Cheers,

mh

> Eric

Re: Help with Confederation-RR-MPBGP

[Michael Hallgren]

Le 18/06/2014 18:31, Philip Lavine a écrit :
> I guess my question is (sorry MPLS speak ahead)
No harm, me I've always rather consifered MPLS as a service provider
(like VPN, etc).

>  with 4 PE's on the edge running MP-BGP and ISIS & 4 P's in the
> core running ISIS, is it best practice to confederate or use a route
> reflector and make the PE's clients.

MP-BGP for VPN, I guess? Or am I missing something in your case? If so,
you use MPLS for services, right? Where
do you hook up to 'the Internet'?

This aside, I'd go the confederation way (only?) in case I see a
potential future need to do amounts of by destination
routing also within my network. I'd find it nicer than rushing down the
RSVP lane (pending SR :-)) Makes some sense
to you?

>
> Basically I want to know what an ISP would do, not a test in a LAB.
>
>

Me, rarely had a lab for these kind of things, but quite often networks :-)

Cheers,

mh

>
> On Thursday, June 12, 2014 2:45 PM, Michael Hallgren
>  wrote:
>  
>
>
> Le 12/06/2014 18:39, valdis.kletni...@vt.edu
> <mailto:valdis.kletni...@vt.edu> a écrit :
>
> > On Thu, 12 Jun 2014 09:25:20 -0700, Philip Lavine said:
> >> need some guidance on best practices
> >
> > What the vendor says is best practices, or what people in the trenches
> say?
> >
> >> Is it more efficient to use RR or Confederation?
> >
> > If option A is 2% more "efficient" than option B, but takes 10%
> longer to
> > deploy and causes 3% more SLA payouts to your customers when the added
> > complexity causes a whoopsie, how much more work could you have gotten
> done in
> > the time you spent in an uncomfortable meeting explaining to upper
> management
> > why the whoopsie happened?
> >
> > (Sorry, it's been that sort of week :)
>
>
> :-)
>
> Now, Philip, I think along the same path as Vladis: it depends... What
> does
> your physical or layer 2 network look like? How do you expect packets to
> move around inside, and in and out, of that topology? You need policing?
> How much and of what, etc, etc...?
>
> I'm quite often a fan of confed's, if the network is young thus ``easy''
> migration, but there are scenarios... Please provide more detail to this
> mail
> thread or one-to-one if you prefer.
>
> Cheers,
>
> mh
>
> >
>
>
>
>

Re: Help with Confederation-RR-MPBGP

[Michael Hallgren]

Le 12/06/2014 18:39, valdis.kletni...@vt.edu a écrit :
> On Thu, 12 Jun 2014 09:25:20 -0700, Philip Lavine said:
>> need some guidance on best practices
>
> What the vendor says is best practices, or what people in the trenches
say?
>
>> Is it more efficient to use RR or Confederation?
>
> If option A is 2% more "efficient" than option B, but takes 10% longer to
> deploy and causes 3% more SLA payouts to your customers when the added
> complexity causes a whoopsie, how much more work could you have gotten
done in
> the time you spent in an uncomfortable meeting explaining to upper
management
> why the whoopsie happened?
>
> (Sorry, it's been that sort of week :)

:-)

Now, Philip, I think along the same path as Vladis: it depends... What does
your physical or layer 2 network look like? How do you expect packets to
move around inside, and in and out, of that topology? You need policing?
How much and of what, etc, etc...?

I'm quite often a fan of confed's, if the network is young thus ``easy''
migration, but there are scenarios... Please provide more detail to this
mail
thread or one-to-one if you prefer.

Cheers,

mh
>

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

[Michael Hallgren]

Le 03/05/2014 20:23, Mikael Abrahamsson a écrit :
> On Sat, 3 May 2014, Vitkovský Adam wrote:
>
>> Sure it's a different transport protocol altogether, anyways It's
>> interesting to see how everybody tends to separate the IPv4 and IPv6
>> AFs onto a different TCP sessions and still run the plethora of other
>> AFs on the common v4 TCP session, maybe apart from couple of the big
>> folks, who can afford running separate control-plane and edge
>> infrastructure for some of the AFs, IPv6 AF being the first ran
>> separately.
>
> I know lots of people who run vpnv4 separately from ipv4 and ipv6 (so
> they have 3 sessions). The ones I talked to intends to run vpnv6
> separately as well.
>

Voilà ! Question is rather ``why not''?... once you decide to support
services...

mh

Re: misunderstanding scale

[Michael Hallgren]

Le 22/03/2014 23:49, Nick Hilliard a écrit :
> On 22/03/2014 19:35, Justin M. Streiner wrote:
>> CGN also comes with lots of downside that customers are likely to find
>> unpleasant.  For some operators, customer (dis)satisfaction might be the
>> driver that ultimately forces them to deploy IPv6.
> don't believe for a moment that v6 to v4 protocol translation is any less
> ugly than CGN.
Shared view.
mh
>
> Nick
>
>

Re: BGP multihoming with two address spaces

[Michael Hallgren]

Le 29/01/2014 20:34, Owen DeLong a écrit :
>> This sort of local-pref default seems to be a common practice with
>> backbones. It's very annoying. I wish they'd stop.
> Most of their customers would actually be very unhappy if they stopped. This 
> local-pref default prevents many many problems and in the vast majority of 
> cases provides the desired result. Yes, it's important to know what is going 
> on and to be able to ask your providers to make necessary changes in 
> circumstances where this is not optimal (either via community or ticket), but 
> I assure you that if every backbone turned this off suddenly, most internet 
> users would be very !HAPPY.

The underlying reason for this type of local preference has to do with
an assumption of cost
(which, given current transit prices, may be true or not):

cost(customer) < 0 < cost(peer) < cost(provider) ..., thus

local_pref(customer) > local_pref(peer) > local_pref(provider),

and as you say Owen, many actors sharing a policy simplifies our view of
things a bit. Another
way of assigning local preference of a route may factor in measured or
perceived path quality,
slightly more complex, but not a crime at all :-).

Cheers,
mh


>
> Owen
>
>

Re: best practice for advertising peering fabric routes

[Michael Hallgren]

Le 15/01/2014 07:59, Eric A Louie a écrit :
> Ok, so the right way to do it is in iBGP.  That pretty much answers the 
> question - don't redistribute those ixp-participant prefixes into my IGP.

Yes, using next-hop self (rather than importing IXP routes) as pointed
out earlier in this thread.

>
> I have a lot of iBGP homework to do, to make it work with the 5 POPs that are 
> all taking full route feeds.  I tried once and couldn't get the BGP tables 
> working correctly with a full mesh of the 5 routers, so it looks like time to 
> try it again, this time with a route reflector.  
>

I don't think you need route-reflection in a 5 node iBGP. What do you
mean by "couldn't get the BGP
tables working correctly"?

Cheers,

mh

>
>
>
>> 
>> From: Christopher Morrow 
>> To: Eric A Louie  
>> Cc: Patrick W. Gilmore ; NANOG list  
>> Sent: Tuesday, January 14, 2014 10:37 PM
>> Subject: Re: best practice for advertising peering fabric routes
>>
>>
>> On Wed, Jan 15, 2014 at 1:22 AM, Eric A Louie  wrote:
>>> Thank you - I will heed the warning.  I want to be a good community member 
>>> and make sure we're maintaining the agreed-upon practices (I'll 
>>> re-read/review my agreement with the IXP)
>>>
>>>
>>> So if that is the case, I have to rely on the peering fabric to just return 
>>> traffic, since the rest of my network (save the directly connected router) 
>>> will not know about those routes outbound?  And what about my customers who 
>>> are counting on me routing their office traffic through my network into the 
>>> peering fabric to their properties?  (I have one specifically who is 
>>> eventually looking for that capability)  Do I have to provide them some 
>>> sort of VPN to make that happen across my network to the peering fabric 
>>> router?
>>>
>> perhaps I'm confused, but you have sort of this situation:
>>   ixp-participants -> ixp -> your-router -> your-network -> your-customer
>>
>> you get routes for ixp-participants from 'ixp'
>> you send to the 'ixp' (and on to 'ixp-participants') routes for
>> 'your-customer' and 'your-network'
>>
>> right?
>>
>> then so long as you send 'your-customer' the routes you learn from
>> 'ixp' (which you set 'next-hop-self' on in ibgp from 'your-router' to
>> 'your-network' (in the ibgp-mesh that you will setup) ... everything
>> just works.
>>
>> All routers behind 'your-router' in 'your-netowrk' see
>> 'ixp-participants' with a next-hop of 'your-router' who still knows
>> 'send to ixp!' for the route(s) in question.
>>
>>>
>>>
 
 From: Patrick W. Gilmore 
 To: NANOG list 
 Sent: Tuesday, January 14, 2014 7:11 PM
 Subject: Re: best practice for advertising peering fabric routes


 Pardon the top post, but I really don't have anything to comment below 
 other than to agree with Chris and say rfc5963 is broken.

 NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An 
 IXP LAN should not be reachable from any device not directly attached to 
 that LAN. Period.

 Doing so endangers your peers & the IX itself. It is on the order of not 
 implementing BCP38, except no one has the (lame, ridiculous, idiotic, and 
 pure cost-shifting BS) excuse that they "can't" do this.

 --
 TTFN,
 patrick


 On Jan 14, 2014, at 21:22 , Christopher Morrow  
 wrote:

> On Tue, Jan 14, 2014 at 9:09 PM, Cb B  wrote:
>> On Jan 14, 2014 6:01 PM, "Eric A Louie"  wrote:
>>> I have a connection to a peering fabric and I'm not distributing the
>> peering fabric routes into my network.
> good plan.
>
>>> I see three options
>>> 1. redistribute into my igp (OSPF)
>>>
>>> 2. configure ibgp and route them within that infrastructure.  All the
>> default routes go out through the POPs so iBGP would see packets destined
>> for the peering fabric and route it that-a-way
>>> 3. leave it "as is", and let the outbound traffic go out my upstreams 
>>> and
>> the inbound traffic come back through the peering fabric
>>>
> 4. all peering-fabric routes get next-hop-self on your peering router
> before going into ibgp...
> all the rest of your network sees your local loopback as nexthop and
> things just work.
>
>>> Advantages and disadvantages, pros and cons?  Recommendations?
>> Experiences, good and bad?
>>>
>>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the
>> POPs yet.  That's another issue completely from a planning perspective.
>>> thanks
>>> Eric
>>>
>> http://tools.ietf.org/html/rfc5963
>>
>> I like no-export




>>
>>

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

[Michael Hallgren]

+1, I fully agree. And not only concerning the "domestic" use by country, but 
also with regards to "information peering" with neighbors, and such. 

Enjoy '14! 

mh

 Message d'origine 
De : Ray Soucy  
Date :  
A : Blair Trosper  
Cc : "nanog@nanog.org list"  
Objet : Re: NSA able to compromise Cisco, Juniper, Huawei switches 
 
I think there needs to be some clarification on how these tools get used,
how often they're used, and if they're ever cleaned up when no longer part
of an active operation.  Of course we'll never get that.

The amount of apologists with the attitude "this isn't a big deal, nothing
to see here, the NSA does this kind of thing" is kind of shocking for this
community; especially with the information that's been released over the
past few months.

This whole backdoor business is a very, very, dangerous game.




On Tue, Dec 31, 2013 at 12:19 AM, Blair Trosper wrote:

> To supplement and amend what I said:
>
> These are the KINDS of things we want the NSA to do; however, the
> institutional oversight necessary to make sure it's Constitutional,
> warranted, and kept "in bounds" is woefully lacking (if any exists at all).
>  Even FISA is unsatisfactory.
>
> At any rate, I agree that the current disposition of the NSA (or, at least,
> what's been leaking the last few months) is simply unacceptable and cannot
> be allowed.  I say that last part from the perspective of a US citizen,
> though I'd imagine most people of other nationalities would agree with me,
> but probably for different reasons.
>
>
> On Mon, Dec 30, 2013 at 11:08 PM, Jimmy Hess  wrote:
>
> > On Mon, Dec 30, 2013 at 10:41 PM, Blair Trosper  >wrote:
> >
> >> I'm torn on this.  On one hand, it seems sinister.  On the other, it's
> not
> >> only what the NSA is tasked with doing, but it's what you'd EXPECT them
> to
> >> be doing in the role as the NSA.
> >>
> > [snip]
> >
> > The NSA's role is not supposed to include subterfuge and undermining the
> > integrity or security of domestic enterprise infrastructure
> >
> > With any luck, we'll hopefully find absolutely nothing, or that it was
> > "targetted" backdooring against specific targets only.
> >
> > And people have a need to know that the security agencies haven't left a
> > trail of artificially inserted bugs and backdoors in common IT equipment
> > providing critical infrastructures services,  and that the agencies
> haven't
> > prepared a collection of instant-root 0days,  that are no more protected
> > then the agencies' other poorly guarded "secrets".
> >
> > There would be a risk that any 'backdoors' are ready to be exploited by
> > other unintended nefarious actors!
> > Because the NSA are apparently  great at prepping the flammables and
> > setting fires,    but  totally incapable of  keeping the fires contained,
> > once they  (or someone else)  lights it.
> >
> >
> > It is not the least bit necessary for the NSA itself to be a nefarious
> > actor  exploiting things or even complicit;  for the mere presence of
>  any
> > backdoor or surreptitious code to eventually have the potential for
> serious
> > damage.
> >
> > It could well be a rogue ex-employee of the NSA, such as Snowden,  or
> > others,  that happened to be aware of technical details, hackers, or
> > members of a foreign nation state,  who will just happen to have the time
> > and energy to track down open doors waiting for the taking,  AND  figure
> > out how to abuse them  for evil purposes.
> >
> >
> > There are enough potential 0day risks, without intentional ones,  waiting
> > for bad guys to co-opt!
> >
> > --
> > -JH
> >
>



-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

Re: prefix filtering per IRR - practices

[Michael Hallgren]

Le 22/11/2013 17:57, Chris Rogers a écrit :
> From my experience, networks that are capable of filtering from IRR objects
> generally filter for exact routes, meaning no "le 24". 

Hi,

Are you sure? My experience is, with a small number of exceptions,
that "le 24" ('route' or 'route-set,' sometimes in relation with "is in
AS-set of peer") is an often used policy. Maybe it depends on what
kind of networks one's looking at? 

Cheers,
mh

> While I've always
> found networks to be set in their ways, I know some people that have
> managed to get their filters changed to allow longer prefixes without
> needing additional objects.
>
> But ultimately, it does help prevent the leaking of internal routes.
>
> -Chris
>
> On Fri, Nov 22, 2013 at 6:55 AM, Frank Habicht  wrote:
>
>> Hi,
>>
>> I have a question regarding what's the most common practice [1]
>> for transit ASs to filter prefixes from their BGP customers
>> when using IRR data. (which of course everyone does...)
>>
>> Would many/most/all/none :
>> a) accept only the prefixes listed in route objects
>> or
>> b) accept these and anything "upto /24" (or "le 24")
>>
>> I was hoping / assuming the latter but I start getting a different
>> impression.
>> Yep, and apart from the current status, the tendency would be of interest.
>>
>> Thanks,
>> Frank
>>
>> [1] after "my network, my rules"
>>
>>

Re: Fundamental questions of backbone design

[Michael Hallgren]

Le 18/10/2013 20:03, Anurag Bhatia a écrit :
> Hello everyone
>
>
> I have some fundamental questions about backbone design. Feel free to point
> me to any discussions/presentation material related to these questions.
>
>
>
>1. As I understand it's (sort off) common practice to give highest
>localpref to customer routes then peering and finally transit. Does this
>works well or you see issues with people who have 10+ prepends on some
>peering routes calling you to not send traffic via those circuits? Does it
>makes sense to put a rule to avoid routes 2-3 AS path away when changing
>local preference?

Most often, the (``traditionally'' business driven) classification that you
mention is honored and subtler differences considered (only) in cases
where LOCAL_PREFerence is the same for some candidate routes to a
destination.

There's no ``protocol law'' ruling this, it's all your choice, that you may
base on cost, performance, or any other type of metrics that you feel
relevant... For example, you may want -- as you say -- honor the hints
from neighbors (even transitively) to route over ``less prepended
paths'' (if available) to their networks. But it's up to you, and I'd
suggest
keeping a focus on performance, path stability, neighbours reactivity
in case of failure, or some such (if you can afford it) as a metric.
Else...

>
>2. If I have more peering capacity and relatively less capacity between
>my own PoPs and I start injecting routes in my IGP then how to prevent
>change of choking of backbone? Is it standard practice to have more
>capacity on backbone then peering links? Or I have to inject less routes in
>IGP - say a few % of total routes?

What routes do you inject into your IGP? Generally, it's nice to keep
IGP being merely a logical view of your graph of links, and keep
foreign/other routes in (i)BGP. Then, you need to take a look at the
distribution of your peering sessions over your sites with respect to
your customer sessions. Etc, etc,...

Backbone capacity versus peering capacity, depends on your mix
of peers, customers, providers...

>
>3. How can I maintain use of routes I am learning from various other
>networks (transit+peers+customer) across my IGP? Is BGP community tagging
>good way out?

See above, if I understand your question correctly.

>
>4. How is iBGP Vs OSPF for IGP? I keep on hearing that OSPF is good &
>lot more faster in changing routes during a breakdown as compared to slow
>hold time based iBGP session. Is there's more clear comparison of
>limitations of both when designing?
>

Get in touch off-list, if you feel like?

Cheers,

mh

>
> Appreciate your time & help.
>
>
>
> Thanks.
>

Re: Policy-based routing is evil? Discuss.

[Michael Hallgren]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 11/10/2013 19:41, joel jaeggli a écrit :
>
> On Oct 11, 2013, at 10:27 AM, 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
>
> it's brittle
>
>>  - None of the usual debugging tools work properly
>>  - Adding a new user is complicated because it has to be done in (at
>>least) two places
>>
>
> you take all the useful information that an IGP could be (or is)
providing you, and then you ignore it and do something else.

I like that phrase. ;-)

mh
>
>
>> But I'm having a distinct lack of success locating rants and diatribes
>> or even well-reasoned articles supporting this opinion.
>>
>> Am I out to lunch?
>
> evil is not a synonym for ugly patch placed over a problem that could
be handled better. If it's being used as an alternative to VRF, it isn't.
>
>>
>> -w
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJYPfUACgkQZNZ/rrgsqad+uQCgmQlT3kz8F6QrsYZe8SJmlrvJ
k4MAn2CwQIOJF8vm1yXTsJh0vZR/cOVi
=L+tx
-END PGP SIGNATURE-

Re: Someone from PCCW NOC here ?

[Michael Hallgren]

Le 02/10/2013 19:43, Christopher Morrow a écrit :
> I am shocked that a pccw customer isn't being prefix-filtered.

Ohhh, they're rare bird?

(
I'd hope so, rare bird; and I do strongly agree that (at least) these birds
-- customer-routes -- should live in a transparent community... IRR
(well...),
(or for those who believe) RPKI :-)
)

Thoughts?

Cheers,
mh
>
> On Wed, Oct 2, 2013 at 11:54 AM, Carlos Martinez-Cagnazzo
>  wrote:
>> Hi all,
>>
>> We'd appreciate having someone from PCCW, particularly from their operation
>> in Panama, having contact us. Private is fine.
>>
>> A downstream customer from them in Panama has been observed hijacking some
>> prefixes.
>>
>> regards
>>
>> ~Carlos
>>
>> --
>> --
>> =
>> Carlos M. Martinez-Cagnazzo
>> h ttp://cagnazzo.me
>> =

Re: common method to count traffic volume on IX

[Michael Hallgren]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 17/09/2013 20:15, Patrick W. Gilmore a écrit :
> On Sep 17, 2013, at 12:11 , Martin T  wrote:
>
>> Thanks for all the replies!
>>
>>
>> Nick,
>>
>> counting traffic on inter-switch links is kind of cheating, isn't it?
>> I mean if "input bytes" and "output bytes" on all the ports facing the
>> IX members are already counted, then counting traffic on links between
>> the switches in fabric will count some of the traffic multiple times.
>>
>>
>>
>> Patrick,
>>
>> how does smaller sampling period help to show more traffic volume on
>> switch fabric? Or do you mean that in case of shorter sampling periods
>> the traffic peaks are not averaged out and thus peak in and peak out
>> traffic levels remain higher?

Hi,

Good reading, to get an idea:

https://www1.ethz.ch/csg/people/dimitroc/papers/p95pam.pdf

Section 3, mainly.

Cheers,

mh

>>
>
> The graph has a bigger peak, and DE-CIX has claimed "see, we are
bigger" using such graphs. Not only did they not caveat the fact they
were using a non-standard sampling method, they have refused to change
when confronted or even say what their traffic would be with a 300
second timer.
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlI45K0ACgkQZNZ/rrgsqaeSAQCfR93/ksBGa1KRW6P6zLR2cRwG
2fEAnRlZMtamameFoQgVdYZwTKD7Lb1b
=UVol
-END PGP SIGNATURE-

Re: common method to count traffic volume on IX

[Michael Hallgren]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 17/09/2013 20:15, Patrick W. Gilmore a écrit :


Hi,

Good reading, to get an idea:

https://www1.ethz.ch/csg/people/dimitroc/papers/p95pam.pdf

Section 3, mainly.

Cheers,

mh



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlI45KgACgkQZNZ/rrgsqae9JQCghTqXy8+bL6eq95ZD/DHvbTCx
izwAniJ1Fiq1zsbZmewT464eG/S4RinZ
=R+r3
-END PGP SIGNATURE-

Re: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty

[Michael Hallgren]

Le 09/09/2013 21:16, Joe Abley a écrit :
> On 2013-09-09, at 14:29, joel jaeggli  wrote:
>
>> On 9/9/13 7:43 AM, Jason Lixfeld wrote:
>>> That notwithstanding, it's stupid to send traffic to/from one of the
>>> large $your_region/country incumbents via $not_your_region/country.
>>> It's just not good Internet. 
>> yyz-yvr is faster via the united states. physics doesn't respect
>> poltical boundries.
> Not only physics, but geometry. Vancouver is further north than Seattle, but 
> Toronto is further south than Portland.
>
> http://www.gcmap.com/mapui?P=YYZ-YVR

Fiber path along great circle? Cool case. :)

mh

>
>
> Joe
>
>

Re: Is the FBI's DNSSEC broken?

[Michael Hallgren]

Le 03/09/2013 23:28, John Levine a écrit :
>>> On Fri, Aug 30, 2013 at 10:27:36PM +, John Levine wrote:
 I don't claim to be a big DNSSEC expert, but this looks just plain
 wrong to me, and unbound agrees, turning it into a SERVFAIL.
> I heard back, seems like I found someone at the FBI who was able to
> explain the problem to Neustar (DNS software provider) who say they
> will fix it.

So, what was the problem then?

Cheers,

mh
>
> R's,
> John
>

Re: huawei

[Michael Hallgren]

Le 13/06/2013 18:22, Randy Bush a écrit :
>> I've always wondered about thatwould you know that the Huawei is
>> leaking data?
> yes.  they have a contract to leak it to the NSA

:-)

mh

>

Re: PRISM: NSA/FBI Internet data mining project

[Michael Hallgren]

Le 09/06/2013 20:26, Rob McEwen a écrit :
> Dan,
>
> I doubt anyone can answer your question easily because you seem to have
> contradictions in your scenario. At one point you say:
>
>> private company to collect information about terrorist entities, who
>> in turn privately contracts with the top X telecom providers and Y
>> social media companies
> but then you continue:
>> to obtain all available information that it can, via TAP ports or
>> direct database access.
> and then:
>> That private organization, through analysis, knows a lot about you
> I'm confused, in your scenario, is the data collection limited to
> "terrorist entities", or does your statement, "all available information
> that it can" mean that it gets everyone's info, and then does their
> filtering later?
>
> Additionally, one would hope that by "terrorist entities", you would be
> referring to those who plan on hurting or killing innocent people,
> whether that be an Islamofactist terrorist planning to blow up a
> government building, or a right wing terrorist planning to do the same
> (for different reasons), or a environmentalists planning to sink a legal
> whaling boat, or a anti-abortionist planning to blow up an abortion
> clinic... take your pick. The point being that mass-killing of innocent
> people is the common thread... NOT the politics. And I hope that you
> haven't downward defined this to someone that could be easily used to
> "pick off" political opponents, right?
>
>> Have your 4th Amendment rights been abridged in this scenario
> Sorry if this comes across as rude or snobby, but I think you just need
> to read the 4th Amendment about 20 times to yourself and let it all soak in.
>
> TO ANSWER YOUR QUESTION:
> If the Federal Government is paying a private entity to do the snooping,
> then they are a defacto agent of the state. That doesn't make the 4th
> amendment apply any less applicable. Even then, to abide by the 4th
> amendment, there should be SPECIFIC persons/orgs AND specific info/items
> that are being searched where that search is SPECIFICALLY approved by a
> judge or court IN ADVANCE (no super wide "blanket" approvals, no broad
> fishing expeditions)... only THEN does the searching for the information
> meet 4th amendment requirements. The fact that the search was of your
> e-mail or phone records doesn't make the 4th amendment apply any less
> than if they were looking inside the drawer in the nightstand next to
> your bed!
>
> There are notable exceptions... for example, an employer is really the
> owner of the mailbox, not their employee. Therefore, there is an
> argument that government employees don't have "privacy rights" from the
> government for their official work e-mail accounts. There are probably
> several other exceptions like that. But such exceptions are a tiny
> percentage of the whole.

Right. And among these exceptions we (still) find, at least in some
European countries, the notion of a private sphere also in your
professional role. Summing up to that a reasonable amount and
type of private communications (for instance, with your bank,
childcare, tax office, family, friends, and other with whom you may
share urgency as well as office hours and inability of relying
efficiently on end-to-en encryption) are likely to happen, and
expected to be honored as private, also via your professional
communication channels. I think that, in France for instance, you
flag these communications by tagging them 'private/perso' or
similar and legally expect them to be treated as such. I may
stand corrected?

A word about a small, yet significant I think, piece in a quite complex
puzzle...

Cheers,

mh

>

RE : Re: PRISM: NSA/FBI Internet data mining project

[Michael Hallgren]

Yet appears a certain lack of transparency, no? 
mh 

 Message d'origine 
De : "Jason L. Sparks"  
Date :  
A : ku po  
Cc : NANOG  
Objet : Re: PRISM: NSA/FBI Internet data mining project 
 
To be fair, the reporting (initially) claimed the providers were granting the 
USG "access directly to their servers."  It's understandable and appropriate 
that the providers pushed back against that apparently erroneous reporting. 

Jason

On Jun 8, 2013, at 22:44, ku po  wrote:

> What is the point to argue whether they have the capacity to process all
> the data?
> They DON'T need to build expensive systems.
> They just need to make sure when they ask your company for information,
> these information are available for them and fast enough.
> So the statement that saying "we don't give them direct access" means
> nothing!!!
> The right question is IS THERE A DIRECT CHANNEL for them to ask you for
> information without providing all the evidence( how could they show you all
> the evidence when it is security related??),  which you can't deny their
> access.
> 
> 
> 
> 
> On Sun, Jun 9, 2013 at 8:20 AM, James Harrison 
> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>> 
>> On 08/06/2013 16:31, William Herrin wrote:
>>> On Fri, Jun 7, 2013 at 1:25 AM, jamie rishaw  wrote:
 Just wait until we find out dark and lit private fiber is getting
 vampired.
>>> 
>>> Why wait?
>>> 
>>> http://www.nytimes.com/2005/02/20/politics/20submarine.html?_r=0
>>> 
>>> -Bill
>> 
>> In a similar vein, a new PRISM slide was released by the Guardian this
>> morning:
>> 
>> 
>> http://www.guardian.co.uk/world/2013/jun/08/nsa-prism-server-collection-facebook-google
>> 
>> Doesn't specifically say private fiber - just "fiber cables and
>> infrastructure". May just refer to fiber to/from/within complying
>> company infrastructure, ofc, not necessarily anything else.
>> 
>> They also apparently have a web 2.0 compliant dashboard with a catchy
>> name and pop-ups with big numbers in: Boundless Informant.
>> 
>> 
>> http://www.guardian.co.uk/world/2013/jun/08/nsa-boundless-informant-global-datamining
>> 
>> Speaking from the other side of the pond it's interesting to see where
>> this is going. GCHQ (the UK NSA equivalent) are being asked stern
>> questions by the government about their involvement and if they've
>> been asking the NSA for UK citizens' data (since they're not allowed
>> to collect it themselves).
>> 
>> Cheers,
>> James Harrison
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2.0.17 (MingW32)
>> 
>> iEYEARECAAYFAlGzyl4ACgkQ22kkGnnJQAwVfQCePSYz9p5P95bnWYbp4YA2SeQD
>> HeQAn0AOnReV6DQC0Y3k5P046BbFnBUJ
>> =auDI
>> -END PGP SIGNATURE-
>> 
>> 

Re: PRISM: NSA/FBI Internet data mining project

[Michael Hallgren]

Le 07/06/2013 19:10, Warren Bailey a écrit :
> Five days ago anyone who would have talked about the government having this 
> capability would have been issued another tin foil hat. We think we know the 
> truth now, but why hasn't echelon been brought up? I'm not calling anyone a 
> liar, but isn't not speaking the truth the same thing?


;-)

mh

>
>
> Sent from my Mobile Device.
>
>
>  Original message 
> From: Matthew Petach 
> Date: 06/07/2013 9:34 AM (GMT-08:00)
> To:
> Cc: NANOG 
> Subject: Re: PRISM: NSA/FBI Internet data mining project
>
>
> On Thu, Jun 6, 2013 at 5:04 PM, Matthew Petach wrote:
>
>>
>> On Thu, Jun 6, 2013 at 4:35 PM, Jay Ashworth  wrote:
>>
>>> Has fingers directly in servers of top Internet content companies,
>>> dates to 2007.  Happily, none of the companies listed are transport
>>> networks:
>>>
>>>
>>> http://www.washingtonpost.com/investigations/us-intelligence-mining-data-from-nine-us-internet-companies-in-broad-secret-program/2013/06/06/3a0c0da8-cebf-11e2-8845-d970ccb04497_story.html
>>>
>>> Cheers,
>>> -- jra
>>> --
>>> Jay R. Ashworth  Baylink
>>> j...@baylink.com
>>> Designer The Things I Think   RFC
>>> 2100
>>> Ashworth & Associates http://baylink.pitas.com 2000 Land
>>> Rover DII
>>> St Petersburg FL USA   #natog  +1 727
>>> 647 1274
>>>
>>>
>> I've always just assumed that if it's in electronic form,
>> someone else is either reading it now, has already read
>> it, or will read it as soon as I walk away from the screen.
>>
>> Much less stress in life that way.  ^_^
>>
>> Matt
>>
>>
> When I posted this yesterday, I was speaking somewhat
> tongue-in-cheek, because we hadn't yet made a formal
> statement to the press.  Now that we've made our official
> reply, I can echo it, and note that whatever fluffed up
> powerpoint was passed around to the washington post,
> it does not reflect reality.  There are no optical taps in
> our datacenters funneling information out, there are no
> sooper-seekret backdoors in the software that funnel
> information to the government.  As our formal reply
> stated: "Yahoo does not provide the government with
> direct access to its servers, systems, or network."
> I believe the other major players supposedly listed
> in the document have released similar statements,
> all indicating a similar lack of super-cheap government
> listening capabilities.
>
> Speaking just for myself, and if you quote me on this
> as speaking on anyone else's behalf, you're a complete
> fool, if the government was able to build infrastructure
> that could listen to all the traffic from a major provider
> for a fraction of what it costs them to handle that traffic
> in the first place, I'd be truly amazed--and I'd probably
> wonder why the company didn't outsource their infrastruture
> to the government, if they can build and run it so much
> more cheaply than the commercial providers.  ;P
> 7 companies were listed; if we assume the
> burden was split roughly evenly between them, that's
> 20M/7, about $2.85M per company per year to tap in,
> or about $238,000/month per company listed, to
> supposedly snoop on hundreds of gigs per second
> of data.  Two ways to handle it: tap in, and funnel
> copies of all traffic back to distant monitoring posts,
> or have local servers digesting and filtering, just
> extracting the few nuggets they want, and sending
> just those back.
>
> Let's take the first case; doing optical taps, or other
> form of direct traffic mirroring, carrying it untouched
> offsite to process; that's going to mean the ability to
> siphon off hundreds of Gbps per datacenter and carry
> it offsite for $238k/month; let's figure a major player
> has data split across at least 3 datacenters, so about
> $75K/month per datacenter to carry say 300Gbps of
> traffic.  It's pretty clearly going to have to be DWDM
> on dark fiber at that traffic volume; most recent
> quotes I've seen for dark fiber put it at $325/mile
> for already-laid-in-ground (new builds are considerably
> more, of course).  If we figure the three datacenters
> are split around just the US, on average you're going
> to need to run about 1500 miles to reach their central
> listening post; that's $49K/month just to carry the
> bitstream, which leaves you just about $25K/month
> to run the servers to digest that data; at 5c/kwhr, a
> typical server pulling 300 watts is gonna cost you $11/month
> to run; let's assume each server can process 2Gbps of
> traffic, constantly; 150 servers for the stream of 300Gbps
> means we're down to $22K for the rest of our support
> costs; figure two sysadmins getting paid $10k/month
> to run the servers (120k annual salary), and you've got
> just $2k for G&A overhead.
>
> That's a heck of an efficient operation they'd have to be
> running to listen in on all the traffic for the supposed
> budget number claimed.
>
> I'm late for work; I'll follow up 

Re: Tier1 blackholing policy?

[Michael Hallgren]

Le 01/05/2013 14:46, David Miller a écrit :
> On 05/01/2013 05:40 AM, Thomas Schmid wrote:
>> Joel,
>>
>> Am 30.04.2013 18:00, schrieb joel jaeggli:
>>> On 4/30/13 8:23 AM, Thomas Schmid wrote:
 On 30.04.2013 17:07, Chris Boyd wrote:
> On Tue, 2013-04-30 at 10:59 -0400, ML wrote:
>> 1) Do nothing - They're supposed deliver any and all bits
>> (Disregarding
>> a DoS or similiar situation which impedes said network)
>> 2) Prefix filter - Don't be a party (at least in one direction) to
>> the
>> bad actors traffic.
> 3 - Deliver all packets unless I've signed up for an enhanced security
> offering?
>
 right - I see this really as something that should be decided at the
 edge
 of the internet (Tier2+) and not in the core.
>>> You seem to have odd ideas about what it means to be a settlement
>>> free provider. Most of their customers are not smaller internet
>>> service providers.
>> I know what it means to be a customer of
>> $LargeGlobalISPthatsellsTransittootherISPs since
>> 1995 and I have *never* seen one of these guys blackholing
>> single IPs on their own (and I'm not talking about RTB, botnet
>> controllers that threaten to kill
>> the internet etc.). Now since a few weeks we get regular complaints
>> about this. So something has changed.
>>
>> The sensitive approach would really be to make this an opt-in service
>> for their customers
>> and not a default service without opt-out option. In times of CGN and
>> hundrets or thousands of
>> websites behind one IP, blocking addresses is not the right answer to
>> the phishing problem.
>>
> ... or perhaps on an internet where many network owners block / police /
> throttle packets by source or destination, implementing CGN or stacking
> thousands of websites behind one IP address are poor solutions to the
> connectivity problem.
>
> My only issue is the lack of information provided when blocks go into
> place.  I would love to see networks provide information publicly that
> shows what is being blocked along with a description of why.  A history
> that extends for a few days would be a bonus.

I agree with that. While some blocking and policing may be judged
"good thing" there is a well-known potential for "other kinds" of
policing...

Cheers,
mh

>
> -DMM
>
>

Re: "It's the end of the world as we know it" -- REM

[Michael Hallgren]

Le 24/04/2013 21:35, Lee Howard a écrit :
>
> On 4/24/13 2:45 PM, "ML"  wrote:
>
>> On 4/23/2013 5:41 PM, Valdis Kletnieks wrote:
>>> I didn't see any mention of this Tony Hain paper:
>>>
>>> http://tndh.net/~tony/ietf/ARIN-runout-projection.pdf
>>>
>>> tl;dr: ARIN predicted to run out of IP space to allocate in August this
>>> year.
>>>
>>> Are you ready?
>>>
>>
>> Where do the startup ISPs whom didn't qualify for PI IPv4 in the past
>> fit into a post-run out world where they would qualify?
>> I am speaking in generics but also about a real ISP that is in this
>> situation today. 
>>
>> In my example This ISP could show need for a /22 but wasn't multihoming
>> at the time and likely will not until after run-out.
>> How does such an ISP begin to address their backbone and customers
>> facing interfaces without tying themselves to an ISP and their PA space?
>>
>> I don't imagine they will be open to paying extortion prices for IPs
>> that other people never bothered to use.
>
> Once ARIN is unable to meet an organization's justified need, they can't
> get addresses from ARIN.  They can beg, borrow or buy addresses from
> someone else.  They can try AfriNIC's or LACNIC's policies.  They can do
> CGN.  They can do IPv6.

Might be that IPv6would be their currently best bet... ;)
mh

>
> Lee
>
>
>

Re: Visio-fu

[Michael Hallgren]

Le 25/02/2013 23:15, Warren Bailey a écrit :
> I've seen smart draw. I wish these drawing software companies would port 
> their application over to mac.. Every big design guy I know is a mac fanboy, 
> Adobe has it figured out but smart draw and visio have no excuse. Omni is 
> about the only thing out there, but it is hell to use in my opinion. :)

Hell is quite structured in the TeX related list I just proposed. :)

mh
>
>
> From my Android phone on T-Mobile. The first nationwide 4G network.
>
>
>
>  Original message 
> From: Josh Baird 
> Date: 02/25/2013 2:10 PM (GMT-08:00)
> To: George Herbert 
> Cc: Warren Bailey ,North American 
> Network Operators Group 
> Subject: Re: Visio-fu
>
>
> Check SmartDraw.
>
> On Mon, Feb 25, 2013 at 5:04 PM, George Herbert 
> mailto:george.herb...@gmail.com>> wrote:
> On Mon, Feb 25, 2013 at 12:58 PM, George Herbert
> mailto:george.herb...@gmail.com>> wrote:
>> [...]
>> My company has a Visio whiz, who I'm going to ping for his opinion on
>> that, but I am guessing it's a no.
> Our Visio guy's opinion concurred with mine; it's custom drawing, not
> off-the-shelf capability, and would most likely have been in a
> graphics program (though he thinks it might have been possible with
> Visio, it would have been much easier in for example Illustrator).
>
>
> --
> -george william herbert
> george.herb...@gmail.com
>
>

Re: Visio-fu

[Michael Hallgren]

Le 25/02/2013 23:06, Josh Baird a écrit :
> Check SmartDraw.

pstricks, metapost, TikZ (pgf),...

mh

>
> On Mon, Feb 25, 2013 at 5:04 PM, George Herbert 
> wrote:
>
>> On Mon, Feb 25, 2013 at 12:58 PM, George Herbert
>>  wrote:
>>> [...]
>>> My company has a Visio whiz, who I'm going to ping for his opinion on
>>> that, but I am guessing it's a no.
>> Our Visio guy's opinion concurred with mine; it's custom drawing, not
>> off-the-shelf capability, and would most likely have been in a
>> graphics program (though he thinks it might have been possible with
>> Visio, it would have been much easier in for example Illustrator).
>>
>>
>> --
>> -george william herbert
>> george.herb...@gmail.com
>>
>>

Re: How are operators using IRR?

[Michael Hallgren]

Hi,

Some of the networks close to me, use IRR based AS_PATH and
prefix filters at customer-route import.

Needless to say that running periodic diffs between what's found in
IRR and what's received in RW and discuss the results with customers
is a necessary good thing to make sure that what is expected is
really happening. (And potentially a means to bump up the quality of
the IRR data set.)

Cheers,
mh


Le 17/01/2013 14:14, Phil Bedard a écrit :
> I have mainly worked at small and medium sized operators and we did not
> use IRR at all apart from registering our own and customer blocks with
> the one upstream provider we had (Level3) which required it. We
> maintained our own databases of customer prefixes tied to other
> customer information strict prefix lists were generated from. I have
> rarely seen as path filtering used except with large customers where
> maintaining strict prefix lists wasn't manageable.
>
> Phil From: ML
> Sent: 1/16/2013 19:57
> To: NANOG
> Subject: How are operators using IRR?
> How are operators using the data available in the various IRRs?
>
> Using an example:
>
> AS1 is your customer
> AS1 has AS2, AS3 and AS4 described as customers in an IRR
> Also assume AS2 has IRR data describing AS1000 and AS2000 as it's customers.
>
> Are operators building AS path regexes such as the following
> automatically from IRR and applying that to your BGP sessions?
>
> 
> AS1{1,}
> AS1{1,} AS2{1,}
> AS1{1,} AS3{1,}
> AS1{1,} AS2{1,} AS1000{1,}
> AS1{1,} AS2{1,} AS2000{1,}
> 
>
>
> I would imagine most operators that are building policy from IRR are
> building prefix lists to limit what they are accepting.  Is this being
> paired with some AS path filtering?
>
>
> Are operators just traversing an AS-SET as far as it will go and
> building prefix lists to represent all intended prefixes to be heard on
> a session regardless of who originates them? Is the possibility of
> AS1000 hijacking AS2000 prefixes towards AS2 a problem you as the
> upstream to AS1 need to consider? (Last question assumes AS2 made a
> mistake and wasn't filtering properly on it's own customers and AS1 is
> just accepting all prefixes under the cone of AS2)
>
> Thanks
>

Re: RFC becomes Visio

[Michael Hallgren]

Le mercredi 03 octobre 2012 à 07:31 -0400, Rodrick Brown a écrit :
> On Oct 3, 2012, at 7:26 AM, Brian Christopher Raaen
>  wrote:
> 
> 
> > The newest version of libreoffice draw can open Visio diagrams.
> > 
> > 
> 
> 
> Also Microsoft does provide a free Visio plugin/viewer for Internet
> Explorer. 
> 
> 
> http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=21701
> 


Can you also edit/write using these?

mh

> > ---
> > Brian Raaen
> > Zcorum
> > 
> > On Tue, Oct 2, 2012 at 5:43 PM, Michael Hallgren
> >  wrote:
> > > Le mardi 02 octobre 2012 à 23:25 +0200, Dan Luedtke a écrit :
> > > > On Fri, 2012-09-28 at 19:31 +0100, Nick Hilliard wrote:
> > > > > Here's a visio diagram you can send them:
> > > > > 
> > > > > http://www.foobar.org/~nick/bgp-network-diagram.vsd
> > > > 
> > > > Is there a .png version of it somewhere?
> > > > The whole thread made my day, I'm eager to see this diagram as
> > > > well.
> > > > I don't have this MS Visio thingy you all use to set up your
> > > > Avian
> > > > Carrier BGP sessions...
> > > 
> > > Don't use ``MS Visio thingy'', prefer TeX with metapost, PGF/TikZ
> > > (or
> > > PSTRicks). The output is by far more beautiful, and maintaining
> > > the
> > > document much more slim.
> > > 
> > > Cheers,
> > > mh
> > > 
> > > > 
> > > > Regards
> > > > 
> > > > Dan
> > > > 
> > > 
> > > 
> > > 
> > 
> > 

Re: RFC becomes Visio

[Michael Hallgren]

Le mardi 02 octobre 2012 à 23:25 +0200, Dan Luedtke a écrit :
> On Fri, 2012-09-28 at 19:31 +0100, Nick Hilliard wrote:
> > Here's a visio diagram you can send them:
> > 
> > http://www.foobar.org/~nick/bgp-network-diagram.vsd
> 
> Is there a .png version of it somewhere?
> The whole thread made my day, I'm eager to see this diagram as well.
> I don't have this MS Visio thingy you all use to set up your Avian
> Carrier BGP sessions...

Don't use ``MS Visio thingy'', prefer TeX with metapost, PGF/TikZ (or 
PSTRicks). The output is by far more beautiful, and maintaining the
document much more slim.

Cheers,
mh

> 
> Regards
> 
> Dan
> 

RE: IRR-clueful person at 3356?

[Michael Hallgren]

Yes, usually something like "accept r/n" iff "there is a route object 
'covering' r/n and the 'origin AS' of r/n is in the AS-set of the neighbor AS.

mh
-Message d'origine-
De:Mike Simkins
Envoyé: 17/08/2012, 18:04 
A: jle...@lewis.org; r...@seastrom.com
Cc: nanog@nanog.org
Objet:Re: IRR-clueful person at 3356?


That's the sort of thing we have in Europe, downstream customer need to be
in your AS-SET for filtering purposes



- Original Message -
From: Jon Lewis [mailto:jle...@lewis.org]
Sent: Friday, August 17, 2012 11:29 AM
To: Robert E. Seastrom 
Cc: nanog@nanog.org 
Subject: Re: IRR-clueful person at 3356?

On Fri, 17 Aug 2012, Robert E. Seastrom wrote:

> The telemetry I'm getting (thirdhand and believed to originate from
> first line support) suggests that both Level(3)'s direct customer and
> any downstreams of that customer need to be in the same IRR component.

Can't say for sure if it's true, but I've been told the same thing by
Level3 support.

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

Re: LinkedIn password database compromised

[Michael Hallgren]

Hi Randy,

Le jeudi 07 juin 2012 à 10:03 -0700, Randy Bush a écrit :
> hi etaoin,
> 
> > I still don't want single sign on.  Not anywhere.
> 
> i believe that 'single sign on' is a bad deal and dangerous for all, not
> just we geeks.  essentially it means that the 'identiry provider' owns
> your identity.  i love that they call themselves 'identity providers'
> when it is MY fracking identity and they are reselling it.

I agree.

> 
> the 'single sign on' i encourage for the end using human beings i
> support is 1password and its ilk.  it provides the user with one sign-on
> yet strongly encourages separation of identities and strong passwords
> for sites.
> 

Local repository of passwords, aggregation in a way. Right? Encrypted?
Open source?

> add to that, something such as ghostery for your browser, and you have a
> small chance of actually preserving your identity and minimizing cross-
> site tracking.
> 
> randy

mh

> 

RE: Industry practice for BGP costs - one time or fixed/monthly?

[Michael Hallgren]

Le vendredi 25 mai 2012 à 16:04 +, Ashish Rastogi a écrit :
> Price is probably for high availability and high SLA standards.

Yes, hopefully not for simple BGP route exchange...! :)

mh

> 
> Ashish Rastogi
> 
> 
> From: Anurag Bhatia [m...@anuragbhatia.com]
> Sent: Friday, May 25, 2012 12:01 PM
> To: NANOG Mailing List
> Subject: Industry practice for BGP costs - one time or fixed/monthly?
> 
> Hello everyone
> 
> 
> I have been aggressively looking for deals in servers in Europe for
> anycasting. One thing which surprises me is the "setup costs" for BGP. Few
> providers quoted additional $50-100 which looks OK but a few of them quoted
> as high as $150 *extra every month* just for having BGP (no full routing
> table, but just default route pointing). Is there's any technical logic
> behind such heavy costs? I mean at the end of day we are all talking at
> layer 3 and thus it does not involves any hard connection/physical work.
> What other members pay for BGP setup costs?
> 
> 
> 
> Thanks!
> 
> --
> 
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
> 
> Linkedin  |
> Twitter|
> Google+ 
> http://www.csscorp.com/common/email-disclaimer.php
> 

Re: IPv6 aggregation tool

[Michael Hallgren]

Le mardi 22 mai 2012 à 14:02 -0400, Rafael Rodriguez a écrit :
> :) thanks! Was wondering how to do that.

$ perldoc Net::IP ;) That doc's a fine one to read also for other
reasons.

Cheers,

mh

> 
> Sent from my iPhone
> 
> On May 21, 2012, at 9:36, Stefan Jakob  wrote:
> 
> > Am 04.05.12 03:35, schrieb Rafael Rodriguez:
> >> Found this tool that works perfectly.
> >> 
> >> http://zwitterion.org/software/aggregate-cidr-addresses/aggregate-cidr-addresses
> >> 
> >> Hoping this'll help someone else here on the list.  Thanks!
> > 
> > Thx, this is at least three times faster than what I have here.
> > 
> > 
> > Just a comment on the final print statement, which doesn't fit my needs
> > for ipv6:
> > 
> > 
> > -print "prefix: ", $_->prefix(), "\n";
> > +print "print: " , $_->print(), "\n";
> > 
> > 
> > - prefix: 2001:0db8::::::/32
> > + print: 2001:db8::/32
> > 
> > 
> > Rgds, Stefan
> > 
> 

Re: Programmers with network engineering skills

[Michael Hallgren]

Le lundi 27 février 2012 à 14:14 -0800, Owen DeLong a écrit :
> On Feb 27, 2012, at 12:31 PM, david raistrick wrote:
> 
> > On Mon, 27 Feb 2012, Owen DeLong wrote:
> > 
> >> I think you're more likely to find a network engineer with (possibly 
> >> limited)
> >> programming skills.
> > 
> > While I'll agree about the more likely, if I needed a coder who had a firm 
> > grasp of networking I'd rather teach a good coder networking, than try to 
> > teach the art and magic of good development to a network guy.
> > 
> 
> Well, I won't call myself a hard-core coder, but, I think I have a reasonable 
> grasp on the art and magic of good development. What I mostly lack is speed 
> and efficiency in the language of choice for whatever project. I can write 
> good code, it just takes me longer than it would take a hard-core coder.
> 
> OTOH, having done both, I would say that I think you are not necessarily 
> correct about which direction of teaching is harder. Yes, if you start with a 
> network engineer that knows nothing about writing code or doesn't understand 
> the principles of good coding, you're probably right. However, starting with 
> a network engineer that can write decent code slowly, I think you will get a 
> better result in most cases than if you try to teach network engineering to a 
> hard-core coder that has only a minimal understanding of networking.
> 
> > I think it really comes down to which you need: a hardcore network 
> > engineer/architect who can hack up code, or a hardcore developer who has or 
> > can obtain enough of a grasp of networking fundementals and specifics to 
> > build you the software you need him to develop.
> > 
> 
> I'm guessing that someone who needed a hard-core developer that could grasp 
> fundamentals would have grabbed an existing coder and handed him a copy of 
> Comer.
> 
> The fact that this person posted to NANOG instead implies to me that he needs 
> someone that has a better grasp than just the fundamentals.
> 
> Of course I am speculating about that and I could be wrong.
> 
> > The ones who already know both ends extremely well are going to be -very- 
> > hard to find, but finding one who can learn enough of the other to 
> > accomplish what you need shouldn't be hard at all.
> > 
> 
> Depends on what you need. However, I think it's faster to go from limited 
> coding skills with a good basis in the fundamentals to usable development 
> than to go from limited networking skills to a firm grasp on how networks 
> behave in the real world. To the best of my knowledge, nothing but experience 
> will teach you the latter. Even with 20+ years experience networks do still 
> occasionally manage to surprise me.
> 
> > ...d (who is not exactly the former though I've played one for TV, and not 
> > at all the later)
> 
> I am admittedly lost given the three choices as to which constitutes former 
> or latter at this point.
> 
> 1.Strong coder with limited networking
> 2.Strong networker with limited coding
> 3.Strong in both

It's all about KISS, to appreciate sound abstraction, in other words.

Cheers,
mh

> 
> Owen
> Who is a strong network engineer
> Who has been a professional software engineer (though many years ago and my 
> skills are rusty
>   and out of date)
> 
> 

Re: Hijacked Network Ranges

[Michael Hallgren]

Le dimanche 05 février 2012 à 22:41 -0800, goe...@anime.net a écrit :
> On Mon, 6 Feb 2012, Christopher Morrow wrote:
> > why aren't filters applied at all?
> 
> filters don't generate revenue.

... but at times, they prevent loss of... ...

mh

> 
> -Dan
> 

Re: Trouble accessing www.nanog.org

[Michael Hallgren]

Le mercredi 04 janvier 2012 à 20:18 +, bmann...@vacation.karoshi.com
a écrit :
> On Wed, Jan 04, 2012 at 03:10:13PM -0500, George, Wes wrote:
> > > From: Wessels, Duane [mailto:dwess...@verisign.com]
> > > Sent: Wednesday, January 04, 2012 1:41 PM
> > > Subject: Re: Trouble accessing www.nanog.org
> > >
> > >
> > > The brief problem in accessing www.nanog.org was due to numerous
> > > parallel
> > > downloads of a large video file by a single source IP address.  We have
> > > no reason to believe it was malicious in intent, but the offender has
> > > been
> > > blocked anyway.
> > 
> > [WEG] In the lovely CGN future, not only will you see this type of behavior 
> > (multiple pulls from the same IP) all of the time, your response to block 
> > it would have taken tens or hundreds of users out of service simultaneously.
> > /troll
> > 
> > Not meant to fault your response, merely to point out yet one more way that 
> > CGN is likely to break things where an assumption of 1 IP = 1 
> > user/host/network exists.
> > 
> > Wes George
> 
>   Hum... thats not how I read Duanes response at all.. I thought they 
> blocked
>   the (excessively) large video file from download... :)

Depends of how we (are supposed to) interpret ``the offender has been
blocked anyway'' :)

Cheers,
mh
> 
> /bill
> 

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

[Michael Hallgren]

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

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

Cheers,
mh

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

Re: DPI deployment use case

[Michael Hallgren]

Le samedi 08 octobre 2011 à 05:57 +0900, Randy Bush a écrit :
> > Actually, we've been faced with proposals to build services based on
> > traffic classification, like e.g. "access our own webmail and all
> > social networking sites, but not skype and video"
> 
> you're on the wrong list.  this list is about the internet.

good point; +1
mh
> 
> randy
> 

Re: Need the perspective of a Level3 customer.

[Michael Hallgren]

Le vendredi 13 mai 2011 à 01:39 -0700, Joe Renwick a écrit :
> Can anyone peering with Level3 directly tell me if they are seeing
> 63.210.162.0/24 coming from the Level3 peer?

Yes, I do.

mh

> 
> Thanks for the help.
> 
> Cheers,
> 

Re: Downstream Usage-BGP Communites

[Michael Hallgren]

Le mardi 10 mai 2011 à 17:52 -0400, Nick Olsen a écrit :
> Greetings NANOG,
> Was hoping to gain some insight into common practice with using BGP 
> Communities downstream.
> 
> For instance:
> We peer with AS100 (example)
> AS100 peers with TW Telecom (AS4323).
> Since I happen to know that AS100 doesn't sanitize the communities I send 
> with my routes. I can take advantage of TW Telecom's BGP communities for 
> traffic engineering. Such as 4323:666 (Keep in TWTC Backbone). Would this 
> be something that is generally frowned upon? Still under the assumption 
> that the communities aren't scrubbed off my routes. Could I do this with 
> other AS's beyond TW Telecom? Such as TW's peering with Global Crossing 
> (AS3549)?

It's quite common, in my experience, that we remove (or at least filter;
usually looking at geo-origin ones only) BGP community values from peers
and filter them (modulo some set of agreed ones) from customers. 

In other words, don't generally expect transitivity.

mh

> 
> Nick Olsen
> Network Operations (855) FLSPEED  x106
> 
>  

Re: Anyone still maintaining altdb.net?

[Michael Hallgren]

Le mercredi 20 avril 2011 à 10:05 -0500, Richard A Steenbergen a écrit :
> On Wed, Apr 20, 2011 at 10:30:44AM -0400, Jon Lewis wrote:
> > On Wed, 20 Apr 2011, Bret Palsson wrote:
> > 
> > > I submitted my objects April 11. the mtrner object needs to be 
> > > created by the db-admin. I realize this is a volunteer thing. Could 
> > > I help out or could the people that are helping out look at adding 
> > > my record? I need to setup some peering relationships. I'd prefer to 
> > > support open communities rather than paying and am willing to help 
> > > out if need be.
> > 
> > If you're just getting started, it might make sense to look at another db. 
> > IIRC, RIPE's routing registry is free to use, supports md5crypt and 
> > PGP/GPG auth, and isn't a volunteer one-man show.
> 
> One of the premises of AltDB is that no support is provided. For 
> example, a lot of people send email asking "how do I use this", and the 
> unfortunate answer has to be "sorry we can't help you". If you need 
> support, then by all means pay the money to someone like RADB and let 
> them help walk you through the process. Of course after the initial 
> mntner creation everything is pretty much automated anyways, so if you 
> know what you're doing AltDB provides a free method to maintain your IRR 
> entries with very little sacrificied over a commercial solution.

I believe that RIPE still provide training sessions (as well as quite 
extensive documentation), mailing lists, etc, etc

mh

> 
> There is infact more than 1 person volunteering for AltDB, but from what 
> I can see of this April 11th email, it falls into the "please provide 
> support" category. :)
> 

Re: Regional AS model

[Michael Hallgren]

Le vendredi 25 mars 2011 à 02:09 -0700, Zaid Ali a écrit :
> On Mar 24, 2011, at 3:17 PM, Michael Hallgren wrote:
> 
> > Le jeudi 24 mars 2011 à 14:26 -0700, Bill Woodcock a écrit :
> >> On Mar 24, 2011, at 1:47 PM, Patrick W. Gilmore wrote:
> >>> On Mar 24, 2011, at 3:40 PM, Owen DeLong wrote:
> >>>> On Mar 24, 2011, at 12:42 PM, Zaid Ali  wrote:
> >>>> 
> >>>>> I have seen age old discussions on single AS vs multiple AS for 
> >>>>> backbone and datacenter design. I am particularly interested in 
> >>>>> operational challenges for running AS per region e.g. one AS for US, 
> >>>>> one EU etc or I have heard folks do one AS per DC. I particularly don't 
> >>>>> see any advantage in doing one AS per region or datacenter since most 
> >>>>> of the reasons I hear is to reduce the iBGP mesh. I generally prefer 
> >>>>> one AS  and making use of confederation. 
> >>>> 
> >>>> If you have good backbone between the locations, then, it's mostly a 
> >>>> matter of personal preference. If you have discreet autonomous sites 
> >>>> that are not connected by internal circuits (not VPNs), then, AS per 
> >>>> site is greatly preferable.
> >>> 
> >>> We disagree.
> >>> Single AS worldwide is fine with or without a backbone.
> >>> Which is "preferable" is up to you, your situation, and your personal 
> >>> tastes. 
> >> 
> >> 
> >> We're with Patrick on this one.  We operate a single AS across 
> >> seventy-some-odd locations in dozens of countries, with very little of 
> >> what an eyeball operator would call "backbone" between them, and we've 
> >> never seen any potential benefit from splitting them.  I think the 
> >> management headache alone would be sufficient to make it unattractive to 
> >> us.
> >> 
> >>-Bill
> >> 
> >> 
> > 
> > Right. I think that a single AS is most often quite fine. I think our
> > problem space is rather about how you organise the routing in your AS.
> > Flat, route-reflection, confederations? How much policing between 
> > regions do you feel that you need? In some scenarios, I think 
> > confederations may be a pretty sound replacement of the multiple-AS
> > approach. Policing iBGP sessions in a route-reflector topology? Limits?
> > Thoughts?
> 
> I always look at confederations as a longer term plan because you have some 
> idea how your backbone is going to shape out. Knowing where you are going 
> makes confederation planning easier. Start with RR's and then see if confeds 
> make sense.
> 

Yes, I agree. Confed's is a choice, in particular if you need elaborate
policies between regions of your network. Police sessions between
sub-ASes, keep iBGP simple...

Say, you start with RR... If or once your network is large, and having
customers connected to it, migrating to conferedrations may be a
challenge. Right? Thoughts? Experiences?

mh

> Zaid 

Re: Regional AS model

[Michael Hallgren]

Le jeudi 24 mars 2011 à 14:26 -0700, Bill Woodcock a écrit :
> On Mar 24, 2011, at 1:47 PM, Patrick W. Gilmore wrote:
> > On Mar 24, 2011, at 3:40 PM, Owen DeLong wrote:
> >> On Mar 24, 2011, at 12:42 PM, Zaid Ali  wrote:
> >> 
> >>> I have seen age old discussions on single AS vs multiple AS for backbone 
> >>> and datacenter design. I am particularly interested in operational 
> >>> challenges for running AS per region e.g. one AS for US, one EU etc or I 
> >>> have heard folks do one AS per DC. I particularly don't see any advantage 
> >>> in doing one AS per region or datacenter since most of the reasons I hear 
> >>> is to reduce the iBGP mesh. I generally prefer one AS  and making use of 
> >>> confederation. 
> >> 
> >> If you have good backbone between the locations, then, it's mostly a 
> >> matter of personal preference. If you have discreet autonomous sites that 
> >> are not connected by internal circuits (not VPNs), then, AS per site is 
> >> greatly preferable.
> > 
> > We disagree.
> > Single AS worldwide is fine with or without a backbone.
> > Which is "preferable" is up to you, your situation, and your personal 
> > tastes. 
> 
> 
> We're with Patrick on this one.  We operate a single AS across 
> seventy-some-odd locations in dozens of countries, with very little of what 
> an eyeball operator would call "backbone" between them, and we've never seen 
> any potential benefit from splitting them.  I think the management headache 
> alone would be sufficient to make it unattractive to us.
> 
> -Bill
> 
> 

Right. I think that a single AS is most often quite fine. I think our
problem space is rather about how you organise the routing in your AS.
Flat, route-reflection, confederations? How much policing between 
regions do you feel that you need? In some scenarios, I think 
confederations may be a pretty sound replacement of the multiple-AS
approach. Policing iBGP sessions in a route-reflector topology? Limits?
Thoughts?

Cheers,

mh

> 
> 
> 
> 

Re: What If....

[Michael Hallgren]

Le lundi 28 février 2011 à 11:57 -1000, David Conrad a écrit :
> On Feb 28, 2011, at 11:11 AM, Michael Hallgren wrote:
> >>> I'm glad to see they are up to date:
> >>> "Paper submissions should
> >>> include a three and one-half inch
> >>> computer diskette in HTML, ASCII,
> >>> Word or WordPerfect format (please
> >>> specify version)."
> > 
> > Any problem with Postscript or PDF? Somewhat less clumsy with versions
> > than Word*. Computer diskette... timing :)
> 
> No, there is no problem with sending electronic-only submissions.  The 
> requirement to include a 3.5" floppy is only if you send them paper (I wonder 
> if anyone still does that...).
> 

:)

> Regards,
> -drc
> 

Re: What If....

[Michael Hallgren]

Le lundi 28 février 2011 à 15:50 -0500, Edward Lewis a écrit :
> At 9:35 +1300 3/1/11, Brian E Carpenter wrote:
> 
> >>  http://www.ntia.doc.gov/frnotices/2011/fr_ianafunctionsnoi_02252011.pdf
> 
> >I'm glad to see they are up to date:
> >"Paper submissions should
> >include a three and one-half inch
> >computer diskette in HTML, ASCII,
> >Word or WordPerfect format (please
> >specify version)."

Any problem with Postscript or PDF? Somewhat less clumsy with versions
than Word*. Computer diskette... timing :)

> 
> Certainly a deterrent against paper submissions. ;)  Quite "green" of them!

Positive! ;)

mh

Re: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database)

[Michael Hallgren]

Le mardi 01 février 2011 à 18:01 -0500, Christopher Morrow a écrit :
> On Tue, Feb 1, 2011 at 4:33 PM, Michael Hallgren  wrote:
> > Le mardi 01 février 2011 à 12:14 -0500, Christopher Morrow a écrit :
> 
> >> countries do not have RIR's, countries have NIR's... regions have RIR's.
> >
> > In this context, at least, perhaps the NIR should be considered
> > superfluous or redundant? What is the operational rationale behind the
> > NIR level? Wouldn't a flatter RIR-LIR structure do just fine?
> 
> some parts of the world are invested in the NIR ocncept... not my
> part, but I do admit other folks like it. (and I didn't want to leave
> someone out of the mix)

Neither do I, but I think it's a good thing to discuss. Any NIR rep's
around?

mh

Re: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database)

[Michael Hallgren]

Le mercredi 02 février 2011 à 07:04 +0900, Randy Bush a écrit :
> > In this context, at least, perhaps the NIR should be considered
> > superfluous or redundant? What is the operational rationale behind the
> > NIR level? Wouldn't a flatter RIR-LIR structure do just fine?
> 
> and then, by inference, what is the use of the RIR level?

A meeting point for communities, potentially able to reflect a consensus
view of policies and moderate "NIR" and other might be more unilateral
initiatives. If one individual of a community goes "insane", enable the
remaing ones to modrate.  

> 
> randy

mh

Re: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database)

[Michael Hallgren]

Le mardi 01 février 2011 à 16:54 -0500, Martin Millnert a écrit :
> On Tue, Feb 1, 2011 at 4:36 PM, Michael Hallgren  wrote:
> > But RIR is (at least supposed to be) regional, so
> > (hopefully) more stable from a policy point of view (since the number of
> > national "stake holders" need to agree on a common policy). In theory,
> > at least...
> 
> For Europe and RIPE, the EU commission at your service...

Yeah, good point... ... as was Owen's... :)

So, what's next hop forward?


mh
> 
> Regards,
> Martin

Re: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database)

[Michael Hallgren]

Le mardi 01 février 2011 à 13:20 -0800, Owen DeLong a écrit :
> On Feb 1, 2011, at 9:14 AM, Christopher Morrow wrote:
> 
> > On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert  wrote:
> >> Here be dragons,
> > 
> >> It should be fairly obvious, by most recently what's going on in
> >> Egypt, why allowing a government to control the Internet is a Really
> >> Bad Idea.
> >> 
> > 
> > how is the egypt thing related to rPKI?
> > How is the propsed rPKI work related to gov't control?
> > 
> RPKI is a big knob governments might be tempted to turn.
> 
> >> architecturally/technologically *impossible* for a entity from country
> >> A to via-the-hierarchical-trust-model block a prefix assigned to some
> >> entity in country B, that is assigned by B's RIR and in full
> >> accordance with the RIR policies and in no breach of any contract.
> > 
> > countries do not have RIR's, countries have NIR's... regions have RIR's.
> 
> RIRs live in countries with governments.
> RIRs are unlikely to mount a successful challenge against an organization
> with tanks and mortars.

Yes, right. But RIR is (at least supposed to be) regional, so
(hopefully) more stable from a policy point of view (since the number of
national "stake holders" need to agree on a common policy). In theory,
at least...

mh

> 
> Owen
> 
> 

Re: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database)

[Michael Hallgren]

Le mardi 01 février 2011 à 12:14 -0500, Christopher Morrow a écrit : 
> On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert  wrote:
> > Here be dragons,
> 
> > It should be fairly obvious, by most recently what's going on in
> > Egypt, why allowing a government to control the Internet is a Really
> > Bad Idea.
> >
> 
> how is the egypt thing related to rPKI?
> How is the propsed rPKI work related to gov't control?
> 
> > architecturally/technologically *impossible* for a entity from country
> > A to via-the-hierarchical-trust-model block a prefix assigned to some
> > entity in country B, that is assigned by B's RIR and in full
> > accordance with the RIR policies and in no breach of any contract.
> 
> countries do not have RIR's, countries have NIR's... regions have RIR's.

In this context, at least, perhaps the NIR should be considered
superfluous or redundant? What is the operational rationale behind the
NIR level? Wouldn't a flatter RIR-LIR structure do just fine?

mh

> 




signature.asc
Description: This is a digitally signed message part

Re: Single AS Number for multiple prefixes in different country

[Michael Hallgren]

Le lundi 17 janvier 2011 à 12:00 -0800, Michel de Nostredame a écrit :
> On Mon, Jan 17, 2011 at 12:20 AM, Patrick W. Gilmore  
> wrote:
> > On Jan 17, 2011, at 12:32 AM, Michel de Nostredame wrote:
> > I do not think that paragraph means what you think it means.
> > I've seen my own AS in full tables from upstreams using Juniper routers 
> > many times.
> 
> According to the problem I had, the behavior is more like
> "when I receive asX from 1st direct link, I will not send to asX on
> 2nd direct link by default."
> 
> For example,
> I (say as#65001) advertised "10.1.0.0/16 ^65001$" on 1st link to my
> ISP, say as#65000.
> and advertise "10.2.0.0/16 ^65001$" to the same ISP on 2nd link.
> 
> Then,
> I will not receive "10.2.0.0/16 ^65000 65001$" on 1st link,
> and will not receive "10.1.0.0/16 ^65000 65001$" on 2nd link.
> 
> I believe my ISP did not intentionally filter out my routes,
> but it more like default behavior as described in document.
> Setting up default-route on both of my border routers addressed the needs.
> 
> After we established the leased line between two sites,
> we no longer need to send cross site traffic via ISP.

I feel, asking to recieve (and use) default route appears "cleaner" than
hacking routing protocol ways. Unless, one does as you just did. Right?

Cheers,

mh 

> 
> --
> Michel~
> 

Re: Cisco Sanitization

[Michael Hallgren]

Le mercredi 12 janvier 2011 à 11:41 -0800, JC Dill a écrit :

> Randy,
> 
> If you want to cite list policy, let's start by noting that it's a clear 
> violation of the nanog list AUP to setup an autoresponder reply to list 
> email[1], no matter if the autoresponder replies to the list or just to 
> the poster.  You must whitelist email from the list before applying an 
> autoresponder.  If you don't want to see the disclaimer-laden emails, 
> then you can whitelist, then send posts with disclaimers (along with all 
> other posts you don't care to read) to dev/null.
> 
> OTOH, there is nothing in the AUP about disclaimers.  Disclaimers, top 
> posting, excessive quoting, etc. are discouraged (considered poor 
> netiquette) but not outright forbidden.

Either way, a 15-50 or more lines legal notification style appendix to
a mail in an informal operation's forum... ... seems at the very best...
to be of... bad taste... (to me). (Who's reading these? :))

Cheers,

mh

Re: Mastercard problems

[Michael Hallgren]

Le mercredi 08 décembre 2010 à 14:23 -0800, andrew.wallace a écrit :
> "MasterCard works closely with the 
> U.S. Secret Service, the FBI, the Postal Inspection Service, Interpol, 
> Europol and counterpart organizations throughout the world to facilitate 
> investigation and prosecution."
> 
> http://www.mastercard.com/us/merchant/security/collaborating_experts.html

Sure, and fortunately,... but that's about fraud prevention...

mh

> 
> Andrew
> 
> 
> 
> 
> - Original Message -
> From:James Downs 
> To:andrew.wallace 
> Cc:Christopher Morrow ; "nanog@nanog.org" 
> 
> Sent:Wednesday, 8 December 2010, 21:30:20
> Subject:Re: Mastercard problems
> 
> 
> On Dec 8, 2010, at 12:30 PM, andrew.wallace wrote:
> 
> > I would say the attack falls under the jurisdiction of the US secret 
> > service since this is an attack on the financial system.
> > 
> > "Today the agency's primary investigative mission is to safeguard the 
> > payment and financial systems of the United States." --- secretservice.gov
> 
> Yikes.. you consider a private company's business to be the financial and 
> payment system of the United States?
> 
> -j
> 
> 
> 
>   
> 

Re: regional ASN's

[Michael Hallgren]

Le mercredi 01 décembre 2010 à 17:31 +, deles...@gmail.com a écrit :
> You can use one AS and communities to seperate your traffic/policies.

Or other iBGP means of internal separation, like BGP confederations (in
order to avoid iBGP session hacks).

mh

> 
> -jim
> --Original Message--
> From: Ryan Finnesey
> To: NANOG list
> Subject: regional ASN's
> Sent: Dec 1, 2010 1:13 PM
> 
> I see various people are recommending networks setup regional ASN's.  I
> am in the process of setting up a new network which will serve as a
> transit network for all our operating units.  I was planning on using
> one ASN for North America, Asia and Europe.  Is this not recommended?
> 
> Cheers
> Ryan
> 
> 
> 
> 
> Sent from my BlackBerry device on the Rogers Wireless Network
> 



signature.asc
Description: This is a digitally signed message part

Re: RINA - scott whaps at the nanog hornets nest :-)

[Michael Hallgren]

Le samedi 06 novembre 2010 à 13:29 -0700, Matthew Petach a écrit :
> On Sat, Nov 6, 2010 at 1:22 PM, George Bonser  wrote:
> >> >
> >> > Last week I asked the operator of fairly major public peering points
> >> if they supported anything larger than 1500 MTU.  The answer was "no".
> >> >
> >>
> >> There's still a metric buttload of SONET interfaces in the core that
> >> won't go above 4470.
> >>
> >> So, you might conceivably get 4k MTU at some point in the future, but
> >> it's really, *really* unlikely you'll get to 9k MTU any time in the
> >> next
> >> decade.
> >>
> >> Matt
> >
> > There is no reason why we are still using 1500 byte MTUs at exchange points.
> >
> 
> Completely agree with you on that point.  I'd love to see Equinix, AMSIX, 
> LINX,
> DECIX, and the rest of the large exchange points put out statements indicating
> their ability to transparently support jumbo frames through their
> fabrics, or at
> least indicate a roadmap and a timeline to when they think they'll be able to
> support jumbo frames throughout the switch fabrics.

Agree. Some people do: Netnod. ;) (1500 in one option, 4470 in another,
part of a single interconnection deal -- unless I'm mistaken about the
contractual side of things).

mh

> 
> Matt



signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: RINA - scott whaps at the nanog hornets nest :-)

[Michael Hallgren]

Le samedi 06 novembre 2010 à 13:01 -0700, Matthew Petach a écrit :
> On Sat, Nov 6, 2010 at 12:32 PM, George Bonser  wrote:
> >> I doubt that 1500 is (still) widely used in our Internet... Might be,
> >> though, that most of us don't go all the way to 9k.
> >>
> >> mh
> >
> > Last week I asked the operator of fairly major public peering points if 
> > they supported anything larger than 1500 MTU.  The answer was "no".
> >
> 
> There's still a metric buttload of SONET interfaces in the core that
> won't go above 4470.
> 
> So, you might conceivably get 4k MTU at some point in the future, but
> it's really, *really* unlikely you'll get to 9k MTU any time in the next
> decade.

Right, though I'm unsure of "decade" since we're moving off SDH/Sonet
quite agressively.

mh

> 
> Matt



signature.asc
Description: Ceci est une partie de message	numériquement signée

RE: RINA - scott whaps at the nanog hornets nest :-)

[Michael Hallgren]

Le samedi 06 novembre 2010 à 12:15 -0700, George Bonser a écrit :
> > Sent: Saturday, November 06, 2010 9:45 AM
> > To: nanog@nanog.org
> > Subject: Re: RINA - scott whaps at the nanog hornets nest :-)
> > 
> > On 11/5/2010 5:32 PM, Scott Weeks wrote:
> > >
> > > It's really quiet in here.  So, for some Friday fun let me whap at
> > the hornets nest and see what happens...>;-)
> > >
> > >
> > > http://www.ionary.com/PSOC-MovingBeyondTCP.pdf
> > >
> > 
> > SCTP is a great protocol. It has already been implemented in a number
> > of
> > stacks. With these benefits over that theory, it still hasn't become
> > mainstream yet. People are against change. They don't want to leave v4.
> > They don't want to leave tcp/udp. Technology advances, but people will
> > only change when they have to.
> > 
> > 
> > Jack (lost brain cells actually reading that pdf)
> 
> I believe SCTP will become more widely used in the mobile device world.  You 
> can have several different streams so you can still get an IM, for example, 
> while you are streaming a movie.  Eliminating the "head of line" blockage on 
> thin connections is really valuable. 
> 
> It would be particularly useful where you have different types of traffic 
> from a single destination.  File transfer, for example, might be a good 
> application where one might wish to issue interactive commands to move around 
> the directory structure while a large file transfer is taking place.
> 
> If you really want to shake a hornet's nest, try getting people to get rid of 
> this idiotic 1500 byte MTU in the "middle of the internet"


I doubt that 1500 is (still) widely used in our Internet... Might be,
though, that most of us don't go all the way to 9k.

mh


>  and try to get everyone to adopt 9000 byte frames as the standard.  That 
> change right there would provide a huge performance increase, load reduction 
> on networks and servers, and with a greater number of native ethernet end to 
> end connections, there is no reason to use 1500 byte MTUs.  This is 
> particularly true with modern PMUT methods (such as with modern Linux kernels 
> ... /proc/sys/net/ipv4/tcp_mtu_probing set to either 1 or 2).
> 
> While the end points should just be what they are, there is no reason for the 
> "middle" portion, the long haul transport part, to be MTU 1500.
> 
> http://staff.psc.edu/mathis/MTU/
> 
> 



signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: What must one do to avoid Gmail's overachieving spam filtering?

[Michael Hallgren]

Le mercredi 29 septembre 2010 à 16:31 -0500, Daniel Seagraves a écrit :
> On Sep 29, 2010, at 4:08 PM, Ryan Hayes wrote:
> 
> > Can you please not use the word "retarded" in a pejorative sense?
> 
> The word "please" is probably not required, since using that word in this 
> manner is prosecutable hate speech in some jurisdictions.

You're serious? :)

mh
> 

Re: IPv6 enabled carriers?

[Michael Hallgren]

Le mercredi 10 mars 2010 à 11:18 -0800, Seth Mattinen a écrit :
> On 3/10/10 11:00 AM, Charles Mills wrote:
> > Does anyone have a list of carriers who are IPv6 capable today?
> > 
> > I would assume this would be rolled out in larger cities first but
> > anything outside of "testbed environments" and "trials" as in
> > Comcast's recent announcement seems to be all that is available.
> > 
> > I'm being tasked with coming up with an IPv6 migration plan for a data 
> > center.
> > 
> > Mostly interested in if ATT, Level3, GLBX, Saavis, Verizon Business
> > and Qwest are capable as those are the typical ones I deal with.
> > 
> 
> Ones I have personal experience with:
> 
> GLBX - yes
> SAVVIS - no
> VZB - yes, good luck
> ATT - "Beginning in 1Q2010 MIS will provide the ability to support IPv6
> in a dual stack mode."
> 
> When I disconnected my SAVVIS circuit in November 2009 I explicitly told
> them IPv6 was a deciding factor. Not all of Verizon's pops are IPv6
> enabled, which may cause you trouble ordering it. It's put me in month
> 11 of trying to turn up a dual-stack circuit because they refuse to read
> the order and keep putting it in Sacramento (v4 only) when it needs to
> go to San Jose (dual-stack). Sprint wasn't on your list, but they are
> rolling out native IPv6 support on all of 1239. I've been using their
> 6175 testbed since 2005.
> 


+ Tata AS6453, production network since quite some time now, dual stack.

mh

> ~Seth
> 


-- 
michael hallgren, mh2198-ripe


signature.asc
Description: Ceci est une partie de message	numériquement signée