From keegan.holley at sungard.com  Wed Feb  1 00:02:03 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 1 Feb 2012 01:02:03 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
Message-ID: <CABO8Q6S+HvK=sL=LSE8xZTnx_86uCxu_GurH-Gj1mSYfPtLBcw@mail.gmail.com>

That may not be a bad idea.  Have you gotten your company's lawyers
involved? They may be able to get some sort of court action started and get
things moving. They may also be able to compel the ISP's to act.


2012/1/31 Kelvin Williams <kwilliams at altuscgi.com>

> I hope none of you ever get hijacked by a spammer housed at Phoenix NAP.
>  :)
>
> We're still not out of the woods, announcing /24s and working with upper
> tier carriers to filter out our lists.  However, I just got this response
> from Phoenix NAP and found it funny.  The "thief" is a former customer,
> whom we terminated their agreement with.  They then forged an LOA,
> submitted it to CWIE.net and Phoenix NAP and resumed using space above and
> beyond their terminated agreement.  So now any request for assistance to
> stop our networks from being announced is now responded to with an
> instruction to contact the thief's lawyer.
>
> kw
>
> ---------- Forwarded message ----------
> From: Kelvin Williams <kwilliams at altuscgi.com>
> Date: Tue, Jan 31, 2012 at 7:43 PM
> Subject: Re: [#135346] Unauthorized BGP Announcements
> To: noc at phoenixnap.com
>
>
> We'll be forwarding this to our peers in the industry--rather funny that
> Phoenix NAP would rather send us to the attorney of the people stealing our
> space than bothering to perform an ARIN WHOIS search, or querying any of
> the IRRs.
>
> Interesting...  Very interesting...  So, who all do you have
> there--spammers and child pornographers?  Is this level of protection what
> you give to them all?
>
>
>
> On Tue, Jan 31, 2012 at 7:30 PM, Brandon S <BrandonS at phoenixnap.com>
> wrote:
>
> > Hello,
> >
> > Thank you for your email. Please direct any further questions regarding
> > this issue to the following contact.
> >
> > Bennet Kelley
> > 100 Wilshire Blvd.
> > Suite 950
> > Santa Monica, CA 90401
> > bkelley at internetlawcenter.net
> >
> > Telephone
> > 310-452-0401
> >
> > Facsimile
> > 702-924-8740
> >
> > --
> > Brandon S.
> > NOC Services Technician
> >
> > ** We want to hear from you!**
> > We care about the quality of our service. If you?ve received
> > anything less than a prompt response or exceptional service or would like
> > to share any
> > feedback regarding your experience, please let us know by sending an
> email
> > to management:
> > supportfeedback at phoenixnap.com
> >
> > --
> Kelvin Williams
> Sr. Service Delivery Engineer
> Broadband & Carrier Services
> Altus Communications Group, Inc.
>
>
> "If you only have a hammer, you tend to see every problem as a nail." --
> Abraham Maslow
>
>

From marka at isc.org  Wed Feb  1 00:14:42 2012
From: marka at isc.org (Mark Andrews)
Date: Wed, 01 Feb 2012 17:14:42 +1100
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: Your message of "Tue, 31 Jan 2012 18:00:44 -0800."
 <D73AF1AF-B75E-49B6-937A-5FBE770AD83D@virtualized.org>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <20120201015257.39A071C95D68@drugs.dv.isc.org>
 <D73AF1AF-B75E-49B6-937A-5FBE770AD83D@virtualized.org>
Message-ID: <20120201061442.A55381C96CD2@drugs.dv.isc.org>


In message <D73AF1AF-B75E-49B6-937A-5FBE770AD83D at virtualized.org>, David Conrad
 writes:
> On Jan 31, 2012, at 5:52 PM, Mark Andrews wrote:
> >> "We have a contractual relationship with our customer to announce =
> that =3D
> >> space.  We have neither a contractual relationship (in this context) =
> =3D
> >> with the RIR nor the RIR's customer.  The RIR and/or the RIR's =
> customer =3D
> >> should resolve this issue with our customer."
> >=20
> > And if I have a contract to commit murder that doesn't mean that
> > it is right nor legal.  A contract can't get you out of dealing
> > with the law of the land and in most place in the world "aiding and
> > abetting" is illegal.
> 
> You appear to be making a large number of assumptions on limited =
> evidence. In the case I'm familiar with, I can assure you that no laws =
> were being broken (even if all the parties were in the same country, =
> which they weren't).  However, this is getting off-topic and I don't =
> want to hijack the thread.  The issue of route hijacking is quite =
> serious and it will be interesting to see how this all works out.

And would sidr have helped.
 
> Regards,
> -drc
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From saku at ytti.fi  Wed Feb  1 01:32:00 2012
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 1 Feb 2012 09:32:00 +0200
Subject: Console Server Recommendation
In-Reply-To: <15445673-C219-467D-BB5F-98C873B04355@delong.com>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
 <20120131091136.GA22047@pob.ytti.fi>
 <15445673-C219-467D-BB5F-98C873B04355@delong.com>
Message-ID: <20120201073200.GA23107@pob.ytti.fi>

On (2012-01-31 11:09 -0800), Owen DeLong wrote:
 
> > - IP address mappable to a console port. So that accessing device normally
> >  is 'ssh router' and via OOB 'ssh router.oob' no need to train people
> 
> How about normal is 'ssh device' and OOB is 'console device'?

Home-baked systems are certainly good option to many, but for some of us it
means we need to either hire worker to design, acquire, build and support
them or consultant. And as you can find devices which support above
requirements (opengear) TCO for us is simply just lower to buy one ready.

'console device' is what we do today, which is script someone needs to
maintain (it picks up from DNS TXT records OOB and port where to connect).
I prefer giving each port an IP and just use it via ssh (at least cyclades
and opengear do this), if you are brave you could even setup same IP
address for console and on-band loop, but I found that to be suboptimal, as
you sometimes want to connect to OOB even when on-band is working.

> There are other tools that do this, such as rancid. I'm not sure I see significant advantage
> to integrating it.

This was exactly for easy integration to rancid, if you cannot puke all
config easily from one place, doing rancid module is lot more work. Few of
the boxes I've seen, need to have some files hacked via linux cli and are
PITA to backup.
But as it was nice to have, it by no means is no show-stopper.

> I agree that RS232 on a management plane would be a better choice. Personally,
> I like the idea of having both RS232 and ethernet on dedicated management plane.
> The RS232 allows you to deal with failures on the ethernet and the ethernet provides
> support for image transfers, etc.

You can get that from Nexus7k and Sup7. I wouldn't use the RS232 at all
myself. Probably it's easier to sell this at day1 with RS232 port, as it is
required in many RFPs and when everyone has migrated to ethernet OOB,
phase-out RS232.
So people please add to your 'nice to have' requirements in RFP, proper OOB
:). (Can't tell how many times we've had to power-cycle CSCO or JNPR due to
control-plane console not responding)

> I will point out that the intel mobo OOB has not completely eliminated the need for
> IPKVM in the datacenter. YMMV.

This is bit drifting on the subject, but what are you missing specifically?
You get VNC KVM, all the way from boot to bios, to GUI or CLI. You also get
IDE redirection, to boot the remote box from your laptop CDROM. And you get
API to automatically install factory fresh boxes without ever touching the
boxes.


-- 
  ++ytti


From goemon at anime.net  Wed Feb  1 01:41:59 2012
From: goemon at anime.net (goemon at anime.net)
Date: Tue, 31 Jan 2012 23:41:59 -0800 (PST)
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <20120201015257.39A071C95D68@drugs.dv.isc.org>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <20120201015257.39A071C95D68@drugs.dv.isc.org>
Message-ID: <Pine.LNX.4.64.1201312341020.25698@sasami.anime.net>

On Wed, 1 Feb 2012, Mark Andrews wrote:
> And if I have a contract to commit murder that doesn't mean that
> it is right nor legal.  A contract can't get you out of dealing
> with the law of the land and in most place in the world "aiding and
> abetting" is illegal.

the topic at hand would appear to be more 'willful negligence' than 
'aiding and abetting'. punitive damages could apply.

-Dan


From kwilliams at altuscgi.com  Wed Feb  1 02:58:51 2012
From: kwilliams at altuscgi.com (Kelvin Williams)
Date: Wed, 1 Feb 2012 03:58:51 -0500
Subject: Thanks & Let's Prevent this in the Future.
Message-ID: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>

First off, I'd like to thank everyone on this list who have reached out
today and offered us help with our hijacked network space.  It's so
refreshing to see that there are still so many who refuse to leave a
man/woman down.

I'm not going to place any blame, its useless.  There were lies, there were
incompetencies, and there was negligence but that is now water under the
bridge.

However, I think that we as network operators have a duty to each other to
make sure we don't allow a downstream customer wreck the operations of
another entity who has been rightfully allocated resources.

A few months ago, when establishing a new peering relationship I was
encouraged (actually required) to utilize one of the IRRs.  I took the time
to register all of my routes, ASNs, etc.  However, as I learned today, this
was probably done in vain.  Too many people won't spend the extra
30-seconds to verify the information listed there or in ARINs WHOIS.

I don't care what a customer tells me, too many times I've found they
aren't 100% honest either for malicious/fraudulent reasons or they are
unknowing.  So, for our networks or the networks we manage, we want to
verify what a customer is saying to prevent what happened to us today.

I'd like to get a conversation going and possibly some support of an
initiative to spend that extra 30-seconds to verify ownership and
authorization of network space to be advertised.  Additionally, if someone
rings your NOC's line an industry-standard process of verifying "ownership"
and immediately responding by filtering out announcements. There's no sense
in allowing a service provider to be impaired because a spammer doesn't
want to give up clean IP space.  Do you protect a bad customer or the
Internet as a whole?  I pick the Internet as a whole.

How can we prevent anyone else from ever enduring this again?  While we may
never stop it from ever happening, spammers (that's what we got hit by
today) are a dime a dozen and will do everything possible to hit an Inbox,
so how can we establish a protocol to immediate mitigate the effects of an
traffic-stopping advertisement?

I thought registering with IRRs and up-to-date information in ARINs WHOIS
was sufficient, apparently I was wrong.  Not everyone respects them, but
then again, they aren't very well managed (I've got several networks with
antiquated information I've been unable to remove, it doesn't impair us
normally, but its still there).

What can we do?  Better yet, how do we as a whole respond when we encounter
upstream providers who refuse to look at the facts and allow another to
stay down?

kw

-- 
Kelvin Williams
Sr. Service Delivery Engineer
Broadband & Carrier Services
Altus Communications Group, Inc.


"If you only have a hammer, you tend to see every problem as a nail." --
Abraham Maslow

From leigh.porter at ukbroadband.com  Wed Feb  1 03:12:41 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 1 Feb 2012 09:12:41 +0000
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
References: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
Message-ID: <6F4B982A-90D3-4568-B4EB-29E98C95A479@ukbroadband.com>


On 1 Feb 2012, at 09:01, "Kelvin Williams" <kwilliams at altuscgi.com> wrote:

> 
> A few months ago, when establishing a new peering relationship I was
> encouraged (actually required) to utilize one of the IRRs.  I took the time
> to register all of my routes, ASNs, etc.  However, as I learned today, this
> was probably done in vain.  Too many people won't spend the extra
> 30-seconds to verify the information listed there or in ARINs WHOIS.

It's amazing isn't it. It isn't only fraud and maliciousness that this prevents. 

A number of times I have been asked to advertise space or open filters for space based on typos and people not understanding address notation and CIDR. So it's with doing if only to prevent this.

-- 
Leigh


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


From hank at efes.iucc.ac.il  Wed Feb  1 03:13:57 2012
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Wed, 01 Feb 2012 11:13:57 +0200
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.g
 mail.com>
Message-ID: <5.1.0.14.2.20120201110350.00c51a30@efes.iucc.ac.il>

At 03:58 01/02/2012 -0500, Kelvin Williams wrote:

Those ISPs that are good network citizens have done it already.  Those who 
don't care and who haven't done it yet - won't do it in the future.  The 
only recourse you have is exactly what you have done.

-Hank

>How can we prevent anyone else from ever enduring this again?  While we may
>never stop it from ever happening, spammers (that's what we got hit by
>today) are a dime a dozen and will do everything possible to hit an Inbox,
>so how can we establish a protocol to immediate mitigate the effects of an
>traffic-stopping advertisement?
>
>I thought registering with IRRs and up-to-date information in ARINs WHOIS
>was sufficient, apparently I was wrong.  Not everyone respects them, but
>then again, they aren't very well managed (I've got several networks with
>antiquated information I've been unable to remove, it doesn't impair us
>normally, but its still there).
>
>What can we do?  Better yet, how do we as a whole respond when we encounter
>upstream providers who refuse to look at the facts and allow another to
>stay down?
>
>kw
>
>--
>Kelvin Williams
>Sr. Service Delivery Engineer
>Broadband & Carrier Services
>Altus Communications Group, Inc.
>
>
>"If you only have a hammer, you tend to see every problem as a nail." --
>Abraham Maslow



From hmurray at megapathdsl.net  Wed Feb  1 04:12:19 2012
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 01 Feb 2012 02:12:19 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked 
 Networks)
Message-ID: <20120201101219.3A9D7800037@ip-64-139-1-69.sjc.megapath.net>

I'm not a lawyer nor an operator.

> Imagine that instead of www.google.com, it was www.whitehouse.gov

> At some point, I suspect that this gets service to get it fixed RIGHT NOW.
> At some point, the guys informing you it's RIGHT NOW show up with badges.

Where is Milo Medin when we need him?

> The question is, when is it badges?  It can be construed as a denial of
> service attack on the addresses' rightful owners.  They will respond to any
> major government site being hijacked.  Probably to Apple or Google.  Likely
> to a Tier-1 ISPs internal infrastructure. 

How long should it take to fix a problem like this?

Why didn't one of the players upstream from the bad guy pull their plug or 
drop the bogus announcement?  Why didn't any of the players between the first 
upstream and the tier 1s apply pressure?

Do existing contracts cover this case?  If not, what needs to be fixed?  Is a 
RFC needed so the lawyers have something to reference?

Would a session to discuss this at a NANOG gathering help?


> a) law enforcement doesn't understand the problem. and b) the law moves
> very slowly. 

It might be a good idea to make sure that somebody in law enforcement does 
understands what happened here so they can think about what who needs to do 
what the next time something like this happens.  (Make sure that operators 
know how to get in touch with somebody who knows.)


-- 
These are my opinions, not necessarily my employer's.  I hate spam.





From brian_mk at live.com  Wed Feb  1 04:32:07 2012
From: brian_mk at live.com (Brian)
Date: Wed, 1 Feb 2012 10:32:07 +0000 (UTC)
Subject: IP KVM suggestions
References: <mailman.1976.1327950320.46019.nanog@nanog.org>
 <4F270787.403@gmail.com>
Message-ID: <loom.20120201T111713-788@post.gmane.org>

> On 1/30/2012 11:05 AM, nanog-request <at> nanog.org wrote:
> > ------------------------------
> >
> > Message: 8
> > Date: Mon, 30 Jan 2012 12:09:16 -0600
> > From: "Express Web Systems" <mailinglists <at> expresswebsystems.com>
> > To: "'NANOG'" <nanog <at> nanog.org>
> > Subject: RE: IP KVM suggestions
> > Message-ID: <033601ccdf7a$481d0f90$d8572eb0$@com>
> > Content-Type: text/plain;	charset="us-ascii"
> >
> >> > I have a need for a small, portable, web based IP kvm with decent
> >> > features that doesn't break the bank.  Preferably something that
> >> > supports ISO mounting from http or ftp and USB connectivity.  Would
> >> > also prefer something browser independent.  Small plugin like the
> >> > Raritan devices would be acceptable too. It will be used internally for
> >> > Remote access while building devices pre deployment to customers.  Any
> >> > suggestions?
> >> > 
> >> > Thanks!
> >> > 
> >> > Blake

Brian <brian_mk)<at> live.com> writes:

Hi Blake,

Are you familiar with the PX device (http://minicom.com/kvm_px.htm)? We have it 
placed at several customer sites, and so far extremely reliable. It comes with 
VM included, but can with a special power cable also give you remote power 
control. I give it two thumbs up.

Cheers,
Brian






From mailinglist at theflux.net  Wed Feb  1 09:32:58 2012
From: mailinglist at theflux.net (TFML)
Date: Wed, 1 Feb 2012 10:32:58 -0500
Subject: US DOJ victim letter
In-Reply-To: <CAB+BaiO8RC-pan-GYPv7yJUc3CTk2SWapj8BN0-8morHzJiJyg@mail.gmail.com>
References: <201201201908.q0KJ8u6C045030@mail.r-bonomi.com>
 <CB482859.5D359%carlos@race.com> <20120127181626.GC21814@lab.pobox.com>
 <Pine.LNX.4.61.1201271503160.24418@soloth.lewis.org>
 <CAB+BaiO8RC-pan-GYPv7yJUc3CTk2SWapj8BN0-8morHzJiJyg@mail.gmail.com>
Message-ID: <FE8E6728-7DDA-4CC6-8ADA-F448C53117DE@theflux.net>

If the IP list is pointing to DNS servers, they maybe referring to the following:

http://www.us-cert.gov/reading_room/DNS-recursion033006.pdf

On Jan 31, 2012, at 7:38 PM, Phil Dyer wrote:

> On Fri, Jan 27, 2012 at 3:23 PM, Jon Lewis <jlewis at lewis.org> wrote:
>> On Fri, 27 Jan 2012, Bryan Horstmann-Allen wrote:
> 
>>> Bit odd, if it's a phish. Even more odd if it's actually from the Fed.
>> 
>> 
>> It's definitely real, but seems like they're handling it as incompetently as
>> possible.
> 
> 
> Yep. That sounds about right.
> 
> Man, I'm feeling left out. I kinda want one now.
> 
> phil
> 



From obriapqz at bc.edu  Wed Feb  1 09:59:06 2012
From: obriapqz at bc.edu (Christopher O'Brien)
Date: Wed, 1 Feb 2012 10:59:06 -0500
Subject: Console Server Recommendation
In-Reply-To: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
Message-ID: <4F29614A.6050307@bc.edu>

On 1/30/12 11:08 AM, Ray Soucy wrote:
> What are people using for console servers these days?  We've
> historically used retired routers with ASYNC ports, but it's time for
> an upgrade.
>
> OpenGear seems to have some nice stuff, anyone else?
>

I've been using Western Telematic TSM-40 console servers and have been 
very happy with the price point and feature set.

Also, I aggregate console connections from different parts of my campus 
over my existing fiber plant using TC Communications TC1880 Async Fiber 
MUXs.  This combination has served me well.


From gbonser at seven.com  Wed Feb  1 11:00:43 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 1 Feb 2012 17:00:43 +0000
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
References: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09C9E402@RWC-MBX1.corp.seven.com>

> I'd like to get a conversation going and possibly some support of an
> initiative to spend that extra 30-seconds to verify ownership and
> authorization of network space to be advertised.  Additionally, if
> someone rings your NOC's line an industry-standard process of verifying
> "ownership"
> and immediately responding by filtering out announcements. There's no
> sense in allowing a service provider to be impaired because a spammer
> doesn't want to give up clean IP space.  Do you protect a bad customer
> or the Internet as a whole?  I pick the Internet as a whole.
> 
> How can we prevent anyone else from ever enduring this again?  While we
> may never stop it from ever happening, spammers (that's what we got hit
> by
> today) are a dime a dozen and will do everything possible to hit an
> Inbox, so how can we establish a protocol to immediate mitigate the
> effects of an traffic-stopping advertisement?

One problem is the number of routing registries and the requirements differ for them.  The nefarious operator can enter routes in an IRR just as easily as a legitimate operator.  There was a time when some significant networks used the IRRs for their filtration policy.  I'm not sure how many still do.

But generally speaking, if someone calls me and I can verify that they really are a POC for the entity that is assigned an address allocation (generally some verification method beyond email if the subnet their MX record points to is part of the hijacking!) then I am going to do whatever I can to help them out provided what they are asking for is reasonable and within my capabilities.  It shouldn't be too hard to verify.  If someone claims to be with a commercial entity of Foo.COM then the entity is likely listed in the phone book and a phone call can take care of my personal verification requirement.  

Back in the days of Cyberpromo and Sanford Wallace, what I did was used TCP wrappers on my mail server so that when I received a connection from a Cyberpromo net block, I hairpinned the connection back to his MX server using netcat so when he connected to me, the HELO he received was from his own mail server, which gladly accepted mail from Cyberpromo.  He could pump mail to me all day long if he wanted to, but his mailq wasn't going to get any smaller.

The problem of email spam is an interesting one that has been battled for a very long time and is probably better discussed on a list dedicated to that topic.



From owen at delong.com  Wed Feb  1 11:07:42 2012
From: owen at delong.com (Owen DeLong)
Date: Wed, 1 Feb 2012 09:07:42 -0800
Subject: Console Server Recommendation
In-Reply-To: <20120201073200.GA23107@pob.ytti.fi>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
 <20120131091136.GA22047@pob.ytti.fi>
 <15445673-C219-467D-BB5F-98C873B04355@delong.com>
 <20120201073200.GA23107@pob.ytti.fi>
Message-ID: <3C0E3475-9AEA-4418-A3B1-E9ABCA25CD93@delong.com>


On Jan 31, 2012, at 11:32 PM, Saku Ytti wrote:

> On (2012-01-31 11:09 -0800), Owen DeLong wrote:
> 
>>> - IP address mappable to a console port. So that accessing device normally
>>> is 'ssh router' and via OOB 'ssh router.oob' no need to train people
>> 
>> How about normal is 'ssh device' and OOB is 'console device'?
> 
> Home-baked systems are certainly good option to many, but for some of us it
> means we need to either hire worker to design, acquire, build and support
> them or consultant. And as you can find devices which support above
> requirements (opengear) TCO for us is simply just lower to buy one ready.
> 

I would hardly call conserver software a home-baked solution unless you'd
also call anything based on OSS a "home-baked solution".

You'd have to configure the tserv, ssh, and/or DNS in order to achieve
ssh device.oob, and you have to configure the tserv and the conserver
software in order to achieve what I suggested.

> 'console device' is what we do today, which is script someone needs to
> maintain (it picks up from DNS TXT records OOB and port where to connect).

If you use the conserver software, console isn't a script someone needs to
maintain, it's the client portion of the conserver software package.

> I prefer giving each port an IP and just use it via ssh (at least cyclades
> and opengear do this), if you are brave you could even setup same IP
> address for console and on-band loop, but I found that to be suboptimal, as
> you sometimes want to connect to OOB even when on-band is working.
> 

This takes away several of the other features from your list however, that are
implemented using the conserver software.

>> I agree that RS232 on a management plane would be a better choice. Personally,
>> I like the idea of having both RS232 and ethernet on dedicated management plane.
>> The RS232 allows you to deal with failures on the ethernet and the ethernet provides
>> support for image transfers, etc.
> 
> You can get that from Nexus7k and Sup7. I wouldn't use the RS232 at all
> myself. Probably it's easier to sell this at day1 with RS232 port, as it is
> required in many RFPs and when everyone has migrated to ethernet OOB,
> phase-out RS232.
> So people please add to your 'nice to have' requirements in RFP, proper OOB
> :). (Can't tell how many times we've had to power-cycle CSCO or JNPR due to
> control-plane console not responding)
> 

I've never seen a case where the control plane console failed to respond and I didn't
need to reboot the router to bring the control-plane back to life anyway. It's not like a
router can (usefully) continue for very long with a dead/locked-up control plane.

>> I will point out that the intel mobo OOB has not completely eliminated the need for
>> IPKVM in the datacenter. YMMV.
> 
> This is bit drifting on the subject, but what are you missing specifically?
> You get VNC KVM, all the way from boot to bios, to GUI or CLI. You also get
> IDE redirection, to boot the remote box from your laptop CDROM. And you get
> API to automatically install factory fresh boxes without ever touching the
> boxes.

Only so long as the BIOS doesn't lose its mind which happens with some
unfortunate regularity. With a good IPKVM such as the Raritans, I get
everything you just described with the added advantage of still being able
to connect to a server when it's BIOS has lost its mind. As nice as those
devices sound, they still have some failure modes that stop short of being
my ideal OOB solution.

Owen



From saku at ytti.fi  Wed Feb  1 11:24:44 2012
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 1 Feb 2012 19:24:44 +0200
Subject: Console Server Recommendation
In-Reply-To: <3C0E3475-9AEA-4418-A3B1-E9ABCA25CD93@delong.com>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
 <20120131091136.GA22047@pob.ytti.fi>
 <15445673-C219-467D-BB5F-98C873B04355@delong.com>
 <20120201073200.GA23107@pob.ytti.fi>
 <3C0E3475-9AEA-4418-A3B1-E9ABCA25CD93@delong.com>
Message-ID: <20120201172444.GA27031@pob.ytti.fi>

On (2012-02-01 09:07 -0800), Owen DeLong wrote:
 
> I would hardly call conserver software a home-baked solution unless you'd
> also call anything based on OSS a "home-baked solution".

Home-baked, i.e. it's not product you can get shipped and it'll work out of
the box and you have organization supporting it.
The shipping solutions are really nothing else than embedded linux running
conserver or equivalent, opengear even gives many of their oftware for
free.
It's certainly not difficult to roll one yourself, but for many of us, TCO
is lot more than just buying opengear.

> This takes away several of the other features from your list however, that are
> implemented using the conserver software.

The required list is satisfied by multiple offerings, including giving IP
address to console port. So there are products in the market doing exactly
what I want at cost which I'd be hard to reproduce even if I calculate my
time as free.

> I've never seen a case where the control plane console failed to respond
> and I didn't need to reboot the router to bring the control-plane back to
> life anyway. It's not like a router can (usefully) continue for very long
> with a dead/locked-up control plane.

Lot of people don't have way to remotely power cycle devices, if OOB is
separate management-plane, you can power cycle control-plane remotely. It's
probably <50USD BOM addition to list price, which server guys have enjoyed
for over decade and Cisco has been trying to introduce to networking guys.

> Only so long as the BIOS doesn't lose its mind which happens with some
> unfortunate regularity. With a good IPKVM such as the Raritans, I get

If you can access BIOS from console, you can access it via vPRO/AMT. If you
run into more exotic problem, it's cheaper just to swap that 50<100usd
motherboard than to investigate what happened.

-- 
  ++ytti


From drc at virtualized.org  Wed Feb  1 11:37:48 2012
From: drc at virtualized.org (David Conrad)
Date: Wed, 1 Feb 2012 09:37:48 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
Message-ID: <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>

On Jan 31, 2012, at 8:53 PM, Antonio Querubin wrote:
>> "We have a contractual relationship with our customer to announce that space.  We have neither a contractual relationship (in this context) with the RIR nor the RIR's customer.  The RIR and/or the RIR's customer should resolve this issue with our customer."
> Contracts are generally not a valid reason to be breaking laws.

Which law?

Regards,
-drc



From jlewis at lewis.org  Wed Feb  1 11:51:58 2012
From: jlewis at lewis.org (Jon Lewis)
Date: Wed, 1 Feb 2012 12:51:58 -0500 (EST)
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9E402@RWC-MBX1.corp.seven.com>
References: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9E402@RWC-MBX1.corp.seven.com>
Message-ID: <Pine.LNX.4.61.1202011215350.2201@soloth.lewis.org>

On Wed, 1 Feb 2012, George Bonser wrote:

> One problem is the number of routing registries and the requirements 
> differ for them.  The nefarious operator can enter routes in an IRR just 
> as easily as a legitimate operator.  There was a time when some 
> significant networks used the IRRs for their filtration policy.  I'm not 
> sure how many still do.

A few do, but IRR data really can't be trusted as a means of 
authenticating authority to advertise IP space.  It's a nice system for 
automating route filter updates (between the customer and 
provider...i.e. I add data to an IRR, and Level3 auto-updates my prefix 
filter), but when anyone can put anything into the IRR dbs, obviously 
everyone using the IRR dbs isn't going to stop someone from hijacking 
someone else's space.

As a regional ISP / hosting provider, my policy for accepting BGP routes 
from customers has been to check RIR whois data, make sure the space 
appears to be owned by the customer, and if there's any question, ask for 
clarification and/or an LOA from the customer showing that they are 
authorized to use the space.  Every customer gets a prefix filter that 
allows them to announce only what we've verified they're authorized to 
announce.

Level3, I suppose, just trusts customers won't announce space they 
shouldn't.  The alternative, which I've dealt with with some other "Tier 
1's" is that they require customers to provide an LOA every time they want 
to add a CIDR to their prefix filter.  That's more paper work for me and 
for them, and tends to be slower, as someone has to manually approve 
(maybe manually apply) the change request.

Given what we have available today, there's security or convenience...pick 
one.

It seems like the IRR thing could reasonably easily be solved if the RIRs 
got more deeply involved.

Suppose, as an ARIN member, I used ARIN's IRR.  I'd start out by 
registering my maintainer object, my ASN, my routes, and an as-set. 
Then, when I wanted to add customer ASNs to my as-set, the system wouldn't 
allow me to do so unless the customer had already registered their ASN 
with my ASN as an approved provider/path.  The customer, if they had no 
ASN, would be responsible for updating their route (PI or PA) in the IRR 
db, stating my ASN is a valid origin for their route. This would solve the 
problem of larger providers like Level3 blindly accepting my as-set 
because all the authentication/authorization would already have been done 
before the data went into the IRR db.  Things get a little more 
complicated when I pick up a customer who has "out of region" objects, 
i.e. RIPE IPs/ASN, but if all the RIRs worked together and standardized 
how the information is maintained, it could work.  i.e. When I try to add 
the RIPE ASN to my as-set, ARIN's system would check RIPE's system to see 
if that ASN's owner had set my ASN as a valid provider/path for their ASN.

This seems so simple, either it should have been implemented a decade or 
more ago, or perhaps I'm overlooking something.  It wouldn't stop route 
advertisements from providers who don't care / don't filter, but it would 
make systems like Level3's more secure...and if all the "Tier 1's" adopted 
similar automated filter generators based on the RIR IRR dbs, it would 
stop unauthorized announcements from getting far.

> The problem of email spam is an interesting one that has been battled 
> for a very long time and is probably better discussed on a list 
> dedicated to that topic.

Definitely...but the issue here is ownership/authorization to use IP 
space, and how stop unauthorized BGP announcements when providers don't or 
won't filter their BGP customers.

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


From morrowc.lists at gmail.com  Wed Feb  1 11:55:30 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 1 Feb 2012 12:55:30 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <20120201101219.3A9D7800037@ip-64-139-1-69.sjc.megapath.net>
References: <20120201101219.3A9D7800037@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAL9jLaZgKjCjzx__KTJw2CH1S5MyvzUu7c66VMkcP1hHQsz3Hw@mail.gmail.com>

On Wed, Feb 1, 2012 at 5:12 AM, Hal Murray <hmurray at megapathdsl.net> wrote:
> I'm not a lawyer nor an operator.
>
>> Imagine that instead of www.google.com, it was www.whitehouse.gov
>
>> At some point, I suspect that this gets service to get it fixed RIGHT NOW.
>> At some point, the guys informing you it's RIGHT NOW show up with badges.
>
> Where is Milo Medin when we need him?

how would he be helping?

>> The question is, when is it badges? ?It can be construed as a denial of
>> service attack on the addresses' rightful owners. ?They will respond to any
>> major government site being hijacked. ?Probably to Apple or Google. ?Likely
>> to a Tier-1 ISPs internal infrastructure.
>
> How long should it take to fix a problem like this?

the YT/pk-telecom incident lasted: 2hr 15mins according to renesys
(http://www.renesys.com/blog/2008/02/pakistan-hijacks-youtube-1.shtml)

I think for a few reasons this ONLY lasted 2hrs... one at least being
pktelecom getting some pain from this hijack, plus they PROBABLY
didn't mean to do what they did. (Oops, we fat-fingered, lets fix
that...)

Why did this take even 2hrs? why is the currrent incident lasting
(lasted?) as long as it has? what system(s) would make this problem
better? Danny refers to 'resource certification', I think he's
pointing at RPKI[1], how far out is this? (seems like ~5+ yrs or so
til useful deployment arrives, not even counting router-code for this
appearing in the main set of deployed devices).

-chris
[1]: <http://www.afrinic.net/membership/certification.htm>  (other
RIR's are also represented, this was just the first relevant answer in
bing)

(all discussion of laws is ridiculous... which jurisdiction, which
law, which .... forget about any reasonable answer here)


From owen at delong.com  Wed Feb  1 11:55:02 2012
From: owen at delong.com (Owen DeLong)
Date: Wed, 1 Feb 2012 09:55:02 -0800
Subject: Console Server Recommendation
In-Reply-To: <20120201172444.GA27031@pob.ytti.fi>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
 <20120131091136.GA22047@pob.ytti.fi>
 <15445673-C219-467D-BB5F-98C873B04355@delong.com>
 <20120201073200.GA23107@pob.ytti.fi>
 <3C0E3475-9AEA-4418-A3B1-E9ABCA25CD93@delong.com>
 <20120201172444.GA27031@pob.ytti.fi>
Message-ID: <05509014-2199-43C0-9BD2-AF4744934458@delong.com>


On Feb 1, 2012, at 9:24 AM, Saku Ytti wrote:

> On (2012-02-01 09:07 -0800), Owen DeLong wrote:
> 
>> I would hardly call conserver software a home-baked solution unless you'd
>> also call anything based on OSS a "home-baked solution".
> 
> Home-baked, i.e. it's not product you can get shipped and it'll work out of
> the box and you have organization supporting it.
> The shipping solutions are really nothing else than embedded linux running
> conserver or equivalent, opengear even gives many of their oftware for
> free.
> It's certainly not difficult to roll one yourself, but for many of us, TCO
> is lot more than just buying opengear.
> 

It's a product you can download, compile, configure and it works out of the box.

It is pretty well supported by the authors and they have been very responsive to
each and every question/feature/other request I have made to them, no matter
how stupid. In fact, it has been better supported in my experience than most
boxed software.

conserver doesn't replace the opengear products, it's a software package that
sits next to them and provides increased functionality of the type you suggested
would be desirable.

It's no more difficult to configure conserver than to set up the DNS to do what
you were suggesting with SSH.

>> This takes away several of the other features from your list however, that are
>> implemented using the conserver software.
> 
> The required list is satisfied by multiple offerings, including giving IP
> address to console port. So there are products in the market doing exactly
> what I want at cost which I'd be hard to reproduce even if I calculate my
> time as free.
> 

I think you are misunderstanding and thinking I propose conserver as a
replacement for MRV/Cyclades/etc. I do not. I propose it as a way to get
most of the features you wanted that aren't present in those boxes by
adding it to them.

It has the additional advantage that it can provide the same functionality
transparently across a wide variety of tserv hardware so that you can
use multiple manufacturers over time and keep that transparent for the
most part.

>> I've never seen a case where the control plane console failed to respond
>> and I didn't need to reboot the router to bring the control-plane back to
>> life anyway. It's not like a router can (usefully) continue for very long
>> with a dead/locked-up control plane.
> 
> Lot of people don't have way to remotely power cycle devices, if OOB is
> separate management-plane, you can power cycle control-plane remotely. It's
> probably <50USD BOM addition to list price, which server guys have enjoyed
> for over decade and Cisco has been trying to introduce to networking guys.
> 

Agreed. Nonetheless, power cycling the box vs. power cycling the control plane
isn't a huge difference from my perspective.

>> Only so long as the BIOS doesn't lose its mind which happens with some
>> unfortunate regularity. With a good IPKVM such as the Raritans, I get
> 
> If you can access BIOS from console, you can access it via vPRO/AMT. If you
> run into more exotic problem, it's cheaper just to swap that 50<100usd
> motherboard than to investigate what happened.
> 

Tell me that again when your device looses it's mind and the vPRO/AMT doesn't
come up with a workable IP address. RS-232 does NOT have this problem.


Owen



From tony at lavanauts.org  Wed Feb  1 12:15:28 2012
From: tony at lavanauts.org (Antonio Querubin)
Date: Wed, 1 Feb 2012 08:15:28 -1000 (HST)
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
Message-ID: <alpine.LRH.2.02.1202010813460.2419@sol.manaikaika.com>

On Wed, 1 Feb 2012, David Conrad wrote:

> On Jan 31, 2012, at 8:53 PM, Antonio Querubin wrote:
>>> "We have a contractual relationship with our customer to announce that space.  We have neither a contractual relationship (in this context) with the RIR nor the RIR's customer.  The RIR and/or the RIR's customer should resolve this issue with our customer."
>> Contracts are generally not a valid reason to be breaking laws.
>
> Which law?

I think if you provided more specific details of your example, I suspect 
some of us could probably come up with some specific laws that may have 
been broken :)

Antonio Querubin
e-mail:  tony at lavanauts.org
xmpp:  antonioquerubin at gmail.com


From gbonser at seven.com  Wed Feb  1 12:15:35 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 1 Feb 2012 18:15:35 +0000
Subject: Console Server Recommendation
In-Reply-To: <05509014-2199-43C0-9BD2-AF4744934458@delong.com>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
 <20120131091136.GA22047@pob.ytti.fi>
 <15445673-C219-467D-BB5F-98C873B04355@delong.com>
 <20120201073200.GA23107@pob.ytti.fi>
 <3C0E3475-9AEA-4418-A3B1-E9ABCA25CD93@delong.com>
 <20120201172444.GA27031@pob.ytti.fi>
 <05509014-2199-43C0-9BD2-AF4744934458@delong.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5A7@RWC-MBX1.corp.seven.com>

> It's a product you can download, compile, configure and it works out of
> the box.
> 
> It is pretty well supported by the authors and they have been very
> responsive to each and every question/feature/other request I have made
> to them, no matter how stupid. In fact, it has been better supported in
> my experience than most boxed software.
> 
> conserver doesn't replace the opengear products, it's a software
> package that sits next to them and provides increased functionality of
> the type you suggested would be desirable.
> 
> It's no more difficult to configure conserver than to set up the DNS to
> do what you were suggesting with SSH.

On Ubuntu Linux:  

apt-get install conserver-server
apt-get install conserver-client

You need one conserver server and can have as many clients as you want.  

Getting the software installed is pretty much dead simple. Configuring it is pretty darned intuitive, too.

> I think you are misunderstanding and thinking I propose conserver as a
> replacement for MRV/Cyclades/etc. I do not. I propose it as a way to
> get most of the features you wanted that aren't present in those boxes
> by adding it to them.

Exactly.  It is extremely handy for providing a standard interface / set of features if you have a mix of different console server hardware.  It is simply a layer of abstraction that lives above the console server hardware and allows you to buffer content, share sessions, etc.

 
> It has the additional advantage that it can provide the same
> functionality transparently across a wide variety of tserv hardware so
> that you can use multiple manufacturers over time and keep that
> transparent for the most part.

+1  sure makes things simple if you have different gear at different sites or have changed vendors over the years and have legacy stuff still in service.




From frnkblk at iname.com  Wed Feb  1 12:15:53 2012
From: frnkblk at iname.com (Frank Bulk)
Date: Wed, 1 Feb 2012 12:15:53 -0600
Subject: Console Server Recommendation
In-Reply-To: <4F29614A.6050307@bc.edu>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
 <4F29614A.6050307@bc.edu>
Message-ID: <00a101cce10d$88dfbb10$9a9f3130$@iname.com>

We use WTI, too, just don't like it that it reboots to apply a change.

Frank

-----Original Message-----
From: Christopher O'Brien [mailto:obriapqz at bc.edu] 
Sent: Wednesday, February 01, 2012 9:59 AM
To: nanog at nanog.org
Subject: Re: Console Server Recommendation

On 1/30/12 11:08 AM, Ray Soucy wrote:
> What are people using for console servers these days?  We've
> historically used retired routers with ASYNC ports, but it's time for
> an upgrade.
>
> OpenGear seems to have some nice stuff, anyone else?
>

I've been using Western Telematic TSM-40 console servers and have been 
very happy with the price point and feature set.

Also, I aggregate console connections from different parts of my campus 
over my existing fiber plant using TC Communications TC1880 Async Fiber 
MUXs.  This combination has served me well.





From gbonser at seven.com  Wed Feb  1 12:16:46 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 1 Feb 2012 18:16:46 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>

> >> "We have a contractual relationship with our customer to announce
> that space.  We have neither a contractual relationship (in this
> context) with the RIR nor the RIR's customer.  The RIR and/or the RIR's
> customer should resolve this issue with our customer."
> > Contracts are generally not a valid reason to be breaking laws.
> 
> Which law?
> 
> Regards,
> -drc
> 

Let's say I had a business in space in a building I was leasing at 100 Main Street, Podunk, USA.  Now let's say you didn't renew the lease so I moved to a building up the block but put the 100 Main Street address on my new location and continued to use that address for my business.

Or let's say I operated a TV station on channel 37 that was allocated to you but you terminate my operating contract.  So I lease/erect a new transmitter and continue broadcasting on channel 37.

There obviously must be a remedy for two parties attempting to utilize the same resource at the same time, particularly when one party is the rightfully in control of that resource's use.  It might be civil rather than criminal but the rightful owner of the resource would have a good case.


From bill at herrin.us  Wed Feb  1 12:47:21 2012
From: bill at herrin.us (William Herrin)
Date: Wed, 1 Feb 2012 13:47:21 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
Message-ID: <CAP-guGWm5dZTf0Hx=z-9+PpopuRNZUswjX=+_eTJd-jHA5uixA@mail.gmail.com>

On Wed, Feb 1, 2012 at 12:37 PM, David Conrad <drc at virtualized.org> wrote:
> On Jan 31, 2012, at 8:53 PM, Antonio Querubin wrote:
>>> "We have a contractual relationship with our customer to announce that space. ?We have neither a contractual relationship (in this context) with the RIR nor the RIR's customer. ?The RIR and/or the RIR's customer should resolve this issue with our customer."
>> Contracts are generally not a valid reason to be breaking laws.
>
> Which law?

Tortious interference at the very least. Or did you mean criminal law
as opposed to common law?

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From lists at billmerriam.com  Wed Feb  1 12:54:02 2012
From: lists at billmerriam.com (Bill Merriam)
Date: Wed, 1 Feb 2012 13:54:02 -0500
Subject: ATT, IPv6 and 6RD
Message-ID: <20120201135402.1eecd24d@kilo.billmerriam.com>

I now have ATT IPv6 over their residential ADSL broadband.  They
deployed using 6RD which means every time your IPv4 address changes
your IPv6 address changes also.  Does anybody have a clue why they
chose to use 6RD instead of the much more fully-assed TR-187 for their
deployment?

Saying they're dimwits doesn't count.

Bill


From nanog at hostleasing.net  Wed Feb  1 13:15:02 2012
From: nanog at hostleasing.net (Randy Epstein)
Date: Wed, 01 Feb 2012 14:15:02 -0500
Subject: UCE: Re: Fiber outage in Miami
In-Reply-To: <CAGSJx7sFN_W31Jq9zwrKodBgPwmVjWiEBWGQqtCjLD237spBTw@mail.gmail.com>
Message-ID: <CB4EF949.5B00F%nanog@hostleasing.net>



On 1/30/12 11:53 AM, "Joe Marr" <jimmy.changa007 at gmail.com> wrote:

>I've yet to hear back from them on the reason for the outage and
>explanation on why our "redundant" darkfiber pairs both were down.

They cut ALL THE FIBER going into MI1 .. At the same time.

Randy




From trejrco at gmail.com  Wed Feb  1 13:16:58 2012
From: trejrco at gmail.com (TJ)
Date: Wed, 1 Feb 2012 14:16:58 -0500
Subject: ATT, IPv6 and 6RD
In-Reply-To: <20120201135402.1eecd24d@kilo.billmerriam.com>
References: <20120201135402.1eecd24d@kilo.billmerriam.com>
Message-ID: <CALOgxGZ=V9sB2j90ACSj4uW3OvCH1ccenLh4Aigt1RkA94GvFw@mail.gmail.com>

On Wed, Feb 1, 2012 at 13:54, Bill Merriam <lists at billmerriam.com> wrote:

> I now have ATT IPv6 over their residential ADSL broadband.  They
> deployed using 6RD which means every time your IPv4 address changes
> your IPv6 address changes also.  Does anybody have a clue why they
> chose to use 6RD instead of the much more fully-assed TR-187 for their
> deployment?
>
>
My guess: 6RD pretty readily solves the last-5-miles / provisioning
problems - assuming the CPE supports it.  Oh, and they expect you to expect
your address to change.

Out of curiosity - are they giving you a single /64, or something more
reasonable / generous?
Also OOC - how is the IPv6/6RD throughput & latency, compared to
native/NATed IPv4?


/TJ

From paul4004 at gmail.com  Wed Feb  1 13:53:54 2012
From: paul4004 at gmail.com (PC)
Date: Wed, 1 Feb 2012 12:53:54 -0700
Subject: US DOJ victim letter
In-Reply-To: <FE8E6728-7DDA-4CC6-8ADA-F448C53117DE@theflux.net>
References: <201201201908.q0KJ8u6C045030@mail.r-bonomi.com>
 <CB482859.5D359%carlos@race.com>
 <20120127181626.GC21814@lab.pobox.com>
 <Pine.LNX.4.61.1201271503160.24418@soloth.lewis.org>
 <CAB+BaiO8RC-pan-GYPv7yJUc3CTk2SWapj8BN0-8morHzJiJyg@mail.gmail.com>
 <FE8E6728-7DDA-4CC6-8ADA-F448C53117DE@theflux.net>
Message-ID: <CAJAdsD=cnKjtsB2owLgq3zmeRZw66k5J+Ty891WP1xkTzfbZ0w@mail.gmail.com>

I received one on an IP block that were SWIPed to me.

Has anyone written a regular expression which matches the rogue dns server
IP ranges in question?

   - 85.255.112.0 through 85.255.127.255;
   - 67.210.0.0 through 67.210.15.255;
   - 93.188.160.0 through 93.188.167.255;
   - 77.67.83.0 through 77.67.83.255;
   - 213.109.64.0 through 213.109.79.255;
   - 64.28.176.0 through 64.28.191.255;



On Wed, Feb 1, 2012 at 8:32 AM, TFML <mailinglist at theflux.net> wrote:

> If the IP list is pointing to DNS servers, they maybe referring to the
> following:
>
> http://www.us-cert.gov/reading_room/DNS-recursion033006.pdf
>
> On Jan 31, 2012, at 7:38 PM, Phil Dyer wrote:
>
> > On Fri, Jan 27, 2012 at 3:23 PM, Jon Lewis <jlewis at lewis.org> wrote:
> >> On Fri, 27 Jan 2012, Bryan Horstmann-Allen wrote:
> >
> >>> Bit odd, if it's a phish. Even more odd if it's actually from the Fed.
> >>
> >>
> >> It's definitely real, but seems like they're handling it as
> incompetently as
> >> possible.
> >
> >
> > Yep. That sounds about right.
> >
> > Man, I'm feeling left out. I kinda want one now.
> >
> > phil
> >
>
>
>

From cmadams at hiwaay.net  Wed Feb  1 14:06:38 2012
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 1 Feb 2012 14:06:38 -0600
Subject: Console Server Recommendation
In-Reply-To: <3C0E3475-9AEA-4418-A3B1-E9ABCA25CD93@delong.com>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
 <20120131091136.GA22047@pob.ytti.fi>
 <15445673-C219-467D-BB5F-98C873B04355@delong.com>
 <20120201073200.GA23107@pob.ytti.fi>
 <3C0E3475-9AEA-4418-A3B1-E9ABCA25CD93@delong.com>
Message-ID: <20120201200638.GD10680@hiwaay.net>

Once upon a time, Owen DeLong <owen at delong.com> said:
> I would hardly call conserver software a home-baked solution unless you'd
> also call anything based on OSS a "home-baked solution".

Console server hardware: buy appliance, plug it in, set password/IP
Home-baked box: buy server (or buy parts and assemble), buy a serial
   card (make sure it is supported by Linux/BSD distribution of choice),
   install/configure OS, install/configure console server software

Which one is worth my company's time for me to install?  If you are
going to install and maintain hundreds of them, the second might come
out ahead eventually (assuming you script the install/configure steps),
but the first is going to win almost all the time.

I build stuff for personal use, but at work, we look for canned
solutions to most needs.  I have a couple of Linux firewalls where I
wanted some extra flexibility, but we've got an Avocent console server
(of course, Avocent is also a customer, and it is good to give a
customer a little business).
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From drc at virtualized.org  Wed Feb  1 14:10:00 2012
From: drc at virtualized.org (David Conrad)
Date: Wed, 1 Feb 2012 12:10:00 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
Message-ID: <FABE3FD6-B5D4-4801-91FC-9B324D83FC46@virtualized.org>

On Feb 1, 2012, at 10:16 AM, George Bonser wrote:

>>>> "We have a contractual relationship with our customer to announce
>>>> that space.  We have neither a contractual relationship (in this
>>>> context) with the RIR nor the RIR's customer.  The RIR and/or the RIR's
>>>> customer should resolve this issue with our customer."
>>> Contracts are generally not a valid reason to be breaking laws.
>> Which law?
> Let's say I had a business in space in a building I was leasing at 100 Main Street, Podunk, USA.

I'm told IP addresses aren't property.

> Or let's say I operated a TV station

As I understand it, radio frequencies are subject to international treaties. In signatory countries, laws can be enacted to enforce the provisions of those treaties. As far as I'm aware, there are no treaties dealing with IP addresses or how those addresses are announced.

> It might be civil rather than criminal but the rightful owner of the resource would have a good case.

"Owner"?

Long ago, Mitch Kapor (I believe) described the Internet addressing system working because of the "Tinkerbelle Effect", that is (to paraphase), it works because everyone believes it is in their best interests that it works.  However, as we've seen when push comes to shove, the Tinkerbelle Effect can break down.  Thus, you get perfectly justifiable arguments for stuff like RPKI/BGPSEC and the equivalent of the Protocol Police.  This does have the potential for unintended (and intended) consequences...

Regards,
-drc



From cmadams at hiwaay.net  Wed Feb  1 14:10:12 2012
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 1 Feb 2012 14:10:12 -0600
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
Message-ID: <20120201201012.GE10680@hiwaay.net>

Once upon a time, George Bonser <gbonser at seven.com> said:
> Let's say I had a business in space in a building I was leasing at 100 Main Street, Podunk, USA.  Now let's say you didn't renew the lease so I moved to a building up the block but put the 100 Main Street address on my new location and continued to use that address for my business.

That's covered under trespassing laws.

> Or let's say I operated a TV station on channel 37 that was allocated to you but you terminate my operating contract.  So I lease/erect a new transmitter and continue broadcasting on channel 37.

That's covered under FCC regulations on use of public spectrum.

AFAIK there's no law covering the use of what party X considers their 32
bit numbers (assigned by party A) by party Y.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From nathan at atlasnetworks.us  Wed Feb  1 14:16:23 2012
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Wed, 1 Feb 2012 20:16:23 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <20120201201012.GE10680@hiwaay.net>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>

> AFAIK there's no law covering the use of what party X considers their
> 32 bit numbers (assigned by party A) by party Y.
 
So, to pose the obvious question: Should there be?

(I honestly don't know the answer is to this question, and am asking in earnest for opinions on the subject)

Nathan




From me at anuragbhatia.com  Wed Feb  1 14:25:03 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 2 Feb 2012 01:55:03 +0530
Subject: Question regarding anycasting in CDN setup
Message-ID: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>

Hello everyone!

I have a small question and was wondering if someone could help me with
that.

Question is - why companies like Google, Amazon are having partial
anycasting in CDN setups? E.g if we pick a random hostname from url of
Picasa picture - lh3.googleusercontent.com - this one is further a cname
string and at the end you will find different A records when checked from
different locations.

E.g when checked from my local system (in India):

;; QUESTION SECTION:
;lh3.googleusercontent.com. IN A

;; ANSWER SECTION:
lh3.googleusercontent.com. 86276 IN CNAME
googlehosted.l.googleusercontent.com.
googlehosted.l.googleusercontent.com. 176 IN A 209.85.175.132





Next, lookup from a server in Europe:

;; QUESTION SECTION:
;lh3.googleusercontent.com. IN A

;; ANSWER SECTION:
lh3.googleusercontent.com. 86400 IN CNAME
googlehosted.l.googleusercontent.com.
googlehosted.l.googleusercontent.com. 300 IN A 209.85.148.132


thus different IPs in both cases.

I understand that Google is doing anycasting on core DNS servers, and thus
we always hit nearest DNS server and all DNS servers are sort of
independent and carry different A records for CDN strings which point to
local cache server IP addresses. And here's confirmation:

anurag at laptop:~$ dig googleusercontent.com. ns +short
ns2.google.com.
ns3.google.com.
ns4.google.com.
ns1.google.com.



Picking ns1.google.com. and asking IP for
googlehosted.l.googleusercontent.com. from different locations:

anurag at laptop:~$ dig @ns1.google.com googlehosted.l.googleusercontent.com.
a +short
209.85.175.132


anurag at server7:~$ dig @ns1.google.com googlehosted.l.googleusercontent.com.
a +short
209.85.148.132



As expected - same server (which appears same but is different) giving
different values - thus I am actually hitting different servers in both
cases.

Now my question here is - why this setup and not simply using having a A
record for googlehosted.l.googleusercontent.com. which comes from any
anycasted IP address space? Why not anycasting at CDN itself rather then
only at DNS layer?


Can someone explain?


Thanks!

-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
Linkedin: http://linkedin.anuragbhatia.com

From cmadams at hiwaay.net  Wed Feb  1 14:25:43 2012
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 1 Feb 2012 14:25:43 -0600
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
Message-ID: <20120201202543.GF10680@hiwaay.net>

Once upon a time, Nathan Eisenberg <nathan at atlasnetworks.us> said:
> > AFAIK there's no law covering the use of what party X considers their
> > 32 bit numbers (assigned by party A) by party Y.
>  
> So, to pose the obvious question: Should there be?
> 
> (I honestly don't know the answer is to this question, and am asking in earnest for opinions on the subject)

Personally, I'd rather see the networking community work it out
internally, rather than invite government intervention (I hardly think
it would stop at regulating 32/128 bit numbers).

Besides, how would that work?  Say ARIN assigns US company X (operating
only in the US) a block, but German company Y (with no US operations)
starts announcing the same block.  How are US or German laws going to
help, when the parties have no common jurisdiction?

There need to be better ways to notify (and get action from) upstreams,
upstreams/peers of upstreams, etc.  Since not all peering is public
knowledge, it can be difficult to know who needs notification, so some
type of clearinghouse would be good.  Maybe a mailing list, made up of
network operators, in some type of group, ... :-)

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From sethm at rollernet.us  Wed Feb  1 14:28:44 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 01 Feb 2012 12:28:44 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
Message-ID: <4F29A07C.1000400@rollernet.us>

On 2/1/12 10:16 AM, George Bonser wrote:
> 
> Let's say I had a business in space in a building I was leasing at 100 Main Street, Podunk, USA.  Now let's say you didn't renew the lease so I moved to a building up the block but put the 100 Main Street address on my new location and continued to use that address for my business.
> 
> Or let's say I operated a TV station on channel 37 that was allocated to you but you terminate my operating contract.  So I lease/erect a new transmitter and continue broadcasting on channel 37.
> 
> There obviously must be a remedy for two parties attempting to utilize the same resource at the same time, particularly when one party is the rightfully in control of that resource's use.  It might be civil rather than criminal but the rightful owner of the resource would have a good case.
> 

The FCC has teeth if someone decided to disregard them. There is no
analogue in the world of IP address assignments.

~Seth


From cgucker at onesc.net  Wed Feb  1 14:36:46 2012
From: cgucker at onesc.net (Charles Gucker)
Date: Wed, 1 Feb 2012 15:36:46 -0500
Subject: Question regarding anycasting in CDN setup
In-Reply-To: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
References: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
Message-ID: <CALB2hAf74FzSA4zdiJ-YrT4o_94qWm28TQ5GrZN2Z0MhW+W57A@mail.gmail.com>

On Wed, Feb 1, 2012 at 3:25 PM, Anurag Bhatia <me at anuragbhatia.com> wrote:
> Hello everyone!
>
> I have a small question and was wondering if someone could help me with
> that.
>
> Question is - why companies like Google, Amazon are having partial
> anycasting in CDN setups? E.g if we pick a random hostname from url of
> Picasa picture - lh3.googleusercontent.com - this one is further a cname
> string and at the end you will find different A records when checked from
> different locations.

The simple answer for this is, Google cannot be expected to have a
local cache of every image supplied to them globally on every server.
 So they use unicast servers behind a DNS based geo load balancer
configuration.     As for DNS, every anycasted node is expected to be
able to resolve any DNS request that is made.

It's all a matter of disk and acceptable delay in providing the data
from the "closest" disk.

charles


From jared at puck.nether.net  Wed Feb  1 14:40:58 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 1 Feb 2012 15:40:58 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <20120201201012.GE10680@hiwaay.net>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
Message-ID: <07DB7F4C-C4F1-4DAA-845E-075F63AFFC70@puck.nether.net>


On Feb 1, 2012, at 3:10 PM, Chris Adams wrote:

> AFAIK there's no law covering the use of what party X considers their 32
> bit numbers (assigned by party A) by party Y.

The US bankruptcy courts have treated these as property that can be
sold/transferred comparable to other assets.  (See threads re: borders,
microsoft, etc in 2011).

This does have the effect of being at least a cite in any further
litigation, even if the position is not upheld on appeal.

- Jared



From jared at puck.nether.net  Wed Feb  1 14:47:05 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 1 Feb 2012 15:47:05 -0500
Subject: Question regarding anycasting in CDN setup
In-Reply-To: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
References: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
Message-ID: <83650C5A-D243-4D1A-BDFD-C097417D6A05@puck.nether.net>


On Feb 1, 2012, at 3:25 PM, Anurag Bhatia wrote:

> I have a small question and was wondering if someone could help me with
> that.
> 
> Question is - why companies like Google, Amazon are having partial
> anycasting in CDN setups? E.g if we pick a random hostname from url of
> Picasa picture - lh3.googleusercontent.com - this one is further a cname
> string and at the end you will find different A records when checked from
> different locations.

The real answer to this is highly variable based on criteria that are unknown
by many people outside of the operators at these networks.

what is fairly well known:

1) Anycast can be used to provide low latency queries for stateless (UDP) and
   state full protocols (TCP).
2) Query responses will vary based on node hit and/or source IP address the
   query comes from.  Source address is used to attempt traffic localization.

   This can be defeated by using another resolver on purpose, or inadvertently
   (eg: corporate VPN may cause you to use a CDN node that is non-local by using
    corp DNS).
3) CDNs vary the response based upon uptime/load and other unknown policy criteria.
   They don't want to send you to a server that is down, nor one that is overloaded.

The secret is in the sauce here and is complex enough that it's not easy to perfect.

Also, be careful equating Anycast w/ CDN.  They are not the same thing but sometimes
are related.  (e.g.: cousins)

	- Jared

From gbonser at seven.com  Wed Feb  1 14:49:47 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 1 Feb 2012 20:49:47 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <FABE3FD6-B5D4-4801-91FC-9B324D83FC46@virtualized.org>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <FABE3FD6-B5D4-4801-91FC-9B324D83FC46@virtualized.org>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F7DD@RWC-MBX1.corp.seven.com>

> 
> I'm told IP addresses aren't property.

Neither is the address painted on your curb.  So it's ok for me to paint over the number in front of your house and paint your house number on my curb, right?

The issue isn't about property.  It is about stealing an ADDRESS making impossible for the legitimate holder of that ADDRESS to do business.  




From gbonser at seven.com  Wed Feb  1 14:54:39 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 1 Feb 2012 20:54:39 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <20120201201012.GE10680@hiwaay.net>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F7FA@RWC-MBX1.corp.seven.com>

Take the ex-customer and their immediate upstream providers to small claims and sue each of them for the maximum amount for your time and trouble in dealing with the issue.  If they don't show, get a judgment and put a lien on their stuff until they pay up.

I am not a lawyer and I am not telling you what you should do, only saying what I would consider doing in such an instance.




From gbonser at seven.com  Wed Feb  1 15:00:55 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 1 Feb 2012 21:00:55 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F823@RWC-MBX1.corp.seven.com>

> So, to pose the obvious question: Should there be?
> 
> (I honestly don't know the answer is to this question, and am asking in
> earnest for opinions on the subject)
> 
> Nathan
> 
> 

Well, calling the law on someone is kind of the whiner's way out anyway.  It would seem that the community could agree on a set of standards for dealing with such problems and if you don't agree to those standards, nobody routes your traffic.  In other words, if network A finds network B announcing allocated space belonging to network A and network A makes them (network B) and their upstream provider(s) aware and they refuse to stop the announcement, there should be a mechanism by which the community can agree to filter Network B's AS  *and* the AS of the upstream(s) until the situation is rectified.  That's a pretty big hammer but verifying someone's legitimate claim on address space isn't that hard, in most cases.  




From ikiris at gmail.com  Wed Feb  1 15:07:01 2012
From: ikiris at gmail.com (Blake Dunlap)
Date: Wed, 1 Feb 2012 15:07:01 -0600
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F823@RWC-MBX1.corp.seven.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F823@RWC-MBX1.corp.seven.com>
Message-ID: <CAJvB4tmLd1A53M76aimbO+uxenX5f8c9eppqpdF00t5niU5WXw@mail.gmail.com>

On Wed, Feb 1, 2012 at 15:00, George Bonser <gbonser at seven.com> wrote:

> > So, to pose the obvious question: Should there be?
> >
> > (I honestly don't know the answer is to this question, and am asking in
> > earnest for opinions on the subject)
> >
> > Nathan
> >
> >
>
> Well, calling the law on someone is kind of the whiner's way out anyway.
>  It would seem that the community could agree on a set of standards for
> dealing with such problems and if you don't agree to those standards,
> nobody routes your traffic.  In other words, if network A finds network B
> announcing allocated space belonging to network A and network A makes them
> (network B) and their upstream provider(s) aware and they refuse to stop
> the announcement, there should be a mechanism by which the community can
> agree to filter Network B's AS  *and* the AS of the upstream(s) until the
> situation is rectified.  That's a pretty big hammer but verifying someone's
> legitimate claim on address space isn't that hard, in most cases.
>
>
The problem is no one will actually blacklist a big ASN because its not in
the individual best interest, which scales greatly with size. RPKI is
pretty much the only real fix for this if the chain until the major carrier
refuses to delist, and RPKI has it's own issues.

-Blake

From marka at isc.org  Wed Feb  1 15:13:44 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 02 Feb 2012 08:13:44 +1100
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: Your message of "Wed, 01 Feb 2012 14:10:12 MDT."
 <20120201201012.GE10680@hiwaay.net>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
Message-ID: <20120201211344.2B9291CA11AB@drugs.dv.isc.org>


In message <20120201201012.GE10680 at hiwaay.net>, Chris Adams writes:
> Once upon a time, George Bonser <gbonser at seven.com> said:
> > Let's say I had a business in space in a building I was leasing at 100 Main
>  Street, Podunk, USA.  Now let's say you didn't renew the lease so I moved to
>  a building up the block but put the 100 Main Street address on my new locati
> on and continued to use that address for my business.
> 
> That's covered under trespassing laws.
> 
> > Or let's say I operated a TV station on channel 37 that was allocated to yo
> u but you terminate my operating contract.  So I lease/erect a new transmitte
> r and continue broadcasting on channel 37.
> 
> That's covered under FCC regulations on use of public spectrum.
> 
> AFAIK there's no law covering the use of what party X considers their 32
> bit numbers (assigned by party A) by party Y.

If you present a false letter of authority you are committing fraud.
If you continue to use address after the lease is up it is trespass
/ theft / breach of contract.

I'm sure there are lots more laws that can apply.  Counterfieting,
wire fraud.  Breaches of various Telecommunication Acts, etc.  You
might have juristictional issues.

In the case of the Internet we have a authority for handing out
numbers for use on  the Internet (IANA).  Courts all over the world
do recognise that authority directly or indirectly by recognising
the RIRs.

There are enough analogs in common law to almost everything that
happens on the Internet for there to no be the need for specific
"Internet" laws.   It's just that having a "Internet" law makes it
easier to prosecute.

Mark
> -- 
> Chris Adams <cmadams at hiwaay.net> 
> Systems and Network Administrator - HiWAAY Internet Services 
> I don't speak for anybody but myself - that's enough trouble.  
>
-- 
Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
INTERNET: marka at isc.org


From gbonser at seven.com  Wed Feb  1 15:21:01 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 1 Feb 2012 21:21:01 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CAJvB4tmLd1A53M76aimbO+uxenX5f8c9eppqpdF00t5niU5WXw@mail.gmail.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F823@RWC-MBX1.corp.seven.com>
 <CAJvB4tmLd1A53M76aimbO+uxenX5f8c9eppqpdF00t5niU5WXw@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F87D@RWC-MBX1.corp.seven.com>

> The problem is no one will actually blacklist a big ASN because its not
> in the individual best interest, which scales greatly with size. RPKI
> is pretty much the only real fix for this if the chain until the major
> carrier refuses to delist, and RPKI has it's own issues.
> 
> -Blake

Sadly, you're right. But my guess is that such a blacklisting would have to be done for only a very short period of time and once it is done once or twice, it would never need to be done again.  But it probably is too big a hammer.

Until there is some sort of registry that is the source of truth and is easy to use (distributed?), we're going to keep repeating this process.  


From ikiris at gmail.com  Wed Feb  1 15:35:08 2012
From: ikiris at gmail.com (Blake Dunlap)
Date: Wed, 1 Feb 2012 15:35:08 -0600
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F87D@RWC-MBX1.corp.seven.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F823@RWC-MBX1.corp.seven.com>
 <CAJvB4tmLd1A53M76aimbO+uxenX5f8c9eppqpdF00t5niU5WXw@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F87D@RWC-MBX1.corp.seven.com>
Message-ID: <CAJvB4tkUxu6jRBRUpjK2-mnEax4-=w8RVU2jqcsyseqSx-gdfw@mail.gmail.com>

On Wed, Feb 1, 2012 at 15:21, George Bonser <gbonser at seven.com> wrote:

> > The problem is no one will actually blacklist a big ASN because its not
> > in the individual best interest, which scales greatly with size. RPKI
> > is pretty much the only real fix for this if the chain until the major
> > carrier refuses to delist, and RPKI has it's own issues.
> >
> > -Blake
>
> Sadly, you're right. But my guess is that such a blacklisting would have
> to be done for only a very short period of time and once it is done once or
> twice, it would never need to be done again.  But it probably is too big a
> hammer.
>
> Until there is some sort of registry that is the source of truth and is
> easy to use (distributed?), we're going to keep repeating this process.
>
>
The issue isn't getting the AS blacklisted, the issue is getting people to
use the blacklist. Would you trust your router accepting entire ASNs to
someone else's list? Would your boss agree to allow others to shut down
access to a potentially major entity on the internet for something that
doesn't directly impact you?

I just don't see it ever happening, and anything short of that is no
deterrent for the above.

If you can't target the enablers with any kind of stick, then the only
other option is RPKI which prevents the actual hijack, but that has it's
own issues, due to the same benefits.

-Blake

From heather.schiller at verizon.com  Wed Feb  1 15:44:07 2012
From: heather.schiller at verizon.com (Schiller, Heather A)
Date: Wed, 1 Feb 2012 16:44:07 -0500
Subject: AS8300 - Swisscom hijacking.. Just what are you testing?
Message-ID: <B9EBD2474913AD4A995B8C7B8BEF8C0E14FD65EEC8@FHDP1LUMXC7V43.us.one.verizon.com>


AS8300 started announcing one of the Rove Digital dns changer IP ranges. (The IP ranges the FBI is sending 'you are infected' letters about)  Swisscom's announcement is less specific than the prefixes being announced by ISC during the remediation effort, so it's not impacting traffic... But AS8300 seems to announce less specifics a lot.  Last fall they announced 63/8 and half of that is allocated to 701. AFAIK, we weren't notified they were going to announce a less specific of our space.  As long as folks have pullup routes, and don't have an outage that withdraws their announcements, then Swisscom should only be getting darknet traffic.  The record for AS8300 says 'Test' and the entry for it in CIDR report says "This AS is not currently used to announce prefixes in the global routing table, nor is it used as a visible transit AS."  .. But their announcements certainly do show up in the global routing table, whether they are transiting for someone or not, they could get traffic for anything that doesn't have a more specific.  Given the recent YAHT (yet another hijack thread) it's worth pointing out that hijacking more specifics is bad, but less specifics can be bad as well. (Not suggesting that is the case here..)  

I searched around and couldn't find any mention of what they might be testing.  Anyone know?  

route-views>sh ip bgp 85.255.112.0/20
BGP routing table entry for 85.255.112.0/20, version 2177063753
Paths: (11 available, no best path)
  Not advertised to any peer
  6079 3303 8300 (history entry)
    207.172.6.20 from 207.172.6.20 (207.172.6.20)
      Origin IGP, metric 85, localpref 100, external
      Dampinfo: penalty 495, flapped 2 times in 00:24:37
  3277 3267 174 3303 8300 (history entry)
    194.85.102.33 from 194.85.102.33 (194.85.4.4)
      Origin IGP, localpref 100, external
      Community: 3277:3267 3277:65321 3277:65323 3277:65330
      Dampinfo: penalty 501, flapped 2 times in 00:24:22
....

 --Heather

From patrick at ianai.net  Wed Feb  1 16:01:19 2012
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Wed, 1 Feb 2012 17:01:19 -0500
Subject: Extra Westin reservation
Message-ID: <606683D5-2BFF-438B-ADCC-28859D32D72B@ianai.net>

Apparently I accidentally made two hotel reservations for the Westin Gas Lamp.  Made one, then thought I changed it, but just got confirmation I have two.

I have until 6 PM to cancel.  If you want it, ping me before 5 PM PST.

-- 
TTFN,
patrick



From jeroen at unfix.org  Wed Feb  1 16:12:36 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Wed, 01 Feb 2012 23:12:36 +0100
Subject: AS8300 - Swisscom hijacking.. Just what are you testing?
In-Reply-To: <B9EBD2474913AD4A995B8C7B8BEF8C0E14FD65EEC8@FHDP1LUMXC7V43.us.one.verizon.com>
References: <B9EBD2474913AD4A995B8C7B8BEF8C0E14FD65EEC8@FHDP1LUMXC7V43.us.one.verizon.com>
Message-ID: <4F29B8D4.6040603@unfix.org>

On 2012-02-01 22:44 , Schiller, Heather A wrote:
> 
> AS8300 started announcing one of the Rove Digital dns changer IP ranges.
[..]
> I searched around and couldn't find any mention of what they might be testing.  Anyone know?  

They do internal aggregation of common prefixes to keep their internal
tables small, see for instance this rather old preso:

http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt

These prefixes should of course not be leaked outside their own network.

I would say, kick them either directly (yell offlist if you want direct
contacts) or spam the SwiNOG list and you will get a response quickly too.

Greets,
 Jeroen


From hmurray at megapathdsl.net  Wed Feb  1 16:14:02 2012
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 01 Feb 2012 14:14:02 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked 
 Networks)
In-Reply-To: Message from Christopher Morrow <morrowc.lists@gmail.com> of "Wed,
 01 Feb 2012 12:55:30 EST."
 <CAL9jLaZgKjCjzx__KTJw2CH1S5MyvzUu7c66VMkcP1hHQsz3Hw@mail.gmail.com>
Message-ID: <20120201221402.12950800037@ip-64-139-1-69.sjc.megapath.net>

>> Where is Milo Medin when we need him?
> how would he be helping?

He would have pulled the plug.

The story is from the very early days of the internet, probably long before 
NANOG existed.

Milo worked at NASA and found a cracker from Finland on one of NASAs 
machines.  The link from Finland to the rest of the world went through Norway 
to NASA.  (That's THE link, there was only one link connecting all of 
Scandinavia to the rest of the net.)  So Milo called the guy in Finland and 
said "Please fix it".  The reply was "We can't do anything.  We respect civil 
liberties."  Soon he got the message because  he wasn't connected to the net 
any more.

If anybody has a good URL for the story, please let me know.  I found one 
reference in google-books that said 1988.

-----

> AFAIK there's no law covering the use of what party X considers their 32 bit
> numbers (assigned by party A) by party Y.

Do contracts cover that?  I'd expect that the paperwork for peer-peer, 
customer-ISP and ISP-backbone links would include some nice broad legalese 
about not doing nasty things.


> Besides, how would that work?  Say ARIN assigns US company X (operating only
> in the US) a block, but German company Y (with no US operations) starts
> announcing the same block.  How are US or German laws going to help, when
> the parties have no common jurisdiction? 

The law could be written to apply to the company bringing the bogus 
announcements across the US border.


-- 
These are my opinions, not necessarily my employer's.  I hate spam.





From jared at puck.nether.net  Wed Feb  1 16:22:11 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 1 Feb 2012 17:22:11 -0500
Subject: AS8300 - Swisscom hijacking.. Just what are you testing?
In-Reply-To: <4F29B8D4.6040603@unfix.org>
References: <B9EBD2474913AD4A995B8C7B8BEF8C0E14FD65EEC8@FHDP1LUMXC7V43.us.one.verizon.com>
 <4F29B8D4.6040603@unfix.org>
Message-ID: <F4F5570D-8696-4BBD-8D73-D14045FD1A60@puck.nether.net>


On Feb 1, 2012, at 5:12 PM, Jeroen Massar wrote:

> On 2012-02-01 22:44 , Schiller, Heather A wrote:
>> 
>> AS8300 started announcing one of the Rove Digital dns changer IP ranges.
> [..]
>> I searched around and couldn't find any mention of what they might be testing.  Anyone know?  
> 
> They do internal aggregation of common prefixes to keep their internal
> tables small, see for instance this rather old preso:
> 
> http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt
> 
> These prefixes should of course not be leaked outside their own network.
> 
> I would say, kick them either directly (yell offlist if you want direct
> contacts) or spam the SwiNOG list and you will get a response quickly too.

One could just filter their as-path from 701/702/703 in the interim to get them to address it.

- jared

From sethm at rollernet.us  Wed Feb  1 16:43:26 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 01 Feb 2012 14:43:26 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <20120201211344.2B9291CA11AB@drugs.dv.isc.org>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <20120201211344.2B9291CA11AB@drugs.dv.isc.org>
Message-ID: <4F29C00E.4050704@rollernet.us>

On 2/1/12 1:13 PM, Mark Andrews wrote:
> In message <20120201201012.GE10680 at hiwaay.net>, Chris Adams writes:
>> Once upon a time, George Bonser <gbonser at seven.com> said:
>>> Let's say I had a business in space in a building I was leasing at 100 Main
>>  Street, Podunk, USA.  Now let's say you didn't renew the lease so I moved to
>>  a building up the block but put the 100 Main Street address on my new locati
>> on and continued to use that address for my business.
>>
>> That's covered under trespassing laws.
>>
>>> Or let's say I operated a TV station on channel 37 that was allocated to yo
>> u but you terminate my operating contract.  So I lease/erect a new transmitte
>> r and continue broadcasting on channel 37.
>>
>> That's covered under FCC regulations on use of public spectrum.
>>
>> AFAIK there's no law covering the use of what party X considers their 32
>> bit numbers (assigned by party A) by party Y.
> 
> If you present a false letter of authority you are committing fraud.
> If you continue to use address after the lease is up it is trespass
> / theft / breach of contract.
> 
> I'm sure there are lots more laws that can apply.  Counterfieting,
> wire fraud.  Breaches of various Telecommunication Acts, etc.  You
> might have juristictional issues.
> 
> In the case of the Internet we have a authority for handing out
> numbers for use on  the Internet (IANA).  Courts all over the world
> do recognise that authority directly or indirectly by recognising
> the RIRs.
> 
> There are enough analogs in common law to almost everything that
> happens on the Internet for there to no be the need for specific
> "Internet" laws.   It's just that having a "Internet" law makes it
> easier to prosecute.
> 


Phoenix NAP colluding to hijack address space and then balking when it
was brought to their attention is a perfect example someone could use to
say why "we" need to be regulated. And I'm sure it will eventually
happen again with different players. Either we all play nice and
self-regulate or someone else will start doing it for us, and probably
not in a way we'll be happy with but have to learn to live with.

~Seth


From patrick at ianai.net  Wed Feb  1 16:48:37 2012
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Wed, 1 Feb 2012 17:48:37 -0500
Subject: Extra Westin reservation
In-Reply-To: <606683D5-2BFF-438B-ADCC-28859D32D72B@ianai.net>
References: <606683D5-2BFF-438B-ADCC-28859D32D72B@ianai.net>
Message-ID: <ACCCA046-5E88-4F54-BC18-3EFAF094A303@ianai.net>

And it's gone.

-- 
TTFN,
patrick

On Feb 1, 2012, at 5:01 PM, Patrick W. Gilmore wrote:

> Apparently I accidentally made two hotel reservations for the Westin Gas Lamp.  Made one, then thought I changed it, but just got confirmation I have two.
> 
> I have until 6 PM to cancel.  If you want it, ping me before 5 PM PST.
> 
> -- 
> TTFN,
> patrick
> 



From ops.lists at gmail.com  Wed Feb  1 18:26:15 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Thu, 2 Feb 2012 05:56:15 +0530
Subject: AS8300 - Swisscom hijacking.. Just what are you testing?
In-Reply-To: <4F29B8D4.6040603@unfix.org>
References: <B9EBD2474913AD4A995B8C7B8BEF8C0E14FD65EEC8@FHDP1LUMXC7V43.us.one.verizon.com>
 <4F29B8D4.6040603@unfix.org>
Message-ID: <CAArzuoux-XaA9JGFdN5c8fyFhHrh1r1wcV4ghMEPgXvVCe89Nw@mail.gmail.com>

It is "brilliant" because you can kiss goodbye to multihoming if you
have, say, a /24 that you want to hang off, say, L3 and cogent.

You'd get the covering L3 /9 announcement is all, visible to swisscom ..

On Thu, Feb 2, 2012 at 3:42 AM, Jeroen Massar <jeroen at unfix.org> wrote:
>
> They do internal aggregation of common prefixes to keep their internal
> tables small, see for instance this rather old preso:
>
> http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From mike at mikejones.in  Wed Feb  1 18:38:22 2012
From: mike at mikejones.in (Mike Jones)
Date: Thu, 2 Feb 2012 00:38:22 +0000
Subject: Question regarding anycasting in CDN setup
In-Reply-To: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
References: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
Message-ID: <CAAAas8E7oytFJuFWtxWt_BEugh8yBGSpLY2edYP03jVAHwsk2w@mail.gmail.com>

On 1 February 2012 20:25, Anurag Bhatia <me at anuragbhatia.com> wrote:
<snip>
> Now my question here is - why this setup and not simply using having a A
> record for googlehosted.l.googleusercontent.com. which comes from any
> anycasted IP address space? Why not anycasting at CDN itself rather then
> only at DNS layer?

You are confusing anycasting with offering different results.

I can have an anycast DNS setup where all my servers give the same
response (example: most DNS providers), I can also have a single DNS
server give 192.0.2.80 out to queries sourced from a US IP Address,
198.51.100.80 for queries sourced from a German IP Address and
203.0.113.80 to queries sourced from a Chinese address (djbdns has a
module for this for example).

I would guess that google probably have a highly customised algorithm
which uses a combination of source IP and the node that your query
arrived at as part of the process for deciding what answer to give
you, along with dozens of other internal factors.

Although I do sometimes wonder why they use CNAME chains in cases
where the same servers are authoritative for the target name anyway.

If you were wondering why they direct you to the unicast addresses for
the local datacentre instead of just giving an anycast address which
your nearest datacentre would answer, well their algorithm might
decide that it wants to serve you content from the second closest
datacentre because the closest one is near capacity, anycast can't do
that.

- Mike


From annkwok80 at gmail.com  Wed Feb  1 08:32:22 2012
From: annkwok80 at gmail.com (Ann Kwok)
Date: Wed, 1 Feb 2012 09:32:22 -0500
Subject: Question about prefix list
Message-ID: <CACwqZxjZwUDqbcB+PUM=0+noH9oWogtEeXPxAz_vLed68fxf8w@mail.gmail.com>

Hi

I read this prefix list.

Can I know why there is "le 24" after network block in /22 and /21

Why don't have "le 24" after /24?

I also saw another prefix list before. They use "le 32" instead of  "le 24"

What are their different?

ip prefix-list prefix-filter-as100 seq 10 permit 202,168.136.0/22 le 24
ip prefix-list prefix-filter-as100 seq 20 permit 202,22.92.0/22 le 24
ip prefix-list prefix-filter-as100 seq 30 permit 202,21.148.0/22 le 24
ip prefix-list prefix-filter-as100 seq 40 permit 203,178.88.0/21 le 24
ip prefix-list prefix-filter-as100 seq 50 permit 178.88.74.0/24

Thank you so much

From wouter at terrean.net  Wed Feb  1 19:43:37 2012
From: wouter at terrean.net (Wouter van der Vaart)
Date: Thu, 2 Feb 2012 02:43:37 +0100
Subject: Question about prefix list
In-Reply-To: <CACwqZxjZwUDqbcB+PUM=0+noH9oWogtEeXPxAz_vLed68fxf8w@mail.gmail.com>
References: <CACwqZxjZwUDqbcB+PUM=0+noH9oWogtEeXPxAz_vLed68fxf8w@mail.gmail.com>
Message-ID: <9E8AB7C0-2031-49F7-8D5D-051AEF6FAAD7@terrean.net>

Hi Ann,

The le parameter can be included to match all more-specific prefixes within a par ten prefix up to a specified length. FE: 202.168.136.0/22 le 25 will match 202.168.136.0/22 and all prefixes contained therein with a length of 24 or less.

They appear to be blocking everything with a length longer dan /24 (so /25 /26 etc etc.)

the last line doesn't have this because it's only 1 /24 subnet.

Regards,

Wouter
On Feb 1, 2012, at 15:32 , Ann Kwok wrote:

> Hi
> 
> I read this prefix list.
> 
> Can I know why there is "le 24" after network block in /22 and /21
> 
> Why don't have "le 24" after /24?
> 
> I also saw another prefix list before. They use "le 32" instead of  "le 24"
> 
> What are their different?
> 
> ip prefix-list prefix-filter-as100 seq 10 permit 202,168.136.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 20 permit 202,22.92.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 30 permit 202,21.148.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 40 permit 203,178.88.0/21 le 24
> ip prefix-list prefix-filter-as100 seq 50 permit 178.88.74.0/24
> 
> Thank you so much




From randy at psg.com  Wed Feb  1 19:50:32 2012
From: randy at psg.com (Randy Bush)
Date: Thu, 02 Feb 2012 10:50:32 +0900
Subject: AS8300 - Swisscom hijacking.. Just what are you testing?
In-Reply-To: <CAArzuoux-XaA9JGFdN5c8fyFhHrh1r1wcV4ghMEPgXvVCe89Nw@mail.gmail.com>
References: <B9EBD2474913AD4A995B8C7B8BEF8C0E14FD65EEC8@FHDP1LUMXC7V43.us.one.verizon.com>
 <4F29B8D4.6040603@unfix.org>
 <CAArzuoux-XaA9JGFdN5c8fyFhHrh1r1wcV4ghMEPgXvVCe89Nw@mail.gmail.com>
Message-ID: <m2ehueatqv.wl%randy@psg.com>

> It is "brilliant" because you can kiss goodbye to multihoming if you
> have, say, a /24 that you want to hang off, say, L3 and cogent.
> 
> You'd get the covering L3 /9 announcement is all, visible to swisscom ..
> 
>> They do internal aggregation of common prefixes to keep their internal
>> tables small, see for instance this rather old preso:
>>
>> http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt

why should swisscom pay for your traffic engineering?

randy


From rs at seastrom.com  Wed Feb  1 19:51:13 2012
From: rs at seastrom.com (Robert E. Seastrom)
Date: Wed, 01 Feb 2012 20:51:13 -0500
Subject: This network is too good...
Message-ID: <86d39yknou.fsf@seastrom.com>


Hi all,

Any thoughts on products that screw up networks in deterministic (and
realistic found-in-the-wild) ways?  I'm thinking of stuff like
PacketStorm, Dummynet, etc.  Dial up jitter, latency, tail drop, RED,
whatever...

(I know someone's gonna say "Just buy a Brand Z FubarSwitch 3k, they
will screw up your whole network and you don't even have to configure
it to do so!")

I'm all-ears like Ross Perot.

Thanks,

-r



From randy at psg.com  Wed Feb  1 19:52:19 2012
From: randy at psg.com (Randy Bush)
Date: Thu, 02 Feb 2012 10:52:19 +0900
Subject: Question about prefix list
In-Reply-To: <CACwqZxjZwUDqbcB+PUM=0+noH9oWogtEeXPxAz_vLed68fxf8w@mail.gmail.com>
References: <CACwqZxjZwUDqbcB+PUM=0+noH9oWogtEeXPxAz_vLed68fxf8w@mail.gmail.com>
Message-ID: <m2d39yatnw.wl%randy@psg.com>

> ip prefix-list prefix-filter-as100 seq 10 permit 202,168.136.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 20 permit 202,22.92.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 30 permit 202,21.148.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 40 permit 203,178.88.0/21 le 24
                                                      ^

randy


From bicknell at ufp.org  Wed Feb  1 20:21:35 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 1 Feb 2012 18:21:35 -0800
Subject: This network is too good...
In-Reply-To: <86d39yknou.fsf@seastrom.com>
References: <86d39yknou.fsf@seastrom.com>
Message-ID: <20120202022135.GA11800@ussenterprise.ufp.org>

In a message written on Wed, Feb 01, 2012 at 08:51:13PM -0500, Robert E. Seastrom wrote:
> Any thoughts on products that screw up networks in deterministic (and
> realistic found-in-the-wild) ways?  I'm thinking of stuff like
> PacketStorm, Dummynet, etc.  Dial up jitter, latency, tail drop, RED,
> whatever...
> 
> (I know someone's gonna say "Just buy a Brand Z FubarSwitch 3k, they
> will screw up your whole network and you don't even have to configure
> it to do so!")

The only good L2 solutions I've ever seen are expensive commercial
testing.  DummyNet, on a L3 aware FreeBSD box is extremely useful and
easy to configure to simulate varous loss or latency patterns.

What tool is right depends on if you want to test at L2 (simulate a
circuit/cable with a particular problem) or L3 (just a router in the
middle dropping packets), or testing an end user application.  L2,
particularly if you want to simulate things like a duplex mismatch is
hard, and not often needed.

If your goal is to test applications against network conditions, OSX has
a nifty new tool, "Network Link Conditioner".  It's basically just
dummynet with various throughput, delay, and packet loss settings but it
makes it dead simple to select from various pull downs.

http://www.thegeeksclub.com/simulate-internet-connectivity-speed-mac-os-lion-107-network-link-conditioner

I bring it up mainly because if you want to set your own DummyNet
settings for other testing it's a nice database of average case
performance for a number of link types!

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120201/23977490/attachment-0001.bin>

From ops.lists at gmail.com  Wed Feb  1 20:26:18 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Thu, 2 Feb 2012 07:56:18 +0530
Subject: AS8300 - Swisscom hijacking.. Just what are you testing?
In-Reply-To: <m2ehueatqv.wl%randy@psg.com>
References: <B9EBD2474913AD4A995B8C7B8BEF8C0E14FD65EEC8@FHDP1LUMXC7V43.us.one.verizon.com>
 <4F29B8D4.6040603@unfix.org>
 <CAArzuoux-XaA9JGFdN5c8fyFhHrh1r1wcV4ghMEPgXvVCe89Nw@mail.gmail.com>
 <m2ehueatqv.wl%randy@psg.com>
Message-ID: <CAArzuouxfy+O5aMGcoOW5p7K0f5Qit1OHx0MDpwuKWMMYi2hbQ@mail.gmail.com>

On Thu, Feb 2, 2012 at 7:20 AM, Randy Bush <randy at psg.com> wrote:
>>> They do internal aggregation of common prefixes to keep their internal
>>> tables small, see for instance this rather old preso:
>>>
>>> http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt
>
> why should swisscom pay for your traffic engineering?

Nobody at all is asking them to pay for it.  But do you seriously
expect their routing tables to become full to bursting because, for
example, they checked the ARIN route registry, RADB etc instead of
blindly using minimum prefix size defaults?

Or are swamp space legacy IP ranges with minimum prefix size of /24
that easy to get in this day and age?

-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From mysidia at gmail.com  Wed Feb  1 20:43:51 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 1 Feb 2012 20:43:51 -0600
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <4F29C00E.4050704@rollernet.us>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <20120201211344.2B9291CA11AB@drugs.dv.isc.org>
 <4F29C00E.4050704@rollernet.us>
Message-ID: <CAAAwwbVxtg3dVsNm-WSY7XJbjVjKd+hdSo-4bxB8vLQG=HpnRA@mail.gmail.com>

On Wed, Feb 1, 2012 at 4:43 PM, Seth Mattinen <sethm at rollernet.us> wrote:

> Phoenix NAP colluding to hijack address space and then balking when it
> was brought to their attention is a perfect example someone could use to
> say why "we" need to be regulated. And I'm sure it will eventually
>

There are always going to be some bad actors,  and some negligent
participants who get taken advantage of by bad actors.  There's no way to
guarantee a service provider capable of hijacking space does not fall into
the category of negligent facilitator.

Simple government regulation is of limited value, since the problem network
may be overseas.   Also,  separate networks that adhere to different rules
should  not have to follow the internet's conventions  --  if they want to
implement their own local variant of TCP/IP on their computers connected
over private connections but not connect to the internet, and therefore
follow their own address management system,  in a free society, people
should be free to do this with their computers;  the last thing we ever
need are governments mandating global uniqueness of IP addresses, ASN
numbers, Port numbers,  or other aspects of the engineering of private
computer networks.



I would say a service provider entering into a contractual relationship
with any other network that does not allow the service provider to make and
enforce their own network access TOS and routing policies and disconnect
downstream networks as necessary to protect network stability or comply
with upstream routing policies and what the RFCs and IANA say regarding
internet address management,  is negligent,  from the community's point of
view, in that they are not taking the reasonable care that is expected  and
necessary of service providers participating in the internet.



Agreement to implement RPKI by RIRs and  the RIR community would solve the
problem but has other drawbacks.


What the internet really needs is  Tier1 and Tier2 providers participating
in the internet who  "care", regardless of the popularity or size of
netblocks or issues involved.   And by "care", I mean,  providers
efficiently investigating reports of hijacking or rogue announcement,  and
taking switft responsible actions, without  bureaucratic processes
requiring   years   and reams of paperwork, or any attempt to shrug off
responsibility they have as intermediary.

--
-JH

From tmaufer at gmail.com  Wed Feb  1 21:05:24 2012
From: tmaufer at gmail.com (Thomas Maufer)
Date: Wed, 1 Feb 2012 19:05:24 -0800
Subject: This network is too good...
In-Reply-To: <20120202022135.GA11800@ussenterprise.ufp.org>
References: <86d39yknou.fsf@seastrom.com>
 <20120202022135.GA11800@ussenterprise.ufp.org>
Message-ID: <CA+HC509T_jyOV42ZXq220f1t5+_i9jP4Z6M=ADNaeHaMB02MnQ@mail.gmail.com>

IWL's "Maxwell" is probably what you want:

http://www.iwl.com/press-releases/new-capabilities-for-maxwell-the-network-impairment-system.html

Good luck breaking stuff!





On Wednesday, February 1, 2012, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Wed, Feb 01, 2012 at 08:51:13PM -0500, Robert E.
Seastrom wrote:
>> Any thoughts on products that screw up networks in deterministic (and
>> realistic found-in-the-wild) ways?  I'm thinking of stuff like
>> PacketStorm, Dummynet, etc.  Dial up jitter, latency, tail drop, RED,
>> whatever...
>>
>> (I know someone's gonna say "Just buy a Brand Z FubarSwitch 3k, they
>> will screw up your whole network and you don't even have to configure
>> it to do so!")
>
> The only good L2 solutions I've ever seen are expensive commercial
> testing.  DummyNet, on a L3 aware FreeBSD box is extremely useful and
> easy to configure to simulate varous loss or latency patterns.
>
> What tool is right depends on if you want to test at L2 (simulate a
> circuit/cable with a particular problem) or L3 (just a router in the
> middle dropping packets), or testing an end user application.  L2,
> particularly if you want to simulate things like a duplex mismatch is
> hard, and not often needed.
>
> If your goal is to test applications against network conditions, OSX has
> a nifty new tool, "Network Link Conditioner".  It's basically just
> dummynet with various throughput, delay, and packet loss settings but it
> makes it dead simple to select from various pull downs.
>
>
http://www.thegeeksclub.com/simulate-internet-connectivity-speed-mac-os-lion-107-network-link-conditioner
>
> I bring it up mainly because if you want to set your own DummyNet
> settings for other testing it's a nice database of average case
> performance for a number of link types!
>
> --
>       Leo Bicknell - bicknell at ufp.org - CCIE 3440
>        PGP keys at http://www.ufp.org/~bicknell/
>

-- 

~tom

+1 408 890-7548 (Google Voice)

From streiner at cluebyfour.org  Wed Feb  1 21:25:01 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Wed, 1 Feb 2012 22:25:01 -0500 (EST)
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CAAAwwbVxtg3dVsNm-WSY7XJbjVjKd+hdSo-4bxB8vLQG=HpnRA@mail.gmail.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <20120201211344.2B9291CA11AB@drugs.dv.isc.org>
 <4F29C00E.4050704@rollernet.us>
 <CAAAwwbVxtg3dVsNm-WSY7XJbjVjKd+hdSo-4bxB8vLQG=HpnRA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202012216140.27888@whammy.cluebyfour.org>

On Wed, 1 Feb 2012, Jimmy Hess wrote:

> What the internet really needs is  Tier1 and Tier2 providers participating
> in the internet who  "care", regardless of the popularity or size of
> netblocks or issues involved.   And by "care", I mean,  providers
> efficiently investigating reports of hijacking or rogue announcement,  and
> taking switft responsible actions, without  bureaucratic processes
> requiring   years   and reams of paperwork, or any attempt to shrug off
> responsibility they have as intermediary.

I agree completely, however the boondoggle in large networks often isn't 
the people in the trenches, it's the management buy-in that's often needed 
to take what could be perceived by non-technical types as as a risky 
(exposure to litigation or other legal/contractual entanglements) 
and unusual action of filtering out bad advertisement XYZ.  I've been 
through similar actions that ended up resulting in litigation. 
Depositions aren't fun.

In many big outfits like that, getting management to wrap their heads 
around something like this requires a cultural shift from the mindset 
where actions like this are usually initiated by legal/LEO action.

jms


From fernando at gont.com.ar  Wed Feb  1 21:38:09 2012
From: fernando at gont.com.ar (Fernando Gont)
Date: Thu, 02 Feb 2012 00:38:09 -0300
Subject: Fwd: IPv6 RA-Guard: Advice on the implementation (feedback requested)
Message-ID: <4F2A0521.7000100@gont.com.ar>

Folks,

Not sure if I had posted on this list about RA-Guard evasion issues.
Anyway...nowadays most implementations remain vulnerable.

If you care to get this fixed, please provide feedback about this I-D on
the IETF *v6ops* mailing-list <v6ops at ietf.org>, and CC me if possible
(please see below).

Thanks!

Best regards,
Fernando




-------- Original Message --------
Subject: RA-Guard: Advice on the implementation  (feedback requested)
Date: Wed, 01 Feb 2012 21:44:29 -0300
From: Fernando Gont <fgont at si6networks.com>
Organization: SI6 Networks
To: IPv6 Operations <v6ops at ietf.org>

Folks,

We have just published a revision of our I-D "Implementation Advice for
IPv6 Router Advertisement Guard (RA-Guard)"
<http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-implementation-01.txt>.

In essence, this is the problem statement, and what this I-D is about:

* RA-Guard is essential to have feature parity with IPv4.

* Most (all?) existing RA-Guard implementations can be trivially evaded:
if the attacker includes extension headers in his packets, the RA-Guard
devices fail to identify the Router Advertisement messages. -- For
instance, THC's "IPv6 attack suite" (<http://www.thc.org/thc-ipv6/>)
contains tools that can evade RA-Guard as indicated.

* The I-D discusses this problem, and provides advice on how to
implement RA-Guard, such that the aforementioned vulnerabilities are
eliminated, we have an effective RA-Guard device, and hence
feature-parity with IPv4.

We'd like feedback on this I-D, including high-level comments on whether
you support the proposal in this I-D.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From randy at psg.com  Wed Feb  1 21:53:57 2012
From: randy at psg.com (Randy Bush)
Date: Thu, 02 Feb 2012 12:53:57 +0900
Subject: antisocial security
Message-ID: <m21uqdc2lm.wl%randy@psg.com>

from a stateside host

psg.com:/usr/home/randy> dig ssa.gov. ns

; <<>> DiG 9.4.3-P2 <<>> ssa.gov. ns
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37734
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;ssa.gov.                       IN      NS

;; ANSWER SECTION:
ssa.gov.                24370   IN      NS      dns1.ssa.gov.
ssa.gov.                24370   IN      NS      dns6.ssa.gov.
ssa.gov.                24370   IN      NS      dns5.ssa.gov.
ssa.gov.                24370   IN      NS      dns2.ssa.gov.

;; ADDITIONAL SECTION:
dns1.ssa.gov.           34072   IN      A       199.173.231.82
dns2.ssa.gov.           34073   IN      A       199.173.231.83
dns5.ssa.gov.           34073   IN      A       137.200.4.30
dns6.ssa.gov.           34074   IN      A       137.200.4.31

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Feb  2 03:45:15 2012
;; MSG SIZE  rcvd: 165

psg.com:/usr/home/randy> dig +short @199.173.231.82 www.ssa.gov. any
www.socialsecurity.gov.
CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=
psg.com:/usr/home/randy> dig +short @199.173.231.83 www.ssa.gov. any
www.socialsecurity.gov.
CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=
psg.com:/usr/home/randy> dig +short @137.200.4.30 www.ssa.gov. any
www.socialsecurity.gov.
CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=
psg.com:/usr/home/randy> dig +short @137.200.4.31 www.ssa.gov. any
www.socialsecurity.gov.
CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=

psg.com:/usr/home/randy> traceroute 199.173.231.82
traceroute to 199.173.231.82 (199.173.231.82), 64 hops max, 40 byte packets
 1  r0.sea.rg.net (147.28.0.4)  0.314 ms  1.224 ms  0.202 ms
 2  r1.sea.rg.net (147.28.0.5)  0.340 ms  0.306 ms  0.349 ms
 3  sl-gw20-sea-3-2-1.sprintlink.net (144.232.9.61)  0.355 ms  0.305 ms  0.228 ms
 4  144.232.3.126 (144.232.3.126)  0.352 ms  0.379 ms  0.353 ms
 5  0.xe-11-3-0.BR2.SEA7.ALTER.NET (204.255.168.217)  14.365 ms  1.081 ms  1.075 ms
 6  0.ge-2-3-0.XT2.SEA7.ALTER.NET (152.63.104.21)  1.097 ms  1.127 ms  1.082 ms
 7  0.ge-1-2-0.XT2.DCA6.ALTER.NET (152.63.40.46)  73.575 ms  73.635 ms  73.528 ms
 8  GigabitEthernet7-0-0.GW8.DCA6.ALTER.NET (152.63.40.81)  75.535 ms  75.595 ms  75.545 ms
 9  ssa-gw.customer.alter.net (152.179.9.34)  76.652 ms  76.522 ms  76.671 ms
10  * *^C
psg.com:/usr/home/randy> traceroute 137.200.4.30
traceroute to 137.200.4.30 (137.200.4.30), 64 hops max, 40 byte packets
 1  r0.sea.rg.net (147.28.0.4)  0.378 ms  0.253 ms  0.332 ms
 2  r1.sea.rg.net (147.28.0.5)  0.340 ms  0.394 ms  0.339 ms
 3  sl-gw20-sea-3-2-1.sprintlink.net (144.232.9.61)  0.348 ms  0.263 ms  0.214 ms
 4  144.232.3.126 (144.232.3.126)  66.830 ms  0.345 ms  0.323 ms
 5  0.xe-11-3-0.BR2.SEA7.ALTER.NET (204.255.168.217)  0.977 ms  1.006 ms  1.100 ms
 6  0.ge-2-3-0.XT2.SEA7.ALTER.NET (152.63.104.21)  26.587 ms  1.173 ms  1.086 ms
 7  0.ge-7-0-0.XL2.RDU1.ALTER.NET (152.63.33.38)  86.052 ms  86.084 ms  86.024 ms
 8  POS7-0.GW5.RDU1.ALTER.NET (152.63.35.177)  83.282 ms  83.371 ms  83.145 ms
 9  157.130.212.98 (157.130.212.98)  85.254 ms  84.998 ms  85.170 ms
10  137.200.1.123 (137.200.1.123)  92.646 ms  92.727 ms  92.762 ms
11  *^C

so they have a firewall, but i can get there.

but from tokyo

rair.psg.com:/Users/randy> dig +short @199.173.231.82 www.ssa.gov. any
;; connection timed out; no servers could be reached
rair.psg.com:/Users/randy> dig +short @199.173.231.83 www.ssa.gov. any
;; connection timed out; no servers could be reached
rair.psg.com:/Users/randy> dig +short @137.200.4.30 www.ssa.gov. any
;; connection timed out; no servers could be reached
rair.psg.com:/Users/randy> dig +short @137.200.4.31 www.ssa.gov. any
;; connection timed out; no servers could be reached


rair.psg.com:/Users/randy> traceroute 199.173.231.82
traceroute to 199.173.231.82 (199.173.231.82), 64 hops max, 52 byte packets
 1  192.168.0.1 (192.168.0.1)  5.528 ms  2.325 ms  2.504 ms
 2  tokyo10-f01.flets.2iij.net (210.149.34.66)  6.912 ms  9.912 ms  11.519 ms
 3  tokyo10-ntteast1.flets.2iij.net (210.149.34.113)  5.684 ms  5.820 ms  5.621 ms
 4  tky001lip21.iij.net (210.149.34.101)  8.553 ms  6.054 ms  6.600 ms
 5  tky001bb10.iij.net (58.138.100.217)  5.350 ms  5.412 ms  5.058 ms
 6  tky001bf00.iij.net (58.138.80.1)  11.748 ms
    tky001bf01.iij.net (58.138.80.5)  5.268 ms  7.389 ms
 7  sjc002bf01.iij.net (216.98.96.62)  104.972 ms
    sjc002bf02.iij.net (206.132.169.109)  106.686 ms
    sjc002bf01.iij.net (216.98.96.62)  105.618 ms
 8  sjc002bb10.iij.net (206.132.169.2)  126.691 ms
    sjc002bb10.iij.net (206.132.169.6)  134.246 ms
    sjc002bb10.iij.net (206.132.169.10)  108.460 ms
 9  gigabitethernet1-1.gw2.sjc7.alter.net (152.179.48.1)  110.772 ms  109.116 ms  114.488 ms
10  0.so-0-0-1.xl4.sjc7.alter.net (152.63.51.50)  102.308 ms  106.149 ms  109.410 ms
11  0.so-7-3-0.xt2.dca6.alter.net (152.63.0.245)  187.469 ms  183.993 ms  194.484 ms
12  gigabitethernet7-0-0.gw8.dca6.alter.net (152.63.40.81)  259.830 ms  234.873 ms  186.634 ms
13  * * *
^C
rair.psg.com:/Users/randy> traceroute 137.200.4.30
traceroute to 137.200.4.30 (137.200.4.30), 64 hops max, 52 byte packets
 1  192.168.0.1 (192.168.0.1)  10.197 ms  1.979 ms  4.218 ms
 2  tokyo10-f01.flets.2iij.net (210.149.34.66)  9.268 ms  6.284 ms  6.184 ms
 3  tokyo10-ntteast1.flets.2iij.net (210.149.34.113)  5.913 ms  10.127 ms  6.532 ms
 4  tky001lip21.iij.net (210.149.34.101)  7.983 ms  6.036 ms  6.199 ms
 5  tky001bb10.iij.net (58.138.100.217)  5.774 ms  21.691 ms  7.265 ms
 6  tky001bf01.iij.net (58.138.80.5)  9.906 ms
    tky008bf00.iij.net (58.138.80.9)  8.371 ms
    tky001bf01.iij.net (58.138.80.5)  5.930 ms
 7  sjc002bf00.iij.net (216.98.96.186)  117.184 ms  113.652 ms
    sjc002bf01.iij.net (216.98.96.62)  104.728 ms
 8  sjc002bb10.iij.net (206.132.169.10)  114.864 ms
    sjc002bb10.iij.net (206.132.169.6)  111.701 ms
    sjc002bb10.iij.net (206.132.169.10)  142.274 ms
 9  gigabitethernet1-1.gw2.sjc7.alter.net (152.179.48.1)  123.611 ms  115.159 ms  112.298 ms
10  0.so-0-0-1.xl4.sjc7.alter.net (152.63.51.50)  111.010 ms  104.429 ms  108.738 ms
11  0.so-1-2-0.xl2.rdu1.alter.net (152.63.27.38)  349.150 ms  209.448 ms  207.871 ms
12  pos7-0.gw5.rdu1.alter.net (152.63.35.177)  222.413 ms  208.135 ms  269.150 ms
13  * *^C

and, i noticed the problem because i can not get to the web site at
http://www.ssa.gov/ from tokyo.

randy


From randy_94108 at yahoo.com  Wed Feb  1 22:13:38 2012
From: randy_94108 at yahoo.com (Randy)
Date: Wed, 1 Feb 2012 20:13:38 -0800 (PST)
Subject: Question about prefix list
In-Reply-To: <CACwqZxjZwUDqbcB+PUM=0+noH9oWogtEeXPxAz_vLed68fxf8w@mail.gmail.com>
Message-ID: <1328156018.36060.YahooMailClassic@web181110.mail.ne1.yahoo.com>

Ann,
the commas not withstanding, the le/ge operands as applicable to prefix-lists simply mean "less-than or equal-to" or greater-than or "equal-to" wrt netmasks in CIDR speak.

In you prefix-list below, the le operand means -
allow following ranges:

/22,/23,/24 deny all else
for the /21
it means allow /21 thru /24

Anything without an operand means an exact-match(permit/deny)

Homework for you:

What do the following do:

1) ip prefix-list foo deny 0.0.0.0/0 le32
2) ip prefix-list foo permit 0.0.0/0 le 32

Understand the above and you will understand how operands work in prefix-lists.
./Randy


--- On Wed, 2/1/12, Ann Kwok <annkwok80 at gmail.com> wrote:

> From: Ann Kwok <annkwok80 at gmail.com>
> Subject: Question about prefix list
> To: nanog at nanog.org
> Date: Wednesday, February 1, 2012, 6:32 AM
> Hi
> 
> I read this prefix list.
> 
> Can I know why there is "le 24" after network block in /22
> and /21
> 
> Why don't have "le 24" after /24?
> 
> I also saw another prefix list before. They use "le 32"
> instead of? "le 24"
> 
> What are their different?
> 
> ip prefix-list prefix-filter-as100 seq 10 permit
> 202,168.136.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 20 permit
> 202,22.92.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 30 permit
> 202,21.148.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 40 permit
> 203,178.88.0/21 le 24
> ip prefix-list prefix-filter-as100 seq 50 permit
> 178.88.74.0/24
> 
> Thank you so much
> 


From owen at delong.com  Wed Feb  1 22:54:17 2012
From: owen at delong.com (Owen DeLong)
Date: Wed, 1 Feb 2012 20:54:17 -0800
Subject: antisocial security
In-Reply-To: <m21uqdc2lm.wl%randy@psg.com>
References: <m21uqdc2lm.wl%randy@psg.com>
Message-ID: <D4C1B367-5E9D-4EF1-B41C-C23AEA9C539F@delong.com>

It's not uncommon (although I would agree it is ill advised) practice for some
web sites that think they cater only to an audience in a particular geography
to block access outside of that geography. I ran across this when my credit
union would not let me connect to their web server from S. Korea.

However, I took it up with the credit union rather than NANOG. Is there a
reason you bring this up here instead of with the SSA?

Owen

On Feb 1, 2012, at 7:53 PM, Randy Bush wrote:

> from a stateside host
> 
> psg.com:/usr/home/randy> dig ssa.gov. ns
> 
> ; <<>> DiG 9.4.3-P2 <<>> ssa.gov. ns
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37734
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4
> 
> ;; QUESTION SECTION:
> ;ssa.gov.                       IN      NS
> 
> ;; ANSWER SECTION:
> ssa.gov.                24370   IN      NS      dns1.ssa.gov.
> ssa.gov.                24370   IN      NS      dns6.ssa.gov.
> ssa.gov.                24370   IN      NS      dns5.ssa.gov.
> ssa.gov.                24370   IN      NS      dns2.ssa.gov.
> 
> ;; ADDITIONAL SECTION:
> dns1.ssa.gov.           34072   IN      A       199.173.231.82
> dns2.ssa.gov.           34073   IN      A       199.173.231.83
> dns5.ssa.gov.           34073   IN      A       137.200.4.30
> dns6.ssa.gov.           34074   IN      A       137.200.4.31
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu Feb  2 03:45:15 2012
> ;; MSG SIZE  rcvd: 165
> 
> psg.com:/usr/home/randy> dig +short @199.173.231.82 www.ssa.gov. any
> www.socialsecurity.gov.
> CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=
> psg.com:/usr/home/randy> dig +short @199.173.231.83 www.ssa.gov. any
> www.socialsecurity.gov.
> CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=
> psg.com:/usr/home/randy> dig +short @137.200.4.30 www.ssa.gov. any
> www.socialsecurity.gov.
> CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=
> psg.com:/usr/home/randy> dig +short @137.200.4.31 www.ssa.gov. any
> www.socialsecurity.gov.
> CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=
> 
> psg.com:/usr/home/randy> traceroute 199.173.231.82
> traceroute to 199.173.231.82 (199.173.231.82), 64 hops max, 40 byte packets
> 1  r0.sea.rg.net (147.28.0.4)  0.314 ms  1.224 ms  0.202 ms
> 2  r1.sea.rg.net (147.28.0.5)  0.340 ms  0.306 ms  0.349 ms
> 3  sl-gw20-sea-3-2-1.sprintlink.net (144.232.9.61)  0.355 ms  0.305 ms  0.228 ms
> 4  144.232.3.126 (144.232.3.126)  0.352 ms  0.379 ms  0.353 ms
> 5  0.xe-11-3-0.BR2.SEA7.ALTER.NET (204.255.168.217)  14.365 ms  1.081 ms  1.075 ms
> 6  0.ge-2-3-0.XT2.SEA7.ALTER.NET (152.63.104.21)  1.097 ms  1.127 ms  1.082 ms
> 7  0.ge-1-2-0.XT2.DCA6.ALTER.NET (152.63.40.46)  73.575 ms  73.635 ms  73.528 ms
> 8  GigabitEthernet7-0-0.GW8.DCA6.ALTER.NET (152.63.40.81)  75.535 ms  75.595 ms  75.545 ms
> 9  ssa-gw.customer.alter.net (152.179.9.34)  76.652 ms  76.522 ms  76.671 ms
> 10  * *^C
> psg.com:/usr/home/randy> traceroute 137.200.4.30
> traceroute to 137.200.4.30 (137.200.4.30), 64 hops max, 40 byte packets
> 1  r0.sea.rg.net (147.28.0.4)  0.378 ms  0.253 ms  0.332 ms
> 2  r1.sea.rg.net (147.28.0.5)  0.340 ms  0.394 ms  0.339 ms
> 3  sl-gw20-sea-3-2-1.sprintlink.net (144.232.9.61)  0.348 ms  0.263 ms  0.214 ms
> 4  144.232.3.126 (144.232.3.126)  66.830 ms  0.345 ms  0.323 ms
> 5  0.xe-11-3-0.BR2.SEA7.ALTER.NET (204.255.168.217)  0.977 ms  1.006 ms  1.100 ms
> 6  0.ge-2-3-0.XT2.SEA7.ALTER.NET (152.63.104.21)  26.587 ms  1.173 ms  1.086 ms
> 7  0.ge-7-0-0.XL2.RDU1.ALTER.NET (152.63.33.38)  86.052 ms  86.084 ms  86.024 ms
> 8  POS7-0.GW5.RDU1.ALTER.NET (152.63.35.177)  83.282 ms  83.371 ms  83.145 ms
> 9  157.130.212.98 (157.130.212.98)  85.254 ms  84.998 ms  85.170 ms
> 10  137.200.1.123 (137.200.1.123)  92.646 ms  92.727 ms  92.762 ms
> 11  *^C
> 
> so they have a firewall, but i can get there.
> 
> but from tokyo
> 
> rair.psg.com:/Users/randy> dig +short @199.173.231.82 www.ssa.gov. any
> ;; connection timed out; no servers could be reached
> rair.psg.com:/Users/randy> dig +short @199.173.231.83 www.ssa.gov. any
> ;; connection timed out; no servers could be reached
> rair.psg.com:/Users/randy> dig +short @137.200.4.30 www.ssa.gov. any
> ;; connection timed out; no servers could be reached
> rair.psg.com:/Users/randy> dig +short @137.200.4.31 www.ssa.gov. any
> ;; connection timed out; no servers could be reached
> 
> 
> rair.psg.com:/Users/randy> traceroute 199.173.231.82
> traceroute to 199.173.231.82 (199.173.231.82), 64 hops max, 52 byte packets
> 1  192.168.0.1 (192.168.0.1)  5.528 ms  2.325 ms  2.504 ms
> 2  tokyo10-f01.flets.2iij.net (210.149.34.66)  6.912 ms  9.912 ms  11.519 ms
> 3  tokyo10-ntteast1.flets.2iij.net (210.149.34.113)  5.684 ms  5.820 ms  5.621 ms
> 4  tky001lip21.iij.net (210.149.34.101)  8.553 ms  6.054 ms  6.600 ms
> 5  tky001bb10.iij.net (58.138.100.217)  5.350 ms  5.412 ms  5.058 ms
> 6  tky001bf00.iij.net (58.138.80.1)  11.748 ms
>    tky001bf01.iij.net (58.138.80.5)  5.268 ms  7.389 ms
> 7  sjc002bf01.iij.net (216.98.96.62)  104.972 ms
>    sjc002bf02.iij.net (206.132.169.109)  106.686 ms
>    sjc002bf01.iij.net (216.98.96.62)  105.618 ms
> 8  sjc002bb10.iij.net (206.132.169.2)  126.691 ms
>    sjc002bb10.iij.net (206.132.169.6)  134.246 ms
>    sjc002bb10.iij.net (206.132.169.10)  108.460 ms
> 9  gigabitethernet1-1.gw2.sjc7.alter.net (152.179.48.1)  110.772 ms  109.116 ms  114.488 ms
> 10  0.so-0-0-1.xl4.sjc7.alter.net (152.63.51.50)  102.308 ms  106.149 ms  109.410 ms
> 11  0.so-7-3-0.xt2.dca6.alter.net (152.63.0.245)  187.469 ms  183.993 ms  194.484 ms
> 12  gigabitethernet7-0-0.gw8.dca6.alter.net (152.63.40.81)  259.830 ms  234.873 ms  186.634 ms
> 13  * * *
> ^C
> rair.psg.com:/Users/randy> traceroute 137.200.4.30
> traceroute to 137.200.4.30 (137.200.4.30), 64 hops max, 52 byte packets
> 1  192.168.0.1 (192.168.0.1)  10.197 ms  1.979 ms  4.218 ms
> 2  tokyo10-f01.flets.2iij.net (210.149.34.66)  9.268 ms  6.284 ms  6.184 ms
> 3  tokyo10-ntteast1.flets.2iij.net (210.149.34.113)  5.913 ms  10.127 ms  6.532 ms
> 4  tky001lip21.iij.net (210.149.34.101)  7.983 ms  6.036 ms  6.199 ms
> 5  tky001bb10.iij.net (58.138.100.217)  5.774 ms  21.691 ms  7.265 ms
> 6  tky001bf01.iij.net (58.138.80.5)  9.906 ms
>    tky008bf00.iij.net (58.138.80.9)  8.371 ms
>    tky001bf01.iij.net (58.138.80.5)  5.930 ms
> 7  sjc002bf00.iij.net (216.98.96.186)  117.184 ms  113.652 ms
>    sjc002bf01.iij.net (216.98.96.62)  104.728 ms
> 8  sjc002bb10.iij.net (206.132.169.10)  114.864 ms
>    sjc002bb10.iij.net (206.132.169.6)  111.701 ms
>    sjc002bb10.iij.net (206.132.169.10)  142.274 ms
> 9  gigabitethernet1-1.gw2.sjc7.alter.net (152.179.48.1)  123.611 ms  115.159 ms  112.298 ms
> 10  0.so-0-0-1.xl4.sjc7.alter.net (152.63.51.50)  111.010 ms  104.429 ms  108.738 ms
> 11  0.so-1-2-0.xl2.rdu1.alter.net (152.63.27.38)  349.150 ms  209.448 ms  207.871 ms
> 12  pos7-0.gw5.rdu1.alter.net (152.63.35.177)  222.413 ms  208.135 ms  269.150 ms
> 13  * *^C
> 
> and, i noticed the problem because i can not get to the web site at
> http://www.ssa.gov/ from tokyo.
> 
> randy



From Erik.Amundson at oati.net  Wed Feb  1 23:05:09 2012
From: Erik.Amundson at oati.net (Erik Amundson)
Date: Wed, 1 Feb 2012 23:05:09 -0600
Subject: not excactly on-topic Server Cabinet question
Message-ID: <635D17EE85D35A49B8F278998E6C3404647C8EB4DB@EXVS.dev.oati.local>

I apologize for this being off-topic in the NANOG list, but I'm hoping some of you have experience with the particulars of what I'm looking for...

I am looking for a server cabinet which has an electric latching mechanism on it.  I want to use my existing security system and proximity card reader, but have a cabinet door that would open when the card reader is read.

Does anyone sell anything like this?

I've looked into Rittal, APC, Hoffman, Wrightline (now Eaton), Knurr (via Liebert/Emerson), Middle Atlantic, and Panduit.  So far, nothing.

Any suggestions?  Feel free to reply off-list.

- Erik


From medin at google.com  Thu Feb  2 01:37:29 2012
From: medin at google.com (Milo Medin)
Date: Wed, 1 Feb 2012 23:37:29 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
Message-ID: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>

>> Where is Milo Medin when we need him?

> how would he be helping?



He would have pulled the plug.



The story is from the very early days of the internet, probably long before

NANOG existed.



Milo worked at NASA and found a cracker from Finland on one of NASAs

machines.  The link from Finland to the rest of the world went through
Norway

to NASA.  (That's THE link, there was only one link connecting all of

Scandinavia to the rest of the net.)  So Milo called the guy in Finland and

said "Please fix it".  The reply was "We can't do anything.  We respect
civil

liberties."  Soon he got the message because  he wasn't connected to the
net

any more.



If anybody has a good URL for the story, please let me know.  I found one

reference in google-books that said 1988.



Hmm, is this how people talk about you after you are dead?  J



Dave Burstein dropped me a note about this thread ? I don?t usually follow
NANOG much these days.  So I figured I should respond to make sure all the
facts were straight.



Let me clarify what happened in the case of the Finnish idiot.  At the
time, I worked for NASA and among other things ran the root nameserver at
Ames (ns.nasa.gov).   We managed systems very tightly, and the root was
instrumented well and was notifying that someone at one of the larger
Finnish universities was trying the usual measures to break into the
machine.  We saw these all the time ? people tried the usual tftp or other
tricks, and moved on when they didn?t get satisfaction.  But this
particular individual just kept on trying different things over the course
of a couple days, and distinguished himself as being a real pain.



So I figured I needed to take some action.   I went to the NIC database,
and called up the University?s POC for the address block, saying that one
of their students was attempting to break into a US Government computing
resource (a criminal offense) and violating the AUP of the networks that
connected them.  They refused to act ? basically saying that they didn?t
feel bound by US law, blah blah, etc?  So then I called up the Nordunet
guys in Stockholm, who connected all Scandinavian countries together via a
128 Kbps link to the JVNC supercomputer center in Princeton.  As I recall,
no one returned my call or my emails, though Mats and company usually were
quite on the ball.



The probing was continuing on the root, so I decided to call my friend
Elise Gerich at the NSFnet, and ask her if she wouldn?t put in a null route
to the university in Finland in the core backbone network, figuring that
cutting off the connectivity to the university would get someone?s
attention.  She said that she would really prefer I call Sergio Heker at
Princeton, who managed the link and could install a null route there where
the link came in as a more targeted solution.



When I told Sergio what was happening (one of the root?s being attacked),
and that no one was doing anything about it, he said he would take care of
it.  Instead of installing a null route, he walked into the machine room
where the main JVNC nodes were located, walked to the satellite DSU that
connected JVNC to Stockholm, and pushed the loopback button.    So it is
really Sergio who deserves credit for this story, not me.  No more probes
on the root server.  J



I am told the following morning the grad student responsible for this was
met by a group of angry system administrators as he entered his office.
The conversation went like something this according to one of the people
there:



IT admin: Did you notice that the Internet is down today?

Student:  I noticed that ? is something broken with our connection?

IT admin:  In fact, not only our university can?t talk to the Internet,
 but no one in Finland can.

Student:  Oh, really?

IT admin: In fact, no one in all of Scandinavia can reach the Internet
today.

Student: Wow, that is a big problem.  Why are talking to me about it?

IT admin:  Because it is all YOUR fault! Stop messing around with those
NASA servers!



The connection was restored later that day, and no one from Finland tried
breaking into the root anymore, at least not while I was still there at
Ames.  I don?t believe the grad student was ever jailed, though I suspect
he may have needed a fresh set of underwear that day.  This is the story as
best as I can remember it, and it was around 1990 as opposed to 1988 as I
recall.



Back in the old days, people cared about policing bad behavior.  I could
tell you tons of stories where people had to take action to keep the
routing system safe from abuse.  If there was routing braindamage, people
would just fix it.  The old AUP served as the enforcement vehicle.  Now of
course things are much more complicated, and folks are less concerned with
?public health? than honoring contracts, etc?  But it was not always this
way.



Thanks,

Milo

From gbonser at seven.com  Thu Feb  2 01:53:53 2012
From: gbonser at seven.com (George Bonser)
Date: Thu, 2 Feb 2012 07:53:53 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
In-Reply-To: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
References: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>

> Back in the old days, people cared about policing bad behavior. 

And I believe that is all that is needed today.  We simply, as a community, need to decide that we aren't going to tolerate such behavior.  It really is that simple.  The problem seems to be getting people to act.  In fact, as this demonstrations, actions don't have to be taken often.  Generally, once the big hammer is used, it gets the point across.

Thank you, Milo, for being part of the solution.



From jaap at NLnetLabs.nl  Thu Feb  2 02:10:05 2012
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Thu, 02 Feb 2012 09:10:05 +0100
Subject: antisocial security
In-Reply-To: <m21uqdc2lm.wl%randy@psg.com>
References: <m21uqdc2lm.wl%randy@psg.com>
Message-ID: <201202020810.q128A5mY034136@bartok.nlnetlabs.nl>

    
    and, i noticed the problem because i can not get to the web site at
    http://www.ssa.gov/ from tokyo.
    
Lot's of .gov web sites are not available outside (at least what
somebody thinks is outside) the US.

	jaap


From randy at psg.com  Thu Feb  2 02:13:24 2012
From: randy at psg.com (Randy Bush)
Date: Thu, 02 Feb 2012 17:13:24 +0900
Subject: antisocial security
In-Reply-To: <201202020810.q128A5mY034136@bartok.nlnetlabs.nl>
References: <m21uqdc2lm.wl%randy@psg.com>
 <201202020810.q128A5mY034136@bartok.nlnetlabs.nl>
Message-ID: <m2ipjpac0r.wl%randy@psg.com>

> Lot's of .gov web sites are not available outside (at least what
> somebody thinks is outside) the US.

it turns out to be local to my net segment ip space, we think.  it is
reachable from other networks in japan and even at least two other
segments in iij.

still debugging

randy


From goemon at anime.net  Thu Feb  2 02:12:20 2012
From: goemon at anime.net (goemon at anime.net)
Date: Thu, 2 Feb 2012 00:12:20 -0800 (PST)
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CAAAwwbVxtg3dVsNm-WSY7XJbjVjKd+hdSo-4bxB8vLQG=HpnRA@mail.gmail.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <20120201211344.2B9291CA11AB@drugs.dv.isc.org>
 <4F29C00E.4050704@rollernet.us>
 <CAAAwwbVxtg3dVsNm-WSY7XJbjVjKd+hdSo-4bxB8vLQG=HpnRA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202020010280.24668@sasami.anime.net>

On Wed, 1 Feb 2012, Jimmy Hess wrote:
> What the internet really needs is  Tier1 and Tier2 providers participating
> in the internet who  "care", regardless of the popularity or size of
> netblocks or issues involved.   And by "care", I mean,  providers
> efficiently investigating reports of hijacking or rogue announcement,  and
> taking switft responsible actions, without  bureaucratic processes
> requiring   years   and reams of paperwork, or any attempt to shrug off
> responsibility they have as intermediary.

caring doesn't make money. terminating abusive customers is lost revenue.

what needs to happen is retaining abusive customers needs to be more 
expensive than letting them go.

-Dan


From denys at visp.net.lb  Thu Feb  2 03:16:40 2012
From: denys at visp.net.lb (Denys Fedoryshchenko)
Date: Thu, 02 Feb 2012 11:16:40 +0200
Subject: antisocial security
In-Reply-To: <201202020810.q128A5mY034136@bartok.nlnetlabs.nl>
References: <m21uqdc2lm.wl%randy@psg.com>
 <201202020810.q128A5mY034136@bartok.nlnetlabs.nl>
Message-ID: <f81ab141f9b5e72fe1e725230b2a7393@visp.net.lb>

 On Thu, 02 Feb 2012 09:10:05 +0100, Jaap Akkerhuis wrote:
> and, i noticed the problem because i can not get to the web site at
>     http://www.ssa.gov/ from tokyo.
>
> Lot's of .gov web sites are not available outside (at least what
> somebody thinks is outside) the US.
>
> 	jaap
 Just tested:
 Lebanon, Greece, Saudi Arabia, Netherlands, Germany - all is fine

 ---
 System administrator
 Denys Fedoryshchenko
 Virtual ISP S.A.L.


From ffo at sesp.ch  Thu Feb  2 03:59:24 2012
From: ffo at sesp.ch (Florian Forster)
Date: Thu, 2 Feb 2012 09:59:24 +0000
Subject: AW: not excactly on-topic Server Cabinet question
In-Reply-To: <635D17EE85D35A49B8F278998E6C3404647C8EB4DB@EXVS.dev.oati.local>
References: <635D17EE85D35A49B8F278998E6C3404647C8EB4DB@EXVS.dev.oati.local>
Message-ID: <E620221E2BB25445BC0BD66F19DAD78623513E81@sesp12.sesp.ch>

Rittal can offer an electric lock system, we had those in combination with
legic cards
KABA made the card reader

Sry the link is in german
http://www.thede.de/uploads/media/B-Net_9106_TS8_de.pdf

greets


-----Urspr?ngliche Nachricht-----
Von: Erik Amundson [mailto:Erik.Amundson at oati.net] 
Gesendet: Donnerstag, 2. Februar 2012 06:05
An: nanog at nanog.org
Betreff: [SPAM] not excactly on-topic Server Cabinet question

I apologize for this being off-topic in the NANOG list, but I'm hoping some
of you have experience with the particulars of what I'm looking for...

I am looking for a server cabinet which has an electric latching mechanism
on it.  I want to use my existing security system and proximity card reader,
but have a cabinet door that would open when the card reader is read.

Does anyone sell anything like this?

I've looked into Rittal, APC, Hoffman, Wrightline (now Eaton), Knurr (via
Liebert/Emerson), Middle Atlantic, and Panduit.  So far, nothing.

Any suggestions?  Feel free to reply off-list.

- Erik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5595 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120202/8d9b4fe9/attachment.bin>

From rs at seastrom.com  Thu Feb  2 04:57:23 2012
From: rs at seastrom.com (Robert E. Seastrom)
Date: Thu, 02 Feb 2012 05:57:23 -0500
Subject: US DOJ victim letter
In-Reply-To: <20120128163047.GA25420@vacation.karoshi.com.>
 (bmanning@vacation.karoshi.com's message of "Sat, 28 Jan 2012 16:30:47 +0000")
References: <30970.1327688588@turing-police.cc.vt.edu>
 <CB485770.5A9A7%nanog@hostleasing.net>
 <CAMDXq5OiJ-gXeZW=MmLCD_PznnHyGfHjiMs=i1k2e_b1-S27OA@mail.gmail.com>
 <20120128163047.GA25420@vacation.karoshi.com.>
Message-ID: <86wr85iju4.fsf@seastrom.com>


bmanning at vacation.karoshi.com writes:

> I missed the part where ARIN turned over its address database
> w/ associatedd registration information to the Fed ... I mean
> I've always advocated for LEO access, but ther has been
> significant pushback fromm the community on unfettered access
> to that data.  As I recall, there are even policies and
> processes to limit/restrict external queries to prevent a DDos
> of the whois servers.  And some fairly strict policies on who
> gets dumps of the address space.  As far as I know (not very
> far) bundling the address database -and- the registration data
> are not available to mere mortals.
>
> So - just how DID the Fed get the data w/o violating ARIN policy?

Hi Bill,

In case you're not trolling here (occam's razor says I'm giving you
too much credit), a few points:

   1) There has been substantial involvement by Federal LE at ARIN PPMs
   in terms of pushing for policy that makes WHOIS data more accurate...
   including one person who served on the ARIN AC after he went to work
   in the private sector.

   2) LE can type "show ip bgp" too and only needs to hit a whois server
   once per ASN.

   3) There is a bulk whois policy.  Whether "hi, we now have the
   reins of a compromised botnet or whatever and want to reach out to
   let people know that they're pwn3d" falls under the rubric of
   "Internet operational or technical research purposes pertaining to
   Internet operations" is left as an exercise to the reader.

   Section 3.1 of the NRPM says that Bulk Whois "... point of contact
   information will not include data marked as private."

   As I outlined in #2 above, a full or partial dump is not really
   something that's necessary.

   https://www.arin.net/resources/agreements/bulkwhois.pdf

I'm pretty confident there were no policy violations here.

-r



From bmanning at vacation.karoshi.com  Thu Feb  2 05:23:19 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 2 Feb 2012 11:23:19 +0000
Subject: US DOJ victim letter
In-Reply-To: <86wr85iju4.fsf@seastrom.com>
References: <30970.1327688588@turing-police.cc.vt.edu>
 <CB485770.5A9A7%nanog@hostleasing.net>
 <CAMDXq5OiJ-gXeZW=MmLCD_PznnHyGfHjiMs=i1k2e_b1-S27OA@mail.gmail.com>
 <20120128163047.GA25420@vacation.karoshi.com.> <86wr85iju4.fsf@seastrom.com>
Message-ID: <20120202112319.GA23067@vacation.karoshi.com.>

On Thu, Feb 02, 2012 at 05:57:23AM -0500, Robert E. Seastrom wrote:
> 
> bmanning at vacation.karoshi.com writes:
> 
> > I missed the part where ARIN turned over its address database
> > w/ associatedd registration information to the Fed ... I mean
> > I've always advocated for LEO access, but ther has been
> > significant pushback fromm the community on unfettered access
> > to that data.  As I recall, there are even policies and
> > processes to limit/restrict external queries to prevent a DDos
> > of the whois servers.  And some fairly strict policies on who
> > gets dumps of the address space.  As far as I know (not very
> > far) bundling the address database -and- the registration data
> > are not available to mere mortals.
> >
> > So - just how DID the Fed get the data w/o violating ARIN policy?
> 
> Hi Bill,
> 
> In case you're not trolling here (occam's razor says I'm giving you
> too much credit), a few points:
> 
>    1) There has been substantial involvement by Federal LE at ARIN PPMs
>    in terms of pushing for policy that makes WHOIS data more accurate...
>    including one person who served on the ARIN AC after he went to work
>    in the private sector.
> 
>    2) LE can type "show ip bgp" too and only needs to hit a whois server
>    once per ASN.
> 
>    3) There is a bulk whois policy.  Whether "hi, we now have the
>    reins of a compromised botnet or whatever and want to reach out to
>    let people know that they're pwn3d" falls under the rubric of
>    "Internet operational or technical research purposes pertaining to
>    Internet operations" is left as an exercise to the reader.
> 
>    Section 3.1 of the NRPM says that Bulk Whois "... point of contact
>    information will not include data marked as private."
> 
>    As I outlined in #2 above, a full or partial dump is not really
>    something that's necessary.
> 
>    https://www.arin.net/resources/agreements/bulkwhois.pdf
> 
> I'm pretty confident there were no policy violations here.
> 
> -r

	sigh... will have to look elsewhere for the tri-lateral commission.

/bill


From marka at isc.org  Thu Feb  2 06:08:14 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 02 Feb 2012 23:08:14 +1100
Subject: antisocial security
In-Reply-To: Your message of "Thu, 02 Feb 2012 11:16:40 +0200."
 <f81ab141f9b5e72fe1e725230b2a7393@visp.net.lb>
References: <m21uqdc2lm.wl%randy@psg.com>
 <201202020810.q128A5mY034136@bartok.nlnetlabs.nl>
 <f81ab141f9b5e72fe1e725230b2a7393@visp.net.lb>
Message-ID: <20120202120814.DB34D1CC20E8@drugs.dv.isc.org>


In message <f81ab141f9b5e72fe1e725230b2a7393 at visp.net.lb>, Denys Fedoryshchenko
 writes:
>  On Thu, 02 Feb 2012 09:10:05 +0100, Jaap Akkerhuis wrote:
> > and, i noticed the problem because i can not get to the web site at
> >     http://www.ssa.gov/ from tokyo.
> >
> > Lot's of .gov web sites are not available outside (at least what
> > somebody thinks is outside) the US.
> >
> > 	jaap
>  Just tested:
>  Lebanon, Greece, Saudi Arabia, Netherlands, Germany - all is fine

As is Australia.  I suspect it is just a "normal" snafu.
 
>  ---
>  System administrator
>  Denys Fedoryshchenko
>  Virtual ISP S.A.L.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From sethm at rollernet.us  Thu Feb  2 10:03:55 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 02 Feb 2012 08:03:55 -0800
Subject: not excactly on-topic Server Cabinet question
In-Reply-To: <635D17EE85D35A49B8F278998E6C3404647C8EB4DB@EXVS.dev.oati.local>
References: <635D17EE85D35A49B8F278998E6C3404647C8EB4DB@EXVS.dev.oati.local>
Message-ID: <4F2AB3EB.9050905@rollernet.us>

On 2/1/12 9:05 PM, Erik Amundson wrote:
> I apologize for this being off-topic in the NANOG list, but I'm hoping some of you have experience with the particulars of what I'm looking for...
> 
> I am looking for a server cabinet which has an electric latching mechanism on it.  I want to use my existing security system and proximity card reader, but have a cabinet door that would open when the card reader is read.
> 
> Does anyone sell anything like this?
> 
> I've looked into Rittal, APC, Hoffman, Wrightline (now Eaton), Knurr (via Liebert/Emerson), Middle Atlantic, and Panduit.  So far, nothing.
> 
> Any suggestions?  Feel free to reply off-list.
> 

APC has it, but it's part of access control package AP9361 so I don't
know what the part number of the latch handle alone would be.

~Seth


From morrowc.lists at gmail.com  Thu Feb  2 11:20:41 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 2 Feb 2012 12:20:41 -0500
Subject: antisocial security
In-Reply-To: <20120202120814.DB34D1CC20E8@drugs.dv.isc.org>
References: <m21uqdc2lm.wl%randy@psg.com>
 <201202020810.q128A5mY034136@bartok.nlnetlabs.nl>
 <f81ab141f9b5e72fe1e725230b2a7393@visp.net.lb>
 <20120202120814.DB34D1CC20E8@drugs.dv.isc.org>
Message-ID: <CAL9jLaZp=f+CAUue_kkcksS9BPk+L+wVy_hEd--TTMdy322MiA@mail.gmail.com>

On Thu, Feb 2, 2012 at 7:08 AM, Mark Andrews <marka at isc.org> wrote:
>
> In message <f81ab141f9b5e72fe1e725230b2a7393 at visp.net.lb>, Denys Fedoryshchenko
> ?writes:
>> ?On Thu, 02 Feb 2012 09:10:05 +0100, Jaap Akkerhuis wrote:
>> > and, i noticed the problem because i can not get to the web site at
>> > ? ? http://www.ssa.gov/ from tokyo.
>> >
>> > Lot's of .gov web sites are not available outside (at least what
>> > somebody thinks is outside) the US.
>> >
>> > ? ? jaap
>> ?Just tested:
>> ?Lebanon, Greece, Saudi Arabia, Netherlands, Germany - all is fine
>
> As is Australia. ?I suspect it is just a "normal" snafu.

most likely this is a case of someone on the same /24 (or larger
supernet) where randy's machine lives at home 'hacked' (or port
scanned, or was used in a synflood or .... you get the point) one of
several US .gov assets :( 'eventually' that supernet should be removed
from filters.

-chris
weeee!


From rps at maine.edu  Thu Feb  2 11:32:44 2012
From: rps at maine.edu (Ray Soucy)
Date: Thu, 2 Feb 2012 12:32:44 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
Message-ID: <CALFTrnP0pAtBJOJWTzzcad0hvq2_3DjferwOkckHqycT+sE_OQ@mail.gmail.com>

> So, to pose the obvious question: Should there be [a law against prefix hijacking]?




So far the track record of the US government trying to make laws
regarding technology and the Internet has been less than stellar.

The DMCA is already bad enough, but we continue to see things like
PROTECT IP and SOPA pop up in attempts to hand over even more control
of the Internet to those with enough money to buy the votes; at great
cost to service providers and universities, mind you.

Over the past few years it has become blatantly obvious that entire
industries are trying to gain special control over the Internet.  The
RIAA and the MPAA both being openly guilty:

"Candidly, those who count on quote 'Hollywood' for support need to
understand that this industry is watching very carefully who's going
to stand up for them when their job is at stake, don't ask me to write
a check for you when you think your job is at risk and then don't pay
any attention to me when my job is at stake."

Chris Dodd, CEO MPAA in response to Obama position on SOPA.

With attempts at government control of DNS already underway, I think
handing over control of BGP would be a dream come true for these guys.

No thank you,

I think the Internet is doing just fine.

If anything, I think we need the US government to roll back excessive
copyright and software patent law, and push for the repeal of the
DMCA.

Just my 5 cents.




-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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


From nathan at atlasnetworks.us  Thu Feb  2 12:23:09 2012
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Thu, 2 Feb 2012 18:23:09 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CALFTrnP0pAtBJOJWTzzcad0hvq2_3DjferwOkckHqycT+sE_OQ@mail.gmail.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
 <CALFTrnP0pAtBJOJWTzzcad0hvq2_3DjferwOkckHqycT+sE_OQ@mail.gmail.com>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B696683@ex-mb-1.corp.atlasnetworks.us>

> > So, to pose the obvious question: Should there be [a law against
> prefix hijacking]?

While I'm certain that's largely rooted in lawmakers who are not technically savvy, I wonder if we-as-an-industry couldn't (or, shouldn't) be doing more to move internal values and policies into defensible legal standards.

> So far the track record of the US government trying to make laws
> regarding technology and the Internet has been less than stellar.
> 
> The DMCA is already bad enough, but we continue to see things like
> PROTECT IP and SOPA pop up in attempts to hand over even more control
> of the Internet to those with enough money to buy the votes; at great
> cost to service providers and universities, mind you.

The best we-as-an-industry seem to be able to contribute to the problem is strongly worded and expertly backed petitions to Congress.  We're in permanent legislative fire-fighting mode, and we seem to be losing ground at an alarming pace.
 
> Over the past few years it has become blatantly obvious that entire
> industries are trying to gain special control over the Internet.  The
> RIAA and the MPAA both being openly guilty:
> 
> "Candidly, those who count on quote 'Hollywood' for support need to
> understand that this industry is watching very carefully who's going
> to stand up for them when their job is at stake, don't ask me to write
> a check for you when you think your job is at risk and then don't pay
> any attention to me when my job is at stake."
> 
> Chris Dodd, CEO MPAA in response to Obama position on SOPA.
 
You and I agree that this is a disturbing concept - I doubt there are many dissenting opinions on this list (which is its own monoculture issue for another day).

> With attempts at government control of DNS already underway, I think
> handing over control of BGP would be a dream come true for these guys.
 
Indeed - and I don't think anyone is suggesting that we hand operational control of BGP to the courts.  I'm more curious about legally codifying RIR allocations (obviously, this is a complex and regional issue, but since the two parties in the OP were both US based companies, we can at least begin to have this conversation).

Again, I don't know what the right answer is.  I'm just turning this over in my brain, and it seems to me that the current state of affairs is too fragile.  There is no 'drivers test' before you get your AS number.  There are few consequences for hijackers and the service providers who support them - especially if those providers are very large.  There is historical precedent for government regulation in non-virtual industries helping to curb the chaos.

Hypothesis: If operators could recover their damages via the legal system from a service provider for aiding and abetting the hijacking of their ARIN assigned space, it would encourage a great deal more due-diligence in the service provider space.  With nothing to gain, and money to lose, companies will expect their netops people to behave as good netizens.

Thoughts?

Nathan


From brunner at nic-naa.net  Thu Feb  2 12:58:36 2012
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Thu, 02 Feb 2012 13:58:36 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CALFTrnP0pAtBJOJWTzzcad0hvq2_3DjferwOkckHqycT+sE_OQ@mail.gmail.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
 <CALFTrnP0pAtBJOJWTzzcad0hvq2_3DjferwOkckHqycT+sE_OQ@mail.gmail.com>
Message-ID: <4F2ADCDC.4070400@nic-naa.net>

On 2/2/12 12:32 PM, Ray Soucy wrote:
>> So, to pose the obvious question: Should there be [a law against prefix hijacking]?
> 
> 
> 
> So far the track record of the US government trying to make laws
> regarding technology and the Internet has been less than stellar.
...

While I agree with Ray's points, I want to point out that "new law" to
address (obvious pun) disruptive announcements may not be necessary --
at least, I blew off the better part of a day writing to Peter Dengate
Thrush and Rod Beckstrom that arbitrary bad acts in the public
addressing system were the proper concern of the entity tasked with
the technical coordination of unique endpoint identifiers.

I didn't expect much from the recipients -- I've known Peter too long
and never could be bothered to share Rod's twinkle, but while one
prefix announcement may harm one set of downstreams, rapid sustained
announcement and withdrawal will harm the DFZ, a much larger kettle of
digital fish.

One could claim that absent convergence limiting effect on the DFZ no
prefix bogosity has general adverse effect (but some prefixes are more
interesting than others, so that isn't a policy without nuances), and
enjoy watching the state actors and non-state actors and ordinary
venal idiots and very ordinary fatfingered idiots*
prepend/announce/withdraw with gleeful abandon, or one could assert
that autonomous reallocations of limited resources has general adverse
effect in addition to the local effect on downstreams, and associate
coordinated corrective reallocations with autonomous reallocations.
That's "pulling the plug" on retarded dictators, embezzlers, and the
latent mil-wits who view the DNS and BGP infrastructures as legitimate
military targets.

I don't expect progress overnight, in fact I wrote the former Chair
and current CEO of that "entity tasked with the technical coordination
of unique endpoint identifiers" with no expectations at all
(knowledge, supra), but policy response (including errors, see PIPA,
SOPA, et seq.) to bad acts in one set of identifiers can be extended
to policy response (including errors, resolvers have no monopoly on
errors) on the other set of identifiers.

So, new law? I don't think its necessary.

YMMV,
Eric


From gbonser at seven.com  Thu Feb  2 15:22:04 2012
From: gbonser at seven.com (George Bonser)
Date: Thu, 2 Feb 2012 21:22:04 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <4F2ADCDC.4070400@nic-naa.net>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
 <CALFTrnP0pAtBJOJWTzzcad0hvq2_3DjferwOkckHqycT+sE_OQ@mail.gmail.com>
 <4F2ADCDC.4070400@nic-naa.net>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CA152B@RWC-MBX1.corp.seven.com>

> 
> So, new law? I don't think its necessary.
> 
> YMMV,
> Eric


The problems are manifold.  First of all, a nation's laws only extend to the borders of that nation.  The UN is not a government, it is a diplomatic body so it really can't enact anything either.  The Internet community is global and if we agree to a certain standard of behavior and consequences for violating that standard, we can police it ourselves just fine.  The fundamental problem is there is no absolute "source of truth" in who is entitled to use which resource.  So there is little people can really do with any certainty until such a place exists.  What we need is a registry that we all agree is valid and agree to go by what it says and if you announce a route that belongs to someone else without their permission and you are made aware of that fact and continue to announce the route, you are subject to having your traffic shunned until you are in compliance.  That resource (the registry) should absolutely not be maintained by the UN or any government entity as that will make it unusable.  It is something the community has the technology to do, it just requires the resources and the will to do it.



From shacolby at bluejeans.com  Thu Feb  2 15:50:09 2012
From: shacolby at bluejeans.com (Shacolby Jackson)
Date: Thu, 2 Feb 2012 13:50:09 -0800
Subject: This network is too good...
In-Reply-To: <CA+HC509T_jyOV42ZXq220f1t5+_i9jP4Z6M=ADNaeHaMB02MnQ@mail.gmail.com>
References: <86d39yknou.fsf@seastrom.com>
 <20120202022135.GA11800@ussenterprise.ufp.org>
 <CA+HC509T_jyOV42ZXq220f1t5+_i9jP4Z6M=ADNaeHaMB02MnQ@mail.gmail.com>
Message-ID: <CACEOnk_tAQWc2iWB7Cpysw6RQC5Pq1gNVMO2cbebgM9rsN_xOQ@mail.gmail.com>

I know people who have been very happy with Apposite. They have a couple
different lines that can simulate a lot of different conditions.

http://www.apposite-tech.com

I know they call them WAN simulators but I know a company that strictly
uses them for layer2 to simulate congestion between switches, etc.


On Wed, Feb 1, 2012 at 7:05 PM, Thomas Maufer <tmaufer at gmail.com> wrote:

> IWL's "Maxwell" is probably what you want:
>
>
> http://www.iwl.com/press-releases/new-capabilities-for-maxwell-the-network-impairment-system.html
>
> Good luck breaking stuff!
>
>
>
>
>
> On Wednesday, February 1, 2012, Leo Bicknell <bicknell at ufp.org> wrote:
> > In a message written on Wed, Feb 01, 2012 at 08:51:13PM -0500, Robert E.
> Seastrom wrote:
> >> Any thoughts on products that screw up networks in deterministic (and
> >> realistic found-in-the-wild) ways?  I'm thinking of stuff like
> >> PacketStorm, Dummynet, etc.  Dial up jitter, latency, tail drop, RED,
> >> whatever...
> >>
> >> (I know someone's gonna say "Just buy a Brand Z FubarSwitch 3k, they
> >> will screw up your whole network and you don't even have to configure
> >> it to do so!")
> >
> > The only good L2 solutions I've ever seen are expensive commercial
> > testing.  DummyNet, on a L3 aware FreeBSD box is extremely useful and
> > easy to configure to simulate varous loss or latency patterns.
> >
> > What tool is right depends on if you want to test at L2 (simulate a
> > circuit/cable with a particular problem) or L3 (just a router in the
> > middle dropping packets), or testing an end user application.  L2,
> > particularly if you want to simulate things like a duplex mismatch is
> > hard, and not often needed.
> >
> > If your goal is to test applications against network conditions, OSX has
> > a nifty new tool, "Network Link Conditioner".  It's basically just
> > dummynet with various throughput, delay, and packet loss settings but it
> > makes it dead simple to select from various pull downs.
> >
> >
>
> http://www.thegeeksclub.com/simulate-internet-connectivity-speed-mac-os-lion-107-network-link-conditioner
> >
> > I bring it up mainly because if you want to set your own DummyNet
> > settings for other testing it's a nice database of average case
> > performance for a number of link types!
> >
> > --
> >       Leo Bicknell - bicknell at ufp.org - CCIE 3440
> >        PGP keys at http://www.ufp.org/~bicknell/
> >
>
> --
>
> ~tom
>
> +1 408 890-7548 (Google Voice)
>

From jra at baylink.com  Thu Feb  2 16:38:57 2012
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 2 Feb 2012 17:38:57 -0500 (EST)
Subject: Verisign deep-hacked.  For months.
Message-ID: <20670730.288.1328222336994.JavaMail.root@benjamin.baylink.com>

Oh, my.

http://finance.yahoo.com/news/Key-Internet-operator-rb-2857339070.html

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


From zaid at zaidali.com  Thu Feb  2 17:30:40 2012
From: zaid at zaidali.com (Zaid Ali)
Date: Thu, 02 Feb 2012 15:30:40 -0800
Subject: Verisign deep-hacked.  For months.
In-Reply-To: <20670730.288.1328222336994.JavaMail.root@benjamin.baylink.com>
Message-ID: <CB505A31.346A9%zaid@zaidali.com>

I love this

VeriSign said its executives "do not believe these attacks breached the
servers that support our Domain Name System network,"

"Oh my God," said Stewart Baker, former assistant secretary of the
Department of Homeland Security and before that the top lawyer at the
National Security Agency. "That could allow people to imitate almost any
company on the Net."

Sounds like another opportunity for <insert congress person> to propose
SOPA-2

Zaid  

On 2/2/12 2:38 PM, "Jay Ashworth" <jra at baylink.com> wrote:

>Oh, my.
>
>http://finance.yahoo.com/news/Key-Internet-operator-rb-2857339070.html
>
>Cheers,
>-- jra
>-- 
>Jay R. Ashworth                  Baylink
>jra at baylink.com
>Designer                     The Things I Think                       RFC
>2100
>Ashworth & Associates     http://baylink.pitas.com         2000 Land
>Rover DII
>St Petersburg FL USA      http://photo.imageinc.us             +1 727 647
>1274
>




From kemp at network-services.uoregon.edu  Thu Feb  2 17:32:17 2012
From: kemp at network-services.uoregon.edu (John Kemp)
Date: Thu, 02 Feb 2012 15:32:17 -0800
Subject: new routeviews collector: TELX Atlanta
Message-ID: <4F2B1D01.2040702@network-services.uoregon.edu>


We just brought up a new collector at the
TELX Atlanta facility.    Peering information is at:
http://www.peeringdb.com/view.php?asn=6447&peerParticipantsPublics_mPage=2

    route-views.telxatl.routeviews.org

If anyone is interested an peering and sharing
full views, please e-mail us at help at routeviews.org.
Much thanks to the TELX guys.  They have gone
above and beyond in helping us get this going.

John Kemp (kemp at routeviews.org)
help at routeviews.org




From mysidia at gmail.com  Thu Feb  2 18:00:13 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 2 Feb 2012 18:00:13 -0600
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CA152B@RWC-MBX1.corp.seven.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
 <CALFTrnP0pAtBJOJWTzzcad0hvq2_3DjferwOkckHqycT+sE_OQ@mail.gmail.com>
 <4F2ADCDC.4070400@nic-naa.net>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CA152B@RWC-MBX1.corp.seven.com>
Message-ID: <CAAAwwbXs8gmQrxM_H9sdU_PoUGqf24uJmd7X0JWhLZZYEizWUw@mail.gmail.com>

On Thu, Feb 2, 2012 at 3:22 PM, George Bonser <gbonser at seven.com> wrote:


> The fundamental problem is there is no absolute "source of truth" in who
> is entitled to use which resource.
>

Well, the "absolute truth" would be the whois service maintained by the
RIRs, regarding who is the contact for what resource.

Now if we could only agree on one IRR for every region,   require
authorization by the RIR listed  contact   to  gain  the ability to create
IRR  entries for that resource,    and make publication of a route into the
IRR  an actual requirement,  we would have just that.


However,  it would be just as subject to  government interference,  in the
form of orders to the IRR database maintainer to delete certain networks.

-- 
-Mysid

From ops.lists at gmail.com  Thu Feb  2 18:26:17 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Fri, 3 Feb 2012 05:56:17 +0530
Subject: Verisign deep-hacked. For months.
In-Reply-To: <CB505A31.346A9%zaid@zaidali.com>
References: <20670730.288.1328222336994.JavaMail.root@benjamin.baylink.com>
 <CB505A31.346A9%zaid@zaidali.com>
Message-ID: <CAArzuou_GeCOQwsXHza_iykuKH-S44hQWutzVeSh9JSJ2AoKFw@mail.gmail.com>

So what part of VRSN got broken into?  They do a lot more than just DNS.

On Fri, Feb 3, 2012 at 5:00 AM, Zaid Ali <zaid at zaidali.com> wrote:
>
> VeriSign said its executives "do not believe these attacks breached the
> servers that support our Domain Name System network,"
>
> "Oh my God," said Stewart Baker, former assistant secretary of the
> Department of Homeland Security and before that the top lawyer at the
> National Security Agency. "That could allow people to imitate almost any
> company on the Net."



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From nanog-post at rsuc.gweep.net  Thu Feb  2 18:28:41 2012
From: nanog-post at rsuc.gweep.net (Joe Provo)
Date: Thu, 2 Feb 2012 19:28:41 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>
References: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>
Message-ID: <20120203002840.GA80793@gweep.net>

On Thu, Feb 02, 2012 at 07:53:53AM +0000, George Bonser wrote:
> > Back in the old days, people cared about policing bad behavior. 
> 
> And I believe that is all that is needed today.  We simply, as a
> community, need to decide that we aren't going to tolerate such
> behavior.  It really is that simple.  The problem seems to be getting
> people to act.  In fact, as this demonstrations, actions don't have
> to be taken often.  Generally, once the big hammer is used, it gets
> the point across.

The suits won, and many nerds either threw in with them or revealed 
their affinity for the easy life and gave up. Being principled and 
turning away dirty money or exercising the "fire the customer" clause 
tends to be disliked by corporate officers.


-- 
         RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG


From jsw at inconcepts.biz  Thu Feb  2 18:34:37 2012
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Thu, 2 Feb 2012 19:34:37 -0500
Subject: Verisign deep-hacked. For months.
In-Reply-To: <CAArzuou_GeCOQwsXHza_iykuKH-S44hQWutzVeSh9JSJ2AoKFw@mail.gmail.com>
References: <20670730.288.1328222336994.JavaMail.root@benjamin.baylink.com>
 <CB505A31.346A9%zaid@zaidali.com>
 <CAArzuou_GeCOQwsXHza_iykuKH-S44hQWutzVeSh9JSJ2AoKFw@mail.gmail.com>
Message-ID: <CAPWAtb+Eyjm6uszO38LAArY46mh_T7F-nrmtaLggN=j3d29SUw@mail.gmail.com>

On Thu, Feb 2, 2012 at 7:26 PM, Suresh Ramasubramanian
<ops.lists at gmail.com> wrote:
> So what part of VRSN got broken into? ?They do a lot more than just DNS.

Indeed, VeriSign owns Illuminet, who are mission-critical for POTS.
Illuminet is also in the business of recording telephone calls, SMS
messages, etc. for law enforcement.

That means that a "breach" at "VeriSign" could be nothing, or it could
give bad guys access to a lot more than any breach or leak reported to
date.  Who knows?
-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From zaid at zaidali.com  Thu Feb  2 18:42:27 2012
From: zaid at zaidali.com (Zaid Ali)
Date: Thu, 02 Feb 2012 16:42:27 -0800
Subject: Verisign deep-hacked. For months.
In-Reply-To: <CAArzuou_GeCOQwsXHza_iykuKH-S44hQWutzVeSh9JSJ2AoKFw@mail.gmail.com>
Message-ID: <CB506D08.34718%zaid@zaidali.com>

That part is ambiguous at the moment since Verisign has not released
details. Symantec has bought the SSL part of the business and claim that
the SSL acquired network is not compromised. Sounds like lots of
assumptions being drawn.

Zaid

On 2/2/12 4:26 PM, "Suresh Ramasubramanian" <ops.lists at gmail.com> wrote:

>So what part of VRSN got broken into?  They do a lot more than just DNS.
>
>On Fri, Feb 3, 2012 at 5:00 AM, Zaid Ali <zaid at zaidali.com> wrote:
>>
>> VeriSign said its executives "do not believe these attacks breached the
>> servers that support our Domain Name System network,"
>>
>> "Oh my God," said Stewart Baker, former assistant secretary of the
>> Department of Homeland Security and before that the top lawyer at the
>> National Security Agency. "That could allow people to imitate almost any
>> company on the Net."
>
>
>
>-- 
>Suresh Ramasubramanian (ops.lists at gmail.com)




From johnl at iecc.com  Thu Feb  2 19:56:38 2012
From: johnl at iecc.com (John Levine)
Date: 3 Feb 2012 01:56:38 -0000
Subject: Verisign deep-hacked.  For months.
In-Reply-To: <20670730.288.1328222336994.JavaMail.root@benjamin.baylink.com>
Message-ID: <20120203015638.38650.qmail@joyce.lan>

See my new blog entry: 

World notices that Verisign said three months ago that they had a
security breach two years ago

http://jl.ly/2012/02/02#vrsnbreach

R's,
John


From randy at psg.com  Thu Feb  2 20:00:23 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 03 Feb 2012 11:00:23 +0900
Subject: Verisign deep-hacked.  For months.
In-Reply-To: <20120203015638.38650.qmail@joyce.lan>
References: <20670730.288.1328222336994.JavaMail.root@benjamin.baylink.com>
 <20120203015638.38650.qmail@joyce.lan>
Message-ID: <m2ehuc7k20.wl%randy@psg.com>

At 3 Feb 2012 01:56:38 -0000, John Levine wrote:
> World notices that Verisign said three months ago that they had a
> security breach two years ago

i thought news was only supposed to be at eleven


From jcurran at arin.net  Thu Feb  2 20:02:01 2012
From: jcurran at arin.net (John Curran)
Date: Fri, 3 Feb 2012 02:02:01 +0000
Subject: Regarding Hijacked Networks 
In-Reply-To: <65E48EB1-A51C-4C70-9629-CD7477D6877B@delong.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <20120201015257.39A071C95D68@drugs.dv.isc.org>
 <65E48EB1-A51C-4C70-9629-CD7477D6877B@delong.com>
Message-ID: <E7346720-1357-43E6-88CA-24AC5A99BAE9@corp.arin.net>

On Jan 31, 2012, at 9:03 PM, Owen DeLong wrote:

> Not to put a damper on things, but, is there actually any law that precludes use of integers as internet addresses contrary to the registration data contained in RIR databases?

ARIN spends a bit of time on these types of questions.

The right to exclusive use a particular block Internet addresses is 
indeed provided by contract with ARIN, but the context is within the 
registration system itself.  We are not aware of any law in ARIN's 
service region which would preclude other parties from configuring 
equipment with any numbers they wish.  Note also - if someone thinks 
that they have a right of exclusive use of a particular block Internet 
addresses because of convictions that the addresses themselves are 
"property" (whatever that means), the outcome still doesn't change;
i.e. there is still no law or regulation as best we can determine 
which prevents someone from configuring their own equipment with 
any particular block of IP addresses... (and I would advise some
very careful thought before advocating that such be changed.[*])

In the end, the registry simple reflects a set of numbers managed for 
uniqueness by the policies set by the community.  Since the Internet 
relies on unique host identifiers, it's a pretty useful database, but 
that usefulness is predicated on people actually making use of it...
One would think that ISP's wouldn't accept routes accept from the 
parties not listed on an address block, but that is not universally 
the case, and correcting that other than at the point of injection
is rather problematic unless we have some relatively easy way to 
build, propagate, and verify routing assertions by the address 
holder (e.g. RPKI, as noted by Danny and Randy)

ARIN is slowly but steadily working on getting RPKI rolled out in 
production this year... folks interested in gaining some hands-on 
RPKI experience in the meantime can participate in ARIN's RPKI Pilot;
we have more than 50 organizations participating at this time - 
<https://www.arin.net/resources/rpki.html>

FYI,
/John

John Curran
President and CEO
ARIN

p.s.  [*] As previously noted in this discussion, address blocks may
      sometimes be hijacked based on acts that _are_ violation of law 
      (e.g fraud), but the mechanisms for dealing with such are quite 
      slow by default (at least in the US.)  That doesn't mean that 
      they can't work faster, but only that timeliness increases when 
      there are numerous harmed parties are plainly evident to the law 
      enforcement folks.  Given the potential impact from abuse or even 
      human error for any orders affecting the Internet, the delay may 
      even be an important feature of the present system.




From randy at psg.com  Thu Feb  2 20:57:37 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 03 Feb 2012 11:57:37 +0900
Subject: Regarding Hijacked Networks 
In-Reply-To: <E7346720-1357-43E6-88CA-24AC5A99BAE9@corp.arin.net>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <20120201015257.39A071C95D68@drugs.dv.isc.org>
 <65E48EB1-A51C-4C70-9629-CD7477D6877B@delong.com>
 <E7346720-1357-43E6-88CA-24AC5A99BAE9@corp.arin.net>
Message-ID: <m2aa507hem.wl%randy@psg.com>

my arin email addy and password work on the arin main web site.  they do
not work on https://rpki-pilot.arin.net/, pita

where is the trust anchor for the publication point published?

randy


From juuso.lehtinen at gmail.com  Thu Feb  2 21:01:33 2012
From: juuso.lehtinen at gmail.com (Juuso Lehtinen)
Date: Thu, 2 Feb 2012 19:01:33 -0800
Subject: This network is too good...
In-Reply-To: <86d39yknou.fsf@seastrom.com>
References: <86d39yknou.fsf@seastrom.com>
Message-ID: <CAF2UKmMOLZ7Vi+q0TYongmXZ6HUt+mEUmdQ6LyS3AjJLH15Krg@mail.gmail.com>

You have pretty much two approaches:
-Special built hardware network emulators
-Network emulator software running on generic PC

Special built HW:
If you need extreme accuracy, i.e., delay generation to micro/nanosecond
accuracy, you need to go with special purpose boxes. Special built HW also
usually provides line rate throughput, regardless of impairments you are
applying.

I have experience using Anue Systems GEM/XGEM and Calnex Paragon-X network
emulators. Both tools are special built hardware platforms that allow
generating various network impairments (delay, jitter, packet reordering,
packet loss, CRC errors, etc.).

In my opinion Anue is easier to use. It provides Web GUI where you can
configure different impairment profiles. Calnex on the other hand requires
you to install a Client software on your Windows PC. In the end, both
products support pretty much the same features. There are some differences
if you are doing specific testing with network synchronization protocols,
like SyncE or 1588v2 (PTPv2).

Network emulator SW on generic PC:
I have very little experience on running SW based network emulators. I used
to play with one that was running on Linux box - unfortunately I cannot
remember the software name. The linux software was ok for introducing
packet loss, but way inaccurate when it comes to delay insertion. If
accuracy of tens of milliseconds is good enough for you, the software based
approach might be good for you.

On Wed, Feb 1, 2012 at 5:51 PM, Robert E. Seastrom <rs at seastrom.com> wrote:

>
> Hi all,
>
> Any thoughts on products that screw up networks in deterministic (and
> realistic found-in-the-wild) ways?  I'm thinking of stuff like
> PacketStorm, Dummynet, etc.  Dial up jitter, latency, tail drop, RED,
> whatever...
>
> (I know someone's gonna say "Just buy a Brand Z FubarSwitch 3k, they
> will screw up your whole network and you don't even have to configure
> it to do so!")
>
> I'm all-ears like Ross Perot.
>
> Thanks,
>
> -r
>
>
>

From jcurran at arin.net  Thu Feb  2 21:13:48 2012
From: jcurran at arin.net (John Curran)
Date: Fri, 3 Feb 2012 03:13:48 +0000
Subject: Regarding Hijacked Networks 
In-Reply-To: <m2aa507hem.wl%randy@psg.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <20120201015257.39A071C95D68@drugs.dv.isc.org>
 <65E48EB1-A51C-4C70-9629-CD7477D6877B@delong.com>
 <E7346720-1357-43E6-88CA-24AC5A99BAE9@corp.arin.net>
 <m2aa507hem.wl%randy@psg.com>
Message-ID: <0AF293C9-4329-45DA-B34B-868BC6C84440@arin.net>

On Feb 2, 2012, at 9:57 PM, Randy Bush wrote:

> my arin email addy and password work on the arin main web site.  they do
> not work on https://rpki-pilot.arin.net/, pita

Randy - 

That's correct for the pilot - follow the link at the top of the page which says: 
"If you don't have a log in and want to take part in this pilot, click [here].

Thanks,
/John

John Curran
President and CEO
ARIN




From JTyler at fiberutilities.com  Thu Feb  2 21:20:08 2012
From: JTyler at fiberutilities.com (Jensen Tyler)
Date: Thu, 2 Feb 2012 21:20:08 -0600
Subject: This network is too good...
In-Reply-To: <CAF2UKmMOLZ7Vi+q0TYongmXZ6HUt+mEUmdQ6LyS3AjJLH15Krg@mail.gmail.com>
References: <86d39yknou.fsf@seastrom.com>
 <CAF2UKmMOLZ7Vi+q0TYongmXZ6HUt+mEUmdQ6LyS3AjJLH15Krg@mail.gmail.com>
Message-ID: <1A8A762BD508624A8BDAB9F5E1638F94601CC98D0D@comsrv01.fg.local>

netem - http://www.linuxfoundation.org/collaborate/workgroups/networking/netem 

"netem provides Network Emulation functionality for testing protocols by emulating the properties of wide area networks. The current version emulates variable delay, loss, duplication and re-ordering." 

I have used this in the lab, works OK. You can use it with the bridge util to stay layer 2.

-----Original Message-----
From: Juuso Lehtinen [mailto:juuso.lehtinen at gmail.com] 
Sent: Thursday, February 02, 2012 9:02 PM
To: Robert E. Seastrom
Cc: nanog at nanog.org
Subject: Re: This network is too good...

You have pretty much two approaches:
-Special built hardware network emulators
-Network emulator software running on generic PC

Special built HW:
If you need extreme accuracy, i.e., delay generation to micro/nanosecond
accuracy, you need to go with special purpose boxes. Special built HW also
usually provides line rate throughput, regardless of impairments you are
applying.

I have experience using Anue Systems GEM/XGEM and Calnex Paragon-X network
emulators. Both tools are special built hardware platforms that allow
generating various network impairments (delay, jitter, packet reordering,
packet loss, CRC errors, etc.).

In my opinion Anue is easier to use. It provides Web GUI where you can
configure different impairment profiles. Calnex on the other hand requires
you to install a Client software on your Windows PC. In the end, both
products support pretty much the same features. There are some differences
if you are doing specific testing with network synchronization protocols,
like SyncE or 1588v2 (PTPv2).

Network emulator SW on generic PC:
I have very little experience on running SW based network emulators. I used
to play with one that was running on Linux box - unfortunately I cannot
remember the software name. The linux software was ok for introducing
packet loss, but way inaccurate when it comes to delay insertion. If
accuracy of tens of milliseconds is good enough for you, the software based
approach might be good for you.

On Wed, Feb 1, 2012 at 5:51 PM, Robert E. Seastrom <rs at seastrom.com> wrote:

>
> Hi all,
>
> Any thoughts on products that screw up networks in deterministic (and
> realistic found-in-the-wild) ways?  I'm thinking of stuff like
> PacketStorm, Dummynet, etc.  Dial up jitter, latency, tail drop, RED,
> whatever...
>
> (I know someone's gonna say "Just buy a Brand Z FubarSwitch 3k, they
> will screw up your whole network and you don't even have to configure
> it to do so!")
>
> I'm all-ears like Ross Perot.
>
> Thanks,
>
> -r
>
>
>


From randy at psg.com  Thu Feb  2 21:24:21 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 03 Feb 2012 12:24:21 +0900
Subject: Regarding Hijacked Networks 
In-Reply-To: <0AF293C9-4329-45DA-B34B-868BC6C84440@arin.net>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <20120201015257.39A071C95D68@drugs.dv.isc.org>
 <65E48EB1-A51C-4C70-9629-CD7477D6877B@delong.com>
 <E7346720-1357-43E6-88CA-24AC5A99BAE9@corp.arin.net>
 <m2aa507hem.wl%randy@psg.com>
 <0AF293C9-4329-45DA-B34B-868BC6C84440@arin.net>
Message-ID: <m2obtg8uqi.wl%randy@psg.com>

>> my arin email addy and password work on the arin main web site.  they
>> do not work on https://rpki-pilot.arin.net/, pita
> That's correct for the pilot - follow the link at the top of the page
> which says: "If you don't have a log in and want to take part in this
> pilot, click [here].

been there, done that.  no tee shirt.  but more importantly, no trust
anchor!

randy


From dave.nanog at alfordmedia.com  Thu Feb  2 23:01:45 2012
From: dave.nanog at alfordmedia.com (Dave Pooser)
Date: Thu, 02 Feb 2012 23:01:45 -0600
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CAAAwwbVxtg3dVsNm-WSY7XJbjVjKd+hdSo-4bxB8vLQG=HpnRA@mail.gmail.com>
Message-ID: <CB50C437.863FE%dave.lists@alfordmedia.com>

On 2/1/12 8:43 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:

>Simple government regulation is of limited value, since the problem
>network
>may be overseas.

So government regulation won't work....

>What the internet really needs is  Tier1 and Tier2 providers participating
>in the internet who  "care", regardless of the popularity or size of
>netblocks or issues involved.

...and all we need is for billion-dollar corporations to start putting
moral rectitude ahead of profits.

Well, heck, that should start happening any day now! And then FedEx will
deliver my unicorn!
</snark>

IMO, as long as the consequences for address hijacking boil down to "a
bunch of nerds will be unhappy with you," of COURSE we will continue to
see more hijackings. It's profitable (for spammers and other criminals)
and there is no shortage of sociopaths in this world. If there were a
chance of coordinated shunning of those upstreams that tolerate hijacking
then the moral rectitude/profits calculus would change, but there is no
such chance. So we're left with coordinated governmental action, RPKI, or
anarchy.

A thought experiment: Imagine this happens in IPv6 space. Absent the
element of scarcity, does it become simpler to just get more IPs for your
legitimate company than to spend time fighting with the thieves and their
collection of negligent or colluding upstreams? And what does that do for
the Internet if more and more companies decide to just abandon their V6
space to the squatters rather than contesting it?
-- 
DP




From goemon at anime.net  Thu Feb  2 23:06:02 2012
From: goemon at anime.net (goemon at anime.net)
Date: Thu, 2 Feb 2012 21:06:02 -0800 (PST)
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
In-Reply-To: <20120203002840.GA80793@gweep.net>
References: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>
 <20120203002840.GA80793@gweep.net>
Message-ID: <Pine.LNX.4.64.1202022105160.32170@sasami.anime.net>

On Thu, 2 Feb 2012, Joe Provo wrote:
> The suits won, and many nerds either threw in with them or revealed
> their affinity for the easy life and gave up. Being principled and
> turning away dirty money or exercising the "fire the customer" clause
> tends to be disliked by corporate officers.

bottom line -- the only way to fix this problem is for bad behavior to 
become more expensive than good behavior. it's the only thing the pointy 
hairs will understand.

-Dan


From randy at psg.com  Thu Feb  2 23:59:35 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 03 Feb 2012 14:59:35 +0900
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
In-Reply-To: <Pine.LNX.4.64.1202022105160.32170@sasami.anime.net>
References: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>
 <20120203002840.GA80793@gweep.net>
 <Pine.LNX.4.64.1202022105160.32170@sasami.anime.net>
Message-ID: <m2ipjo8njs.wl%randy@psg.com>

>> The suits won, and many nerds either threw in with them or revealed
>> their affinity for the easy life and gave up. Being principled and
>> turning away dirty money or exercising the "fire the customer" clause
>> tends to be disliked by corporate officers.
> bottom line -- the only way to fix this problem is for bad behavior to
> become more expensive than good behavior. it's the only thing the
> pointy hairs will understand.

i just love to read geeks discussing legal and financial solutions.
just about as educational as watching lawyers and cfos discussing
engineering.

seeing as we are purportedly engineers, perhaps we could discuss a
technical engineering approach to prefix misorigination?

randy


From joelja at bogus.com  Fri Feb  3 00:51:28 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Thu, 02 Feb 2012 22:51:28 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
In-Reply-To: <m2ipjo8njs.wl%randy@psg.com>
References: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>
 <20120203002840.GA80793@gweep.net>
 <Pine.LNX.4.64.1202022105160.32170@sasami.anime.net>
 <m2ipjo8njs.wl%randy@psg.com>
Message-ID: <4F2B83F0.2080600@bogus.com>

On 2/2/12 21:59 , Randy Bush wrote:
>>> The suits won, and many nerds either threw in with them or revealed
>>> their affinity for the easy life and gave up. Being principled and
>>> turning away dirty money or exercising the "fire the customer" clause
>>> tends to be disliked by corporate officers.
>> bottom line -- the only way to fix this problem is for bad behavior to
>> become more expensive than good behavior. it's the only thing the
>> pointy hairs will understand.
> 
> i just love to read geeks discussing legal and financial solutions.
> just about as educational as watching lawyers and cfos discussing
> engineering.
> 
> seeing as we are purportedly engineers, perhaps we could discuss a
> technical engineering approach to prefix misorigination?

I hear there's this thing called RPKI that does origin validation, it's
a shame that TCP MD5 shared secrets are already considered to hard to
manage in this community.

> randy
> 



From randy at psg.com  Fri Feb  3 01:02:03 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 03 Feb 2012 16:02:03 +0900
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
In-Reply-To: <4F2B83F0.2080600@bogus.com>
References: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>
 <20120203002840.GA80793@gweep.net>
 <Pine.LNX.4.64.1202022105160.32170@sasami.anime.net>
 <m2ipjo8njs.wl%randy@psg.com> <4F2B83F0.2080600@bogus.com>
Message-ID: <m2bopg8kno.wl%randy@psg.com>

> I hear there's this thing called RPKI that does origin validation

<pedantic>

well, not exactly.  to quote myself from the other week in another forum

--

Just to be clear, as people keep calling BGP security 'RPKI'

In the current taxonomy, there are three pieces, the RPKI, RPKI-based
origin validation, and then path validation.

RPKI is the X.509 based hierarchy with is congruent with the internet IP
address allocation administration, the IANA, RIRS, ISPs, ...  It is the
substrate on which the next two are based.  It is currently deployed in
four of the five administrative regions, ARIN in North America being the
sad and embarrassing exception.

RPKI-based origin validation uses some of the RPKI data to allow a
router to verify that the autonomous system announcing an IP address
prefix is in fact authorized to do so.  This is not crypto checked so
can be violated.  But it prevents the vast majority of accidental
'hijackings' on the internet today, e.g. the famous Pakastani accidental
announcement of YouTube's address space.  RPKI-based origin validation
is in shipping code from Cisco, and will be shipping by Juniper in q2.

Path validation uses the full crypto information of the RPKI to make up
for the embarrassing mistake that, like much of the internet BGP was
designed with no thought to securing the BGP protocol itself from being
gamed/violated.  It allows a receiver of a BGP announcement to formally
cryptographically validate that the originating autonomous system was
truely authorized to announce the IP address prefix, and that the
systems through which the announcement passed were indeed those which
the sender/forwarder at each hop intended.

Sorry to drone on, but these three really need to be differentiated.

randy


From aservin at lacnic.net  Fri Feb  3 06:16:01 2012
From: aservin at lacnic.net (Arturo Servin)
Date: Fri, 3 Feb 2012 10:16:01 -0200
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
References: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
Message-ID: <2288A74A-F1FE-4E87-A12F-30866EF6EAB3@lacnic.net>


	One option is to use RPKI and origin validation. But it won't help much unless prefix holders create their certificates and ROAs and networks operators use those to validate origins. It won't solve all the issues but at least some fat fingers/un-expierience errors.

	We are running an experiment to detect route-hijacks/missconf using RPKI. So far, not many routes are "signed" but at least we can periodically check our own prefix (or any other with ROAs) to detect some inconsistencies:

http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/pfx/200.7.84.0/

http://www.labs.lacnic.net/rpkitools/looking_glass/


Regards,
-as
	

On 1 Feb 2012, at 06:58, Kelvin Williams wrote:

> First off, I'd like to thank everyone on this list who have reached out
> today and offered us help with our hijacked network space.  It's so
> refreshing to see that there are still so many who refuse to leave a
> man/woman down.
> 
> I'm not going to place any blame, its useless.  There were lies, there were
> incompetencies, and there was negligence but that is now water under the
> bridge.
> 
> However, I think that we as network operators have a duty to each other to
> make sure we don't allow a downstream customer wreck the operations of
> another entity who has been rightfully allocated resources.
> 
> A few months ago, when establishing a new peering relationship I was
> encouraged (actually required) to utilize one of the IRRs.  I took the time
> to register all of my routes, ASNs, etc.  However, as I learned today, this
> was probably done in vain.  Too many people won't spend the extra
> 30-seconds to verify the information listed there or in ARINs WHOIS.
> 
> I don't care what a customer tells me, too many times I've found they
> aren't 100% honest either for malicious/fraudulent reasons or they are
> unknowing.  So, for our networks or the networks we manage, we want to
> verify what a customer is saying to prevent what happened to us today.
> 
> I'd like to get a conversation going and possibly some support of an
> initiative to spend that extra 30-seconds to verify ownership and
> authorization of network space to be advertised.  Additionally, if someone
> rings your NOC's line an industry-standard process of verifying "ownership"
> and immediately responding by filtering out announcements. There's no sense
> in allowing a service provider to be impaired because a spammer doesn't
> want to give up clean IP space.  Do you protect a bad customer or the
> Internet as a whole?  I pick the Internet as a whole.
> 
> How can we prevent anyone else from ever enduring this again?  While we may
> never stop it from ever happening, spammers (that's what we got hit by
> today) are a dime a dozen and will do everything possible to hit an Inbox,
> so how can we establish a protocol to immediate mitigate the effects of an
> traffic-stopping advertisement?
> 
> I thought registering with IRRs and up-to-date information in ARINs WHOIS
> was sufficient, apparently I was wrong.  Not everyone respects them, but
> then again, they aren't very well managed (I've got several networks with
> antiquated information I've been unable to remove, it doesn't impair us
> normally, but its still there).
> 
> What can we do?  Better yet, how do we as a whole respond when we encounter
> upstream providers who refuse to look at the facts and allow another to
> stay down?
> 
> kw
> 
> -- 
> Kelvin Williams
> Sr. Service Delivery Engineer
> Broadband & Carrier Services
> Altus Communications Group, Inc.
> 
> 
> "If you only have a hammer, you tend to see every problem as a nail." --
> Abraham Maslow


From rs at seastrom.com  Fri Feb  3 06:59:30 2012
From: rs at seastrom.com (Robert E. Seastrom)
Date: Fri, 03 Feb 2012 07:59:30 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
In-Reply-To: <m2bopg8kno.wl%randy@psg.com> (Randy Bush's message of "Fri,
 03 Feb 2012 16:02:03 +0900")
References: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>
 <20120203002840.GA80793@gweep.net>
 <Pine.LNX.4.64.1202022105160.32170@sasami.anime.net>
 <m2ipjo8njs.wl%randy@psg.com> <4F2B83F0.2080600@bogus.com>
 <m2bopg8kno.wl%randy@psg.com>
Message-ID: <86mx90xebx.fsf@seastrom.com>


Randy Bush <randy at psg.com> writes:

> well, not exactly.  to quote myself from the other week in another forum
>
> [ 30 lines deleted ]
>
> Sorry to drone on, but these three really need to be differentiated.

The truly wonderful thing about the evolution of BGP security is its
elegant simplicity.  It is good to know that the barriers to entry for
the IRR system (templates, objects, "Dear Colleague" emails from the
auto-dbm robot, etc) have been eradicated in favor of simple,
easy-to-understand and maintain maintain digital certificate chains.
I predict epic uptake the likes of which we haven't seen since I filed
my last NACR.

-r



From richard.barnes at gmail.com  Fri Feb  3 07:09:43 2012
From: richard.barnes at gmail.com (Richard Barnes)
Date: Fri, 3 Feb 2012 08:09:43 -0500
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <2288A74A-F1FE-4E87-A12F-30866EF6EAB3@lacnic.net>
References: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
 <2288A74A-F1FE-4E87-A12F-30866EF6EAB3@lacnic.net>
Message-ID: <CACB24MvY0qDkq47iCrwm4HXSHqw_MTtmMNN8xu5aEZGPsJNAOg@mail.gmail.com>

In related news, the IETF working group that is writing standards for
the RPKI is having an interim meeting in San Diego just after NANOG.
They deliberately chose that place/time to make it easy for NANOG
attendees to contribute, so comments from this community are
definitely welcome.
<http://www.ietf.org/mail-archive/web/sidr/current/msg03923.html>
<http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209>



On Fri, Feb 3, 2012 at 7:16 AM, Arturo Servin <aservin at lacnic.net> wrote:
>
> ? ? ? ?One option is to use RPKI and origin validation. But it won't help much unless prefix holders create their certificates and ROAs and networks operators use those to validate origins. It won't solve all the issues but at least some fat fingers/un-expierience errors.
>
> ? ? ? ?We are running an experiment to detect route-hijacks/missconf using RPKI. So far, not many routes are "signed" but at least we can periodically check our own prefix (or any other with ROAs) to detect some inconsistencies:
>
> http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/pfx/200.7.84.0/
>
> http://www.labs.lacnic.net/rpkitools/looking_glass/
>
>
> Regards,
> -as
>
>
> On 1 Feb 2012, at 06:58, Kelvin Williams wrote:
>
>> First off, I'd like to thank everyone on this list who have reached out
>> today and offered us help with our hijacked network space. ?It's so
>> refreshing to see that there are still so many who refuse to leave a
>> man/woman down.
>>
>> I'm not going to place any blame, its useless. ?There were lies, there were
>> incompetencies, and there was negligence but that is now water under the
>> bridge.
>>
>> However, I think that we as network operators have a duty to each other to
>> make sure we don't allow a downstream customer wreck the operations of
>> another entity who has been rightfully allocated resources.
>>
>> A few months ago, when establishing a new peering relationship I was
>> encouraged (actually required) to utilize one of the IRRs. ?I took the time
>> to register all of my routes, ASNs, etc. ?However, as I learned today, this
>> was probably done in vain. ?Too many people won't spend the extra
>> 30-seconds to verify the information listed there or in ARINs WHOIS.
>>
>> I don't care what a customer tells me, too many times I've found they
>> aren't 100% honest either for malicious/fraudulent reasons or they are
>> unknowing. ?So, for our networks or the networks we manage, we want to
>> verify what a customer is saying to prevent what happened to us today.
>>
>> I'd like to get a conversation going and possibly some support of an
>> initiative to spend that extra 30-seconds to verify ownership and
>> authorization of network space to be advertised. ?Additionally, if someone
>> rings your NOC's line an industry-standard process of verifying "ownership"
>> and immediately responding by filtering out announcements. There's no sense
>> in allowing a service provider to be impaired because a spammer doesn't
>> want to give up clean IP space. ?Do you protect a bad customer or the
>> Internet as a whole? ?I pick the Internet as a whole.
>>
>> How can we prevent anyone else from ever enduring this again? ?While we may
>> never stop it from ever happening, spammers (that's what we got hit by
>> today) are a dime a dozen and will do everything possible to hit an Inbox,
>> so how can we establish a protocol to immediate mitigate the effects of an
>> traffic-stopping advertisement?
>>
>> I thought registering with IRRs and up-to-date information in ARINs WHOIS
>> was sufficient, apparently I was wrong. ?Not everyone respects them, but
>> then again, they aren't very well managed (I've got several networks with
>> antiquated information I've been unable to remove, it doesn't impair us
>> normally, but its still there).
>>
>> What can we do? ?Better yet, how do we as a whole respond when we encounter
>> upstream providers who refuse to look at the facts and allow another to
>> stay down?
>>
>> kw
>>
>> --
>> Kelvin Williams
>> Sr. Service Delivery Engineer
>> Broadband & Carrier Services
>> Altus Communications Group, Inc.
>>
>>
>> "If you only have a hammer, you tend to see every problem as a nail." --
>> Abraham Maslow
>


From streiner at cluebyfour.org  Fri Feb  3 08:25:29 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 3 Feb 2012 09:25:29 -0500 (EST)
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CB50C437.863FE%dave.lists@alfordmedia.com>
References: <CB50C437.863FE%dave.lists@alfordmedia.com>
Message-ID: <Pine.LNX.4.64.1202030923480.5976@whammy.cluebyfour.org>

On Thu, 2 Feb 2012, Dave Pooser wrote:

> ...and all we need is for billion-dollar corporations to start putting
> moral rectitude ahead of profits.
>
> Well, heck, that should start happening any day now! And then FedEx will
> deliver my unicorn!
> </snark>

Your unicorn has been impounded by Customs.

jms


From jra at baylink.com  Fri Feb  3 09:31:05 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 3 Feb 2012 10:31:05 -0500 (EST)
Subject: Verisign deep-hacked. For months.
In-Reply-To: <CAPWAtb+Eyjm6uszO38LAArY46mh_T7F-nrmtaLggN=j3d29SUw@mail.gmail.com>
Message-ID: <29407925.356.1328283065834.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jeff Wheeler" <jsw at inconcepts.biz>

> On Thu, Feb 2, 2012 at 7:26 PM, Suresh Ramasubramanian
> <ops.lists at gmail.com> wrote:
> > So what part of VRSN got broken into? They do a lot more than just
> > DNS.
> 
> Indeed, VeriSign owns Illuminet, who are mission-critical for POTS.
> Illuminet is also in the business of recording telephone calls, SMS
> messages, etc. for law enforcement.

"Illuminet"?

Shea and Wilson would be proud.

Cheers,
-- jr 'and somewhere, an evil geek is dry-washing his hands' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From bmanning at vacation.karoshi.com  Fri Feb  3 10:09:39 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 3 Feb 2012 16:09:39 +0000
Subject: [POLITICS] ICANN elections
Message-ID: <20120203160939.GA5520@vacation.karoshi.com.>


There are four really good candidates.  Please consider sending in a statement of
support for one of them.

/bill

----- Forwarded message -----

Date: Fri, 03 Feb 2012 09:38:06 +1000
To: Bill Manning <bmanning at karoshi.com>
Subject: Comment Period for ICANN Board Seat 9 Election

Consistent with the ASO Memorandum of Understanding and ICANN Bylaws,
the Address Supporting Organization Address Council (ASO AC) is
responsible for the appointment of a representative to serve on Seat
Number 9 of the ICANN Board.

The ASO AC is pleased to announce the following four candidates for its
upcoming appointment.

The Candidates are:

    - Thomas Eric Brunner-Williams
    - Martin J. Levy
    - William Manning
    - Raymond Alan Plzak

In accordance with the ASO AC election procedures, a comment period is
now open. A short biography is available and supporting comment
facilities for each candidate may be found at:

http://aso.icann.org/people/icann-board-elections/2012-elections/

The comment period will close at 23:59 UTC on 19 April 2012. Comments
will be moderated.

ASO Secretariat
secretariat at aso.icann.org

----- End forwarded message -----


From rubensk at gmail.com  Fri Feb  3 10:40:13 2012
From: rubensk at gmail.com (Rubens Kuhl)
Date: Fri, 3 Feb 2012 14:40:13 -0200
Subject: Verisign deep-hacked. For months.
In-Reply-To: <CAPWAtb+Eyjm6uszO38LAArY46mh_T7F-nrmtaLggN=j3d29SUw@mail.gmail.com>
References: <20670730.288.1328222336994.JavaMail.root@benjamin.baylink.com>
 <CB505A31.346A9%zaid@zaidali.com>
 <CAArzuou_GeCOQwsXHza_iykuKH-S44hQWutzVeSh9JSJ2AoKFw@mail.gmail.com>
 <CAPWAtb+Eyjm6uszO38LAArY46mh_T7F-nrmtaLggN=j3d29SUw@mail.gmail.com>
Message-ID: <CAGFn2k0FyweJS_8TMzY22s2O0xzFaW6jeOVKth=7OVFVSq7=WQ@mail.gmail.com>

On Thu, Feb 2, 2012 at 10:34 PM, Jeff Wheeler <jsw at inconcepts.biz> wrote:
> On Thu, Feb 2, 2012 at 7:26 PM, Suresh Ramasubramanian
> <ops.lists at gmail.com> wrote:
>> So what part of VRSN got broken into? ?They do a lot more than just DNS.
>
> Indeed, VeriSign owns Illuminet, who are mission-critical for POTS.
> Illuminet is also in the business of recording telephone calls, SMS
> messages, etc. for law enforcement.

Wasn't this division acquired by TNS ?
http://www.bizjournals.com/washington/stories/2009/05/04/daily5.html


Rubens


From Sandra.Murphy at sparta.com  Fri Feb  3 10:43:29 2012
From: Sandra.Murphy at sparta.com (Murphy, Sandra)
Date: Fri, 3 Feb 2012 16:43:29 +0000
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <CACB24MvY0qDkq47iCrwm4HXSHqw_MTtmMNN8xu5aEZGPsJNAOg@mail.gmail.com>
References: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
 <2288A74A-F1FE-4E87-A12F-30866EF6EAB3@lacnic.net>,
 <CACB24MvY0qDkq47iCrwm4HXSHqw_MTtmMNN8xu5aEZGPsJNAOg@mail.gmail.com>
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60852BF@Hermes.columbia.ads.sparta.com>

Thanks for the reminder, Richard.

Yes, as I announced earlier (see
http://mailman.nanog.org/pipermail/nanog/2012-January/044493.html
- the message with the corrected date), there is an interim sidr meeting on 
Thu *9* Feb in San Diego.

Registration is free.  
Registration is easy (email).  
Registration is open to all.
Registration is open ended.
Registration is encouraged (so we know how many to expect).  

As the message says, see the sidr wiki http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209 for agenda and a list of attendees.

--Sandy Murphy

________________________________________
From: Richard Barnes [richard.barnes at gmail.com]
Sent: Friday, February 03, 2012 8:09 AM
To: Arturo Servin
Cc: nanog
Subject: Re: Thanks & Let's Prevent this in the Future.

In related news, the IETF working group that is writing standards for
the RPKI is having an interim meeting in San Diego just after NANOG.
They deliberately chose that place/time to make it easy for NANOG
attendees to contribute, so comments from this community are
definitely welcome.
<http://www.ietf.org/mail-archive/web/sidr/current/msg03923.html>
<http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209>


<snip>

From brunner at nic-naa.net  Fri Feb  3 11:09:23 2012
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Fri, 03 Feb 2012 12:09:23 -0500
Subject: [POLITICS] ICANN elections
In-Reply-To: <20120203160939.GA5520@vacation.karoshi.com.>
References: <20120203160939.GA5520@vacation.karoshi.com.>
Message-ID: <4F2C14C3.6060800@nic-naa.net>

What Bill said.

Comments to the website
(http://aso.icann.org/people/icann-board-elections/2012-elections/)
are moderated, so any statements of support won't show up (except to
the person who makes the statement) until the moderator has gotten a
round tuit.

The [s]electorate to be persuaded is here:
http://aso.icann.org/people/address-council/address-council-members/

Cheers,
Eric

> There are four really good candidates.  Please consider sending in a statement of
> support for one of them.
> 
> /bill
> 
> ----- Forwarded message -----
> 
> Date: Fri, 03 Feb 2012 09:38:06 +1000
> To: Bill Manning <bmanning at karoshi.com>
> Subject: Comment Period for ICANN Board Seat 9 Election
> 
> Consistent with the ASO Memorandum of Understanding and ICANN Bylaws,
> the Address Supporting Organization Address Council (ASO AC) is
> responsible for the appointment of a representative to serve on Seat
> Number 9 of the ICANN Board.
> 
> The ASO AC is pleased to announce the following four candidates for its
> upcoming appointment.
> 
> The Candidates are:
> 
>     - Thomas Eric Brunner-Williams
>     - Martin J. Levy
>     - William Manning
>     - Raymond Alan Plzak
> 
> In accordance with the ASO AC election procedures, a comment period is
> now open. A short biography is available and supporting comment
> facilities for each candidate may be found at:
> 
> http://aso.icann.org/people/icann-board-elections/2012-elections/
> 
> The comment period will close at 23:59 UTC on 19 April 2012. Comments
> will be moderated.
> 
> ASO Secretariat
> secretariat at aso.icann.org
> 
> ----- End forwarded message -----
> 
> 
> 


From hvgeekwtrvl at gmail.com  Fri Feb  3 12:55:17 2012
From: hvgeekwtrvl at gmail.com (james machado)
Date: Fri, 3 Feb 2012 10:55:17 -0800
Subject: [rt-users] External Auth using Active Directory 2008
In-Reply-To: <84E70F84D007E14BBD13A402719AF27C1583726E@SN2PRD0102MB153.prod.exchangelabs.com>
References: <84E70F84D007E14BBD13A402719AF27C15832CC1@SN2PRD0102MB153.prod.exchangelabs.com>
 <20120201233243.GF5178@jibsheet.com>
 <84E70F84D007E14BBD13A402719AF27C15833CF1@SN2PRD0102MB153.prod.exchangelabs.com>
 <20120202171716.GL5178@jibsheet.com>
 <84E70F84D007E14BBD13A402719AF27C1583405E@SN2PRD0102MB153.prod.exchangelabs.com>
 <20120203173218.GN5178@jibsheet.com>
 <84E70F84D007E14BBD13A402719AF27C1583726E@SN2PRD0102MB153.prod.exchangelabs.com>
Message-ID: <CADVasu5kFwjv_joBkN3Y+dHDNF9v5AfsbNQHZUemuGQw1voHEw@mail.gmail.com>

I would use ldapsearch on that machine to make sure you can bind to
the AD server using the login credentials in your Site_Config.  Make
sure you are using the proper certificates to connect via the TLS you
have configured.  I've noticed that being one of the biggest problems
with ldap and Windows 2008 and 2008 R2 AD servers.

james


From hvgeekwtrvl at gmail.com  Fri Feb  3 12:56:44 2012
From: hvgeekwtrvl at gmail.com (james machado)
Date: Fri, 3 Feb 2012 10:56:44 -0800
Subject: [rt-users] External Auth using Active Directory 2008
In-Reply-To: <CADVasu5kFwjv_joBkN3Y+dHDNF9v5AfsbNQHZUemuGQw1voHEw@mail.gmail.com>
References: <84E70F84D007E14BBD13A402719AF27C15832CC1@SN2PRD0102MB153.prod.exchangelabs.com>
 <20120201233243.GF5178@jibsheet.com>
 <84E70F84D007E14BBD13A402719AF27C15833CF1@SN2PRD0102MB153.prod.exchangelabs.com>
 <20120202171716.GL5178@jibsheet.com>
 <84E70F84D007E14BBD13A402719AF27C1583405E@SN2PRD0102MB153.prod.exchangelabs.com>
 <20120203173218.GN5178@jibsheet.com>
 <84E70F84D007E14BBD13A402719AF27C1583726E@SN2PRD0102MB153.prod.exchangelabs.com>
 <CADVasu5kFwjv_joBkN3Y+dHDNF9v5AfsbNQHZUemuGQw1voHEw@mail.gmail.com>
Message-ID: <CADVasu7+OQJTnML_ggVkAFfh_5J3hF4F075pHdd0No73-ixQqQ@mail.gmail.com>

my apologies - fat fingered the email address

 james


From cscora at apnic.net  Fri Feb  3 12:59:49 2012
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 4 Feb 2012 04:59:49 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201202031859.q13IxniU018235@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 04 Feb, 2012

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              395820
    Prefixes after maximum aggregation:                          169388
    Deaggregation factor:                                          2.34
    Unique aggregates announced to Internet:                     191947
Total ASes present in the Internet Routing Table:                 40003
    Prefixes per ASN:                                              9.89
Origin-only ASes present in the Internet Routing Table:           32689
Origin ASes announcing only one prefix:                           15521
Transit ASes present in the Internet Routing Table:                5393
Transit-only ASes present in the Internet Routing Table:            142
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      33
    Max AS path prepend of ASN (48687)                               24
Prefixes from unregistered ASNs in the Routing Table:               315
    Unregistered ASNs in the Routing Table:                         120
Number of 32-bit ASNs allocated by the RIRs:                       2257
Number of 32-bit ASNs visible in the Routing Table:                1921
Prefixes from 32-bit ASNs in the Routing Table:                    4672
Special use prefixes present in the Routing Table:                    2
Prefixes being announced from unallocated address space:            120
Number of addresses announced to Internet:                   2512081104
    Equivalent to 149 /8s, 187 /16s and 80 /24s
    Percentage of available address space announced:               67.8
    Percentage of allocated address space announced:               67.8
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               92.0
Total number of prefixes smaller than registry allocations:      167934

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                    97613
    Total APNIC prefixes after maximum aggregation:               31507
    APNIC Deaggregation factor:                                    3.10
Prefixes being announced from the APNIC address blocks:           93918
    Unique aggregates announced from the APNIC address blocks:    39044
APNIC Region origin ASes present in the Internet Routing Table:    4648
    APNIC Prefixes per ASN:                                       20.21
APNIC Region origin ASes announcing only one prefix:               1238
APNIC Region transit ASes present in the Internet Routing Table:    731
Average APNIC Region AS path length visible:                        4.3
    Max APNIC Region AS path length visible:                         18
Number of APNIC region 32-bit ASNs visible in the Routing Table:    140
Number of APNIC addresses announced to Internet:              635833440
    Equivalent to 37 /8s, 230 /16s and 12 /24s
    Percentage of available APNIC address space announced:         80.6

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8,
                       182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
                       219/8, 220/8, 221/8, 222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    148115
    Total ARIN prefixes after maximum aggregation:                75385
    ARIN Deaggregation factor:                                     1.96
Prefixes being announced from the ARIN address blocks:           120087
    Unique aggregates announced from the ARIN address blocks:     49290
ARIN Region origin ASes present in the Internet Routing Table:    14884
    ARIN Prefixes per ASN:                                         8.07
ARIN Region origin ASes announcing only one prefix:                5683
ARIN Region transit ASes present in the Internet Routing Table:    1577
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          22
Number of ARIN region 32-bit ASNs visible in the Routing Table:      15
Number of ARIN addresses announced to Internet:               804133824
    Equivalent to 47 /8s, 238 /16s and 27 /24s
    Percentage of available ARIN address space announced:          63.9

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 173/8,
                       174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8,
                       208/8, 209/8, 214/8, 215/8, 216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                     98052
    Total RIPE prefixes after maximum aggregation:                52278
    RIPE Deaggregation factor:                                     1.88
Prefixes being announced from the RIPE address blocks:            89929
    Unique aggregates announced from the RIPE address blocks:     55955
RIPE Region origin ASes present in the Internet Routing Table:    16285
    RIPE Prefixes per ASN:                                         5.52
RIPE Region origin ASes announcing only one prefix:                7995
RIPE Region transit ASes present in the Internet Routing Table:    2598
Average RIPE Region AS path length visible:                         4.7
    Max RIPE Region AS path length visible:                          33
Number of RIPE region 32-bit ASNs visible in the Routing Table:    1322
Number of RIPE addresses announced to Internet:               498585736
    Equivalent to 29 /8s, 183 /16s and 208 /24s
    Percentage of available RIPE address space announced:          80.3

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   38255
    Total LACNIC prefixes after maximum aggregation:               8059
    LACNIC Deaggregation factor:                                   4.75
Prefixes being announced from the LACNIC address blocks:          37876
    Unique aggregates announced from the LACNIC address blocks:   19445
LACNIC Region origin ASes present in the Internet Routing Table:   1569
    LACNIC Prefixes per ASN:                                      24.14
LACNIC Region origin ASes announcing only one prefix:               442
LACNIC Region transit ASes present in the Internet Routing Table:   294
Average LACNIC Region AS path length visible:                       4.3
    Max LACNIC Region AS path length visible:                        24
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   440
Number of LACNIC addresses announced to Internet:              95986568
    Equivalent to 5 /8s, 184 /16s and 163 /24s
    Percentage of available LACNIC address space announced:        63.6

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   8951
    Total AfriNIC prefixes after maximum aggregation:              2087
    AfriNIC Deaggregation factor:                                  4.29
Prefixes being announced from the AfriNIC address blocks:          6957
    Unique aggregates announced from the AfriNIC address blocks:   2150
AfriNIC Region origin ASes present in the Internet Routing Table:   512
    AfriNIC Prefixes per ASN:                                     13.59
AfriNIC Region origin ASes announcing only one prefix:              163
AfriNIC Region transit ASes present in the Internet Routing Table:  115
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    4
Number of AfriNIC addresses announced to Internet:             30867968
    Equivalent to 1 /8s, 215 /16s and 2 /24s
    Percentage of available AfriNIC address space announced:       46.0

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2474      11102         982   Korea Telecom (KIX)
17974     1723        503          36   PT TELEKOMUNIKASI INDONESIA
 7545     1642        303          85   TPG Internet Pty Ltd
 4755     1529        385         155   TATA Communications formerly 
 7552     1408       1064           7   Vietel Corporation
 9829     1167        989          28   BSNL National Internet Backbo
 9583     1123         82         483   Sify Limited
 4808     1102       2051         313   CNCGROUP IP network: China169
24560     1014        385         167   Bharti Airtel Ltd., Telemedia
17488      934        161         224   Hathway IP Over Cable Interne

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3445       3807         201   bellsouth.net, inc. 
 7029     3211       1017         199   Windstream Communications Inc
18566     2093        382         177   Covad Communications 
 1785     1865        680         125   PaeTec Communications, Inc.
20115     1627       1552         627   Charter Communications 
 4323     1609       1062         384   Time Warner Telecom
22773     1498       2910         109   Cox Communications, Inc.
30036     1437        253         743   Mediacom Communications Corp 
19262     1386       4683         400   Verizon Global Networks 
 7018     1305       7007         851   AT&T WorldNet Services

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8402     1712        480          15   Corbina telecom
 2118     1391         99          14   EUnet/RELCOM Autonomous Syste
15557     1096       2161          64   LDCOM NETWORKS
34984      643        188         172   BILISIM TELEKOM
 6830      642       1927         412   UPC Distribution Services
20940      602        195         467   Akamai Technologies European 
12479      561        642          54   Uni2 Autonomous System
31148      532         37           9   FreeNet ISP
 3320      531       8162         397   Deutsche Telekom AG
 8551      530        360          81   Bezeq International

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1735        323         170   TVCABLE BOGOTA 
28573     1618       1083          72   NET Servicos de Comunicao S.A
 8151     1336       2995         344   UniNet S.A. de C.V. 
 7303     1260        757         180   Telecom Argentina Stet-France
26615      887        640          33   Tim Brasil S.A.
11172      697         95          75   Servicios Alestra S.A de C.V 
27947      650         73          99   Telconet S.A
22047      581        322          17   VTR PUNTO NET S.A. 
 3816      550        237          91   Empresa Nacional de Telecomun
 7738      550       1050          31   Telecomunicacoes da Bahia S.A

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8452     1131        958          13   TEDATA
24863      834        155          43   LINKdotNET AS number
 6713      485        649          18   Itissalat Al-MAGHRIB
 3741      280        939         229   The Internet Solution 
15706      238         32           6   Sudatel Internet Exchange Aut
33776      237         13          13   Starcomms Nigeria Limited
29571      214         17          12   Ci Telecom Autonomous system 
12258      197         28          62   Vodacom Internet Company 
24835      193         80           8   RAYA Telecom - Egypt
16637      163        664          82   MTN Network Solutions

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3445       3807         201   bellsouth.net, inc. 
 7029     3211       1017         199   Windstream Communications Inc
 4766     2474      11102         982   Korea Telecom (KIX)
18566     2093        382         177   Covad Communications 
 1785     1865        680         125   PaeTec Communications, Inc.
10620     1735        323         170   TVCABLE BOGOTA 
17974     1723        503          36   PT TELEKOMUNIKASI INDONESIA
 8402     1712        480          15   Corbina telecom
 7545     1642        303          85   TPG Internet Pty Ltd
20115     1627       1552         627   Charter Communications 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
 7029      3211        3012      Windstream Communications Inc
18566      2093        1916      Covad Communications 
 1785      1865        1740      PaeTec Communications, Inc.
 8402      1712        1697      Corbina telecom
17974      1723        1687      PT TELEKOMUNIKASI INDONESIA
10620      1735        1565      TVCABLE BOGOTA 
 7545      1642        1557      TPG Internet Pty Ltd
28573      1618        1546      NET Servicos de Comunicao S.A
 4766      2474        1492      Korea Telecom (KIX)
 7552      1408        1401      Vietel Corporation

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.103.0/24        7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
32873   UNALLOCATED  12.46.100.0/23       10912       InterNAP Network Ser

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
128.0.0.0/21         12654     RIPE NCC RIS Project
128.0.24.0/24        12654     RIPE NCC RIS Project

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
14.192.0.0/22        45464     Room 201, TGU Bldg
14.192.4.0/22        45464     Room 201, TGU Bldg
14.192.8.0/22        45464     Room 201, TGU Bldg
14.192.12.0/22       45464     Room 201, TGU Bldg
14.192.16.0/22       45464     Room 201, TGU Bldg
14.192.20.0/22       45464     Room 201, TGU Bldg
14.192.24.0/22       45464     Room 201, TGU Bldg
14.192.28.0/22       45464     Room 201, TGU Bldg
37.77.128.0/21        8492     Siris
37.77.152.0/21       44176     RIPE Network Coordination Cen

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:19       /9:12      /10:27      /11:80      /12:231     
/13:458     /14:817     /15:1466    /16:12151   /17:6170    /18:10294   
/19:20359   /20:28181   /21:29140   /22:39550   /23:36869   /24:206457  
/25:1189    /26:1430    /27:786     /28:43      /29:59      /30:14      
/31:0       /32:18      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 7029     2841          3211      Windstream Communications Inc
 6389     2115          3445      bellsouth.net, inc. 
18566     2042          2093      Covad Communications 
 8402     1691          1712      Corbina telecom
10620     1629          1735      TVCABLE BOGOTA 
30036     1396          1437      Mediacom Communications Corp 
11492     1117          1154      Cable One 
 1785     1063          1865      PaeTec Communications, Inc.
15557     1046          1096      LDCOM NETWORKS
 7011     1033          1149      Citizens Utilities 

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:499       2:475       4:14        5:1         6:3         8:378    
  12:1954     13:1        14:595      15:11       16:3        17:6      
  20:9        23:125      24:1725     27:1187     31:852      32:65     
  33:2        34:2        36:9        37:161      38:791      40:114    
  41:3108     42:92       43:1        44:3        46:1279     47:3      
  49:322      50:514      52:13       54:2        55:8        56:3      
  57:38       58:958      59:491      60:344      61:1186     62:927    
  63:2000     64:4147     65:2287     66:4421     67:2048     68:1167   
  69:3149     70:916      71:410      72:1794     74:2646     75:452    
  76:323      77:963      78:913      79:498      80:1221     81:877    
  82:562      83:538      84:582      85:1163     86:746      87:910    
  88:341      89:1539     90:253      91:4473     92:540      93:1555   
  94:1338     95:1134     96:417      97:310      98:811      99:38     
 100:20      101:138     103:737     106:4       107:143     108:142    
 109:1467    110:687     111:837     112:429     113:525     114:596    
 115:757     116:860     117:722     118:906     119:1249    120:356    
 121:682     122:1627    123:1064    124:1338    125:1360    128:538    
 129:189     130:213     131:590     132:164     133:21      134:231    
 135:59      136:214     137:152     138:285     139:140     140:489    
 141:261     142:378     143:400     144:509     145:70      146:484    
 147:227     148:724     149:274     150:168     151:194     152:446    
 153:170     154:7       155:398     156:211     157:367     158:156    
 159:513     160:329     161:243     162:341     163:188     164:532    
 165:397     166:556     167:455     168:765     169:147     170:833    
 171:110     172:4       173:1757    174:591     175:414     176:468    
 177:470     178:1246    180:1176    181:64      182:703     183:274    
 184:430     185:1       186:2028    187:853     188:1030    189:1168   
 190:5444    192:5979    193:5525    194:4330    195:3390    196:1299   
 197:180     198:3615    199:4359    200:5710    201:1728    202:8404   
 203:8598    204:4343    205:2443    206:2747    207:2817    208:4064   
 209:3558    210:2724    211:1475    212:1976    213:1841    214:855    
 215:93      216:4984    217:1472    218:553     219:341     220:1243   
 221:555     222:321     223:274    

End of report


From jg at freedesktop.org  Fri Feb  3 13:29:00 2012
From: jg at freedesktop.org (Jim Gettys)
Date: Fri, 03 Feb 2012 14:29:00 -0500
Subject: bufferbloat videos are up.
Message-ID: <4F2C357C.9070407@freedesktop.org>

If people have heard of bufferbloat at all, it is usually just an
abstraction despite having had personal experience with it. Bufferbloat
can occur in your operating system, your home router, your broadband
gear, wireless, and almost anywhere in the Internet. Most still think
that if experience poor Internet speed means they must need more
bandwidth, and take vast speed variation for granted. Sometimes, adding
bandwidth can actually hurt rather than help. Most people have no idea
what they can do about bufferbloat.

So I?ve been working to put together several demos to help make
bufferbloat concrete, and demonstrate at least partial mitigation. The
mitigation shown may or may not work in your home router, and you need
to be able to set both upload and download bandwidth. People like Fred
Baker, with fiber to his house and Cisco routers, need not pay attention....

Two of four cases we commonly all suffer from at home are:

 1. Broadband bufferbloat (upstream)
 2. Home router bufferbloat (downstream)

Rather than attempt to show worst case bufferbloat which can easily
induce complete failure, I decided to demonstrate these two cases of
?typical? bufferbloat as shown by the ICSI data. As the bufferbloat
varies widely as theICSI data
<http://gettys.files.wordpress.com/2010/12/uplink_buffer_all.png>shows
<http://gettys.files.wordpress.com/2010/12/downlink_buffer_all.png>,
your mileage will also vary widely.
There are two versions of the video:

 1. A short bufferbloat video
    <http://www.youtube.com/watch?v=npiG7EBzHOU>, of slightly over 8
    minutes, which includes both demonstrations, but elides most of the
    explanation. It?s intent is to get people ?hooked? so they will want
    to know more.
 2. The longer version of the video
    <http://www.youtube.com/watch?v=-D-cJNtKwuw>clocks in at 21 minutes,
    includes both demonstrations, but gives a simplified explanation of
    bufferbloat?s cause, to encourage people to dig yet further.

Best regards,
Jim Gettys





From bhmccie at gmail.com  Fri Feb  3 14:10:00 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 03 Feb 2012 14:10:00 -0600
Subject: IPv6 dual stacking and route tables
Message-ID: <4F2C3F18.3080804@gmail.com>

So, we are preparing to add IPv6 to our multi-homed (separate routers 
and carriers with IBGP) multi-site business. Starting off with a lab of 
course. Circuits and hardware are a few months away. I'm doing the 
initial designs and having some delivery questions with the carrier(s). 
One interesting question came up. There was a thread I found (and have 
since lost) regarding what routes to accept. Currently, in IPv4, we 
accept a default route only from both carriers at both sites. Works 
fine. Optimal? No. Significantly negative impact? No. In IPv6, I have 
heard some folks say that in a multi-homed environment it is better to 
get the full IPv6 table fed into both of your edge routers. Ok. Fine. 
Then, The thread I was referring to said that it is also advisable to 
have the entire IPv4 table fed in parallel. Ok. I understand we are 
talking about completely separate protocols. So it's not a layer 3 
issue. The reasoning was that DNS could potentially introduce some latency.

"If you have a specific route to a AAAA record but a less specific route 
to an A record the potential is for the trip to take longer."

That was the premise of the thread. I swear I googled it for 20 minutes 
to link before giving up. Anyway, can anyone who's been thru this 
provide any opinions on why or why not it is important to accept the 
full IPv6 table AND the full IPv4 table? I have the hardware to handle 
it I'm just not sure long term what the reasoning would be for or 
against. Again, I'm an end customer. Not a carrier. So my concern is (A) 
my Internet facing applications and (B) my users who eventually will 
surf IPv6.

Any guidance would be appreciated. Thanks.




-Hammer-

"I was a normal American nerd"
-Jack Herer




From ryan at u13.net  Fri Feb  3 14:20:03 2012
From: ryan at u13.net (Ryan Rawdon)
Date: Fri, 3 Feb 2012 15:20:03 -0500
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C3F18.3080804@gmail.com>
References: <4F2C3F18.3080804@gmail.com>
Message-ID: <5C7B4C2E-AD2E-4165-B6BA-FBDCF72BBBF6@u13.net>


On Feb 3, 2012, at 3:10 PM, -Hammer- wrote:

> So, we are preparing to add IPv6 to our multi-homed (separate routers and carriers with IBGP) multi-site business. Starting off with a lab of course. Circuits and hardware are a few months away. I'm doing the initial designs and having some delivery questions with the carrier(s). One interesting question came up. There was a thread I found (and have since lost) regarding what routes to accept. Currently, in IPv4, we accept a default route only from both carriers at both sites. Works fine. Optimal? No. Significantly negative impact? No. In IPv6, I have heard some folks say that in a multi-homed environment it is better to get the full IPv6 table fed into both of your edge routers. Ok. Fine. Then, The thread I was referring to said that it is also advisable to have the entire IPv4 table fed in parallel. Ok. I understand we are talking about completely separate protocols. So it's not a layer 3 issue. The reasoning was that DNS could potentially introduce some latency.
> 
> "If you have a specific route to a AAAA record but a less specific route to an A record the potential is for the trip to take longer."
> 
> That was the premise of the thread. I swear I googled it for 20 minutes to link before giving up. Anyway, can anyone who's been thru this provide any opinions on why or why not it is important to accept the full IPv6 table AND the full IPv4 table? I have the hardware to handle it I'm just not sure long term what the reasoning would be for or against. Again, I'm an end customer. Not a carrier. So my concern is (A) my Internet facing applications and (B) my users who eventually will surf IPv6.
> 
> Any guidance would be appreciated. Thanks.
> 
> -Hammer-

We have been accepting our upstreams' connected and customer routes only (v4) and full routes (v6) without issue.  I can't say that I have previously heard of the DNS performance example/concern you provided above

From tagno25 at gmail.com  Fri Feb  3 14:25:51 2012
From: tagno25 at gmail.com (Philip Dorr)
Date: Fri, 3 Feb 2012 14:25:51 -0600
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C3F18.3080804@gmail.com>
References: <4F2C3F18.3080804@gmail.com>
Message-ID: <CABidiTLDRTAqqcbn1Qnmrr5RZGMJLVEg6c9aptu+Z98_6+XQdg@mail.gmail.com>

You should accept the full v6 table, because some IPs may not,
currently, be reachable via one of the carriers.

On Fri, Feb 3, 2012 at 2:10 PM, -Hammer- <bhmccie at gmail.com> wrote:
> So, we are preparing to add IPv6 to our multi-homed (separate routers and
> carriers with IBGP) multi-site business. Starting off with a lab of course.
> Circuits and hardware are a few months away. I'm doing the initial designs
> and having some delivery questions with the carrier(s). One interesting
> question came up. There was a thread I found (and have since lost) regarding
> what routes to accept. Currently, in IPv4, we accept a default route only
> from both carriers at both sites. Works fine. Optimal? No. Significantly
> negative impact? No. In IPv6, I have heard some folks say that in a
> multi-homed environment it is better to get the full IPv6 table fed into
> both of your edge routers. Ok. Fine. Then, The thread I was referring to
> said that it is also advisable to have the entire IPv4 table fed in
> parallel. Ok. I understand we are talking about completely separate
> protocols. So it's not a layer 3 issue. The reasoning was that DNS could
> potentially introduce some latency.
>
> "If you have a specific route to a AAAA record but a less specific route to
> an A record the potential is for the trip to take longer."
>
> That was the premise of the thread. I swear I googled it for 20 minutes to
> link before giving up. Anyway, can anyone who's been thru this provide any
> opinions on why or why not it is important to accept the full IPv6 table AND
> the full IPv4 table? I have the hardware to handle it I'm just not sure long
> term what the reasoning would be for or against. Again, I'm an end customer.
> Not a carrier. So my concern is (A) my Internet facing applications and (B)
> my users who eventually will surf IPv6.
>
> Any guidance would be appreciated. Thanks.
>
>
>
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>


From streiner at cluebyfour.org  Fri Feb  3 14:27:34 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 3 Feb 2012 15:27:34 -0500 (EST)
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C3F18.3080804@gmail.com>
References: <4F2C3F18.3080804@gmail.com>
Message-ID: <Pine.LNX.4.64.1202031524460.5976@whammy.cluebyfour.org>

On Fri, 3 Feb 2012, -Hammer- wrote:

> "If you have a specific route to a AAAA record but a less specific route to 
> an A record the potential is for the trip to take longer."
>
> That was the premise of the thread. I swear I googled it for 20 minutes to 
> link before giving up. Anyway, can anyone who's been thru this provide any 
> opinions on why or why not it is important to accept the full IPv6 table AND 
> the full IPv4 table? I have the hardware to handle it I'm just not sure long 
> term what the reasoning would be for or against. Again, I'm an end customer. 
> Not a carrier. So my concern is (A) my Internet facing applications and (B) 
> my users who eventually will surf IPv6.

We currently take full v4 and v6 routes, however we do not yet have 
end-users officially on v6 (users doing their own 6to4 tunnels and stuff 
like Teredo notwithstanding), so I don't have any experience with the 
A/AAAA resolution asymmetry you're describing.

jms


From cb.list6 at gmail.com  Fri Feb  3 14:28:01 2012
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Fri, 3 Feb 2012 12:28:01 -0800
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C3F18.3080804@gmail.com>
References: <4F2C3F18.3080804@gmail.com>
Message-ID: <CAD6AjGTnVoSVUXKGb9BbhyQj9NGiPqC6C5c7NQRd7Dv72oj0jg@mail.gmail.com>

On Fri, Feb 3, 2012 at 12:10 PM, -Hammer- <bhmccie at gmail.com> wrote:
> So, we are preparing to add IPv6 to our multi-homed (separate routers and
> carriers with IBGP) multi-site business. Starting off with a lab of course.
> Circuits and hardware are a few months away. I'm doing the initial designs
> and having some delivery questions with the carrier(s). One interesting
> question came up. There was a thread I found (and have since lost) regarding
> what routes to accept. Currently, in IPv4, we accept a default route only
> from both carriers at both sites. Works fine. Optimal? No. Significantly
> negative impact? No. In IPv6, I have heard some folks say that in a
> multi-homed environment it is better to get the full IPv6 table fed into
> both of your edge routers. Ok. Fine. Then, The thread I was referring to
> said that it is also advisable to have the entire IPv4 table fed in
> parallel. Ok. I understand we are talking about completely separate
> protocols. So it's not a layer 3 issue. The reasoning was that DNS could
> potentially introduce some latency.
>
> "If you have a specific route to a AAAA record but a less specific route to
> an A record the potential is for the trip to take longer."
>
> That was the premise of the thread. I swear I googled it for 20 minutes to
> link before giving up. Anyway, can anyone who's been thru this provide any
> opinions on why or why not it is important to accept the full IPv6 table AND
> the full IPv4 table? I have the hardware to handle it I'm just not sure long
> term what the reasoning would be for or against. Again, I'm an end customer.
> Not a carrier. So my concern is (A) my Internet facing applications and (B)
> my users who eventually will surf IPv6.
>
> Any guidance would be appreciated. Thanks.
>
>

Well.  I don't really follow the above text.

But, the principle is the same for IPv4 or IPv6.  If you take a full
or partial table, your router can make a better choice than just
getting default  (only maybe, BGP is never guaranteeing anything about
performance).

That said, in v6, it is a little bit more important, IMHO, to take the
ISP routes instead of just a default since the v6 peering is not as
robust out on the Internet.  There are still turf wars going on or
some SPs are still not peering IPv6 in all the places they peer for
IPv4.  Less peering = longer latency. But, this situation has improved
dramatically in the last 12 months.

In the end, my guidance is to take "provider routes" or "customer
route" + default.  This helps your router make an educated guess
without absorbing all the churn and gunk that a full BGP feed hits
your router with.  Make the SP trim those routes on their side so you
don't see it.

CB
>
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>


From jeroen at unfix.org  Fri Feb  3 14:28:38 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Fri, 03 Feb 2012 21:28:38 +0100
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C3F18.3080804@gmail.com>
References: <4F2C3F18.3080804@gmail.com>
Message-ID: <4F2C4376.4070307@unfix.org>

On 2012-02-03 21:10 , -Hammer- wrote:

> So, we are preparing to add IPv6 to our multi-homed (separate routers
> and carriers with IBGP) multi-site business. Starting off with a lab of
> course.

Dear "Hammer",

Welcome to the 21th century. 2012 is going to "the year" (they claim,
again ;) of IPv6 thus it is better to start before the big launch event
that is this year, (of which there was also one back in in 2004:
http://www.global-ipv6.org/ for the folks who have IPv6 for some time
now ;) Better late than never some would say.

> Circuits and hardware are a few months away. I'm doing the
> initial designs and having some delivery questions with the carrier(s).
> One interesting question came up. There was a thread I found (and have
> since lost) regarding what routes to accept. Currently, in IPv4, we
> accept a default route only from both carriers at both sites. Works
> fine. Optimal? No. Significantly negative impact? No. In IPv6, I have
> heard some folks say that in a multi-homed environment it is better to
> get the full IPv6 table fed into both of your edge routers. Ok. Fine.
> Then, The thread I was referring to said that it is also advisable to
> have the entire IPv4 table fed in parallel. Ok. I understand we are
> talking about completely separate protocols. So it's not a layer 3
> issue.

The only advantage of more routes, in both IPv4 and IPv6 is that the
path selection can be better. An end-host does not make this decision
where packets flow, thus having a full route or not should not matter
much, except that the route might be more optimal. No DNS involvement
here yet.

The trick comes with Happy-Eyeballs alike setups (especially Mac OSX
Lion and up which does not follow that spec and in which it cannot be
turned off either, which is awesome when you are debugging things...)

Due to HE (Happy-Eyeballs) setups, which can differ per OS and per tool.

Chrome has it's own HE implementation, thus if you run Chrome on a Mac
you will have sometimes one sometimes another connect depending on if
you are using Safari or Chrome for instance as Safari does use the
system provided things. Ping will pick another again etc. It will be
quite random all the time.

The fun with the Mac OS X implementation is that it keeps a local cache
of per-destination latency/speed information.

If you thus have two default routes, be that IPv4 or IPv6, and your
routers are swapping paths between either and thus don't have a stable
outgoing path those latencies will vary and thus the pretty HE
algorithms will be very confused.

This is likely why your "source" recommended to have a full path, as per
sub-prefix the path will become more stable and established than if you
are doing hot-potato with two defaults.

Greets,
 Jeroen



From bhmccie at gmail.com  Fri Feb  3 14:37:44 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 03 Feb 2012 14:37:44 -0600
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C4376.4070307@unfix.org>
References: <4F2C3F18.3080804@gmail.com> <4F2C4376.4070307@unfix.org>
Message-ID: <4F2C4598.5060505@gmail.com>

Thanks Jeroen (and Ryan/Philip/Cameron/Justin/Etc.) for all the online 
and offline responses. That was fast. The struggle is that I'm having 
trouble seeing how/why it would matter other than potential latency on 
the IPv4 side. IPv6 conversations usually involve taking the full table 
when dealing with multi-homed/multi-site setups. IPv4 I didn't really 
consider (taking the full table) until I mentioned this to some of my 
vendors technical folks and it caused a lot of reflection. Not on the L3 
part. Just on the DNS part. This appears to be a tough subject area when 
it comes to V4/V6 deployment strategies. The bottom line is that I'll 
take whatever the carrier feeds in V6. Just trying to see where I would 
be missing out by not doing the same in V4. Again, I have the hardware 
to support it and I really have no reason not to do it. I just want to 
be able to justify to myself why I'm doing it.

A lot of kinks to work out this year.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/3/2012 2:28 PM, Jeroen Massar wrote:
> On 2012-02-03 21:10 , -Hammer- wrote:
>
>> So, we are preparing to add IPv6 to our multi-homed (separate routers
>> and carriers with IBGP) multi-site business. Starting off with a lab of
>> course.
> Dear "Hammer",
>
> Welcome to the 21th century. 2012 is going to "the year" (they claim,
> again ;) of IPv6 thus it is better to start before the big launch event
> that is this year, (of which there was also one back in in 2004:
> http://www.global-ipv6.org/ for the folks who have IPv6 for some time
> now ;) Better late than never some would say.
>
>> Circuits and hardware are a few months away. I'm doing the
>> initial designs and having some delivery questions with the carrier(s).
>> One interesting question came up. There was a thread I found (and have
>> since lost) regarding what routes to accept. Currently, in IPv4, we
>> accept a default route only from both carriers at both sites. Works
>> fine. Optimal? No. Significantly negative impact? No. In IPv6, I have
>> heard some folks say that in a multi-homed environment it is better to
>> get the full IPv6 table fed into both of your edge routers. Ok. Fine.
>> Then, The thread I was referring to said that it is also advisable to
>> have the entire IPv4 table fed in parallel. Ok. I understand we are
>> talking about completely separate protocols. So it's not a layer 3
>> issue.
> The only advantage of more routes, in both IPv4 and IPv6 is that the
> path selection can be better. An end-host does not make this decision
> where packets flow, thus having a full route or not should not matter
> much, except that the route might be more optimal. No DNS involvement
> here yet.
>
> The trick comes with Happy-Eyeballs alike setups (especially Mac OSX
> Lion and up which does not follow that spec and in which it cannot be
> turned off either, which is awesome when you are debugging things...)
>
> Due to HE (Happy-Eyeballs) setups, which can differ per OS and per tool.
>
> Chrome has it's own HE implementation, thus if you run Chrome on a Mac
> you will have sometimes one sometimes another connect depending on if
> you are using Safari or Chrome for instance as Safari does use the
> system provided things. Ping will pick another again etc. It will be
> quite random all the time.
>
> The fun with the Mac OS X implementation is that it keeps a local cache
> of per-destination latency/speed information.
>
> If you thus have two default routes, be that IPv4 or IPv6, and your
> routers are swapping paths between either and thus don't have a stable
> outgoing path those latencies will vary and thus the pretty HE
> algorithms will be very confused.
>
> This is likely why your "source" recommended to have a full path, as per
> sub-prefix the path will become more stable and established than if you
> are doing hot-potato with two defaults.
>
> Greets,
>   Jeroen
>
>


From jeroen at unfix.org  Fri Feb  3 14:47:00 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Fri, 03 Feb 2012 21:47:00 +0100
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C4598.5060505@gmail.com>
References: <4F2C3F18.3080804@gmail.com> <4F2C4376.4070307@unfix.org>
 <4F2C4598.5060505@gmail.com>
Message-ID: <4F2C47C4.3050303@unfix.org>

On 2012-02-03 21:37 , -Hammer- wrote:
> Thanks Jeroen (and Ryan/Philip/Cameron/Justin/Etc.) for all the online
> and offline responses. That was fast. The struggle is that I'm having
> trouble seeing how/why it would matter other than potential latency on
> the IPv4 side. IPv6 conversations usually involve taking the full table
> when dealing with multi-homed/multi-site setups. IPv4 I didn't really
> consider (taking the full table) until I mentioned this to some of my
> vendors technical folks and it caused a lot of reflection. Not on the L3
> part. Just on the DNS part. This appears to be a tough subject area when
> it comes to V4/V6 deployment strategies. The bottom line is that I'll
> take whatever the carrier feeds in V6. Just trying to see where I would
> be missing out by not doing the same in V4. Again, I have the hardware
> to support it and I really have no reason not to do it. I just want to
> be able to justify to myself why I'm doing it.

Why you want non-defaults in both IPv4 and IPv6:
 - more possible paths
 - less chances of blackholes.

And of course, those paths will be more stable and you don't get
hot-potato swapping between two defaults.

And that in turn allows the Happy Eyeballs mechanisms to do their jobs
much better as they keep a history per host or prefix, they assume IPv6
/48's and IPv4 /24's from what I have seen, in some cases.

Greets,
 Jeroen



From bhmccie at gmail.com  Fri Feb  3 15:04:18 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 03 Feb 2012 15:04:18 -0600
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C47C4.3050303@unfix.org>
References: <4F2C3F18.3080804@gmail.com> <4F2C4376.4070307@unfix.org>
 <4F2C4598.5060505@gmail.com> <4F2C47C4.3050303@unfix.org>
Message-ID: <4F2C4BD2.4080904@gmail.com>

OK. Looking forward to getting the lab up. Since I can handle the volume 
I'll take both tables. At least in the lab. Looking forward to doing 
some experiments with DNS just to see what all the fuss is about. Looks 
like I'll need to order a Mac for the lab. No harm there. :)

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/3/2012 2:47 PM, Jeroen Massar wrote:
> On 2012-02-03 21:37 , -Hammer- wrote:
>> Thanks Jeroen (and Ryan/Philip/Cameron/Justin/Etc.) for all the online
>> and offline responses. That was fast. The struggle is that I'm having
>> trouble seeing how/why it would matter other than potential latency on
>> the IPv4 side. IPv6 conversations usually involve taking the full table
>> when dealing with multi-homed/multi-site setups. IPv4 I didn't really
>> consider (taking the full table) until I mentioned this to some of my
>> vendors technical folks and it caused a lot of reflection. Not on the L3
>> part. Just on the DNS part. This appears to be a tough subject area when
>> it comes to V4/V6 deployment strategies. The bottom line is that I'll
>> take whatever the carrier feeds in V6. Just trying to see where I would
>> be missing out by not doing the same in V4. Again, I have the hardware
>> to support it and I really have no reason not to do it. I just want to
>> be able to justify to myself why I'm doing it.
> Why you want non-defaults in both IPv4 and IPv6:
>   - more possible paths
>   - less chances of blackholes.
>
> And of course, those paths will be more stable and you don't get
> hot-potato swapping between two defaults.
>
> And that in turn allows the Happy Eyeballs mechanisms to do their jobs
> much better as they keep a history per host or prefix, they assume IPv6
> /48's and IPv4 /24's from what I have seen, in some cases.
>
> Greets,
>   Jeroen
>
>


From ryan at u13.net  Fri Feb  3 15:44:33 2012
From: ryan at u13.net (Ryan Rawdon)
Date: Fri, 3 Feb 2012 16:44:33 -0500
Subject: IPv6 dual stacking and route tables
In-Reply-To: <CABidiTLDRTAqqcbn1Qnmrr5RZGMJLVEg6c9aptu+Z98_6+XQdg@mail.gmail.com>
References: <4F2C3F18.3080804@gmail.com>
 <CABidiTLDRTAqqcbn1Qnmrr5RZGMJLVEg6c9aptu+Z98_6+XQdg@mail.gmail.com>
Message-ID: <D9A448B4-1D5B-48A0-AF1F-1CE17D1FA958@u13.net>


On Feb 3, 2012, at 3:25 PM, Philip Dorr wrote:

> You should accept the full v6 table, because some IPs may not,
> currently, be reachable via one of the carriers.

Definitely agreed here, and this is why we take full v6 tables.  Especially since one of our upstreams does not peer with at least one other large network; if we took just a default from them, we would likely be sending them traffic which they in turn do not have a route for whereas the other upstream of ours does.

> 
> On Fri, Feb 3, 2012 at 2:10 PM, -Hammer- <bhmccie at gmail.com> wrote:
>> So, we are preparing to add IPv6 to our multi-homed (separate routers and
>> carriers with IBGP) multi-site business. Starting off with a lab of course.
>> Circuits and hardware are a few months away. I'm doing the initial designs
>> and having some delivery questions with the carrier(s). One interesting
>> question came up. There was a thread I found (and have since lost) regarding
>> what routes to accept. Currently, in IPv4, we accept a default route only
>> from both carriers at both sites. Works fine. Optimal? No. Significantly
>> negative impact? No. In IPv6, I have heard some folks say that in a
>> multi-homed environment it is better to get the full IPv6 table fed into
>> both of your edge routers. Ok. Fine. Then, The thread I was referring to
>> said that it is also advisable to have the entire IPv4 table fed in
>> parallel. Ok. I understand we are talking about completely separate
>> protocols. So it's not a layer 3 issue. The reasoning was that DNS could
>> potentially introduce some latency.
>> 
>> "If you have a specific route to a AAAA record but a less specific route to
>> an A record the potential is for the trip to take longer."
>> 
>> That was the premise of the thread. I swear I googled it for 20 minutes to
>> link before giving up. Anyway, can anyone who's been thru this provide any
>> opinions on why or why not it is important to accept the full IPv6 table AND
>> the full IPv4 table? I have the hardware to handle it I'm just not sure long
>> term what the reasoning would be for or against. Again, I'm an end customer.
>> Not a carrier. So my concern is (A) my Internet facing applications and (B)
>> my users who eventually will surf IPv6.
>> 
>> Any guidance would be appreciated. Thanks.
>> 
>> 
>> 
>> 
>> -Hammer-
>> 
>> "I was a normal American nerd"
>> -Jack Herer
>> 
>> 
>> 
> 



From cidr-report at potaroo.net  Fri Feb  3 16:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 3 Feb 2012 22:00:00 GMT
Subject: BGP Update Report
Message-ID: <201202032200.q13M00AS097487@wattle.apnic.net>

BGP Update Report
Interval: 26-Jan-12 -to- 02-Feb-12 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS8402            53901  3.1%      29.0 -- CORBINA-AS OJSC "Vimpelcom"
 2 - AS28683           39445  2.3%     646.6 -- BENINTELECOM
 3 - AS5800            33859  1.9%     117.2 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
 4 - AS12479           25806  1.5%     154.5 -- UNI2-AS France Telecom Espana SA
 5 - AS9829            25640  1.5%      36.9 -- BSNL-NIB National Internet Backbone
 6 - AS32528           23059  1.3%    7686.3 -- ABBOTT Abbot Labs
 7 - AS23154           20656  1.2%    5164.0 -- SANMINA-SCI Sanmina-SCI Corporation
 8 - AS20632           20258  1.2%     519.4 -- PETERSTAR-AS PeterStar
 9 - AS7029            18611  1.1%       7.2 -- WINDSTREAM - Windstream Communications Inc
10 - AS6713            18375  1.1%      37.7 -- IAM-AS
11 - AS24560           18180  1.0%      46.0 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
12 - AS31148           16044  0.9%      24.7 -- FREENET-AS FreeNet ISP
13 - AS6066            12493  0.7%    6246.5 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
14 - AS9583            11691  0.7%      11.9 -- SIFY-AS-IN Sify Limited
15 - AS17974           11635  0.7%       8.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
16 - AS5976            11626  0.7%     118.6 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
17 - AS4538            11580  0.7%      22.7 -- ERX-CERNET-BKB China Education and Research Network Center
18 - AS6503            11445  0.7%       7.0 -- Axtel, S.A.B. de C.V.
19 - AS37004           11269  0.7%     433.4 -- SUBURBAN-AS
20 - AS43348           10512  0.6%      79.6 -- TATARINOVA-AS PE Tatarinova Alla Ivanovna


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS29126            9346  0.5%    9346.0 -- DATIQ-AS Datiq B.V.
 2 - AS32528           23059  1.3%    7686.3 -- ABBOTT Abbot Labs
 3 - AS6066            12493  0.7%    6246.5 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
 4 - AS23154           20656  1.2%    5164.0 -- SANMINA-SCI Sanmina-SCI Corporation
 5 - AS10209            3894  0.2%    3894.0 -- SYNOPSYS-AS-JP-AP Japan HUB and Data Center
 6 - AS5868             1677  0.1%    1677.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
 7 - AS53362            1001  0.1%    1001.0 -- MIXIT-AS - Mixit, Inc.
 8 - AS16045             830  0.1%     830.0 -- SPEKTAR-AD Spektar AD
 9 - AS27295             670  0.0%     670.0 -- GENICA - Genica Corporation
10 - AS36980             660  0.0%     660.0 -- JOHNHOLT-ASN
11 - AS28683           39445  2.3%     646.6 -- BENINTELECOM
12 - AS53222            1770  0.1%     590.0 -- 
13 - AS19226             565  0.0%     565.0 -- AURA-SOUTH - A.U.R.A
14 - AS17408            3247  0.2%     541.2 -- ABOVE-AS-AP AboveNet Communications Taiwan
15 - AS28123             527  0.0%     527.0 -- 
16 - AS52861            1575  0.1%     525.0 -- 
17 - AS20632           20258  1.2%     519.4 -- PETERSTAR-AS PeterStar
18 - AS5863              473  0.0%     473.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
19 - AS49047             471  0.0%     471.0 -- PCSI-ASN Pentacomp Systemy Informatyczne S.A.
20 - AS27689             465  0.0%     465.0 -- Laboratorio Nacional de Inform?tica Avanzada AC


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 148.164.14.0/24   20619  1.1%   AS23154 -- SANMINA-SCI Sanmina-SCI Corporation
 2 - 84.204.132.0/24   20117  1.1%   AS20632 -- PETERSTAR-AS PeterStar
 3 - 130.36.34.0/24    11529  0.6%   AS32528 -- ABBOTT Abbot Labs
 4 - 130.36.35.0/24    11529  0.6%   AS32528 -- ABBOTT Abbot Labs
 5 - 122.161.0.0/16    10190  0.6%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
 6 - 217.170.24.0/21    9346  0.5%   AS29126 -- DATIQ-AS Datiq B.V.
 7 - 62.36.252.0/22     8037  0.4%   AS12479 -- UNI2-AS France Telecom Espana SA
 8 - 202.92.235.0/24    6528  0.3%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 9 - 150.225.0.0/16     6247  0.3%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
10 - 204.29.239.0/24    6246  0.3%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
11 - 62.36.249.0/24     6087  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
12 - 62.36.241.0/24     5537  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
13 - 194.63.9.0/24      5387  0.3%   AS1273  -- CW Cable and Wireless Worldwide plc
14 - 62.36.210.0/24     5289  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
15 - 190.67.172.0/22    5051  0.3%   AS3816  -- COLOMBIA TELECOMUNICACIONES S.A. ESP
16 - 111.125.126.0/24   4975  0.3%   AS17639 -- COMCLARK-AS ComClark Network & Technology Corp.
17 - 205.73.118.0/24    4667  0.2%   AS5976  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
18 - 205.73.116.0/23    4553  0.2%   AS5976  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
19 - 198.182.50.0/23    3894  0.2%   AS10209 -- SYNOPSYS-AS-JP-AP Japan HUB and Data Center
20 - 202.153.174.0/24   3193  0.2%   AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Feb  3 16:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 3 Feb 2012 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201202032200.q13M00Vs097482@wattle.apnic.net>

This report has been generated at Fri Feb  3 21:12:45 2012 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        27-01-12    396272      229808
        28-01-12    395687      230060
        29-01-12    396508      229971
        30-01-12    396324      229998
        31-01-12    396621      229745
        01-02-12    396817      230146
        02-02-12    397186      229608
        03-02-12    397625      230080


AS Summary
         40099  Number of ASes in routing system
         16816  Number of ASes announcing only one prefix
          3445  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      109882880  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 03Feb12 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     398212   230080   168132    42.2%   All ASes

AS6389      3445      204     3241    94.1%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS7029      3260     1427     1833    56.2%   WINDSTREAM - Windstream
                                               Communications Inc
AS18566     2093      413     1680    80.3%   COVAD - Covad Communications
                                               Co.
AS4766      2478     1005     1473    59.4%   KIXS-AS-KR Korea Telecom
AS22773     1499      118     1381    92.1%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4755      1528      197     1331    87.1%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS2118      1391       76     1315    94.5%   RELCOM-AS OOO "NPO Relcom"
AS4323      1610      386     1224    76.0%   TWTC - tw telecom holdings,
                                               inc.
AS28573     1624      407     1217    74.9%   NET Servicos de Comunicao S.A.
AS1785      1868      789     1079    57.8%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS7552      1408      363     1045    74.2%   VIETEL-AS-AP Vietel
                                               Corporation
AS19262     1386      401      985    71.1%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS10620     1735      766      969    55.9%   Telmex Colombia S.A.
AS8402      1653      726      927    56.1%   CORBINA-AS OJSC "Vimpelcom"
AS7303      1260      366      894    71.0%   Telecom Argentina S.A.
AS26615      885       33      852    96.3%   Tim Celular S.A.
AS8151      1337      550      787    58.9%   Uninet S.A. de C.V.
AS18101      935      156      779    83.3%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS4808      1102      344      758    68.8%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS24560     1010      299      711    70.4%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS30036     1437      753      684    47.6%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS9498       878      206      672    76.5%   BBIL-AP BHARTI Airtel Ltd.
AS9394       878      210      668    76.1%   CRNET CHINA RAILWAY
                                               Internet(CRNET)
AS7545      1642      998      644    39.2%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS3356      1098      457      641    58.4%   LEVEL3 Level 3 Communications
AS17676      687       74      613    89.2%   GIGAINFRA Softbank BB Corp.
AS17974     1724     1121      603    35.0%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS11172      698      113      585    83.8%   Alestra, S. de R.L. de C.V.
AS15557     1096      511      585    53.4%   LDCOMNET Societe Francaise du
                                               Radiotelephone S.A
AS4804       660       95      565    85.6%   MPX-AS Microplex PTY LTD

Total      44305    13564    30741    69.4%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        14.192.0.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.4.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.8.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.12.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.16.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.20.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.24.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.28.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        37.77.176.0/21       AS16082 SPITFIRE Spitfire Network Services Autonomous System
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.129.0.0/19        AS3901  ARRAKIS - Higher Technology Services
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.143.0/24      AS3356  LEVEL3 Level 3 Communications
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.44.16.0/20        AS15054 HAMELTRONICS - Hameltronics, LLC
        80.88.10.0/24        AS33774 DJAWEB
        98.159.96.0/20       AS46975 
        110.34.44.0/22       AS12653 COMTONET Com-ToNet
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        172.45.1.0/24        AS3356  LEVEL3 Level 3 Communications
        172.45.2.0/24        AS29571 CITelecom-AS
        172.45.3.0/24        AS29571 CITelecom-AS
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        193.0.22.0/23        AS3333  RIPE-NCC-AS RIPE Network Coordination Centre
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.23.84.0/24       AS8151  Uninet S.A. de C.V.
        200.24.73.0/24       AS26061 Equant Colombia
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.86.32.0/20       AS18255 BRISBANE-AP Brisbane City Council
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.140.128.0/19     AS9583  SIFY-AS-IN Sify Limited
        202.160.152.0/22     AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.80.130.0/23      AS9260  MULTINET-PK NSP,ISP,HFC,DSL,DIALUP,Data Network Connectivity solutions,
        203.142.219.0/24     AS45149 
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A.
        205.189.0.0/24       AS54372 DROPBOX-CORP - Dropbox, Inc.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - KNOLOGY,  Inc.
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.91.56.0/21       AS22241 IC2NET - IC2NET
        208.91.56.0/24       AS22241 IC2NET - IC2NET
        208.91.57.0/24       AS22241 IC2NET - IC2NET
        208.91.58.0/24       AS22241 IC2NET - IC2NET
        208.91.59.0/24       AS22241 IC2NET - IC2NET
        208.91.60.0/24       AS22241 IC2NET - IC2NET
        208.91.61.0/24       AS22241 IC2NET - IC2NET
        208.91.62.0/24       AS22241 IC2NET - IC2NET
        208.91.63.0/24       AS22241 IC2NET - IC2NET
        209.133.224.0/19     AS4323  TWTC - tw telecom holdings, inc.
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        209.222.240.0/22     AS19747 
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.12.160.0/20      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From mpetach at netflight.com  Fri Feb  3 16:01:54 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Fri, 3 Feb 2012 14:01:54 -0800
Subject: This network is too good...
In-Reply-To: <86d39yknou.fsf@seastrom.com>
References: <86d39yknou.fsf@seastrom.com>
Message-ID: <CAEmG1=rQkeQ2Y6BddDvN++-0rDtaEMkJxw5=WTammbc5NCQNvg@mail.gmail.com>

On Wed, Feb 1, 2012 at 5:51 PM, Robert E. Seastrom <rs at seastrom.com> wrote:
>
> Hi all,
>
> Any thoughts on products that screw up networks in deterministic (and
> realistic found-in-the-wild) ways? ?I'm thinking of stuff like
> PacketStorm, Dummynet, etc. ?Dial up jitter, latency, tail drop, RED,
> whatever...
>
> (I know someone's gonna say "Just buy a Brand Z FubarSwitch 3k, they
> will screw up your whole network and you don't even have to configure
> it to do so!")
>
> I'm all-ears like Ross Perot.
>
> Thanks,
>
> -r

Definite +1 for dummynet on freebsd; I've used in the lab at layer 2 in
bridge mode, and layer 3 both, for doing testing.  latency introduction
is good down to a few ms, but isn't accurate below that--but for most
of what we do, in terms of simulating latency and loss/jitter, it works
like a charm.

Matt


From owen at delong.com  Fri Feb  3 17:02:23 2012
From: owen at delong.com (Owen DeLong)
Date: Fri, 3 Feb 2012 15:02:23 -0800
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C3F18.3080804@gmail.com>
References: <4F2C3F18.3080804@gmail.com>
Message-ID: <5E284873-1AE5-42C9-9E8D-EA8D040A1412@delong.com>


On Feb 3, 2012, at 12:10 PM, -Hammer- wrote:

> So, we are preparing to add IPv6 to our multi-homed (separate routers and carriers with IBGP) multi-site business. Starting off with a lab of course. Circuits and hardware are a few months away. I'm doing the initial designs and having some delivery questions with the carrier(s). One interesting question came up. There was a thread I found (and have since lost) regarding what routes to accept. Currently, in IPv4, we accept a default route only from both carriers at both sites. Works fine. Optimal? No. Significantly negative impact? No. In IPv6, I have heard some folks say that in a multi-homed environment it is better to get the full IPv6 table fed into both of your edge routers. Ok. Fine. Then, The thread I was referring to said that it is also advisable to have the entire IPv4 table fed in parallel. Ok. I understand we are talking about completely separate protocols. So it's not a layer 3 issue. The reasoning was that DNS could potentially introduce some latency.
> 
> "If you have a specific route to a AAAA record but a less specific route to an A record the potential is for the trip to take longer."
> 
> That was the premise of the thread. I swear I googled it for 20 minutes to link before giving up. Anyway, can anyone who's been thru this provide any opinions on why or why not it is important to accept the full IPv6 table AND the full IPv4 table? I have the hardware to handle it I'm just not sure long term what the reasoning would be for or against. Again, I'm an end customer. Not a carrier. So my concern is (A) my Internet facing applications and (B) my users who eventually will surf IPv6.
> 
> Any guidance would be appreciated. Thanks.
> 
> 
> 
> 
> -Hammer-
> 
> "I was a normal American nerd"
> -Jack Herer
> 
> 

On a purely theoretical level, mores specific routes are always better than default.

So, on a purely theoretical level:

IDEAL:			Full routes, both protocols
	Advantage:  Most information available, theoretically best decisions possible.
	Disadvantage:	Router cost rivals national debt of third-world country.

Second best:		Full routes IPv6, default or partial routes IPv4
	Advantage:  Lots of information available, theoretically best IPv6 decisions.
	Disadvantage:  IPv6 might outperform IPv4 (not really a problem in most cases)
	Bigger disadvantage: Some IPv4 destinations might get blackholed from time to time.

Third choice:		Default both protocols
	Advantage:  At least you're still dual-stacked.
	Disadvantage: All the disadvantages applied to IPv4 above now apply to IPv6, too.

Worst choice:	Don't implement IPv6
	Advantage:  Absolutely none.
	Disadvantage: You can reach progressively less and less of the internet over time.

However, the real answer is more complex than that. Sometimes the route that looks the best in BGP might not actually be the best and so in some cases with full tables you might send to the provider with the less effective path even though default would have had you going via the more effective path. These circumstances are rare, however, but, BGP has lots of knobs and depending on how well you and your upstreams set those knobs, your experience can be radically better or worse as a result.

If your trip to the A destination via default takes longer than your trip to the AAAA destination via specifics, I'm not seeing a problem. Clients that have IPv6 capability will get a better user experience and clients that don't have IPv6 will get the same experience they got with default-based IPv4 prior to you implementing IPv6.

Owen



From robertg at garlic.com  Fri Feb  3 19:25:46 2012
From: robertg at garlic.com (Robert Glover)
Date: Fri, 03 Feb 2012 17:25:46 -0800
Subject: AT&T / prodigy.net mail admin
Message-ID: <4F2C891A.4090403@garlic.com>

Hello,

Can an AT&T mail admin contact me off-list please?  I have attempted to 
get a resolution for an issue through the normal channels and have not 
gotten anywhere.

Sincerely,
Bobby Glover
Director of Information Services
SVI Incorporated


From merlyn at geeks.org  Fri Feb  3 20:36:55 2012
From: merlyn at geeks.org (Doug McIntyre)
Date: Fri, 3 Feb 2012 20:36:55 -0600
Subject: not excactly on-topic Server Cabinet question
In-Reply-To: <635D17EE85D35A49B8F278998E6C3404647C8EB4DB@EXVS.dev.oati.local>
References: <635D17EE85D35A49B8F278998E6C3404647C8EB4DB@EXVS.dev.oati.local>
Message-ID: <20120204023655.GA18107@geeks.org>

On Wed, Feb 01, 2012 at 11:05:09PM -0600, Erik Amundson wrote:
> I apologize for this being off-topic in the NANOG list, but I'm hoping some of you have experience with the particulars of what I'm looking for...
> 
> I am looking for a server cabinet which has an electric latching mechanism on it.  I want to use my existing security system and proximity card reader, but have a cabinet door that would open when the card reader is read.
> 
> Does anyone sell anything like this?

Chatsworth has a solution..

http://www.chatsworth.com/Products/Environmental-Monitoring-and-Security/Electronic-Locking-Systems/



From swmike at swm.pp.se  Fri Feb  3 22:09:56 2012
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Sat, 4 Feb 2012 05:09:56 +0100 (CET)
Subject: bufferbloat videos are up.
In-Reply-To: <4F2C357C.9070407@freedesktop.org>
References: <4F2C357C.9070407@freedesktop.org>
Message-ID: <alpine.DEB.2.00.1202040451570.8029@uplift.swm.pp.se>

On Fri, 3 Feb 2012, Jim Gettys wrote:

> 2. The longer version of the video

Good visualisation. Just a little nitpicking, 802.11 is 54 megabit, not 
megahertz. It should also be pointed out that 802.11 is half duplex, which 
might affect things.

Also, you might want to point out in your material that large buffers are 
there to handle bursts on TCP sessions over high RTT. Your suggestion to 
improve interactive performance hurts high speed TCP high RTT sessions. 
This is probably what most people want to do, but it would be good to 
point it out. Doing a promotion for ECN support in equipment would also be 
good, because introduing WRED with high drop probability a low buffer fill 
will really hurt performance for TCP transfers. ECN will help to avoid 
restransmissions, which just wastes bw.

Where does your 100ms buffer size recommendation come from? The classical 
one is 2xRTT, with a lot of platforms developed around 2000 sized at 600ms 
of buffering (because 300 ms RTT seems like a decent value to choose for 
"max RTT" I guess). At megabit speeds I'd say to achieve your goal having 
100ms FIFO buffering is too high anyway, so to handle your problem you 
need "fairqueue" to look at flows and put persistent buffer filling TCP 
sessions in "the background". This would also mean TCP would be able to 
use full bw without hurting interactivity.

Also, for some operating systems (Linux is the one I know about), there is 
a tendency to have high buffers not only in the IP stack, but also high 
FIFO buffers towards the hardware, in the device driver. I engaged the 
linux-usb mailing list about this, and I did see some talk that indicated 
that people understood the problem.

So basically I agree with your problem statement, however I think it would 
be benficial if your proposed solution was a bit more specific, or at 
least pointed more in that direction. To propose a solution that sounds 
more like "limit buffers to 100ms or less and everything will be fine" 
would indeed remove some of the problem, but it would hurt performance for 
some applications.

The problem you're describing has been know for 25 years, unfortunately 
not by the right people in the business, especially the ones making high 
volume low cost home equipment.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se


From bicknell at ufp.org  Fri Feb  3 22:29:40 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 3 Feb 2012 22:29:40 -0600
Subject: bufferbloat videos are up.
In-Reply-To: <alpine.DEB.2.00.1202040451570.8029@uplift.swm.pp.se>
References: <4F2C357C.9070407@freedesktop.org>
 <alpine.DEB.2.00.1202040451570.8029@uplift.swm.pp.se>
Message-ID: <418169E5-A04B-459D-88B7-22C78D6182BF@ufp.org>


On Feb 3, 2012, at 10:09 PM, Mikael Abrahamsson wrote:

> So basically I agree with your problem statement, however I think it would be benficial if your proposed solution was a bit more specific, or at least pointed more in that direction. To propose a solution that sounds more like "limit buffers to 100ms or less and everything will be fine" would indeed remove some of the problem, but it would hurt performance for some applications.

The key to the solution is better Adaptive Queue Management, or AQM.  As long as we have to decide on fixed queue sizes for all traffic, we're forced to cater to the most common traffic type.

It would be nice to put queues of different RTT into different queues.  Today that is basically impossible.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/







From matt at mattreath.com  Sat Feb  4 01:40:55 2012
From: matt at mattreath.com (Matthew Reath)
Date: Sat, 4 Feb 2012 01:40:55 -0600
Subject: Question about prefix list
In-Reply-To: <1328156018.36060.YahooMailClassic@web181110.mail.ne1.yahoo.com>
References: <1328156018.36060.YahooMailClassic@web181110.mail.ne1.yahoo.com>
Message-ID: <ff66073bc8c812da166670a74b7221be.squirrel@mail.mattreath.com>

> Ann,
> the commas not withstanding, the le/ge operands as applicable to
> prefix-lists simply mean "less-than or equal-to" or greater-than or
> "equal-to" wrt netmasks in CIDR speak.
>
> In you prefix-list below, the le operand means -
> allow following ranges:
>
> /22,/23,/24 deny all else
> for the /21
> it means allow /21 thru /24
>
> Anything without an operand means an exact-match(permit/deny)
>
> Homework for you:
>
> What do the following do:
>
> 1) ip prefix-list foo deny 0.0.0.0/0 le32
> 2) ip prefix-list foo permit 0.0.0/0 le 32
>
> Understand the above and you will understand how operands work in
> prefix-lists.
> ./Randy
>
>
> --- On Wed, 2/1/12, Ann Kwok <annkwok80 at gmail.com> wrote:
>
>> From: Ann Kwok <annkwok80 at gmail.com>
>> Subject: Question about prefix list
>> To: nanog at nanog.org
>> Date: Wednesday, February 1, 2012, 6:32 AM
>> Hi
>>
>> I read this prefix list.
>>
>> Can I know why there is "le 24" after network block in /22
>> and /21
>>
>> Why don't have "le 24" after /24?
>>
>> I also saw another prefix list before. They use "le 32"
>> instead of? "le 24"
>>
>> What are their different?
>>
>> ip prefix-list prefix-filter-as100 seq 10 permit
>> 202,168.136.0/22 le 24
>> ip prefix-list prefix-filter-as100 seq 20 permit
>> 202,22.92.0/22 le 24
>> ip prefix-list prefix-filter-as100 seq 30 permit
>> 202,21.148.0/22 le 24
>> ip prefix-list prefix-filter-as100 seq 40 permit
>> 203,178.88.0/21 le 24
>> ip prefix-list prefix-filter-as100 seq 50 permit
>> 178.88.74.0/24
>>
>> Thank you so much
>>
>
>

Here is how I look at prefix lists 


Lets say I have the following:
ip prefix-list EXAMPLE permit 202.21.148.0/22 le 24

What this essentially means is match any prefixes that match the first 22
bits of 202.21.148.0 with a prefix length less than or equal to /24.

The third octet (148) is 10010100 in binary, the /22 would be at
100101|00. So we would match anything that has the same bits set before
the divider or the /22 mark.

Matching prefixes would be:
202.21.148.0/22
202.21.148.0/23
202.21.150.0/23
202.21.148.0/24
202.21.149.0/24
202.21.150.0/24
202.21.151.0/24

Hope that makes sense.

--
Matt Reath
CCIE #27316 (SP)
matt at mattreath.com | http://mattreath.com
Twitter: http://twitter.com/mpreath



From matt at mattreath.com  Sat Feb  4 01:55:20 2012
From: matt at mattreath.com (Matthew Reath)
Date: Sat, 4 Feb 2012 01:55:20 -0600
Subject: Please help our simple bgp
In-Reply-To: <CACwqZxjBp_R_b-r-9zdB+4xSO1mPmfaYhg8nuDwnt7g2i6RXTg@mail.gmail.com>
References: <CACwqZxjBp_R_b-r-9zdB+4xSO1mPmfaYhg8nuDwnt7g2i6RXTg@mail.gmail.com>
Message-ID: <ad888288ddfe04e7150ac1716439c4b2.squirrel@mail.mattreath.com>

> Hello
>
> Our router is running simple bgp. "one BGP router, two upstreams (each
> 100M
> from ISP A and ISP B)
> We are getting full feeds tables from them
>
> We discover the routes is going to ISP A only even the bandwidth 100M is
> full
>
> Can we set the weight to change to ISP B to use ISP B as preference
> routes?
>
> Can the following configuration work?
> What suggest to this weight no. too?
>
>  neighbor 1.2.3.4 description ISP B
>  neighbor 1.2.3.4 remote-as 111
>  neighbor 1.2.3.4 weight 2000
>
> If this works, how is ISP B upstream connection is down?
>
> Can it still be failover to ISP A automatically?
>
> If it won't work, Do you have any suggestion?
>
> Thank you for your help
>

Ann,

I've done this for a few customers that have requested it. Some engineers
complain that advertising /24 routes dilutes the Internet routing tables,
which is true in some regards.  However, this does work in many situations
to "balance" things out.

Check out my blog post that walks through this procedure:
http://mattreath.com/2012/01/29/bgp-load-balancing/

-Matt


--
Matt Reath
CCIE #27316 (SP)
matt at mattreath.com | http://mattreath.com
Twitter: http://twitter.com/mpreath



From grupo.ipv6 at gmail.com  Sat Feb  4 06:45:21 2012
From: grupo.ipv6 at gmail.com (Grupo IPv6)
Date: Sat, 4 Feb 2012 10:45:21 -0200
Subject: Some Smokeping doubts
Message-ID: <CANuE+sDX8TD7cujDxGFv=pcFUK6tr3KqEGLiuPAD3_SQn+3TjA@mail.gmail.com>

Hi all,


I?m using Smokeping (http://oss.oetiker.ch/smokeping/) and I have some
doubs that maybe you can answer:

-          Why Smokeping needs to be connected to internet even when I have
only one Target to a host in my LAN ?

-          What is exactly the Standard deviation calculated at the bottom
right of the graphs? Can it be interpreted as Jitter? Or is there another
way to know the jitter?

-          Why sometimes when I add a new host, for the first minute I get
a list of errors saying that the RDD file doesn?t exist? This happens
commonly? Is there any way to solve this problem?

Many thanks,

Gabriel

From mysidia at gmail.com  Sat Feb  4 10:51:25 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 4 Feb 2012 10:51:25 -0600
Subject: Please help our simple bgp
In-Reply-To: <CACwqZxjBp_R_b-r-9zdB+4xSO1mPmfaYhg8nuDwnt7g2i6RXTg@mail.gmail.com>
References: <CACwqZxjBp_R_b-r-9zdB+4xSO1mPmfaYhg8nuDwnt7g2i6RXTg@mail.gmail.com>
Message-ID: <CAAAwwbWL8gZA2Pq=W+rd5uDi_o0ki1NtG0cfXFhVuHhxYqMeKg@mail.gmail.com>

On Mon, Jan 30, 2012 at 8:27 PM, Ann Kwok <annkwok80 at gmail.com> wrote:

> We discover the routes is going to ISP A only even the bandwidth 100M is
> full
>
> Can we set the weight to change to ISP B to use ISP B as preference routes?
> Can the following configuration work?
>

Tuning weights and  localpreference values can influence traffic that your
equipment sends _to_ ISP A and ISP B.   These options do not control what
incoming traffic  gets forwarded into your network _from_  ISP A or ISP
B;   you need a separate strategy for incoming bits.


The config you listed should do just what the vendor documentation says it
does, so I can't say it doesn't "work";  it just  does nothing to help
remedy the situation.

That is, if you have two ISP links each 100M full duplex;  and one of them
is at 100% outbound usage,   increasing the weight of all the other
neighbor's paths  assuming the set of prefixes received over BGP are the
same,   will mean that ISP B is the preferred next-hop for each path;
which means ISP A  outgoing utilization should drop to near 0,  and  then
ISP B  should be just as fully utilized as ISP A  is currently.



You could instead identify some specific paths that are heavy users or
would carry a high percentage of the outgoing traffic,   and  use
filters/route maps  to  adjust local preference  of specific paths,  to
take outgoing load off ISP A.

or  increase the weight for 128.0.0.0/1   on routes received from ISP B,
and allow your outgoing traffic  to rest of the address space  to utilize
ISP A, for example.


But the preferred fix for this problem would be to upgrade ISP A and ISP B
links to at least double their current capacity.



Weight is a vendor-specific parameter,  local to your router.  I would
consider increasing the default local preference for ISP A first, by the
way,


But as long as you only have one router on which ISP A and ISP B sessions
land,
when you have an identical prefix from ISP A and B,  the outgoing path
through
ISP B  is to be preferred by your local router,  if the path has a higher
weight.



"  What suggest to this weight no. too? "

With weights the magnitude of the numbers and the numerical difference
between weights is not significant;  it just matters if one path has a
higher weight, or both paths have equal weight.

I would suggest weights that are uniformly spaced apart and easy to
remember, e.g. 100 200 300 400.    When you want to add  ISP C  later,  you
will also have flexibility  without re-assigning your existing weights.


If this works, how is ISP B upstream connection is down?
>
> Can it still be failover to ISP A automatically?
>
> If it won't work, Do you have any suggestion?
>
> Thank you for your help
>



-- 
-JH

From mike-nanog at tiedyenetworks.com  Sat Feb  4 13:08:18 2012
From: mike-nanog at tiedyenetworks.com (Mike)
Date: Sat, 04 Feb 2012 11:08:18 -0800
Subject: bgp history lookup tool?
Message-ID: <4F2D8222.5000304@tiedyenetworks.com>

Hi,

I am trying to diagnose an event yesterday where our provider appears to 
have dropped our routes and we were inaccessible from outside our 
provider. I thought somewhere someone was keeping a searchable database 
of bgp announce/withdrawals and it would be useful to have a peek and 
see if any such event concerning our prefix/as was seen anywhere.

Mike-


From morrowc.lists at gmail.com  Sat Feb  4 13:10:50 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 4 Feb 2012 14:10:50 -0500
Subject: bgp history lookup tool?
In-Reply-To: <4F2D8222.5000304@tiedyenetworks.com>
References: <4F2D8222.5000304@tiedyenetworks.com>
Message-ID: <CAL9jLaakqMHFgF2vnpbE8tNQKse4A2dAqdL6FvAWHKyEcm3ntQ@mail.gmail.com>

ris.ripe.net

bgpplay.routeviews.org ?

On Sat, Feb 4, 2012 at 2:08 PM, Mike <mike-nanog at tiedyenetworks.com> wrote:
> Hi,
>
> I am trying to diagnose an event yesterday where our provider appears to
> have dropped our routes and we were inaccessible from outside our provider.
> I thought somewhere someone was keeping a searchable database of bgp
> announce/withdrawals and it would be useful to have a peek and see if any
> such event concerning our prefix/as was seen anywhere.
>
> Mike-
>


From prt at prt.org  Sat Feb  4 13:12:47 2012
From: prt at prt.org (Paul Thornton)
Date: Sat, 04 Feb 2012 19:12:47 +0000
Subject: bgp history lookup tool?
In-Reply-To: <4F2D8222.5000304@tiedyenetworks.com>
References: <4F2D8222.5000304@tiedyenetworks.com>
Message-ID: <4F2D832F.9020402@prt.org>

On 04/02/2012 19:08, Mike wrote:
> Hi,
> 
> I am trying to diagnose an event yesterday where our provider appears to
> have dropped our routes and we were inaccessible from outside our
> provider. I thought somewhere someone was keeping a searchable database
> of bgp announce/withdrawals and it would be useful to have a peek and
> see if any such event concerning our prefix/as was seen anywhere.

RIPE's RIS does this - http://ris.ripe.net

Paul.


From eric at roxanne.org  Sun Feb  5 14:21:58 2012
From: eric at roxanne.org (Eric Gauthier)
Date: Sun, 5 Feb 2012 15:21:58 -0500
Subject: ISP access in Hebron, KY
Message-ID: <20120205202158.GA15605@roxanne.org>

Hello,

We're looking for DIA in the 20 - 50mbps range for a
warehouse we have in Hebron, KY.  CinBell has been a
bit "slow" to respond to our DS3 requets, so I'm 
wondering who else in town has their own facilities
(also wondering who might be a good for a backup 
circuit)?

Thanks!

Eric :)


From jra at baylink.com  Sun Feb  5 14:29:07 2012
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 5 Feb 2012 15:29:07 -0500 (EST)
Subject: Super Sunday
Message-ID: <28660078.796.1328473747740.JavaMail.root@benjamin.baylink.com>

What, no whacky weekend thread?

NBC and the NFL are, for the first time, televising the Super Bowl and its
preshow on the Internet... using a Silverlight app (so I hope you Linux people
don't enjoy football).

It's supposed to be available to tablets too, as a second-screen cast with 
selectable angles and such, but Verizontal has an exclusive on mobile, so the
target page should bounce cellphones, unless a) they lie or b) they weren't 
smart enough to IP block the carrier ranges.

  http://mashable.com/2012/02/04/watch-super-bowl-xlvi-online/

It will be interesting to see how this works out.  

Enjoy the game.  Especially if you have a Big Wall to watch it on.

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


From dave at temk.in  Sun Feb  5 12:21:27 2012
From: dave at temk.in (Dave Temkin)
Date: Sun, 05 Feb 2012 13:21:27 -0500
Subject: [NANOG-announce] Tutorials starting today, some available via webcast!
Message-ID: <4F2EC8A7.1030602@temk.in>

For the first time, NANOG will be webcasting (and archiving) some of our tutorials.

Beginning at 2PM PT, you can see John Kristoff give an Introduction to Shell and Perl Scripting for Network 
Operators, with a break from 3:30-4 and then starting back at 4PM PT with Intermediate Perl Scripting for 
Network Operators.  Both tutorials will be available later for review.

You may see all streaming options at http://www.nanog.org/streaming.php

-Dave Temkin
For the NANOG Program Committee

_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce


From rgasnick at milestechnologies.com  Sun Feb  5 17:36:13 2012
From: rgasnick at milestechnologies.com (Ray Gasnick III)
Date: Sun, 5 Feb 2012 18:36:13 -0500
Subject: UDP port 80 DDoS attack
Message-ID: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>

We just saw a huge flux of traffic occur this morning that spiked one of our upstream ISPs gear and killed the layer 2 link on another becuase of a DDoS attack on UDP port 80.



Wireshark shows this appears to be from a compromised game server (call of duty) with source IPs in a variety of different prefixes.



Only solution thus far was to dump the victim IP address in our block into the BGP Black hole community with one of our 2 providers and completely stop advertising to the other.



Anybody see this recently and have any tips on mitigation,  reply on or off list.



Thank You,

Ray Gasnick III
CISSP, Technology Specialist: Network Security & Infrastructure
Miles Technologies
www.milestechnologies.com<http://www.milestechnologies.com/>

Phone: (856) 439-0999 x127
Direct: (856) 793-3821
How am I doing?  Email my manager at itmanager at milestechnologies.com<mailto:itmanager at milestechnologies.com>

Computer Networking ? IT Support ? Business Software ? Website Design ? Online Marketing & PR


From j at arpa.com  Sun Feb  5 17:48:51 2012
From: j at arpa.com (jamie rishaw)
Date: Sun, 5 Feb 2012 17:48:51 -0600
Subject: Superbowl traffic.
Message-ID: <CABL6YZQuvHfmH_OSmfAkxwtAcbnSTQm4PFXcmeYOtWOxVZPAdQ@mail.gmail.com>

(yeah, i used a (C) term , so sue me)

akam reporting ~17M hits/sec..
anyone seeing clearly identifiable traffic spikes (presumably due to sb)?

reply offlist if you want to submit data but don't want to be outed as
divulging corp info, but graphs and/or raw datars would be awesome
sauce. data will be aggregated/anonymized unless requested otherwise.

? ? ? ? ? ? ? ?^^ yes, you can configure your router for awesomesauce.
 so HDICMRFT flak will be nulled.  :-p

-j
-- 
"sharp, dry wit; brash in his dealings" - Forbes

X-Ob-Zing: "it's very hard not to be condescending when you're
explaining..to an idiot." -BMaher
/*     - teh jamie. ;     uri -> http://about.me/jgr     */


From fredrik at i2b.se  Sun Feb  5 17:47:11 2012
From: fredrik at i2b.se (Fredrik Holmqvist / I2B)
Date: Mon, 06 Feb 2012 00:47:11 +0100
Subject: UDP port 80 DDoS attack
In-Reply-To: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
Message-ID: <273be36298d3b47f04ef10bab7c38112@imap>

Hi.

We had a customer that was attacked by the same "game server feature".
We received aprox 10 Gbit of traffic against the customer.

The attacker sends spoofed packets to the game server with the target
IP as "source", the gameserver sends replies back via UDP to the target
host. The attacker sends a couple of hundred packets per second and thus
generating a 10 Mbit UDP flood.

There is fixes/workarounds for the game servers, just a matter of the
admin taking care of it.
See: http://rankgamehosting.ru/index.php?showtopic=1320

The "attacking" IPs aren't spoofed, so just compile a list and send
e-mails to each provider.

We had 1000+ IPs gathered and sent 100+ abuse e-mails, only received
reply from less than 20%.
Sad that people care so little about mitigating DDoS/UDP/ICMP floods.


On Sun, 5 Feb 2012 18:36:13 -0500, Ray Gasnick III
<rgasnick at milestechnologies.com> wrote:
> We just saw a huge flux of traffic occur this morning that spiked one
> of our upstream ISPs gear and killed the layer 2 link on another
> becuase of a DDoS attack on UDP port 80.
> 
> 
> 
> Wireshark shows this appears to be from a compromised game server
> (call of duty) with source IPs in a variety of different prefixes.
> 
> 
> 
> Only solution thus far was to dump the victim IP address in our block
> into the BGP Black hole community with one of our 2 providers and
> completely stop advertising to the other.
> 
> 
> 
> Anybody see this recently and have any tips on mitigation,  reply on
> or off list.
> 
> 
> 
> Thank You,
> 
> Ray Gasnick III
> CISSP, Technology Specialist: Network Security & Infrastructure
> Miles Technologies
> www.milestechnologies.com<http://www.milestechnologies.com/>
> 
> Phone: (856) 439-0999 x127
> Direct: (856) 793-3821
> How am I doing?  Email my manager at
> itmanager at milestechnologies.com<mailto:itmanager at milestechnologies.com>
> 
> Computer Networking ? IT Support ? Business Software ? Website Design
> ? Online Marketing & PR

-- 
Fredrik Holmqvist
I2B (Internet 2 Business)
070-740 5033



From keegan.holley at sungard.com  Sun Feb  5 18:21:51 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Sun, 5 Feb 2012 19:21:51 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
Message-ID: <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>

There aren't very many ways to combat DDOS.  That's why it's so popular.
Some ISP's partner with a company that offers a tunnel based scrubbing
service where they DPI all your traffic before they send it to you.  If you
only have a few upstreams it may be helpful to you.  I spoke to them last
year but we have too many links and too many blocks to use it.  I think the
name of the company was prolexic.  They're also a L3 VAR if you have L3
links.  There isn't alot of BGP (AFAIK) magic that doesn't involve cutting
someone off to save the rest of your customers.

2012/2/5 Ray Gasnick III <rgasnick at milestechnologies.com>

> We just saw a huge flux of traffic occur this morning that spiked one of
> our upstream ISPs gear and killed the layer 2 link on another becuase of a
> DDoS attack on UDP port 80.
>
>
>
> Wireshark shows this appears to be from a compromised game server (call of
> duty) with source IPs in a variety of different prefixes.
>
>
>
> Only solution thus far was to dump the victim IP address in our block into
> the BGP Black hole community with one of our 2 providers and completely
> stop advertising to the other.
>
>
>
> Anybody see this recently and have any tips on mitigation,  reply on or
> off list.
>
>
>
> Thank You,
>
> Ray Gasnick III
> CISSP, Technology Specialist: Network Security & Infrastructure
> Miles Technologies
> www.milestechnologies.com<http://www.milestechnologies.com/>
>
> Phone: (856) 439-0999 x127
> Direct: (856) 793-3821
> How am I doing?  Email my manager at itmanager at milestechnologies.com
> <mailto:itmanager at milestechnologies.com>
>
> Computer Networking ? IT Support ? Business Software ? Website Design ?
> Online Marketing & PR
>
>
>

From mpalmer at hezmatt.org  Sun Feb  5 18:30:39 2012
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Mon, 6 Feb 2012 11:30:39 +1100
Subject: UDP port 80 DDoS attack
In-Reply-To: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
Message-ID: <20120206003039.GZ11857@hezmatt.org>

On Sun, Feb 05, 2012 at 06:36:13PM -0500, Ray Gasnick III wrote:
> We just saw a huge flux of traffic occur this morning that spiked one of
> our upstream ISPs gear and killed the layer 2 link on another becuase of a
> DDoS attack on UDP port 80.

Yep, we've got a customer who's been hit with it a couple of times (5Gbps
the first time, 3Gbps the second).  For hysterical raisins, we don't
actually control the network for this particular customer, but the network
provider did pretty much what you did -- blackholed the victim IP.  We've
mitigated the problem by using a full-time traffic-scrubbing service -- the
hope is that the scrubbing service will pay for all the traffic and only the
good stuff will get through.  Only time will tell if it works.  We also had
to renumber the customer, as the attacks were obviously remembering the old
IP and still knocking it off the network even after the DNS was repointed at
the scrubbing service.

- Matt

-- 
"I'm tempted to try Gentoo, but then I learned that its installer is in
Python, and, well, a base Python install on my system is something like
fifty megabytes (for what?  oh, right, we NEED four XML libraries, I
forgot)."  -- Dave Brown, ASR



From rdobbins at arbor.net  Sun Feb  5 18:58:50 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 6 Feb 2012 00:58:50 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
Message-ID: <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>


On Feb 6, 2012, at 7:21 AM, Keegan Holley wrote:

> There aren't very many ways to combat DDOS. 

Start with the various infrastructure/host/service BCPs, and S/RTBH, as outlined in this preso:

<https://files.me.com/roland.dobbins/dweagy>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From tvhawaii at shaka.com  Sun Feb  5 18:59:46 2012
From: tvhawaii at shaka.com (Michael Painter)
Date: Sun, 5 Feb 2012 14:59:46 -1000
Subject: Super Sunday
References: <28660078.796.1328473747740.JavaMail.root@benjamin.baylink.com>
Message-ID: <A35872790F4D45119C1BC224552BE35F@owner59e1f1502>

Jay Ashworth wrote:
> What, no whacky weekend thread?
> 
> NBC and the NFL are, for the first time, televising the Super Bowl and its
> preshow on the Internet... using a Silverlight app (so I hope you Linux people
> don't enjoy football).
> 
> It's supposed to be available to tablets too, as a second-screen cast with
> selectable angles and such, but Verizontal has an exclusive on mobile, so the
> target page should bounce cellphones, unless a) they lie or b) they weren't
> smart enough to IP block the carrier ranges.
> 
>  http://mashable.com/2012/02/04/watch-super-bowl-xlvi-online/
> 
> It will be interesting to see how this works out.
> 
> Enjoy the game.  Especially if you have a Big Wall to watch it on.
> 
> Cheers,
> -- jr 'we want pictures' a


Halftime observations from 72.253.0.0/16:

On Vizio 37" 1080p display:
Local NBC affiliate via off-air antenna= flawless 720p picture.
Local NBC affiliate re-broadcast via Dish Network=flawless 1080i picture.
Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i picture.

On Samsung 23" 1080p monitor via Dell 2.8GHz GX270 with 7Mbps down:
Low resolution (appears to be less than VHS), sometimes jerky, picture.






From jra at baylink.com  Sun Feb  5 19:03:57 2012
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 5 Feb 2012 20:03:57 -0500 (EST)
Subject: Super Sunday
In-Reply-To: <A35872790F4D45119C1BC224552BE35F@owner59e1f1502>
Message-ID: <25630107.824.1328490237846.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Michael Painter" <tvhawaii at shaka.com>

> On Vizio 37" 1080p display:
> Local NBC affiliate via off-air antenna= flawless 720p picture.
> Local NBC affiliate re-broadcast via Dish Network=flawless 1080i
> picture.
> Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i
> picture.

I don't suppose you have the MPEG bitrates on those... :-)

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


From keegan.holley at sungard.com  Sun Feb  5 19:10:39 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Sun, 5 Feb 2012 20:10:39 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
Message-ID: <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>

An entire power point just to recommend ACL's, uRPF, CPP, DHCP snooping,
and RTBH?  The first four will not work against a DDOS attack and the last
one just kills the patient so he does not infect other patients.  As I said
earlier beyond traffic scrubbing offsite there isn't much defense against
DDOS.

2012/2/5 Dobbins, Roland <rdobbins at arbor.net>

>
> On Feb 6, 2012, at 7:21 AM, Keegan Holley wrote:
>
> > There aren't very many ways to combat DDOS.
>
> Start with the various infrastructure/host/service BCPs, and S/RTBH, as
> outlined in this preso:
>
> <https://files.me.com/roland.dobbins/dweagy>
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>                The basis of optimism is sheer terror.
>
>                          -- Oscar Wilde
>
>
>
>

From rdobbins at arbor.net  Sun Feb  5 19:20:11 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 6 Feb 2012 01:20:11 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
Message-ID: <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>


On Feb 6, 2012, at 8:10 AM, Keegan Holley wrote:

> An entire power point just to recommend ACL's, uRPF, CPP, DHCP snooping, and RTBH?

Actually, no, that isn't the focus of the preso.

> The first four will not work against a DDOS attack

This is incorrect - suggest you read the preso.

> and the last one just kills the patient so he does not infect other patients. 

S/RTBH - as opposed to D/RTBH - doesn't kill the patient.  Again, suggest you read the preso.

There's been a lot of discussion on this topic on NANOG, suggest you take a look through the archives.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From glen.kent at gmail.com  Sun Feb  5 19:20:54 2012
From: glen.kent at gmail.com (Glen Kent)
Date: Mon, 6 Feb 2012 06:50:54 +0530
Subject: Optimal IPv6 router
Message-ID: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>

Hi,

Most routers today are basically IPv4 routers, with IPv6 thrown in.
They are however designed keeping IPv4 in mind.

With IPv6 growing, if we were to design a native IPv6 router, with
IPv4 functionality thrown in, then is it possible to design a more
optimal IPv6 router, than what exists today?

Glen


From rdobbins at arbor.net  Sun Feb  5 19:22:38 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 6 Feb 2012 01:22:38 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
Message-ID: <0793C62F-214E-4105-885E-469562751463@arbor.net>


On Feb 6, 2012, at 8:20 AM, Dobbins, Roland wrote:

> Actually, no, that isn't the focus of the preso.

More info here:

<https://files.me.com/roland.dobbins/l53gjr>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From tvhawaii at shaka.com  Sun Feb  5 19:23:51 2012
From: tvhawaii at shaka.com (Michael Painter)
Date: Sun, 5 Feb 2012 15:23:51 -1000
Subject: Super Sunday
References: <25630107.824.1328490237846.JavaMail.root@benjamin.baylink.com>
Message-ID: <B1FA751D3847460B96D2DE8DD7A4961C@owner59e1f1502>

Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Michael Painter" <tvhawaii at shaka.com>
>
>> On Vizio 37" 1080p display:
>> Local NBC affiliate via off-air antenna= flawless 720p picture.
>> Local NBC affiliate re-broadcast via Dish Network=flawless 1080i
>> picture.
>> Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i
>> picture.
>
> I don't suppose you have the MPEG bitrates on those... :-)
>
> Cheers,
> -- jra

No, but that's my next project.  I just received the ATSC dongle from AVerMedia.

Getting the SuperBowl in HD (and the house-sound in sync) to all 32 displays at the sportsbar has been a challenge, but we 
made it with 2 hours to spare.<g>

Best,

--Michael 



From mike.lyon at gmail.com  Sun Feb  5 19:27:52 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Sun, 5 Feb 2012 17:27:52 -0800
Subject: Super Sunday
In-Reply-To: <B1FA751D3847460B96D2DE8DD7A4961C@owner59e1f1502>
References: <25630107.824.1328490237846.JavaMail.root@benjamin.baylink.com>
 <B1FA751D3847460B96D2DE8DD7A4961C@owner59e1f1502>
Message-ID: <-3886999636273882100@unknownmsgid>

Sent from my iPhone

On Feb 5, 2012, at 17:24, Michael Painter <tvhawaii at shaka.com> wrote:

> Jay Ashworth wrote:
>> ----- Original Message -----
>>> From: "Michael Painter" <tvhawaii at shaka.com>
>>
>>> On Vizio 37" 1080p display:
>>> Local NBC affiliate via off-air antenna= flawless 720p picture.
>>> Local NBC affiliate re-broadcast via Dish Network=flawless 1080i
>>> picture.
>>> Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i
>>> picture.
>>
>> I don't suppose you have the MPEG bitrates on those... :-)
>>
>> Cheers,
>> -- jra
>
> No, but that's my next project.  I just received the ATSC dongle from AVerMedia.
>
> Getting the SuperBowl in HD (and the house-sound in sync) to all 32 displays at the sportsbar has been a challenge, but we made it with 2 hours to spare.<g>
>
> Best,
>
> --Michael
>

What gear were you using for the sports bar?

-mike


From keegan.holley at sungard.com  Sun Feb  5 19:37:34 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Sun, 5 Feb 2012 20:37:34 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
Message-ID: <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>

2012/2/5 Dobbins, Roland <rdobbins at arbor.net>

>
> On Feb 6, 2012, at 8:10 AM, Keegan Holley wrote:
>
> > An entire power point just to recommend ACL's, uRPF, CPP, DHCP snooping,
> and RTBH?
>
> Actually, no, that isn't the focus of the preso.
>
> > The first four will not work against a DDOS attack
>
> This is incorrect - suggest you read the preso.
>

The ACL's are configured on the routers belonging to the victim AS which
will not save their access pipe if it's overrun unless I'm missing
something.  uRPF may help with spoofed traffic, but sometimes causes
problems with multi-homing and is often more harmful than helpful depending
on the network design.

>
> > and the last one just kills the patient so he does not infect other
> patients.
>
> S/RTBH - as opposed to D/RTBH - doesn't kill the patient.  Again, suggest
> you read the preso.
>

Source RTBH often falls victim to rapidly changing or spoofed source IP"s.
It also isn't as widely supported as it should be. I never said DDOS was
hopeless, there just aren't a wealth of defenses against it.

From rdobbins at arbor.net  Sun Feb  5 19:43:52 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 6 Feb 2012 01:43:52 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
Message-ID: <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>


On Feb 6, 2012, at 8:37 AM, Keegan Holley wrote:

> Source RTBH often falls victim to rapidly changing or spoofed source IP"s. 

S/RTBH can be rapidly shifted in order to deal with changing purported source IPs, and it isn't limited to /32s.  It's widely supported on Cisco and Juniper gear (flowspec is a better choice on Juniper gear).

If folks don't want to read the presos or search through the archives, that's fine, of course.  The fact is that there are quite a few things that operators can and should do in order to mitigate DDoS attacks; and making the perfect the enemy of the merely good only helps the attackers, doesn't it?

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From tvhawaii at shaka.com  Sun Feb  5 19:47:03 2012
From: tvhawaii at shaka.com (Michael Painter)
Date: Sun, 5 Feb 2012 15:47:03 -1000
Subject: Super Sunday
References: <25630107.824.1328490237846.JavaMail.root@benjamin.baylink.com>
 <B1FA751D3847460B96D2DE8DD7A4961C@owner59e1f1502>
 <-3886999636273882100@unknownmsgid>
Message-ID: <6A32CE5ECA4543018459FEDAC15C2084@owner59e1f1502>

Mike Lyon wrote:
> Sent from my iPhone
>
> On Feb 5, 2012, at 17:24, Michael Painter <tvhawaii at shaka.com> wrote:
>
>> Jay Ashworth wrote:
>>> ----- Original Message -----
>>>> From: "Michael Painter" <tvhawaii at shaka.com>
>>>
>>>> On Vizio 37" 1080p display:
>>>> Local NBC affiliate via off-air antenna= flawless 720p picture.
>>>> Local NBC affiliate re-broadcast via Dish Network=flawless 1080i
>>>> picture.
>>>> Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i
>>>> picture.
>>>
>>> I don't suppose you have the MPEG bitrates on those... :-)
>>>
>>> Cheers,
>>> -- jra
>>
>> No, but that's my next project.  I just received the ATSC dongle from AVerMedia.
>>
>> Getting the SuperBowl in HD (and the house-sound in sync) to all 32 displays at the sportsbar has been a challenge, but 
>> we made
>> it with 2 hours to spare.<g>
>>
>> Best,
>>
>> --Michael
>>
>
> What gear were you using for the sports bar?
>
> -mike

I'm integrating the b520 modulator(s) into our exisiting 16 Ch. analog system.  Works great.
http://www.zeevee.com/hdbridge



From keegan.holley at sungard.com  Sun Feb  5 19:50:23 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Sun, 5 Feb 2012 20:50:23 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
Message-ID: <CABO8Q6RttiH6NjsTwKpq_8ZCaN8fdOwjYJAYnkRH+GR5k0grVg@mail.gmail.com>

2012/2/5 Dobbins, Roland <rdobbins at arbor.net>

>
> On Feb 6, 2012, at 8:37 AM, Keegan Holley wrote:
>
> > Source RTBH often falls victim to rapidly changing or spoofed source
> IP"s.
>
> S/RTBH can be rapidly shifted in order to deal with changing purported
> source IPs, and it isn't limited to /32s.  It's widely supported on Cisco
> and Juniper gear (flowspec is a better choice on Juniper gear).
>
> I was referring to support from ISP's not from hardware vendors.

If folks don't want to read the presos or search through the archives,
> that's fine, of course.  The fact is that there are quite a few things that
> operators can and should do in order to mitigate DDoS attacks; and making
> the perfect the enemy of the merely good only helps the attackers, doesn't
> it?
>
> Yes but assuming everything discussed at a conference is instantly adopted
by the entire industry gives one false hope no?

From rdobbins at arbor.net  Sun Feb  5 19:54:01 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 6 Feb 2012 01:54:01 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6RttiH6NjsTwKpq_8ZCaN8fdOwjYJAYnkRH+GR5k0grVg@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CABO8Q6RttiH6NjsTwKpq_8ZCaN8fdOwjYJAYnkRH+GR5k0grVg@mail.gmail.com>
Message-ID: <B65E1D8C-B8D2-468C-B6E5-D6519F1B4AC6@arbor.net>


On Feb 6, 2012, at 8:50 AM, Keegan Holley wrote:

> Yes but assuming everything discussed at a conference is instantly adopted by the entire industry gives one false hope no?

I'm certainly not making that assumption - hence the presos.

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From joelja at bogus.com  Sun Feb  5 20:01:41 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Sun, 05 Feb 2012 18:01:41 -0800
Subject: Optimal IPv6 router
In-Reply-To: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
Message-ID: <4F2F3485.2020503@bogus.com>

On 2/5/12 17:20 , Glen Kent wrote:
> Hi,
> 
> Most routers today are basically IPv4 routers, with IPv6 thrown in.
> They are however designed keeping IPv4 in mind.
> 
> With IPv6 growing, if we were to design a native IPv6 router, with
> IPv4 functionality thrown in, then is it possible to design a more
> optimal IPv6 router, than what exists today?

Asic based forwarding engines with ipv6 support are more than a decade
old at this point.

If one looks at an asr9000 or an MX or T that looks like an ipv6 router
to me.

> Glen
> 



From Valdis.Kletnieks at vt.edu  Sun Feb  5 20:07:57 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 05 Feb 2012 21:07:57 -0500
Subject: Optimal IPv6 router
In-Reply-To: Your message of "Mon, 06 Feb 2012 06:50:54 +0530."
 <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
Message-ID: <107963.1328494077@turing-police.cc.vt.edu>

On Mon, 06 Feb 2012 06:50:54 +0530, Glen Kent said:

> Most routers today are basically IPv4 routers, with IPv6 thrown in.
Not sure if this statement is troll bait or flame bate. Probably both. ;)

I see Joel has already confirmed my memory that vendors had ASICs
doing IPv6 forwarding last century.

> With IPv6 growing, if we were to design a native IPv6 router, with
> IPv4 functionality thrown in, then is it possible to design a more
> optimal IPv6 router, than what exists today?

OK, I'll bite.  What would qualify as a "native IPv6" router?  Is this
another concept as silly as "hardware vs software based" routers?

And whaqt would be the definition of "more optimal"?  Just fixing
the current feature parity mismatch with the IPv4 side, or you got
some new routing paradigm in mind or something?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120205/9bf86740/attachment.bin>

From mike.lyon at gmail.com  Sun Feb  5 20:20:40 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Sun, 5 Feb 2012 18:20:40 -0800
Subject: Super Sunday
In-Reply-To: <6A32CE5ECA4543018459FEDAC15C2084@owner59e1f1502>
References: <25630107.824.1328490237846.JavaMail.root@benjamin.baylink.com>
 <B1FA751D3847460B96D2DE8DD7A4961C@owner59e1f1502>
 <-3886999636273882100@unknownmsgid>
 <6A32CE5ECA4543018459FEDAC15C2084@owner59e1f1502>
Message-ID: <-2382828026831401363@unknownmsgid>

When i did a sports bar of about 24 HD TVs, i used gear from here:

http://www.neoprointegrator.com/products.php

Good product, good support.

-mike

Sent from my iPhone

On Feb 5, 2012, at 17:47, Michael Painter <tvhawaii at shaka.com> wrote:

> Mike Lyon wrote:
>> Sent from my iPhone
>>
>> On Feb 5, 2012, at 17:24, Michael Painter <tvhawaii at shaka.com> wrote:
>>
>>> Jay Ashworth wrote:
>>>> ----- Original Message -----
>>>>> From: "Michael Painter" <tvhawaii at shaka.com>
>>>>
>>>>> On Vizio 37" 1080p display:
>>>>> Local NBC affiliate via off-air antenna= flawless 720p picture.
>>>>> Local NBC affiliate re-broadcast via Dish Network=flawless 1080i
>>>>> picture.
>>>>> Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i
>>>>> picture.
>>>>
>>>> I don't suppose you have the MPEG bitrates on those... :-)
>>>>
>>>> Cheers,
>>>> -- jra
>>>
>>> No, but that's my next project.  I just received the ATSC dongle from AVerMedia.
>>>
>>> Getting the SuperBowl in HD (and the house-sound in sync) to all 32 displays at the sportsbar has been a challenge, but we made
>>> it with 2 hours to spare.<g>
>>>
>>> Best,
>>>
>>> --Michael
>>>
>>
>> What gear were you using for the sports bar?
>>
>> -mike
>
> I'm integrating the b520 modulator(s) into our exisiting 16 Ch. analog system.  Works great.
> http://www.zeevee.com/hdbridge
>


From mohta at necom830.hpcl.titech.ac.jp  Sun Feb  5 20:52:30 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 06 Feb 2012 11:52:30 +0900
Subject: Optimal IPv6 router
In-Reply-To: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
Message-ID: <4F2F406E.5060205@necom830.hpcl.titech.ac.jp>

Glen Kent wrote:

> With IPv6 growing, if we were to design a native IPv6 router, with
> IPv4 functionality thrown in, then is it possible to design a more
> optimal IPv6 router, than what exists today?

It depends on what you want routers to do.

As I am working on Tbps photonic routers with fiber delay lines,
the bottleneck is at constant time (nano seconds order) electric
route look up.

There, several simple 4M*16bit SRAMs is fine for IPv4 with mostly
/24 routing table entries.

IPv6 was better because TLA had was merely 13bit long with only
8192 entries.

However, as the idea of TLA was abandoned long before and a lot
more than /24 is, seemingly, necessary for route look up of IPv6
backbone, I'm afraid IPv6 needs large amount of power consuming
content addressable memories.

Without any (defacto) standard prefix length at the IPv6 backbone,
it is simply impossible to say "optimal".

						Masataka Ohta


From steve.bertrand at gmail.com  Sun Feb  5 21:08:19 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Sun, 05 Feb 2012 22:08:19 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
Message-ID: <4F2F4423.8040803@gmail.com>

On 2012.02.05 20:37, Keegan Holley wrote:
> 2012/2/5 Dobbins, Roland<rdobbins at arbor.net>

>> S/RTBH - as opposed to D/RTBH - doesn't kill the patient.  Again, suggest
>> you read the preso.
>>
>
> Source RTBH often falls victim to rapidly changing or spoofed source IP"s.
> It also isn't as widely supported as it should be. I never said DDOS was
> hopeless, there just aren't a wealth of defenses against it.

This is so very easily automated. Even if you don't actually want to 
trigger the routes automatically, finding the sources you want to 
blackhole is as simple as a monitor port, tcpdump and some basic Perl.

...and as far as this not having been deployed in many ISPs (per your 
next message)... their mitigation strategies should be asked up front, 
and if they don't have any (or don't know what you speak of), find a new 
ISP.

Steve


From tvhawaii at shaka.com  Sun Feb  5 21:23:44 2012
From: tvhawaii at shaka.com (Michael Painter)
Date: Sun, 5 Feb 2012 17:23:44 -1000
Subject: Super Sunday
References: <25630107.824.1328490237846.JavaMail.root@benjamin.baylink.com>
 <B1FA751D3847460B96D2DE8DD7A4961C@owner59e1f1502>
 <-3886999636273882100@unknownmsgid>
 <6A32CE5ECA4543018459FEDAC15C2084@owner59e1f1502>
 <-2382828026831401363@unknownmsgid>
Message-ID: <BD06F18B23A446E18FD743072E68618E@owner59e1f1502>

Mike Lyon wrote:
> When i did a sports bar of about 24 HD TVs, i used gear from here:
> 
> http://www.neoprointegrator.com/products.php
> 
> Good product, good support.
> 
> -mike


Looks like a well designed product...Thanks!

Any idea of what the 'Tahoe' costs (we have 16 sources)? 

--Michael


From keegan.holley at sungard.com  Sun Feb  5 21:30:20 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Sun, 5 Feb 2012 22:30:20 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <4F2F4423.8040803@gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <4F2F4423.8040803@gmail.com>
Message-ID: <CABO8Q6TcybzxOBzuab2dxqWecKOU37dGcDaJ1hqWfgF9dAZG2g@mail.gmail.com>

2012/2/5 Steve Bertrand <steve.bertrand at gmail.com>

> On 2012.02.05 20:37, Keegan Holley wrote:
>
>> 2012/2/5 Dobbins, Roland<rdobbins at arbor.net>
>>
>
>  S/RTBH - as opposed to D/RTBH - doesn't kill the patient.  Again, suggest
>>> you read the preso.
>>>
>>>
>> Source RTBH often falls victim to rapidly changing or spoofed source IP"s.
>> It also isn't as widely supported as it should be. I never said DDOS was
>> hopeless, there just aren't a wealth of defenses against it.
>>
>
> This is so very easily automated. Even if you don't actually want to
> trigger the routes automatically, finding the sources you want to blackhole
> is as simple as a monitor port, tcpdump and some basic Perl.
>

This is still vulnerable to spoofing which could cause you to filter
legitimate traffic and make the problem worse.  Not saying that S/RTBH is a
bad idea.  RTBH is effective and a great idea just not very elegant.


>
> ...and as far as this not having been deployed in many ISPs (per your next
> message)... their mitigation strategies should be asked up front, and if
> they don't have any (or don't know what you speak of), find a new ISP.
>

You sometimes have to weigh the pro's and cons.  You can't always pick the
guys with the coolest knobs.

From steve.bertrand at gmail.com  Sun Feb  5 21:40:19 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Sun, 05 Feb 2012 22:40:19 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6TcybzxOBzuab2dxqWecKOU37dGcDaJ1hqWfgF9dAZG2g@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <4F2F4423.8040803@gmail.com>
 <CABO8Q6TcybzxOBzuab2dxqWecKOU37dGcDaJ1hqWfgF9dAZG2g@mail.gmail.com>
Message-ID: <4F2F4BA3.6080305@gmail.com>

On 2012.02.05 22:30, Keegan Holley wrote:
  > 2012/2/5 Steve Bertrand <steve.bertrand at gmail.com
>     On 2012.02.05 20 <tel:2012.02.05%2020>:37, Keegan Holley wrote:
>         Source RTBH often falls victim to rapidly changing or spoofed
>         source IP"s.
>         It also isn't as widely supported as it should be. I never said
>         DDOS was
>         hopeless, there just aren't a wealth of defenses against it.
>
>
>     This is so very easily automated. Even if you don't actually want to
>     trigger the routes automatically, finding the sources you want to
>     blackhole is as simple as a monitor port, tcpdump and some basic Perl.
>
>
> This is still vulnerable to spoofing which could cause you to filter
> legitimate traffic and make the problem worse.  Not saying that S/RTBH
> is a bad idea.  RTBH is effective and a great idea just not very elegant.

Agreed. Diligence does play a role. However, the times I have 
implemented and used (s/)RTBH, I thought it was most elegant. I love its 
simplicity and effectiveness.

>     ...and as far as this not having been deployed in many ISPs (per
>     your next message)... their mitigation strategies should be asked up
>     front, and if they don't have any (or don't know what you speak of),
>     find a new ISP.
>
>
> You sometimes have to weigh the pro's and cons.  You can't always pick
> the guys with the coolest knobs.

Agreed. But to me, DDOS mitigation is not just a cool knob. If my ISP 
can help mitigate a 1Gb onslaught so my 100Mb pipe isn't overwhelmed, 
that's more functional than cool. Ranks right up there with IPv6 ;)

Steve


From mtinka at globaltransit.net  Sun Feb  5 22:19:43 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 12:19:43 +0800
Subject: Hijacked Network Ranges
In-Reply-To: <CAG9TQPmSMVZ9NoL5JBFx8uLuzRn2GPogc8zsBBtdrGu6bMptJQ@mail.gmail.com>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <CANEysbH_n5SCCtvyv80aJQqNxN6kNJiVF_UADFu+0tQcUfEq1g@mail.gmail.com>
 <CAG9TQPmSMVZ9NoL5JBFx8uLuzRn2GPogc8zsBBtdrGu6bMptJQ@mail.gmail.com>
Message-ID: <201202061219.47007.mtinka@globaltransit.net>

On Wednesday, February 01, 2012 02:57:46 AM Tony McCrory 
wrote:

> Surely something is better than nothing.  Advertise the
> /24's and the /25's, see what happens.

The fact that the hijacking ISP's upstreams accepted routes 
through their network that didn't belong to that ISP is bad 
enough.

That we should still be able to advertise anything without 
an appropriate filter being in place and expecting it to 
work (even if it's with good intention, as in this case) is 
equally as bad.

A big fail to our community, for up to this day, not 
implementing basic routing and forwarding filters that would 
do away with all this cruft in the first place.

Clearly the Youtube/Pakistan/PCCW incident has long been 
forgotten.

But that's life, I guess...

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/072dee90/attachment.bin>

From ops.lists at gmail.com  Sun Feb  5 22:26:51 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Mon, 6 Feb 2012 09:56:51 +0530
Subject: Hijacked Network Ranges
In-Reply-To: <201202061219.47007.mtinka@globaltransit.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <CANEysbH_n5SCCtvyv80aJQqNxN6kNJiVF_UADFu+0tQcUfEq1g@mail.gmail.com>
 <CAG9TQPmSMVZ9NoL5JBFx8uLuzRn2GPogc8zsBBtdrGu6bMptJQ@mail.gmail.com>
 <201202061219.47007.mtinka@globaltransit.net>
Message-ID: <CAArzuosbONqwXhW4ozv8_Ry90RiPbuO7CiWymM4Be9epKvZEjg@mail.gmail.com>

I had this happen to me in 2008 -
http://www.gossamer-threads.com/lists/nanog/users/110097
Total pain in the ass when it does happen.  Funnily enough in that
case it was another downstream of the same ISP who was pulling this
stunt ..

--srs

On Mon, Feb 6, 2012 at 9:49 AM, Mark Tinka <mtinka at globaltransit.net> wrote:
>
>
> The fact that the hijacking ISP's upstreams accepted routes
> through their network that didn't belong to that ISP is bad
> enough.
>
> That we should still be able to advertise anything without
> an appropriate filter being in place and expecting it to
> work (even if it's with good intention, as in this case) is
> equally as bad.



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From mtinka at globaltransit.net  Sun Feb  5 22:49:49 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 12:49:49 +0800
Subject: Hijacked Network Ranges
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9DDF8@RWC-MBX1.corp.seven.com>
References: <CAKGDpZ75Vs+s1+1XzDjQhzswR8Y7mC7_jOuAtYjBqrJDLguXTw@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9DDF8@RWC-MBX1.corp.seven.com>
Message-ID: <201202061249.52468.mtinka@globaltransit.net>

On Wednesday, February 01, 2012 12:10:32 PM George Bonser 
wrote:

> Customer relationship with Kelvin's firm terminated and
> they contracted for service elsewhere but are apparently
> attempting to maintain the use of the address
> allocation(s) they received from Kelvin's firm.  They
> apparently did this by misrepresenting the fact that
> they were entitled to use that address space.

We've been in such situations without customers requesting 
us either to:

	a) Block certain addresses across their transit
	   links in order to mitigate DoS attacks.

	b) Announce address space which does not necessarily
	   belong to them, even though they aren't being
	   nefarious.


In either case, a quick check of the RIR WHOIS database to 
qualify consistency in information does not hurt. Yes, WHOIS 
records aren't always the most up-to-date, but it's a fairly 
good representation of the truth most of the time, 
especially since 'inetnum' objects tend to be managed by the 
RIR's themselves, last time I checked.

This is quickly making the case for RPKI.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/4fb90542/attachment.bin>

From mtinka at globaltransit.net  Sun Feb  5 23:01:20 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 13:01:20 +0800
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9E402@RWC-MBX1.corp.seven.com>
References: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9E402@RWC-MBX1.corp.seven.com>
Message-ID: <201202061301.23850.mtinka@globaltransit.net>

On Thursday, February 02, 2012 01:00:43 AM George Bonser 
wrote:

> One problem is the number of routing registries and the
> requirements differ for them.  The nefarious operator
> can enter routes in an IRR just as easily as a
> legitimate operator.  There was a time when some
> significant networks used the IRRs for their filtration
> policy.  I'm not sure how many still do.

I've dealt with AfriNIC and APNIC WHOIS databases, and they 
normally control the 'inetnum' and inet6num' entries that go 
into the WHOIS databases. So there is some degree of 
certainty that what is in there is generally true.

You're right, anyone can create an IRR record, and it's 
quite terrible how easy it is to create false information 
that could break another person's network. This is why we 
don't generally trust IRR or PeeringDB data when verifying 
downstream prefixes which we should permit through our 
filters. We rely on the RIR 'inetnum' and 'inet6num' records 
for that.

My memory fails me on what ARIN do, but before AfriNIC was 
established and the majority of Africa's prefixes were 
allocated by RIPE and ARIN, I recall the ARIN policy (SWIP 
templates, et al) being a hassle-rich experience that 
anything else is long forgotten :-).

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/c1be930d/attachment.bin>

From mtinka at globaltransit.net  Sun Feb  5 23:07:39 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 13:07:39 +0800
Subject: Hijacked Network Ranges
In-Reply-To: <CAArzuosbONqwXhW4ozv8_Ry90RiPbuO7CiWymM4Be9epKvZEjg@mail.gmail.com>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061219.47007.mtinka@globaltransit.net>
 <CAArzuosbONqwXhW4ozv8_Ry90RiPbuO7CiWymM4Be9epKvZEjg@mail.gmail.com>
Message-ID: <201202061307.39935.mtinka@globaltransit.net>

On Monday, February 06, 2012 12:26:51 PM Suresh 
Ramasubramanian wrote:

> I had this happen to me in 2008 -
> http://www.gossamer-threads.com/lists/nanog/users/110097
> Total pain in the ass when it does happen.  Funnily
> enough in that case it was another downstream of the
> same ISP who was pulling this stunt ..

Clearly the joy of running a clean network is not shared by 
all :-).

Yes, it is a little bit of extra hassle having to update 
filters when your downstreams make change requests 
(including verification, e.t.c.). But when some of our 
upstreams make us go through this, I'm much happier they do 
than they if they didn't. Some are even asking us to "fax" 
documents of such requests; a little extreme, but okay, I'll 
bite :-).

We do have some upstreams who are pretty lax about this. But 
we certainly are not, and as a result, are yet to put one of 
our customers or the Internet in jeopardy because we let one 
through the cracks.

It's 2012, we really shouldn't be seeing this type of thing 
anymore, particularly after what happened in Pakistan.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/1b01d2e1/attachment.bin>

From morrowc.lists at gmail.com  Sun Feb  5 23:14:20 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 6 Feb 2012 00:14:20 -0500
Subject: Hijacked Network Ranges
In-Reply-To: <201202061307.39935.mtinka@globaltransit.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061219.47007.mtinka@globaltransit.net>
 <CAArzuosbONqwXhW4ozv8_Ry90RiPbuO7CiWymM4Be9epKvZEjg@mail.gmail.com>
 <201202061307.39935.mtinka@globaltransit.net>
Message-ID: <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>

On Mon, Feb 6, 2012 at 12:07 AM, Mark Tinka <mtinka at globaltransit.net> wrote:

> It's 2012, we really shouldn't be seeing this type of thing
> anymore, particularly after what happened in Pakistan.

s/pakistan/pakistan,nyc(ntt),minneapolis(ntt),level3's incidents, .../

there's lots of people that have fallen victim of:
  o not having filters at all (pccw/pktel)
  o filtering using old/stale data (ntt/l3)

why aren't filters applied at all? ("its hard, people keep asking me
to update them, bah! work!")
why aren't filter data bases kept up to date? ("its hard, i have to
email something to radb/altdb/etc... bah, work!")
why aren't checks of the filter data simple and mechanical? (and
accurate?) ("Bah! work! plus, have you looked at the ouptput? bah!
work!")

resource certification would at least get us to the point where
checking the data in the IRR is 'easy', it's not going to get people
to PUT FILTERS ON CUSTOMER SESSIONS, and it's not going to get people
to update their IRR objects (add AND DELETE!!!)

-chris


From mtinka at globaltransit.net  Mon Feb  6 00:35:35 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 14:35:35 +0800
Subject: Hijacked Network Ranges
In-Reply-To: <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061307.39935.mtinka@globaltransit.net>
 <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
Message-ID: <201202061435.39053.mtinka@globaltransit.net>

On Monday, February 06, 2012 01:14:20 PM Christopher Morrow 
wrote:

>   o not having filters at all (pccw/pktel)

Well, we know what this leads to (part of the reasons you 
find some eBGP sessions carrying /25's or longer + RFC 1918 
space is because of this).

>   o filtering using old/stale data (ntt/l3)

Well, we think that this problem resolves itself rather 
well:

	o If a customer is not getting traffic hitting a
 	  prefix, they'll check with their upstream on if
	  their prefix is being received and propagated.

	o If a customer is not seeing their prefix on the
	  Internet, they'll check with their upstream on if
	  their prefix is being received and propagated.

	o If a customer starts announcing a new prefix
	  without updating their upstream, one e-mail or
	  phone call to the upstream will get this fixed.


In all cases above, it's better not to have an unauthorized 
prefix in the yonder than have open filters, because one is 
more likely to quickly get resolved without any colleteral 
than the other.

> why aren't filters applied at all? ("its hard, people
> keep asking me to update them, bah! work!")

Well, so was running the Internet without BGP communities or 
prefix lists or AS_PATH filters, until they appeared. And 
while some folk still use so-called "distribute lists" 
today, it's fine with me as long as they maintain secure 
operations with whatever solution they choose, hard or easy.

Some ISP's have automated this process either by using 
internal IRR software, or scripting web GUI's that their NOC 
can use to simply stick in the prefix, select which router 
to update, and bam!

Compared to the alternative, this is a small price to pay.

> why aren't filter data bases kept up to date? ("its hard,
> i have to email something to radb/altdb/etc... bah,
> work!")...

That's why we use the RIPE RR. They have a cool web GUI that 
you can use to edit on object, including IRR data (and 
they're respected by all other major RR's and operators):

	https://apps.db.ripe.net/webupdates/


It certainly beats the old "MAIL FROM" system, although I 
believe that is still operational.

> why aren't checks of the filter data simple and
> mechanical? (and accurate?) ("Bah! work! plus, have you
> looked at the ouptput? bah! work!")

See above.

We manually check the RIR WHOIS database. I'm sure some 
networks might automate this with an internal system that 
checks the RIR WHOIS database, and probably integrates with 
their provisioning system that can automatically create and 
update filters on routers. I don't know...

But it's certainly better than the alternative.

> resource certification would at least get us to the point
> where checking the data in the IRR is 'easy', it's not
> going to get people to PUT FILTERS ON CUSTOMER SESSIONS,
> and it's not going to get people to update their IRR
> objects (add AND DELETE!!!)

I support RPKI, but also realize that operator support will 
take a very long time for various reasons, e.g., education, 
delayed software upgrades, persistence with older methods, 
fear of centralization, e.t.c.

In such a case, operators will need to support "Invalid" and 
"NotFound" states of origin information for a long time. As 
adoption and deployment increases, operators can begin 
dropping "Invalid" results, "NotFound" results, or both. Or 
even mark them down with poor LOCAL_PREF values so as not to 
use those routes for forwarding unless it is really 
necessary.

At some point, when diffusion of RPKI is sufficiently 
prolific, anything that does not return a "Valid" result 
will be dropped. This should force every operator around the 
world to support it, much like the large carriers forced us 
all to use IRR's just so they won't ignore our routes, 
wherever we are in the world.

But before all this happens, we have to prevent more 
hijacks. And we have to use the tools we have today.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/ea1bda25/attachment.bin>

From goemon at anime.net  Mon Feb  6 00:41:53 2012
From: goemon at anime.net (goemon at anime.net)
Date: Sun, 5 Feb 2012 22:41:53 -0800 (PST)
Subject: Hijacked Network Ranges
In-Reply-To: <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061219.47007.mtinka@globaltransit.net>
 <CAArzuosbONqwXhW4ozv8_Ry90RiPbuO7CiWymM4Be9epKvZEjg@mail.gmail.com>
 <201202061307.39935.mtinka@globaltransit.net>
 <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202052241390.2009@sasami.anime.net>

On Mon, 6 Feb 2012, Christopher Morrow wrote:
> why aren't filters applied at all?

filters don't generate revenue.

-Dan


From gbonser at seven.com  Mon Feb  6 00:53:59 2012
From: gbonser at seven.com (George Bonser)
Date: Mon, 6 Feb 2012 06:53:59 +0000
Subject: Hijacked Network Ranges
In-Reply-To: <Pine.LNX.4.64.1202052241390.2009@sasami.anime.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061219.47007.mtinka@globaltransit.net>
 <CAArzuosbONqwXhW4ozv8_Ry90RiPbuO7CiWymM4Be9epKvZEjg@mail.gmail.com>
 <201202061307.39935.mtinka@globaltransit.net>
 <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
 <Pine.LNX.4.64.1202052241390.2009@sasami.anime.net>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CB249F@RWC-MBX1.corp.seven.com>

> To: Christopher Morrow
> Cc: nanog at nanog.org
> Subject: Re: Hijacked Network Ranges
> 
> On Mon, 6 Feb 2012, Christopher Morrow wrote:
> > why aren't filters applied at all?
> 
> filters don't generate revenue.
> 
> -Dan

Don't agree with the implied notion that a commercial network provider won't do anything that doesn't produce revenue.  They do all sorts of things that don't produce revenue, like purchase door locks and security cameras.  This is along the same avenue only for their networking which is their core competency.



From steve at pirk.com  Mon Feb  6 00:55:17 2012
From: steve at pirk.com (steve pirk [egrep])
Date: Sun, 5 Feb 2012 22:55:17 -0800
Subject: Verisign deep-hacked. For months.
In-Reply-To: <CB506D08.34718%zaid@zaidali.com>
References: <CAArzuou_GeCOQwsXHza_iykuKH-S44hQWutzVeSh9JSJ2AoKFw@mail.gmail.com>
 <CB506D08.34718%zaid@zaidali.com>
Message-ID: <CAK4no05X34E9Ok3JyrkZSfEq4XesUNmMs4CrfotBQvGBamKpjg@mail.gmail.com>

On Thu, Feb 2, 2012 at 16:42, Zaid Ali <zaid at zaidali.com> wrote:

> That part is ambiguous at the moment since Verisign has not released
> details. Symantec has bought the SSL part of the business and claim that
> the SSL acquired network is not compromised. Sounds like lots of
> assumptions being drawn.
>
> Zaid
>
>
I am thinking it is related to the Chinese hacking of Gmail accounts in the
fall of 2010. Symantic acquired the SSL business in August 2010. The
hacking could have been in the spring for all we know. Google uses Thwate
as it's CA, but Thwate has "Builtin Object Token: Verisign Class 3 Public
Primary Certificate Authority" as it's root.

Seems to me part of the problem was traced back to browsers not checking
revoked certs via the browser CRLs. Didn't some in the chain have revoked
certs still installed?

-- 
steve pirk
yensid
"father... the sleeper has awakened..." paul atreides - dune
Google+ pirk.com

From mtinka at globaltransit.net  Mon Feb  6 01:04:18 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 15:04:18 +0800
Subject: Hijacked Network Ranges
In-Reply-To: <Pine.LNX.4.64.1202052241390.2009@sasami.anime.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
 <Pine.LNX.4.64.1202052241390.2009@sasami.anime.net>
Message-ID: <201202061504.21817.mtinka@globaltransit.net>

On Monday, February 06, 2012 02:41:53 PM goemon at anime.net 
wrote:

> filters don't generate revenue.

Neither does traffic - that does generate revenue - not 
reaching your customer.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/5a76e4f5/attachment.bin>

From morrowc.lists at gmail.com  Mon Feb  6 01:06:24 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 6 Feb 2012 02:06:24 -0500
Subject: Hijacked Network Ranges
In-Reply-To: <201202061435.39053.mtinka@globaltransit.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061307.39935.mtinka@globaltransit.net>
 <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
 <201202061435.39053.mtinka@globaltransit.net>
Message-ID: <CAL9jLaYfjVd_rHSptnBgaxUhmcLEFvxBnBMRZL7DPmtyL9ureg@mail.gmail.com>

On Mon, Feb 6, 2012 at 1:35 AM, Mark Tinka <mtinka at globaltransit.net> wrote:
> On Monday, February 06, 2012 01:14:20 PM Christopher Morrow

> We manually check the RIR WHOIS database. I'm sure some

do you have customers with 10k long prefix lists? it gets hard when
the lists get long, or the data is for downstream folks of your
customer. Good that someone's checking though, I'd love to see this
part automated.

>> resource certification would at least get us to the point
>> where checking the data in the IRR is 'easy', it's not
>> going to get people to PUT FILTERS ON CUSTOMER SESSIONS,
>> and it's not going to get people to update their IRR
>> objects (add AND DELETE!!!)
>
> I support RPKI, but also realize that operator support will
> take a very long time for various reasons, e.g., education,
> delayed software upgrades, persistence with older methods,
> fear of centralization, e.t.c.
>
> In such a case, operators will need to support "Invalid" and
> "NotFound" states of origin information for a long time. As

RPKI doesn't necessarily mean that the router knows anything about
certificates in the short-term. I think there's a time when 'the
resource certification system' (which is really, today, the rpki)
holds cert/roa data that you could use to filter what the IRR tells
you for a customer. You could even do this in any automated manner!

> adoption and deployment increases, operators can begin
> dropping "Invalid" results, "NotFound" results, or both. Or
> even mark them down with poor LOCAL_PREF values so as not to
> use those routes for forwarding unless it is really
> necessary.

The time between the previous and next paragraphs though is when all
isp's will need to beat the drums with their customers saying: "Hey,
you REALLY need to get that shit into the 'resource certification
system' (rpki), NOW." (because shortly we'll stop accepting your
"invalid" routes... and then the interwebs won't be able to find you,
and we'll all be sad.)

> At some point, when diffusion of RPKI is sufficiently
> prolific, anything that does not return a "Valid" result
> will be dropped. This should force every operator around the
> world to support it, much like the large carriers forced us
> all to use IRR's just so they won't ignore our routes,
> wherever we are in the world.
>
> But before all this happens, we have to prevent more
> hijacks. And we have to use the tools we have today.

sure... it's not working so well though :(


From m.hallgren at free.fr  Mon Feb  6 01:24:37 2012
From: m.hallgren at free.fr (Michael Hallgren)
Date: Mon, 06 Feb 2012 08:24:37 +0100
Subject: Hijacked Network Ranges
In-Reply-To: <Pine.LNX.4.64.1202052241390.2009@sasami.anime.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061219.47007.mtinka@globaltransit.net>
 <CAArzuosbONqwXhW4ozv8_Ry90RiPbuO7CiWymM4Be9epKvZEjg@mail.gmail.com>
 <201202061307.39935.mtinka@globaltransit.net>
 <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
 <Pine.LNX.4.64.1202052241390.2009@sasami.anime.net>
Message-ID: <1328513077.26894.0.camel@home>

Le dimanche 05 f?vrier 2012 ? 22:41 -0800, goemon at 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
> 




From jsw at inconcepts.biz  Mon Feb  6 01:33:29 2012
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Mon, 6 Feb 2012 02:33:29 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <4F2F4423.8040803@gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <4F2F4423.8040803@gmail.com>
Message-ID: <CAPWAtbKCqBQOVxmzJH3z4nJyWsUYVA1LyWPJ_y5f4fucRE++uQ@mail.gmail.com>

On Sun, Feb 5, 2012 at 10:08 PM, Steve Bertrand
<steve.bertrand at gmail.com> wrote:
> This is so very easily automated. Even if you don't actually want to trigger
> the routes automatically, finding the sources you want to blackhole is as

What transit providers are doing flow-spec, or otherwise, to allow
their downstreams to block malicious traffic by SOURCE address?

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From dr at cluenet.de  Mon Feb  6 01:34:26 2012
From: dr at cluenet.de (Daniel Roesen)
Date: Mon, 6 Feb 2012 08:34:26 +0100
Subject: Optimal IPv6 router
In-Reply-To: <107963.1328494077@turing-police.cc.vt.edu>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
Message-ID: <20120206073426.GB8779@srv03.cluenet.de>

On Sun, Feb 05, 2012 at 09:07:57PM -0500, Valdis.Kletnieks at vt.edu wrote:
> OK, I'll bite.  What would qualify as a "native IPv6" router?

Perhaps those which were designed with IPv4+IPv6 in mind from day 1,
both in hardware and software - like Juniper/JUNOS. In contrast to other
the gear where IPv6 was always an aftermath, which shows in both
hardware (limits of performance, functionality and scaling) as well as
software (every feature gets implemented twice, even if the feature
itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment
on XR]).

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0


From mtinka at globaltransit.net  Mon Feb  6 01:59:29 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 15:59:29 +0800
Subject: Hijacked Network Ranges
In-Reply-To: <CAL9jLaYfjVd_rHSptnBgaxUhmcLEFvxBnBMRZL7DPmtyL9ureg@mail.gmail.com>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061435.39053.mtinka@globaltransit.net>
 <CAL9jLaYfjVd_rHSptnBgaxUhmcLEFvxBnBMRZL7DPmtyL9ureg@mail.gmail.com>
Message-ID: <201202061559.32377.mtinka@globaltransit.net>

On Monday, February 06, 2012 03:06:24 PM Christopher Morrow 
wrote:

> do you have customers with 10k long prefix lists? it gets
> hard when the lists get long, or the data is for
> downstream folks of your customer. Good that someone's
> checking though, I'd love to see this part automated.

No, we don't have customers with 10,000-long prefix lists, 
but we have planned to implement automation (either using 
the IRR Toolset or home-grown solutions) to make this 
possible as a means to scaling, should that time arise.

As it is now, throwing NOC staff at the problem for the 
volumes we have works well enough. But this is, by no means, 
a panacea as we scale up.

Heck, one must even worry whether a some router 
configurations can take that many lines. But there are other 
ways around that.

> RPKI doesn't necessarily mean that the router knows
> anything about certificates in the short-term. I think
> there's a time when 'the resource certification system'
> (which is really, today, the rpki) holds cert/roa data
> that you could use to filter what the IRR tells you for
> a customer. You could even do this in any automated
> manner!

Well, given validation information will be available within 
a network, one may use it in non-obvious ways to implement 
policy.

> The time between the previous and next paragraphs though
> is when all isp's will need to beat the drums with their
> customers saying: "Hey, you REALLY need to get that shit
> into the 'resource certification system' (rpki), NOW."
> (because shortly we'll stop accepting your "invalid"
> routes... and then the interwebs won't be able to find
> you, and we'll all be sad.)

Well, we have all seen how doing this with DNSSEC, IPv6 and 
4-byte ASN's worked out.

We need to understand that different operators and different 
customers will have varying reasons as to why they can't yet 
"do the right thing". There is abundant evidence of this 
with other similar initiatives.

Adoption will have to be incremental. During that time, the 
Internet must not break.

> sure... it's not working so well though :(

Not for lack of having some kind of solution.

What we have today may not be the best, most scalable 
option, but it is one nonetheless. Automating it (like what 
RPSL does) is how you can make it scale to some extent, but 
it's still the same solution.

We can't just sit around waiting for RPKI. There will be 
some reason why some of us can't deploy it, while someone 
else is thinking up its successor. Rinse, repeat.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/7de69fc1/attachment.bin>

From ops.lists at gmail.com  Mon Feb  6 04:46:53 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Mon, 6 Feb 2012 16:16:53 +0530
Subject: Hijacked Network Ranges
In-Reply-To: <201202061559.32377.mtinka@globaltransit.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061435.39053.mtinka@globaltransit.net>
 <CAL9jLaYfjVd_rHSptnBgaxUhmcLEFvxBnBMRZL7DPmtyL9ureg@mail.gmail.com>
 <201202061559.32377.mtinka@globaltransit.net>
Message-ID: <CAArzuov2k_sjeoDRTwTq_=EnWjCFsFfUot=8TWUT4nKZZKH2Rg@mail.gmail.com>

That and rely on external telemetry (argus and friends..)

On Mon, Feb 6, 2012 at 1:29 PM, Mark Tinka <mtinka at globaltransit.net> wrote:
>
> Well, given validation information will be available within
> a network, one may use it in non-obvious ways to implement
> policy.



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From alexb at ripe.net  Mon Feb  6 04:47:23 2012
From: alexb at ripe.net (Alex Band)
Date: Mon, 6 Feb 2012 11:47:23 +0100
Subject: Hijacked Network Ranges
In-Reply-To: <201202061559.32377.mtinka@globaltransit.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061435.39053.mtinka@globaltransit.net>
 <CAL9jLaYfjVd_rHSptnBgaxUhmcLEFvxBnBMRZL7DPmtyL9ureg@mail.gmail.com>
 <201202061559.32377.mtinka@globaltransit.net>
Message-ID: <89460018-6616-4EB9-B2B7-0518F7FF0DAF@ripe.net>

With regards to RPKI, I'd like to point out what is possible now, and what the maturity is of the implementations. All RIRs have a system up an running. As John Curran pointed out in an earlier message, ARIN will have a production system up this year, but right now you can already gain experience with their testbed: https://www.arin.net/resources/rpki.html

If you create your ROAs there, there are actually quite some parties who will already validate this information. Of course, basing an actual routing decision on this is a second step; for that we'll need more and better quality data. As it stands there are about 1400 IPv4 and 300 IPv6 announcements that have a ROA associated with them. There are some public test beds up that will give a valid route a higher pref, and an invalid one a lower pref. So create a ROA for your announcements, and then watch it show up on actual RPKI-capable Cisco and Juniper routers:

EuroTransit have made their instance of the RIPE NCC RPKI Validator public, so you can easily verify the validity of your announcement here by searching for it:
http://rpki01.fra2.de.euro-transit.net:8080/bgp-preview

Then you can log in on a public Juniper here:
193.34.50.25, 193.34.50.26
telnet username: rpki
password: testbed

Try commands such as: 
- show validation session detail
- show validation statistics
- show validation database
- show route protocol bgp 204.127.128.0/17
- show route protocol bgp validation-state valid

You can also log into a public Cisco here:
rpki-rtr.ripe.net
telnet username: ripe
no password

Try commands such as:
- sh ip bgp rpki table
- sh ip bgp rpki server
- sh ip bgp 93.175.146.0/24
- sh ip bgp ipv6 unicast rpki table
- sh ip bgp ipv6 unicast 2001:630::/32

Both routers are configured along these lines:
https://www.ripe.net/certification/router-configuration

and talk to the RIPE NCC RPKI Validator service available here:
https://www.ripe.net/certification/tools-and-resources

Try it out, and give feedback!

Cheers,

Alex

P.S. RFCs 6480-6493 have been published. A big thank you goes out to all the people who made that possible.


On 6 Feb 2012, at 08:59, Mark Tinka wrote:

> On Monday, February 06, 2012 03:06:24 PM Christopher Morrow 
> wrote:
> 
>> do you have customers with 10k long prefix lists? it gets
>> hard when the lists get long, or the data is for
>> downstream folks of your customer. Good that someone's
>> checking though, I'd love to see this part automated.
> 
> No, we don't have customers with 10,000-long prefix lists, 
> but we have planned to implement automation (either using 
> the IRR Toolset or home-grown solutions) to make this 
> possible as a means to scaling, should that time arise.
> 
> As it is now, throwing NOC staff at the problem for the 
> volumes we have works well enough. But this is, by no means, 
> a panacea as we scale up.
> 
> Heck, one must even worry whether a some router 
> configurations can take that many lines. But there are other 
> ways around that.
> 
>> RPKI doesn't necessarily mean that the router knows
>> anything about certificates in the short-term. I think
>> there's a time when 'the resource certification system'
>> (which is really, today, the rpki) holds cert/roa data
>> that you could use to filter what the IRR tells you for
>> a customer. You could even do this in any automated
>> manner!
> 
> Well, given validation information will be available within 
> a network, one may use it in non-obvious ways to implement 
> policy.
> 
>> The time between the previous and next paragraphs though
>> is when all isp's will need to beat the drums with their
>> customers saying: "Hey, you REALLY need to get that shit
>> into the 'resource certification system' (rpki), NOW."
>> (because shortly we'll stop accepting your "invalid"
>> routes... and then the interwebs won't be able to find
>> you, and we'll all be sad.)
> 
> Well, we have all seen how doing this with DNSSEC, IPv6 and 
> 4-byte ASN's worked out.
> 
> We need to understand that different operators and different 
> customers will have varying reasons as to why they can't yet 
> "do the right thing". There is abundant evidence of this 
> with other similar initiatives.
> 
> Adoption will have to be incremental. During that time, the 
> Internet must not break.
> 
>> sure... it's not working so well though :(
> 
> Not for lack of having some kind of solution.
> 
> What we have today may not be the best, most scalable 
> option, but it is one nonetheless. Automating it (like what 
> RPSL does) is how you can make it scale to some extent, but 
> it's still the same solution.
> 
> We can't just sit around waiting for RPKI. There will be 
> some reason why some of us can't deploy it, while someone 
> else is thinking up its successor. Rinse, repeat.
> 
> Mark.



From rubensk at gmail.com  Mon Feb  6 05:07:58 2012
From: rubensk at gmail.com (Rubens Kuhl)
Date: Mon, 6 Feb 2012 09:07:58 -0200
Subject: Optimal IPv6 router
In-Reply-To: <107963.1328494077@turing-police.cc.vt.edu>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
Message-ID: <CAGFn2k2XhhHpWT4mav12PA3g7U8ut6VHPQh3BUnxyse9OAmYpQ@mail.gmail.com>

>> With IPv6 growing, if we were to design a native IPv6 router, with
>> IPv4 functionality thrown in, then is it possible to design a more
>> optimal IPv6 router, than what exists today?
>
> OK, I'll bite. ?What would qualify as a "native IPv6" router? ?Is this
> another concept as silly as "hardware vs software based" routers?

Join them and create a router where IPv6 is ASIC-forwarded and IPv4
gets to use a CPU. Market perspectives for such a product are very
shy, but would fit the description.


Rubens


From david at davidswafford.com  Mon Feb  6 05:22:35 2012
From: david at davidswafford.com (David Swafford)
Date: Mon, 6 Feb 2012 06:22:35 -0500
Subject: ISP access in Hebron, KY
In-Reply-To: <20120205202158.GA15605@roxanne.org>
References: <20120205202158.GA15605@roxanne.org>
Message-ID: <CAA8=vb7C7nR1YYcXxQAXfSQFAvRs62xdd24WtiF+o3t8UgfTGA@mail.gmail.com>

Level 3 might be available.  I'm pretty sure TWTC is though -- they're
one of the bigger players in Dayton.

David.


On Sun, Feb 5, 2012 at 3:21 PM, Eric Gauthier <eric at roxanne.org> wrote:
> Hello,
>
> We're looking for DIA in the 20 - 50mbps range for a
> warehouse we have in Hebron, KY. ?CinBell has been a
> bit "slow" to respond to our DS3 requets, so I'm
> wondering who else in town has their own facilities
> (also wondering who might be a good for a backup
> circuit)?
>
> Thanks!
>
> Eric :)
>


From mtinka at globaltransit.net  Mon Feb  6 06:03:46 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 20:03:46 +0800
Subject: Hijacked Network Ranges
In-Reply-To: <89460018-6616-4EB9-B2B7-0518F7FF0DAF@ripe.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061559.32377.mtinka@globaltransit.net>
 <89460018-6616-4EB9-B2B7-0518F7FF0DAF@ripe.net>
Message-ID: <201202062003.46979.mtinka@globaltransit.net>

On Monday, February 06, 2012 06:47:23 PM Alex Band wrote:

> With regards to RPKI, I'd like to point out what is
> possible now, and what the maturity is of the
> implementations. All RIRs have a system up an running.
> As John Curran pointed out in an earlier message, ARIN
> will have a production system up this year, but right
> now you can already gain experience with their testbed:
> https://www.arin.net/resources/rpki.html

This is great, Alex! Thanks.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/faaaa89c/attachment.bin>

From dennis at justipit.com  Mon Feb  6 06:22:38 2012
From: dennis at justipit.com (dennis)
Date: Mon, 6 Feb 2012 07:22:38 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
Message-ID: <73D3547A154D4F9AB0C61976A60C207B@usa.corp.radware.com>

The point is well taken that cloud scrubbing can be an essential component 
of mitigating a volumetric flood.  However, it is important to note that 
DDOS attacks do not only consist of volumetric floods.  Current attacks 
often incorporate a multi-vectored attack campaign including a combination 
of low and slow and application layer attacks on upper layer protocols, ie. 
DNS & HTTP(s).  These campaigns are designed to fly under the triggers of 
other flow based analysis (cloud scrubbing) protections in place today.   As 
with any security protection a layered approach is required in order to 
protect the  perimeter from DDOS.  In addition to the previous 
recommendations of ACL, uRPF, RTBH, CoPP, inspection of the full stack is 
required.    The best protection today includes a detector capable of 
inspecting the full stack and signaling back to the cloud scrubbing station 
to swing the route if the attack becomes volumetric.   The premise device 
should have technique in order to challenge the source and counter the 
attack with intelligence.    I'm aware of two vendors offering some of these 
capabilities today, Radware and Arbor.



--------------------------------------------------
From: "Keegan Holley" <keegan.holley at sungard.com>
Sent: Sunday, February 05, 2012 8:37 PM
To: "Dobbins, Roland" <rdobbins at arbor.net>
Cc: "NANOG Group" <nanog at nanog.org>
Subject: Re: UDP port 80 DDoS attack

> 2012/2/5 Dobbins, Roland <rdobbins at arbor.net>
>
>>
>> On Feb 6, 2012, at 8:10 AM, Keegan Holley wrote:
>>
>> > An entire power point just to recommend ACL's, uRPF, CPP, DHCP 
>> > snooping,
>> and RTBH?
>>
>> Actually, no, that isn't the focus of the preso.
>>
>> > The first four will not work against a DDOS attack
>>
>> This is incorrect - suggest you read the preso.
>>
>
> The ACL's are configured on the routers belonging to the victim AS which
> will not save their access pipe if it's overrun unless I'm missing
> something.  uRPF may help with spoofed traffic, but sometimes causes
> problems with multi-homing and is often more harmful than helpful 
> depending
> on the network design.
>
>>
>> > and the last one just kills the patient so he does not infect other
>> patients.
>>
>> S/RTBH - as opposed to D/RTBH - doesn't kill the patient.  Again, suggest
>> you read the preso.
>>
>
> Source RTBH often falls victim to rapidly changing or spoofed source IP"s.
> It also isn't as widely supported as it should be. I never said DDOS was
> hopeless, there just aren't a wealth of defenses against it.
> 


From leigh.porter at ukbroadband.com  Mon Feb  6 07:39:10 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Mon, 6 Feb 2012 13:39:10 +0000
Subject: Optimal IPv6 router
In-Reply-To: <CAGFn2k2XhhHpWT4mav12PA3g7U8ut6VHPQh3BUnxyse9OAmYpQ@mail.gmail.com>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
 <CAGFn2k2XhhHpWT4mav12PA3g7U8ut6VHPQh3BUnxyse9OAmYpQ@mail.gmail.com>
Message-ID: <D181DDABABE57E4DB72FEE003314786449B070@EALPO1.ukbroadband.com>

> >> With IPv6 growing, if we were to design a native IPv6 router, with
> >> IPv4 functionality thrown in, then is it possible to design a more
> >> optimal IPv6 router, than what exists today?
> >
> > OK, I'll bite. ?What would qualify as a "native IPv6" router? ?Is
> this
> > another concept as silly as "hardware vs software based" routers?
> 
> Join them and create a router where IPv6 is ASIC-forwarded and IPv4
> gets to use a CPU. Market perspectives for such a product are very
> shy, but would fit the description.

And where half the useful features just don't support IPv6.

Make it support draft-ietf-mpls-ldp-ipv6 and we're away :)

--
Leigh Porter


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


From bicknell at ufp.org  Mon Feb  6 08:18:46 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 6 Feb 2012 06:18:46 -0800
Subject: Optimal IPv6 router
In-Reply-To: <20120206073426.GB8779@srv03.cluenet.de>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
 <20120206073426.GB8779@srv03.cluenet.de>
Message-ID: <20120206141846.GB52936@ussenterprise.ufp.org>

In a message written on Mon, Feb 06, 2012 at 08:34:26AM +0100, Daniel Roesen wrote:
> itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment
> on XR]).

IOS-XR is fully AFI-agnostic, as far as I can tell.  It also updated
the CLI to be consistently "ipv4 ..." or "ipv6 ..." with similar
syntax.  I think also that all of the platforms on which IOS-XR
runs (GSR, CRS-1/3, ASR9000) can all run full line rate IPv6 in
hardware, with features.

While much of the IOS-XR vrs JunOS is personal preference, IOS-XR has
one very cool feature.  You can pass parameters in route policy.  Many
networks maintain slightly different versions of policies like
"peer-in/peer-out" due to various load balancing or preference needs,
with a 5-15 stanza policy repeated over and over.  When you have to
update one of the stanzas in all policies it becomes a big mess.
In IOS-XR, you can write a generic policy and then call with with
parameters:

route-policy generic-out($routeCommunity)
  ... ! Do all the common things
  if community matches-any $routeCommunity then
    accept
  endif
  drop
end-policy

community-set send-to-private-peers
  1234:5678
end-set

route-policy private-peer-out
  apply generic-out(send-to-private-peers)
end-policy

community-set send-to-public-peers
  1234:4321
end-set

route-policy public-peer-out
  apply generic-out(send-to-public-peers)
end-policy

With a little bit of careful thought you can really collapse down the
policy to be much shorter, easier to understand, and have almost no
cut-and-paste in it, which should reduce errors when updating in the
future.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/935a7f4d/attachment.bin>

From glen.kent at gmail.com  Mon Feb  6 08:48:29 2012
From: glen.kent at gmail.com (Glen Kent)
Date: Mon, 6 Feb 2012 20:18:29 +0530
Subject: Optimal IPv6 router
In-Reply-To: <20120206073426.GB8779@srv03.cluenet.de>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
 <20120206073426.GB8779@srv03.cluenet.de>
Message-ID: <CAPLq3UMwZE-_jUeeR-EH4+mmmfTfaM_GRJHV9naUa5psa1i4HA@mail.gmail.com>

On Mon, Feb 6, 2012 at 1:04 PM, Daniel Roesen <dr at cluenet.de> wrote:
> On Sun, Feb 05, 2012 at 09:07:57PM -0500, Valdis.Kletnieks at vt.edu wrote:
>> OK, I'll bite. ?What would qualify as a "native IPv6" router?
>
> Perhaps those which were designed with IPv4+IPv6 in mind from day 1,
> both in hardware and software - like Juniper/JUNOS. In contrast to other

Not just that.

I had meant that the HW is optimized for IPv6 and also as a side
effect does IPv4. This router could be designed assuming that you'll
have more IPv6 traffic to forward than IPv4.

> the gear where IPv6 was always an aftermath, which shows in both
> hardware (limits of performance, functionality and scaling) as well as
> software (every feature gets implemented twice, even if the feature
> itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment
> on XR]).

Yes, thats what i had in mind.

One example that comes to my mind is that a few existing routers cant
do line rate routing for IPv6 traffic as long as the netmask is < 65.
Also routers have a limited TCAM size for storing routes with masks >
64. These routers were primarily designed for IPv4 and also support
IPv6.

I was wondering what we could optimize on if we only design an IPv6
router (assume an extreme case where it does not even support IPv4).

Glen
>
> Best regards,
> Daniel
>
> --
> CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
>


From joelja at bogus.com  Mon Feb  6 09:35:39 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Mon, 06 Feb 2012 07:35:39 -0800
Subject: Optimal IPv6 router
In-Reply-To: <CAPLq3UMwZE-_jUeeR-EH4+mmmfTfaM_GRJHV9naUa5psa1i4HA@mail.gmail.com>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
 <20120206073426.GB8779@srv03.cluenet.de>
 <CAPLq3UMwZE-_jUeeR-EH4+mmmfTfaM_GRJHV9naUa5psa1i4HA@mail.gmail.com>
Message-ID: <4F2FF34B.6060109@bogus.com>

On 2/6/12 06:48 , Glen Kent wrote:

> One example that comes to my mind is that a few existing routers
> cant do line rate routing for IPv6 traffic as long as the netmask is
> < 65.

I'm sorry that's  bs. It's trivial to partition a cam in order to do
/128s in a single lookup. that's actually the worst case scenario, a
more efficient packing will result in lower power consumption and memory
use. potentially that results in multiple lookups which in no way
implies you're not going to meet your pps target.

> Also routers have a limited TCAM size for storing routes with masks
> > 64. These routers were primarily designed for IPv4 and also
> support IPv6.

All routers don't use tcams for fib lookups. M T MX devices do not use
cams for fib for example.

limited cam partitioning schemes exist in ip4 as well,
big cams have a cost power wise, and bom wise, parititioning them in a
way that meets the developers view of the distribution of route lengths
can be beneficial and be used to build products suitable for lots of
roles but probably not being a internet core router. standard juniper
ex8200 line cards for example are just peachy for a datacenter but not
so much for a internet core device and the bom feature set and price
reflect that.

> I was wondering what we could optimize on if we only design an IPv6 
> router (assume an extreme case where it does not even support IPv4).

right now if I take a platform that uses a  large CAM like a force 10
e1200i ej line card, I can adjust the cam allocation to do basically
nothing but ipv6, given the default balance between ipv4 and ipv6 doing
so more that doubles the number of ipv6 routes I can expect to hold.

> Glen
>> 
>> Best regards, Daniel
>> 
>> -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP:
>> 0xA85C8AA0
>> 
> 
> 



From surfer at mauigateway.com  Mon Feb  6 14:11:52 2012
From: surfer at mauigateway.com (Scott Weeks)
Date: Mon, 6 Feb 2012 12:11:52 -0800
Subject: Hijacked Network Ranges
Message-ID: <20120206121152.D490B6EE@resin11.mta.everyone.net>

--- mtinka at globaltransit.net wrote:
From: Mark Tinka <mtinka at globaltransit.net>

A big fail to our community, for up to this day, not 
implementing basic routing and forwarding filters that would 
do away with all this cruft in the first place.

Clearly the Youtube/Pakistan/PCCW incident has long been 
forgotten.
-----------------------------------


I know of folks in charge of BGP enabled networks (with downstream BGP 
customers as well) that have never heard of the Youtube/Pakistan/PCCW 
incident and don't care if they put extra routes in the table and I 
doubt that is an isolated situation.  Further, I doubt it will change 
unless they're forced to care by technology somehow.  An unfortunate 
situation for sure...

scott


From mpetach at netflight.com  Mon Feb  6 14:51:55 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Mon, 6 Feb 2012 12:51:55 -0800
Subject: 2012.02.06 NANOG54 monday morning session notes are up
Message-ID: <CAEmG1=q6Rcmg21MnEeRpLOzdThPCTdDCuzho2W_tdA-5XM3ijQ@mail.gmail.com>

I posted my notes from this morning's session at

http://kestrel3.netflight.com/2012.02.06-nanog54-morning-session.txt

in case people find them to be useful.

Thanks!

Matt


From annkwok80 at gmail.com  Mon Feb  6 15:41:03 2012
From: annkwok80 at gmail.com (Ann Kwok)
Date: Mon, 6 Feb 2012 16:41:03 -0500
Subject: Switch and router
Message-ID: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>

Hello

There is big congestion between router and switch

I read some documents about flowcontral

Do I disable or adjust flowcontral at the same?

Can flowcontral solve the congestion issue?

How can I adjust flowcontral in cisco router and HP switch?

Thank you so much

From fdelmotte1 at mac.com  Mon Feb  6 15:56:08 2012
From: fdelmotte1 at mac.com (Fabien Delmotte)
Date: Mon, 06 Feb 2012 22:56:08 +0100
Subject: Switch and router
In-Reply-To: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>
References: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>
Message-ID: <D1AC84E0-29C1-4BC2-A732-A023B76D9476@mac.com>

Hi
Forget flow control, because you will use buffer and at the someone will not understant pause frame.
Another issue is : with pause frame you block all the traffic from the outbound port ... So very dangerous.
Best way : big pipe.

Regards

Fabien

Envoy? de mon iPad

Le 6 f?vr. 2012 ? 22:41, Ann Kwok <annkwok80 at gmail.com> a ?crit :

> Hello
> 
> There is big congestion between router and switch
> 
> I read some documents about flowcontral
> 
> Do I disable or adjust flowcontral at the same?
> 
> Can flowcontral solve the congestion issue?
> 
> How can I adjust flowcontral in cisco router and HP switch?
> 
> Thank you so much


From regnauld at nsrc.org  Mon Feb  6 16:09:08 2012
From: regnauld at nsrc.org (Phil Regnauld)
Date: Mon, 6 Feb 2012 23:09:08 +0100
Subject: 2012.02.06 NANOG54 monday morning session notes are up
In-Reply-To: <CAEmG1=q6Rcmg21MnEeRpLOzdThPCTdDCuzho2W_tdA-5XM3ijQ@mail.gmail.com>
References: <CAEmG1=q6Rcmg21MnEeRpLOzdThPCTdDCuzho2W_tdA-5XM3ijQ@mail.gmail.com>
Message-ID: <20120206220908.GF5356@macbook.bluepipe.net>

Matthew Petach (mpetach) writes:
> I posted my notes from this morning's session at
> 
> http://kestrel3.netflight.com/2012.02.06-nanog54-morning-session.txt
> 
> in case people find them to be useful.

	For those of us not attenting, this is invaluable. Thanks a lot
	for this work, Matt.

	Cheers,
	Phil


From sven at cb3rob.net  Mon Feb  6 19:43:00 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Tue, 7 Feb 2012 01:43:00 +0000 (UTC)
Subject: UDP port 80 DDoS attack
In-Reply-To: <73D3547A154D4F9AB0C61976A60C207B@usa.corp.radware.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <73D3547A154D4F9AB0C61976A60C207B@usa.corp.radware.com>
Message-ID: <Pine.LNX.4.64.1202070126150.14602@a84-22-97-10.cb3rob.net>

>> It also isn't as widely supported as it should be. I never said DDOS was
>> hopeless, there just aren't a wealth of defenses against it.

there is a fix for it, it's called "putting a fuckton of ram in -most- 
routers on the internet" and keeping statistics for each destination 
ip:destination port:outgoing interface so that none of them individually 
can (entirely/procentually compared to other traffic) flood the outgoing 
interface on that router... end result, if enough routers are structured
like that, is that ddos attacks will be come completely useless.

keyword here, is terabytes of ram.

statistic tables on very basic ipv4 stuff alone would already take 
multiple 100's of gigabytes...

(keep in mind, this won't be "cpu work", its just using the table entry 
size * dest ip as an offset and reading it out ;)

the good news is, ram doesn't cost a flying fuck anymore...

it just requires a complete re-think of router design, but then again, 
with the prices that cisco and juniper charge we expect a bit more than a 
1960's telephone exchange look and feel device, or we might as well use 1 
linux box/blade per 20gbit/s throughput and consider that whole thing a 
"hotpluggable interface". cisco and juniper, at the moment, sell faster 
versions of their crap from the 1990s, but not much effort went into 
completely re-designing the stuff to be suitable for the internet as it is 
today, they still forward all packets they can get their hands on, and 
besides rather simple stuff like QoS, not much effort went into 
inteligently spreading the capacity available on the outgoing interface 
(at least for that individual router) over all the possible targets.

now, if an outgoing interface is 10ge, and 10mbit traffic should go to 
1.2.3.4 and 20ge (ddos) traffic should go to 4.3.2.1, i'd say, a router 
should give 1.2.3.4 the full 10ge, as it is available, and lower volume 
should basically just get a higher priority.

we have not quite worked out the formula yet... but it should be something 
along those lines (simply to say, any destination ip can never fill more 
than half of the outgoing interface, doesn't quite cover it, it needs some 
"intelligent adjustment of the percentage")..

basically...
table:

destip
destport
packetcounter

every so and so many packets/timeslices,whatever that packetcounter is 
decreased by 1

every packet, the packet counter is incremented

after inactivity for that ip for timeperiod x, the packet counter is 
cleared.

with ipv4, this "destip" entry is such a small (32 bit) integer that its 
better to just not store the ip itself but rather just throw more ram at 
it and use the ip address number as the offset in the array

(for faster lookups, preferably in hardware logic).


the same thing could be applied to pretty much every other concept still 
done with slow lookups nowadays (arp, routes, etc)... throw more ram at it 
and use the destination as the offset, who cares if 99.9% of the ram is 
not actually used. for the price of a juniper, you can buy a truck full of 
ram chips ;).. it's faster that way, and it allows us to do a lot of 
things, like not passing potential ddos floods in the first place, and 
intelligently allowing everyone, not an equal share of the traffic 
capacity, but the part they need.

if you don't mind wasting 50% of the available capacity the formula to 
determine wether to forward a packet or not is 
quite simple, if you also want to give a destip 100% of the traffic in 
situations where there is no other traffic, it becomes a bit more 
complicated..

as stated before, we haven't quite worked it out in full yet, but in any 
case... this would require for at least 30% of the routers that currently 
are on the internet and are 110 kg heavy "1960s telephone exchange models" 
to be replaced with 2012 style hardware, not "just faster cisco 7200 like 
things".


From robertg at garlic.com  Mon Feb  6 20:01:57 2012
From: robertg at garlic.com (Robert Glover)
Date: Mon, 06 Feb 2012 18:01:57 -0800
Subject: Any Covad / MegaPath folks around?
Message-ID: <4F308615.1030707@garlic.com>

Hi,

Looks like the Connect portal has been down for hours.  Can someone from 
Covad / MegaPath ping me off-list?

Thanks!

Sincerely,
Bobby Glover
Director of Information Services
South Valley Internet


From mpetach at netflight.com  Mon Feb  6 20:04:20 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Mon, 6 Feb 2012 18:04:20 -0800
Subject: 2012.02.06 NANOG54 day1 afternoon session notes
Message-ID: <CAEmG1=rFts8PvX4m1djoWewbrpk0fpVRX_VOEi=2Pa4JrJko-A@mail.gmail.com>

My notes from the second half of today's NANOG 54
talks are now up at

http://kestrel3.netflight.com/2012.02.06-nanog54-afternoon-session.txt

for those catching up remotely before the videos
get posted up.

Off to the Beer and Gear now.  ^_^

Thanks!

Matt


From jsw at inconcepts.biz  Mon Feb  6 22:12:26 2012
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Mon, 6 Feb 2012 23:12:26 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <Pine.LNX.4.64.1202070126150.14602@a84-22-97-10.cb3rob.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <73D3547A154D4F9AB0C61976A60C207B@usa.corp.radware.com>
 <Pine.LNX.4.64.1202070126150.14602@a84-22-97-10.cb3rob.net>
Message-ID: <CAPWAtb+3yQjUmmJvfqOGqa2VY7j2WaSCmidcrvtfsHGY=HZQfg@mail.gmail.com>

On Mon, Feb 6, 2012 at 8:43 PM, Sven Olaf Kamphuis <sven at cb3rob.net> wrote:
> there is a fix for it, it's called "putting a fuckton of ram in -most-
> routers on the internet" and keeping statistics for each destination
> ip:destination port:outgoing interface so that none of them individually can
> (entirely/procentually compared to other traffic) flood the outgoing
> interface on that router... end result, if enough routers are structured
> like that, is that ddos attacks will be come completely useless.

There are two obvious problems with your approach.

First, adding the policers you suggest, at the scale needed, is a
little harder than you imagine.  It's not a simple matter of the cost
of RAM but also power/heat density per port.

Second, if you re-engineer every router on the Internet to prevent an
interface from being congested by malicious flow(s) destined for one
particular destination IP:port, then DDoS attacks will simply target
multiple ports or multiple destination IP addresses that are likely to
traverse a link they are able to congest.

If you want to dramatically increase the cost of routers in order to
solve the problem of DDoS with one deft (and expensive) move, you have
to imagine that the people behind DDoS attacks aren't complete idiots,
and will actually spend some time thinking about how to defeat your
system.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From packetjockey at gmail.com  Mon Feb  6 22:23:20 2012
From: packetjockey at gmail.com (Rafael Rodriguez)
Date: Mon, 6 Feb 2012 20:23:20 -0800
Subject: Optimal IPv6 router
In-Reply-To: <20120206141846.GB52936@ussenterprise.ufp.org>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
 <20120206073426.GB8779@srv03.cluenet.de>
 <20120206141846.GB52936@ussenterprise.ufp.org>
Message-ID: <28549ED9-622F-4F58-B2ED-5E09DBD8748B@gmail.com>

You can do the same with Junos (calling a 'generic' policy as a sub-routine).

Sent from my iPhone

On Feb 6, 2012, at 6:18, Leo Bicknell <bicknell at ufp.org> wrote:

> In a message written on Mon, Feb 06, 2012 at 08:34:26AM +0100, Daniel Roesen wrote:
>> itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment
>> on XR]).
> 
> IOS-XR is fully AFI-agnostic, as far as I can tell.  It also updated
> the CLI to be consistently "ipv4 ..." or "ipv6 ..." with similar
> syntax.  I think also that all of the platforms on which IOS-XR
> runs (GSR, CRS-1/3, ASR9000) can all run full line rate IPv6 in
> hardware, with features.
> 
> While much of the IOS-XR vrs JunOS is personal preference, IOS-XR has
> one very cool feature.  You can pass parameters in route policy.  Many
> networks maintain slightly different versions of policies like
> "peer-in/peer-out" due to various load balancing or preference needs,
> with a 5-15 stanza policy repeated over and over.  When you have to
> update one of the stanzas in all policies it becomes a big mess.
> In IOS-XR, you can write a generic policy and then call with with
> parameters:
> 
> route-policy generic-out($routeCommunity)
>  ... ! Do all the common things
>  if community matches-any $routeCommunity then
>    accept
>  endif
>  drop
> end-policy
> 
> community-set send-to-private-peers
>  1234:5678
> end-set
> 
> route-policy private-peer-out
>  apply generic-out(send-to-private-peers)
> end-policy
> 
> community-set send-to-public-peers
>  1234:4321
> end-set
> 
> route-policy public-peer-out
>  apply generic-out(send-to-public-peers)
> end-policy
> 
> With a little bit of careful thought you can really collapse down the
> policy to be much shorter, easier to understand, and have almost no
> cut-and-paste in it, which should reduce errors when updating in the
> future.
> 
> -- 
>       Leo Bicknell - bicknell at ufp.org - CCIE 3440
>        PGP keys at http://www.ufp.org/~bicknell/


From keegan.holley at sungard.com  Mon Feb  6 22:58:42 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Mon, 6 Feb 2012 23:58:42 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <CAPWAtb+3yQjUmmJvfqOGqa2VY7j2WaSCmidcrvtfsHGY=HZQfg@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <73D3547A154D4F9AB0C61976A60C207B@usa.corp.radware.com>
 <Pine.LNX.4.64.1202070126150.14602@a84-22-97-10.cb3rob.net>
 <CAPWAtb+3yQjUmmJvfqOGqa2VY7j2WaSCmidcrvtfsHGY=HZQfg@mail.gmail.com>
Message-ID: <CABO8Q6QQQz5tYwq9MgwaL0SkDPjRA4gMd_=kVoFYgakVsiB5ZA@mail.gmail.com>

2012/2/6 Jeff Wheeler <jsw at inconcepts.biz>

> On Mon, Feb 6, 2012 at 8:43 PM, Sven Olaf Kamphuis <sven at cb3rob.net>
> wrote:
> > there is a fix for it, it's called "putting a fuckton of ram in -most-
> > routers on the internet" and keeping statistics for each destination
> > ip:destination port:outgoing interface so that none of them individually
> can
> > (entirely/procentually compared to other traffic) flood the outgoing
> > interface on that router... end result, if enough routers are structured
> > like that, is that ddos attacks will be come completely useless.
>
> There are two obvious problems with your approach.
>
> First, adding the policers you suggest, at the scale needed, is a
> little harder than you imagine.  It's not a simple matter of the cost
> of RAM but also power/heat density per port.
>

Since when are policers implemented in ram?  You're talking FPGA if you
want to be able to make forwarding/filtering decisions assuming it's
possible which it isn't you're 1 million dollar boxes suddenly become
hundred million dollar boxes.  Then there's v6 info..

>
> Second, if you re-engineer every router on the Internet to prevent an
> interface from being congested by malicious flow(s) destined for one
> particular destination IP:port, then DDoS attacks will simply target
> multiple ports or multiple destination IP addresses that are likely to
> traverse a link they are able to congest.
>


Not to mention that the routers themselves become an attack vector.  This
cache will have a finite limit because there's no such thing as an infinite
amount of cache among other flaws.  When that limit is reached it will do
something no one want's it to do and that will become the new DDOS attack.

>
> If you want to dramatically increase the cost of routers in order to
> solve the problem of DDoS with one deft (and expensive) move, you have
> to imagine that the people behind DDoS attacks aren't complete idiots,
> and will actually spend some time thinking about how to defeat your
> system.
>
> Not to mention cost?  You're not going to get a tier I ISP to upgrade to
this new super router (assuming it's possible to build such a things)
without an act of congress or at least the FCC.  They won't even spend
enough on fiber to bring broadband into rural areas.

From dr at cluenet.de  Tue Feb  7 00:32:07 2012
From: dr at cluenet.de (Daniel Roesen)
Date: Tue, 7 Feb 2012 07:32:07 +0100
Subject: Optimal IPv6 router
In-Reply-To: <28549ED9-622F-4F58-B2ED-5E09DBD8748B@gmail.com>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
 <20120206073426.GB8779@srv03.cluenet.de>
 <20120206141846.GB52936@ussenterprise.ufp.org>
 <28549ED9-622F-4F58-B2ED-5E09DBD8748B@gmail.com>
Message-ID: <20120207063207.GA23688@srv03.cluenet.de>

On Mon, Feb 06, 2012 at 08:23:20PM -0800, Rafael Rodriguez wrote:
> You can do the same with Junos (calling a 'generic' policy as a
> sub-routine).

You cannot pass parameters.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0


From peterehiwe at gmail.com  Tue Feb  7 00:37:06 2012
From: peterehiwe at gmail.com (Peter Ehiwe)
Date: Tue, 7 Feb 2012 07:37:06 +0100
Subject: DOS ATTACK ON BGP , LPTS ??
Message-ID: <CADECfTUJZpgxECBh=6MGZjCejn83gW8rOpO3_t7hJCcJ+EcbFQ@mail.gmail.com>

Hi ,
What is the best way to mitigate DOS attack against the bgp process of a
router , is LPTS on IOS-XR enough ?
Rgds
Peter

From rdobbins at arbor.net  Tue Feb  7 00:40:27 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 7 Feb 2012 06:40:27 +0000
Subject: DOS ATTACK ON BGP , LPTS ??
In-Reply-To: <CADECfTUJZpgxECBh=6MGZjCejn83gW8rOpO3_t7hJCcJ+EcbFQ@mail.gmail.com>
References: <CADECfTUJZpgxECBh=6MGZjCejn83gW8rOpO3_t7hJCcJ+EcbFQ@mail.gmail.com>
Message-ID: <EEF5841A-5CDB-4F19-8FFF-F9217C8C16B1@arbor.net>


On Feb 7, 2012, at 1:37 PM, Peter Ehiwe wrote:

> What is the best way to mitigate DOS attack against the bgp process of a router , 

iACLs and CoPP:

<https://files.me.com/roland.dobbins/prguob

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From peterehiwe at gmail.com  Tue Feb  7 00:52:20 2012
From: peterehiwe at gmail.com (Peter Ehiwe)
Date: Tue, 7 Feb 2012 07:52:20 +0100
Subject: DOS ATTACK ON BGP , LPTS ??
In-Reply-To: <D2155AE4-2A2A-46F4-A0AC-C2007B8DAAB2@arbor.net>
References: <CADECfTUJZpgxECBh=6MGZjCejn83gW8rOpO3_t7hJCcJ+EcbFQ@mail.gmail.com>
 <EEF5841A-5CDB-4F19-8FFF-F9217C8C16B1@arbor.net>
 <CADECfTUYsj+kz4xmWSjs2c7XPmK9mzH_tkBTNNWwTht0wdbQvw@mail.gmail.com>
 <D2155AE4-2A2A-46F4-A0AC-C2007B8DAAB2@arbor.net>
Message-ID: <CADECfTUaifA3TXUZkonwPwc62r01VJtR8TH_OJKXstACMniuYw@mail.gmail.com>

Thanks Roland,
Does anyone have a recommended value for tuning LPTS based on experience ?
Rgds
Peter

On Tue, Feb 7, 2012 at 7:45 AM, Dobbins, Roland <rdobbins at arbor.net> wrote:

>
> On Feb 7, 2012, at 1:43 PM, Peter Ehiwe wrote:
>
> > What is the attacker spoofs the correct peering address ,
>
> In that case, work with your peer(s) to get them to deploy anti-spoofing
> filters at their edges.
>
> > then iACL may not suffice , from experience is the default policer
> values for LPTS enough for XR routers
>
> Hard to say - look at CoPP/LPTS tuning.
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>                The basis of optimism is sheer terror.
>
>                          -- Oscar Wilde
>
>


-- 
Warm Regards

Peter(CCIE 23782).

From me at anuragbhatia.com  Tue Feb  7 02:46:19 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Tue, 7 Feb 2012 14:16:19 +0530
Subject: 2012.02.06 NANOG54 day1 afternoon session notes
In-Reply-To: <CAEmG1=rFts8PvX4m1djoWewbrpk0fpVRX_VOEi=2Pa4JrJko-A@mail.gmail.com>
References: <CAEmG1=rFts8PvX4m1djoWewbrpk0fpVRX_VOEi=2Pa4JrJko-A@mail.gmail.com>
Message-ID: <CAJ0+aXYDL82vN9wZ9qpEDiw2wo7_=ga+1NxV0iuZw7z67sZU6A@mail.gmail.com>

Thanks for sharing notes Matt.

Does anyone has archived video links of event? I enjoyed watching a couple
of sessions on live stream but due to low bandwidth it was pain to see in
pause-play-pause-play manner. Link to video archive will be very useful.


Thanks.

On Tue, Feb 7, 2012 at 7:34 AM, Matthew Petach <mpetach at netflight.com>wrote:

> My notes from the second half of today's NANOG 54
> talks are now up at
>
> http://kestrel3.netflight.com/2012.02.06-nanog54-afternoon-session.txt
>
> for those catching up remotely before the videos
> get posted up.
>
> Off to the Beer and Gear now.  ^_^
>
> Thanks!
>
> Matt
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
Linkedin: http://linkedin.anuragbhatia.com

From mpetach at netflight.com  Tue Feb  7 03:42:48 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Tue, 7 Feb 2012 01:42:48 -0800
Subject: 2012.02.06 NANOG54 day1 afternoon session notes
In-Reply-To: <CAJ0+aXYDL82vN9wZ9qpEDiw2wo7_=ga+1NxV0iuZw7z67sZU6A@mail.gmail.com>
References: <CAEmG1=rFts8PvX4m1djoWewbrpk0fpVRX_VOEi=2Pa4JrJko-A@mail.gmail.com>
 <CAJ0+aXYDL82vN9wZ9qpEDiw2wo7_=ga+1NxV0iuZw7z67sZU6A@mail.gmail.com>
Message-ID: <CAEmG1=r-rf5m+Zx4jVKENHdzZhTbnxFX7hrwxnKFB-5tvGsFyQ@mail.gmail.com>

On Tue, Feb 7, 2012 at 12:46 AM, Anurag Bhatia <me at anuragbhatia.com> wrote:
> Thanks for sharing notes Matt.
>
> Does anyone has archived video links of event? I enjoyed watching a couple
> of sessions on live stream but due to low bandwidth it was pain to see in
> pause-play-pause-play manner. Link to video archive will be very useful.

The archived video streams will generally be posted on the website
within a month or so;  it just requires a wee bit of patience.  ^_^

Thanks!

Matt

> Thanks.
>
> On Tue, Feb 7, 2012 at 7:34 AM, Matthew Petach <mpetach at netflight.com>
> wrote:
>>
>> My notes from the second half of today's NANOG 54
>> talks are now up at
>>
>> http://kestrel3.netflight.com/2012.02.06-nanog54-afternoon-session.txt
>>
>> for those catching up remotely before the videos
>> get posted up.
>>
>> Off to the Beer and Gear now. ?^_^
>>
>> Thanks!
>>
>> Matt
>>
>
>
>
> --
>
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
>
> Twitter: @anurag_bhatia
> Linkedin: http://linkedin.anuragbhatia.com
>


From annkwok80 at gmail.com  Tue Feb  7 07:32:21 2012
From: annkwok80 at gmail.com (Ann Kwok)
Date: Tue, 7 Feb 2012 08:32:21 -0500
Subject: Switch and router
In-Reply-To: <D1AC84E0-29C1-4BC2-A732-A023B76D9476@mac.com>
References: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>
 <D1AC84E0-29C1-4BC2-A732-A023B76D9476@mac.com>
Message-ID: <CACwqZxgiOCP0g-jOoFHTqkaDSRXD-ygnvkOsrqwUEFf1XWP5dQ@mail.gmail.com>

Hello

Thank you for your help

But we can't increase the pipe as we are using 10G switch.

The congestion happens when the traffic is using 7G

Any idea?

In addition, how to determine the congestion happens in router or switch.

Thank you

On Mon, Feb 6, 2012 at 4:56 PM, Fabien Delmotte <fdelmotte1 at mac.com> wrote:

> Hi
> Forget flow control, because you will use buffer and at the someone will
> not understant pause frame.
> Another issue is : with pause frame you block all the traffic from the
> outbound port ... So very dangerous.
> Best way : big pipe.
>
> Regards
>
> Fabien
>
> Envoy? de mon iPad
>
> Le 6 f?vr. 2012 ? 22:41, Ann Kwok <annkwok80 at gmail.com> a ?crit :
>
> > Hello
> >
> > There is big congestion between router and switch
> >
> > I read some documents about flowcontral
> >
> > Do I disable or adjust flowcontral at the same?
> >
> > Can flowcontral solve the congestion issue?
> >
> > How can I adjust flowcontral in cisco router and HP switch?
> >
> > Thank you so much
>

From streiner at cluebyfour.org  Tue Feb  7 08:04:35 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Tue, 7 Feb 2012 09:04:35 -0500 (EST)
Subject: Switch and router
In-Reply-To: <CACwqZxgiOCP0g-jOoFHTqkaDSRXD-ygnvkOsrqwUEFf1XWP5dQ@mail.gmail.com>
References: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>
 <D1AC84E0-29C1-4BC2-A732-A023B76D9476@mac.com>
 <CACwqZxgiOCP0g-jOoFHTqkaDSRXD-ygnvkOsrqwUEFf1XWP5dQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202070853100.24619@whammy.cluebyfour.org>

On Tue, 7 Feb 2012, Ann Kwok wrote:

> Thank you for your help
>
> But we can't increase the pipe as we are using 10G switch.
>
> The congestion happens when the traffic is using 7G
>
> Any idea?
>
> In addition, how to determine the congestion happens in router or switch.

Different manufacturers and platforms have different ways of indicating 
the presence of congestion.  Some will not explicitly report it, so you 
end up having to go back and look at performance statistics on your devices
(per-interface traffic, overall traffic and/or traffic per ASIC group, 
CPU/memory/buffer utilization, link errors, overruns, etc).

Whichever manufacturers you use will likely have lots of resources 
available through their websites/support channels for troubleshooting 
congestion.

I'm going to go out on a limb here and take a guess that Ann = Deric, 
using a different address?

jms

> On Mon, Feb 6, 2012 at 4:56 PM, Fabien Delmotte <fdelmotte1 at mac.com> wrote:
>
>> Hi
>> Forget flow control, because you will use buffer and at the someone will
>> not understant pause frame.
>> Another issue is : with pause frame you block all the traffic from the
>> outbound port ... So very dangerous.
>> Best way : big pipe.
>>
>> Regards
>>
>> Fabien
>>
>> Envoy? de mon iPad
>>
>> Le 6 f?vr. 2012 ? 22:41, Ann Kwok <annkwok80 at gmail.com> a ?crit :
>>
>>> Hello
>>>
>>> There is big congestion between router and switch
>>>
>>> I read some documents about flowcontral
>>>
>>> Do I disable or adjust flowcontral at the same?
>>>
>>> Can flowcontral solve the congestion issue?
>>>
>>> How can I adjust flowcontral in cisco router and HP switch?
>>>
>>> Thank you so much
>>
>

From jgreco at ns.sol.net  Tue Feb  7 08:28:25 2012
From: jgreco at ns.sol.net (Joe Greco)
Date: Tue, 7 Feb 2012 08:28:25 -0600 (CST)
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6QQQz5tYwq9MgwaL0SkDPjRA4gMd_=kVoFYgakVsiB5ZA@mail.gmail.com>
Message-ID: <201202071428.q17ESPLA083237@aurora.sol.net>

> Since when are policers implemented in ram?  You're talking FPGA if you
> want to be able to make forwarding/filtering decisions assuming it's
> possible which it isn't you're 1 million dollar boxes suddenly become
> hundred million dollar boxes.  Then there's v6 info..

Of course it's not possible ... if you use a crummy design.  It's trivial
to come up with non-completely-crummy designs.  For example, adding a
front-end where you take a hash of source-ip/dest-ip and run it through
a smallish hash table, you can use that as a filter to eliminate a lot
of traffic that's just normal and non-interesting.  You want to take a
closer look at the traffic that's heaviest (read: most hits) or new and
significant (read: diff against an hour ago).  You probably don't want
to do this just per-IP, but likely also per-network.  And you probably
don't want to use just this one technique, you want to combine it with
others.  And you probably need to consider the types of attacks that
are known, likely, etc., and design accordingly, because this one little
example I've provided is just one part of a comprehensive solution, but
it is capable of dealing with any amount of traffic and it would be a
very useful filter to start pulling out potentially interesting stuff.

This stuff isn't *easy*.  Fine.  But it certainly *is* possible.

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


From rsm at fast-serv.com  Tue Feb  7 10:55:03 2012
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 7 Feb 2012 11:55:03 -0500
Subject: Switch and router
In-Reply-To: <CACwqZxgiOCP0g-jOoFHTqkaDSRXD-ygnvkOsrqwUEFf1XWP5dQ@mail.gmail.com>
References: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>
 <D1AC84E0-29C1-4BC2-A732-A023B76D9476@mac.com>
 <CACwqZxgiOCP0g-jOoFHTqkaDSRXD-ygnvkOsrqwUEFf1XWP5dQ@mail.gmail.com>
Message-ID: <20120207165202.M37729@fast-serv.com>

On Tue, 7 Feb 2012 08:32:21 -0500, Ann Kwok wrote
> Hello
> 
> Thank you for your help
> 
> But we can't increase the pipe as we are using 10G switch.
> 
> The congestion happens when the traffic is using 7G

If you cannot increase bandwidth, then you must increase the TX queue (in QOS
and/or port buffer).

~Randy



From gbonser at seven.com  Tue Feb  7 12:05:03 2012
From: gbonser at seven.com (George Bonser)
Date: Tue, 7 Feb 2012 18:05:03 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <201202071428.q17ESPLA083237@aurora.sol.net>
References: <CABO8Q6QQQz5tYwq9MgwaL0SkDPjRA4gMd_=kVoFYgakVsiB5ZA@mail.gmail.com>
 <201202071428.q17ESPLA083237@aurora.sol.net>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBA094@RWC-MBX1.corp.seven.com>

> Of course it's not possible ... if you use a crummy design.  It's
> trivial to come up with non-completely-crummy designs.  For example,
> adding a front-end where you take a hash of source-ip/dest-ip and run
> it through a smallish hash table, you can use that as a filter to
> eliminate a lot of traffic that's just normal and non-interesting.  You
> want to take a closer look at the traffic that's heaviest (read: most
> hits) or new and significant (read: diff against an hour ago).  You
> probably don't want to do this just per-IP, but likely also per-
> network. 

I think one of the problems is that with modern bot-nets, traffic can be generated by a huge number of hosts and assuming your DoS traffic is coming from a source that can be blocked might be an unreasonable expectation.  You can't assume that you are going to get a flood of traffic from some source that you can pin down and block.  You might get flood of traffic from tens of thousands of source IPs from all over the world with each one sending only a very small amount AND the source IPs constantly changing.  They might even be sending traffic that looks perfectly legitimate on the surface and might need to be profiled/fingerprinted in some manner at layer 4.  It isn't as easy as just handling it at the router.  And there is no guarantee the source IP of the traffic is really where it is coming from since there are still a good number of providers out there who don't install packet filters on their customer links.  They accept any traffic their customer sends them even if the source IP isn't within the customer's network range.  So that is part of the game, too.  If you have 10,000 hosts sending packets with spoofed IP addresses where the goal is to get you to block the apparent source network, as soon as you block those source addresses, the DoS has succeeded.


> And you probably don't want to use just this one technique,
> you want to combine it with others.  

I think "probably" is the wrong word here.  The word "certainly" leaps to mind.

> And you probably need to consider
> the types of attacks that are known, likely, etc., and design
> accordingly, because this one little example I've provided is just one
> part of a comprehensive solution, but it is capable of dealing with any
> amount of traffic and it would be a very useful filter to start pulling
> out potentially interesting stuff.

The problem is that you have a game of cat and mouse with what amounts to an infinite supply of mice.  It takes cooperation between the source and the provider networks.  The "eyeball" heavy networks need to ensure they can't source bogus traffic.  Having gear these days where the ACLs are in hardware has greatly reduced the CPU expense of filtering on edge ports but the human resource expense of maintaining those is still high unless automation is brought into the mix so that those filters are changed when the addresses served by a port change.

> This stuff isn't *easy*.  Fine.  But it certainly *is* possible.

Of course it isn't easy.  It is designed to be difficult.  But there is plenty of "low hanging fruit" out there still.



From gbonser at seven.com  Tue Feb  7 12:06:28 2012
From: gbonser at seven.com (George Bonser)
Date: Tue, 7 Feb 2012 18:06:28 +0000
Subject: Switch and router
In-Reply-To: <20120207165202.M37729@fast-serv.com>
References: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>
 <D1AC84E0-29C1-4BC2-A732-A023B76D9476@mac.com>
 <CACwqZxgiOCP0g-jOoFHTqkaDSRXD-ygnvkOsrqwUEFf1XWP5dQ@mail.gmail.com>
 <20120207165202.M37729@fast-serv.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBA0AB@RWC-MBX1.corp.seven.com>

> 
> On Tue, 7 Feb 2012 08:32:21 -0500, Ann Kwok wrote
> > Hello
> >
> > Thank you for your help
> >
> > But we can't increase the pipe as we are using 10G switch.
> >
> > The congestion happens when the traffic is using 7G
> 
> If you cannot increase bandwidth, then you must increase the TX queue
> (in QOS and/or port buffer).
> 
> ~Randy
> 

Or the congestion could be further upstream or the flows might be high latency TCP and are being throttled because of the network latency. There could be any number of issues.



From sven at cb3rob.net  Tue Feb  7 12:04:52 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Tue, 7 Feb 2012 18:04:52 +0000 (UTC)
Subject: Switch and router
In-Reply-To: <20120207165202.M37729@fast-serv.com>
References: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>
 <D1AC84E0-29C1-4BC2-A732-A023B76D9476@mac.com>
 <CACwqZxgiOCP0g-jOoFHTqkaDSRXD-ygnvkOsrqwUEFf1XWP5dQ@mail.gmail.com>
 <20120207165202.M37729@fast-serv.com>
Message-ID: <Pine.LNX.4.64.1202071800490.7180@a84-22-97-10.cb3rob.net>

"increase pipe" = port trunking/etherchannel/port bonding whatever your 
supplier calls it. just use 2 or 4 ports instead of just one.

ieee 802.3ad/lacp/link aggregation, etc.... all the same stuff. ;)

provided you have another interface on/for your router ofcourse (your 
switch probably has plenty ;)

also an option (for cisco)...

int gix/x/x
max-reserved-bandwidth 1

(i'd say, 1% of 10ge should about cover all the needs for inband layer-2 
related stuff as a few kbit/s already should suffice ;)

1% being the minimum you can set this to.

-- 
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=========================================================================
Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
          D-13359                   Registration:    HRA 42834 B
          BERLIN                    Phone:           +31/(0)87-8747479
          Germany                   GSM:             +49/(0)152-26410799
RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
=========================================================================
<penpen> C3P0, der elektrische Westerwelle
http://www.facebook.com/cb3rob
=========================================================================

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Tue, 7 Feb 2012, Randy McAnally wrote:

> On Tue, 7 Feb 2012 08:32:21 -0500, Ann Kwok wrote
>> Hello
>>
>> Thank you for your help
>>
>> But we can't increase the pipe as we are using 10G switch.
>>
>> The congestion happens when the traffic is using 7G
>
> If you cannot increase bandwidth, then you must increase the TX queue (in QOS
> and/or port buffer).
>
> ~Randy
>
>


From xionox at gmail.com  Tue Feb  7 13:19:42 2012
From: xionox at gmail.com (Arzhel Younsi)
Date: Tue, 7 Feb 2012 20:19:42 +0100
Subject: Wireless Recommendations
In-Reply-To: <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
Message-ID: <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>

Xirrus say that they can support 640 clients with this device:
http://www.xirrus.com/Products/Wireless-Arrays/XR-Series/XR-4000-Series
I heard about it a couple weeks ago, didn't try it yet.

On Wed, Feb 1, 2012 at 02:09, Mario Eirea <meirea at charterschoolit.com> wrote:
> Aruba AP 105. This version comes with a virtual controller that can manage 16 APs without the need of an additional controller. For high capacity areas I would go with Ruckus.
>
> -Mario Eirea
>
> On Jan 31, 2012, at 11:46 AM, "Joel jaeggli" <joelja at bogus.com> wrote:
>
>> On 1/30/12 12:46 , Jim Gonzalez wrote:
>>> Hi,
>>>
>>> ? ? ? ? ? ? ? ?I am looking for a Wireless bridge or Router that will
>>> support 600 wireless clients concurrently (mostly cell phones). ?I need it
>>> for a proof of concept.
>>
>> an aruba controller and 8 dual radio aps.
>>
>>>
>>>
>>>
>>>
>>> Thanks in advance
>>>
>>> Jim
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1416 / Virus Database: 2109/4778 - Release Date: 01/31/12
>


From source_route at yahoo.com  Tue Feb  7 13:43:24 2012
From: source_route at yahoo.com (Philip Lavine)
Date: Tue, 7 Feb 2012 11:43:24 -0800 (PST)
Subject: issues with Level3 in NYC
Message-ID: <1328643804.47714.YahooMailNeo@web30801.mail.mud.yahoo.com>

Anybody having issues with peering with Level3 in NYC

From jof at thejof.com  Tue Feb  7 13:50:20 2012
From: jof at thejof.com (Jonathan Lassoff)
Date: Tue, 7 Feb 2012 11:50:20 -0800
Subject: Wireless Recommendations
In-Reply-To: <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
 <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>
Message-ID: <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>

On Tue, Feb 7, 2012 at 11:19 AM, Arzhel Younsi <xionox at gmail.com> wrote:
> Xirrus say that they can support 640 clients with this device:
> http://www.xirrus.com/Products/Wireless-Arrays/XR-Series/XR-4000-Series
> I heard about it a couple weeks ago, didn't try it yet.

That's a pretty neat product -- it seems like it takes care of
spectrally isolating clients by utilizing 4 - 8 radios per AP-box and
8 - 24 directional sector antennas.

I feel like this addresses the suggestions that I and others gave to
utilize more APs rather than a big central one, but it just packages
it all into one box with many antennas.

Cheers,
jof


From me at anuragbhatia.com  Tue Feb  7 13:57:18 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Wed, 8 Feb 2012 01:27:18 +0530
Subject: issues with Level3 in NYC
In-Reply-To: <1328643804.47714.YahooMailNeo@web30801.mail.mud.yahoo.com>
References: <1328643804.47714.YahooMailNeo@web30801.mail.mud.yahoo.com>
Message-ID: <CAJ0+aXb=hgO8dVfMHeZP7-Fkn9XuFvmGUAW-f9B=VA=odYM8yA@mail.gmail.com>

I checked couple of main networks from NYC site via Level3's looking
glass<http://lookingglass.level3.net/>.
It went fine.

What's your network's ASN?

On Wed, Feb 8, 2012 at 1:13 AM, Philip Lavine <source_route at yahoo.com>wrote:

> Anybody having issues with peering with Level3 in NYC
>



-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
Linkedin: http://linkedin.anuragbhatia.com

From mpetach at netflight.com  Tue Feb  7 15:01:51 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Tue, 7 Feb 2012 13:01:51 -0800
Subject: 2012.02.07 NANOG54 day 2 morning session notes
Message-ID: <CAEmG1=o6ui8L+GjVBr-gHV0Djekz2G9cFe1oFaCyiGvQaPWTTg@mail.gmail.com>

I've posted my notes from the morning session at

http://kestrel3.netflight.com/2012.02.07-nanog54-morning-session.txt

for those who find them useful.

Off to grab lunch now!

BTW--wouldn't deploying the telex proxy require ISPs to do
away with BCP 38 in their networks?

Just curious.

Thanks!

Matt


From matt at mattreath.com  Tue Feb  7 15:31:21 2012
From: matt at mattreath.com (Matthew Reath)
Date: Tue, 7 Feb 2012 15:31:21 -0600
Subject: Firewalls in service provider environments
Message-ID: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>

All,

Looking for some recommendations on firewall placement in service provider
environments.  I'm of the school of thought that in my SP network I do as
little firewalling/packet filtering as possible. As in none, leave that to
my end users or offer a "managed" firewall solution where if a customer
signs up for the extra service I put him in a VRF or VLAN that is "behind"
a firewall and manage that solution for them. Otherwise I don't prefer to
have a firewall inline in my service provider network for all customer
traffic to go through. I can accomplish filtering of known bad ports on my
edge routers either facing my customers or upstream providers.

What is the group's thought on this?

-Matt

--
Matt Reath
CCIE #27316 (SP)
matt at mattreath.com | http://mattreath.com
Twitter: http://twitter.com/mpreath



From leigh.porter at ukbroadband.com  Tue Feb  7 15:42:34 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Tue, 7 Feb 2012 21:42:34 +0000
Subject: Firewalls in service provider environments
In-Reply-To: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
Message-ID: <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Matthew Reath [mailto:matt at mattreath.com]
> Sent: 07 February 2012 21:34
> To: nanog at nanog.org
> Subject: Firewalls in service provider environments
> 
> All,
> 
> Looking for some recommendations on firewall placement in service
> provider
> environments.  I'm of the school of thought that in my SP network I do
> as
> little firewalling/packet filtering as possible. As in none, 

I had a vendor actually suggest that that ALL my customer traffic should traverse a firewall. I asked why and they said "Ahhh it the internet, must have firewall". I suppose this must have been a great firewall.

So yes I would agree with you, firewall nothing for your customers unless they are paying you for a specific service. Filtering known bad ports, well, what's a known bad port? Bad for one person may be quite important for another. Whilst filtering port 25 outbound may help prevent some bots from emanating spam, it certainly does a lot to annoy other people.

--
Leigh Porter


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


From streiner at cluebyfour.org  Tue Feb  7 15:46:04 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Tue, 7 Feb 2012 16:46:04 -0500 (EST)
Subject: Firewalls in service provider environments
In-Reply-To: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
Message-ID: <Pine.LNX.4.64.1202071636030.24619@whammy.cluebyfour.org>

On Tue, 7 Feb 2012, Matthew Reath wrote:

> Looking for some recommendations on firewall placement in service provider
> environments.  I'm of the school of thought that in my SP network I do as
> little firewalling/packet filtering as possible. As in none, leave that to
> my end users or offer a "managed" firewall solution where if a customer
> signs up for the extra service I put him in a VRF or VLAN that is "behind"
> a firewall and manage that solution for them. Otherwise I don't prefer to
> have a firewall inline in my service provider network for all customer
> traffic to go through. I can accomplish filtering of known bad ports on my
> edge routers either facing my customers or upstream providers.

I tend to agree with this, and I think you'll find that most providers 
agree with that as well.

There are several reasons for this:
1. Firewalls present another point of failure, and SPs are generally loath 
to force customer traffic* through another choke point.
2. Many firewall appliances are stateful.  Multihomed customers and 
stateful firewalls can be a major headache.  Asymmetric routing through 
stateful firewalls is pretty much a non-starter.
3. You (the customer) know your applications and internal network better 
than the SP does.  It makes sense for you to manage your firewalls/NAT/
internal LAN.  If you can't or don't want to do this, hire a consultant to 
do the work for you.
4. Most SPs would not want the liability of managing firewall service.
5. Dropping packets at the SP edge could be done, but I think most SPs 
would only want to do so in extraordinary circumstances.

* - As you mentioned, unless the SP offers, and those customers 
specifically pay for a firewalled service.

jms


From matt at mattreath.com  Tue Feb  7 15:52:04 2012
From: matt at mattreath.com (Matthew Reath)
Date: Tue, 7 Feb 2012 15:52:04 -0600
Subject: Firewalls in service provider environments
In-Reply-To: <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
Message-ID: <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>

>
>
>> -----Original Message-----
>> From: Matthew Reath [mailto:matt at mattreath.com]
>> Sent: 07 February 2012 21:34
>> To: nanog at nanog.org
>> Subject: Firewalls in service provider environments
>>
>> All,
>>
>> Looking for some recommendations on firewall placement in service
>> provider
>> environments.  I'm of the school of thought that in my SP network I do
>> as
>> little firewalling/packet filtering as possible. As in none,
>
> I had a vendor actually suggest that that ALL my customer traffic should
> traverse a firewall. I asked why and they said "Ahhh it the internet, must
> have firewall". I suppose this must have been a great firewall.
>
> So yes I would agree with you, firewall nothing for your customers unless
> they are paying you for a specific service. Filtering known bad ports,
> well, what's a known bad port? Bad for one person may be quite important
> for another. Whilst filtering port 25 outbound may help prevent some bots
> from emanating spam, it certainly does a lot to annoy other people.
>
> --
> Leigh Porter
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
>

>From a filtering perspective there are some know worm ports and such that
we usually have a template created for.

Here is the template we typically use (or a variant of it):

<-- snippet -->
access-list 102 deny   ip 10.0.0.0 0.255.255.255 any
access-list 102 deny   ip 172.16.0.0 0.15.255.255 any
access-list 102 deny   ip 192.168.0.0 0.0.255.255 any
access-list 102 deny   ip 0.0.0.0 0.255.255.255 any
access-list 102 deny   ip 127.0.0.0 0.255.255.255 any
access-list 102 deny   ip 224.0.0.0 15.255.255.255 any
access-list 102 deny   ip host 255.255.255.255 any
access-list 102 deny   tcp any any eq 135
access-list 102 deny   udp any any eq 135
access-list 102 deny   udp any any eq netbios-ns
access-list 102 deny   tcp any any eq 139
access-list 102 deny   udp any any eq netbios-ss
access-list 102 deny   tcp any any eq 445
access-list 102 deny   tcp any any eq 593
access-list 102 deny   tcp any any eq 4444
access-list 102 deny   tcp any any eq 9996
access-list 102 deny   tcp any any eq 5554
access-list 102 deny   tcp any any eq 8888
access-list 102 deny   tcp any any eq 7778
access-list 102 deny   tcp any any eq 8594
access-list 102 deny   tcp any any eq 8563
access-list 102 deny   tcp any any eq 1434
<-- end snippet -->

This blocks some common worm ports as well as traffic sourced outside of
our network from reserved address space.

-Matt




From bill at herrin.us  Tue Feb  7 16:10:35 2012
From: bill at herrin.us (William Herrin)
Date: Tue, 7 Feb 2012 17:10:35 -0500
Subject: Firewalls in service provider environments
In-Reply-To: <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
Message-ID: <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>

On Tue, Feb 7, 2012 at 4:52 PM, Matthew Reath <matt at mattreath.com> wrote:
> Here is the template we typically use (or a variant of it):
>
> <-- snippet -->
> access-list 102 deny ? ip 10.0.0.0 0.255.255.255 any
> access-list 102 deny ? ip 172.16.0.0 0.15.255.255 any
> access-list 102 deny ? ip 192.168.0.0 0.0.255.255 any
> access-list 102 deny ? ip 0.0.0.0 0.255.255.255 any
> access-list 102 deny ? ip 127.0.0.0 0.255.255.255 any
> access-list 102 deny ? ip 224.0.0.0 15.255.255.255 any
> access-list 102 deny ? ip host 255.255.255.255 any
> access-list 102 deny ? tcp any any eq 135
> access-list 102 deny ? udp any any eq 135
> access-list 102 deny ? udp any any eq netbios-ns
> access-list 102 deny ? tcp any any eq 139
> access-list 102 deny ? udp any any eq netbios-ss
> access-list 102 deny ? tcp any any eq 445
> access-list 102 deny ? tcp any any eq 593
> access-list 102 deny ? tcp any any eq 4444
> access-list 102 deny ? tcp any any eq 9996
> access-list 102 deny ? tcp any any eq 5554
> access-list 102 deny ? tcp any any eq 8888
> access-list 102 deny ? tcp any any eq 7778
> access-list 102 deny ? tcp any any eq 8594
> access-list 102 deny ? tcp any any eq 8563
> access-list 102 deny ? tcp any any eq 1434
> <-- end snippet -->

One of my customers has a list like that. They can't understand why
one in every hundred or so TCP connections on port 443 fails.

Hint: you forgot "access-list 102 permit tcp any any established"
after "access-list 102 deny   ip host 255.255.255.255 any". The
destination port in one direction is the source port in the other and
many of those are dynamic source ports picked by Windows. Unless you
restrict that filter to just packets attempting to initiate a new
connection, you're shooting yourself in the foot.

Regards,
Bill Herrin




-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From bill at herrin.us  Tue Feb  7 16:22:38 2012
From: bill at herrin.us (William Herrin)
Date: Tue, 7 Feb 2012 17:22:38 -0500
Subject: Firewalls in service provider environments
In-Reply-To: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
Message-ID: <CAP-guGXcc6JUn=67-YnMAGL36+zxMFLzT4s-2U1+V1Ax+ij78Q@mail.gmail.com>

On Tue, Feb 7, 2012 at 4:31 PM, Matthew Reath <matt at mattreath.com> wrote:
> Looking for some recommendations on firewall placement in service provider
> environments. ?I'm of the school of thought that in my SP network I do as
> little firewalling/packet filtering as possible. As in none, leave that to
> my end users or offer a "managed" firewall solution where if a customer
> signs up for the extra service I put him in a VRF or VLAN that is "behind"
> a firewall and manage that solution for them. Otherwise I don't prefer to
> have a firewall inline in my service provider network for all customer
> traffic to go through. I can accomplish filtering of known bad ports on my
> edge routers either facing my customers or upstream providers.
>
> What is the group's thought on this?

Hi Matthew,

It Depends.

High end business customers (of the BGP speaking variety) generally
appreciate having a remote triggered black hole facility. That's a
kind of firewall. http://tools.ietf.org/html/rfc5635

Business customers in general shouldn't be filtered unless they buy a
managed firewall service from you. Don't tamper with their DNS either!

When you get down to the residential and Internet Cafe type users,
there is some common filtering you should consider:

TCP SYN to port 25 outbound from your dynamic IP customers should
generally be disallowed except to your local mail servers. 99 times
out of 100, connections originating to this port from dynamic IP
customers will be Email Spam from an infected PC. This will hurt you.
It will hurt you with spam complaints. It will hurt you with adverse
action by RBL providers. It will hurt you with damage to your
reputation and brand.

http://www.spamhaus.org/faq/answers.lasso?section=isp%20spam%20issues#133


Blocking TCP and UDP 137, 138, 139 and 445 is not terribly unusual.
These are associated with Microsoft file sharing protocols. Off the
LAN and outside the enterprise anybody actually open to this traffic
is generally asking to be hacked. Then a spam bot is installed and you
have another problem customer who isn't paying you enough to deal with
that crap.

Regards,
Bill Herrin





-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From gbonser at seven.com  Tue Feb  7 16:34:07 2012
From: gbonser at seven.com (George Bonser)
Date: Tue, 7 Feb 2012 22:34:07 +0000
Subject: Firewalls in service provider environments
In-Reply-To: <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBB5C5@RWC-MBX1.corp.seven.com>

> 
> Here is the template we typically use (or a variant of it):
> 
> <-- snippet -->
> access-list 102 deny   ip 10.0.0.0 0.255.255.255 any
> access-list 102 deny   ip 172.16.0.0 0.15.255.255 any
> access-list 102 deny   ip 192.168.0.0 0.0.255.255 any
> access-list 102 deny   ip 0.0.0.0 0.255.255.255 any
> access-list 102 deny   ip 127.0.0.0 0.255.255.255 any
> access-list 102 deny   ip 224.0.0.0 15.255.255.255 any
> access-list 102 deny   ip host 255.255.255.255 any

I typically also include traffic to/from:

TCP/UDP port 0
169.254.0.0/16
192.0.2.0/24
198.51.100.0/24
203.0.113.0/24

Been wondering if I should also block 198.18.0.0/15 as well.





From matt at mattreath.com  Tue Feb  7 16:35:44 2012
From: matt at mattreath.com (Matthew Reath)
Date: Tue, 7 Feb 2012 16:35:44 -0600
Subject: Firewalls in service provider environments
In-Reply-To: <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
Message-ID: <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>

> On Tue, Feb 7, 2012 at 4:52 PM, Matthew Reath <matt at mattreath.com> wrote:
>> Here is the template we typically use (or a variant of it):
>>
>> <-- snippet -->
>> access-list 102 deny ? ip 10.0.0.0 0.255.255.255 any
>> access-list 102 deny ? ip 172.16.0.0 0.15.255.255 any
>> access-list 102 deny ? ip 192.168.0.0 0.0.255.255 any
>> access-list 102 deny ? ip 0.0.0.0 0.255.255.255 any
>> access-list 102 deny ? ip 127.0.0.0 0.255.255.255 any
>> access-list 102 deny ? ip 224.0.0.0 15.255.255.255 any
>> access-list 102 deny ? ip host 255.255.255.255 any
>> access-list 102 deny ? tcp any any eq 135
>> access-list 102 deny ? udp any any eq 135
>> access-list 102 deny ? udp any any eq netbios-ns
>> access-list 102 deny ? tcp any any eq 139
>> access-list 102 deny ? udp any any eq netbios-ss
>> access-list 102 deny ? tcp any any eq 445
>> access-list 102 deny ? tcp any any eq 593
>> access-list 102 deny ? tcp any any eq 4444
>> access-list 102 deny ? tcp any any eq 9996
>> access-list 102 deny ? tcp any any eq 5554
>> access-list 102 deny ? tcp any any eq 8888
>> access-list 102 deny ? tcp any any eq 7778
>> access-list 102 deny ? tcp any any eq 8594
>> access-list 102 deny ? tcp any any eq 8563
>> access-list 102 deny ? tcp any any eq 1434
>> <-- end snippet -->
>
> One of my customers has a list like that. They can't understand why
> one in every hundred or so TCP connections on port 443 fails.
>
> Hint: you forgot "access-list 102 permit tcp any any established"
> after "access-list 102 deny   ip host 255.255.255.255 any". The
> destination port in one direction is the source port in the other and
> many of those are dynamic source ports picked by Windows. Unless you
> restrict that filter to just packets attempting to initiate a new
> connection, you're shooting yourself in the foot.
>
> Regards,
> Bill Herrin
>
>
>
>
> --
> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
>

Yeah agreed.  The only place this gets applied is inbound on the interface
facing an upstream provider. ACLs ingress from end customers are much
different. In theory this could cause issues with externally initiated
traffic that use lets say 8888 as its random source port.

-Matt






From jared at puck.nether.net  Tue Feb  7 16:46:36 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 7 Feb 2012 17:46:36 -0500
Subject: Firewalls in service provider environments
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBB5C5@RWC-MBX1.corp.seven.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBB5C5@RWC-MBX1.corp.seven.com>
Message-ID: <2F517843-FA2E-4198-8E8C-2055DEE7B523@puck.nether.net>

Yes, you should.

On Feb 7, 2012, at 5:34 PM, George Bonser wrote:

> Been wondering if I should also block 198.18.0.0/15 as well.



From matt at overloaded.net  Tue Feb  7 16:59:35 2012
From: matt at overloaded.net (Matt Buford)
Date: Tue, 7 Feb 2012 16:59:35 -0600
Subject: Firewalls in service provider environments
In-Reply-To: <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
 <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>
Message-ID: <CAALUyuRJ4pob=97fk=ph39ey3zvpbNC4COtzMBaeOai+LfDGxw@mail.gmail.com>

On Tue, Feb 7, 2012 at 4:35 PM, Matthew Reath <matt at mattreath.com> wrote:

> > One of my customers has a list like that. They can't understand why
> > one in every hundred or so TCP connections on port 443 fails.
> >
> > Hint: you forgot "access-list 102 permit tcp any any established"
> > after "access-list 102 deny   ip host 255.255.255.255 any". The
> > destination port in one direction is the source port in the other and
> > many of those are dynamic source ports picked by Windows. Unless you
> > restrict that filter to just packets attempting to initiate a new
> > connection, you're shooting yourself in the foot.
>
> Yeah agreed.  The only place this gets applied is inbound on the interface
> facing an upstream provider. ACLs ingress from end customers are much
> different. In theory this could cause issues with externally initiated
> traffic that use lets say 8888 as its random source port.
>

If you apply the ACL you showed as an inbound ACL on your provider facing
interfaces, you will be breaking any connections that exit your network
with source ports from your list of bad ports.  For example, you connect
out from x.x.x.x:8888 to y.y.y.y:80, then the response packets coming back
into your network will be from y.y.y.y:80 to x.x.x.x:8888 and will be
dropped by your ACL.

This seems to be a common mistake, and is often missed because it manifests
as one-in-thousands failures of TCP connections.  People tend to just try a
second time and it works and never investigate why they had one random
failure.

From morrowc.lists at gmail.com  Tue Feb  7 16:59:47 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 7 Feb 2012 17:59:47 -0500
Subject: Firewalls in service provider environments
In-Reply-To: <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
Message-ID: <CAL9jLaY8Fki-3Kn0uTMHEApiJqa3fC1FbOUMW9mLp2N5f2ScpA@mail.gmail.com>

On Tue, Feb 7, 2012 at 4:42 PM, Leigh Porter
<leigh.porter at ukbroadband.com> wrote:
>
>
>> -----Original Message-----
>> From: Matthew Reath [mailto:matt at mattreath.com]
>> Sent: 07 February 2012 21:34
>> To: nanog at nanog.org
>> Subject: Firewalls in service provider environments
>>
>> All,
>>
>> Looking for some recommendations on firewall placement in service
>> provider
>> environments. ?I'm of the school of thought that in my SP network I do
>> as
>> little firewalling/packet filtering as possible. As in none,
>
> I had a vendor actually suggest that that ALL my customer traffic should traverse a firewall. I asked why and they said "Ahhh it the internet, must have firewall". I suppose this must have been a great firewall.

'of china'! ha! hahaha.... anyway.

> So yes I would agree with you, firewall nothing for your customers unless they are paying you for a specific service. Filtering known bad ports, well, what's a known bad port? Bad for one person may be quite important for another. Whilst filtering port 25 outbound may help prevent some bots from emanating spam, it certainly does a lot to annoy other people.
>

I think for a purely SP network, transit-provider core links sort of
thing, why filter anything at all? why filter anything that's not
destined to your own equipment? You can't possibly know what some
customer (or set of customers) are going to do with their traffic, so
you can't possibly filter it sanely/safely.

for a consumer ISP, provided your TOS says it's ok, why not filter
some common problems:
  tcp/25
  ... not much else really... and REALLY you just want to send tcp/25
-> 587 on your mail-relays (or redirect to internal use addresses on
the relays).

If customers (in either case) want to pay you for 'security services'
then rock some filters on their CPE, with the option to move that
upstream to your PE if you have to (too much crap on customer link).

-chris


From mysidia at gmail.com  Tue Feb  7 18:51:16 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 7 Feb 2012 18:51:16 -0600
Subject: Firewalls in service provider environments
In-Reply-To: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
Message-ID: <CAAAwwbXcE-1PhPNoNN9DL9XZ8M9qz7Q_c=wwTNY_i0ri1pdPUg@mail.gmail.com>

On Tue, Feb 7, 2012 at 3:31 PM, Matthew Reath <matt at mattreath.com> wrote:

> traffic to go through. I can accomplish filtering of known bad ports on my
> edge routers either facing my customers or upstream providers.
>

I wouldn't want my provider breaking my connectivity in the name of
security. My thought on this is:  by all means filter, firewall, and
mangle  packets addressed  From/To service provider equipment  (for
example, port 22 TCP packets sent to the address of the ISP router),  in
order to protect ISP network,     But, with some minor exceptions, in your
role as ISP, internal firewalls should be separate from customer networks,
and,  never ever filter, firewall, or mangle packets _forwarded_ by service
provider equipment To/From customer networks.

If you manage the downstream network,  the customer has requested special
filtering or restrictions,  or  a pattern of abuse has been detected from a
certain downstream that can be temporarily mitigated with a filter,  that's
a different story.

It is acceptable to drop packets to enforce network policy, such as no-spam
rules that a customer or host has violated,  for example:  all IP packets
to a host.   It is acceptable to drop erroneous packets, such as ones with
an incorrect checksum or source IP that the  customer has not been
assigned,  or has not informed the provider that they were assigned.

I would say it's in general unacceptable for an ISP to discriminate against
packets addressed to or sourced from specific port numbers.

That's actually breaking connectivity.

There's no such thing as a "bad port number";   there are port numbers that
certain applications have abused;    the entire port range should be
available for any host as indicated by the various RFCs that define the
protocol.


If packets with any valid bit pattern in the source port or destination
port field are dropped, based on a valid bit pattern in that field, then
that is really a breakage of proper connectivity by the provider.


What is the group's thought on this?
> -Matt
>
--
-JH

From rdobbins at arbor.net  Tue Feb  7 19:00:00 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Wed, 8 Feb 2012 01:00:00 +0000
Subject: 2011 Worldwide Infrastructure Report available for download.
Message-ID: <C35D7438-2408-49C9-836A-EAD12B88D9B0@arbor.net>


[Apologies if you've already seen this announcement in other forums.]

We've just posted the 2011 Worldwide Infrastructure Security Report for download at this URL:

<http://www.arbornetworks.com/report>

This year's WWISR contains responses and data from 114 network operators in all major geographical regions.  The WWISR is based upon input from the global operational community, and, as such, is unique in its focus on the operational security aspects of public-facing networks.

Many of you contributed to the survey which forms the foundation of the report; as always, we're grateful for your insight and participation, and welcome your feedback and comments.

Thanks much!

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From ops.lists at gmail.com  Tue Feb  7 19:45:34 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Wed, 8 Feb 2012 07:15:34 +0530
Subject: Firewalls in service provider environments
In-Reply-To: <CAP-guGXcc6JUn=67-YnMAGL36+zxMFLzT4s-2U1+V1Ax+ij78Q@mail.gmail.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <CAP-guGXcc6JUn=67-YnMAGL36+zxMFLzT4s-2U1+V1Ax+ij78Q@mail.gmail.com>
Message-ID: <CAArzuovzrprSvt+kj-+O_2y4PC9j78pUBL0-W+JRbYZm3uXjFw@mail.gmail.com>

On Wed, Feb 8, 2012 at 3:52 AM, William Herrin <bill at herrin.us> wrote:

> High end business customers (of the BGP speaking variety) generally
> appreciate having a remote triggered black hole facility. That's a
> kind of firewall. http://tools.ietf.org/html/rfc5635

While I 100% agree that sticking a stateful firewall into a SP
environment is several kinds of dumb, I wouldn't run it wide open and
unfiltered either.

There are several things that a SP should definitely be looking at,
that'd still describe as a firewall, and are not the "stateful
firewall / IDS / IPS magic black box" half the posters in this thread
are instinctively reacting to.   For the record, yes, I agree those
are a bad idea.

But how about these -  All these are going to be implemented to a
greater or a lesser degree, and in different places, depending on how
you define SP (selling only transit OC-48s?  T1..T3 to end user
corporations?  Datacenter hosting?)

1. S/RTBH

2. Netflow based devices (Arbor, Tivoli TNPFA flow analyzers, etc)

3. DDoS mitigation - possibly resold as an extra service [built
inhouse / provided by other vendors or your upstream tier 1]

4. Router ACLs to get rid of common worm traffic

5. Filtering both ways to prevent async routing to bypass your filters
(http://irbs.net/internet/nanog/0408/0405.html and in that thread,
http://irbs.net/internet/nanog/0408/0465.html for a fun example)

6.  Putting different customers into different VLANs rather than
packing everybody into a single VLAN - that way they don't spoof
unused IPs on the same VLAN (that is, unused IPs anywhere in your IP
space .. and this is, like #5, a rather old attack that I haven't seen
in a while, it used to be very popular with spammers some years back,
and sticking your customers into separate VLANs anyway makes a lot of
sense from a management perspective, leave alone the security
implications)

--srs

-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From ops.lists at gmail.com  Tue Feb  7 19:47:41 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Wed, 8 Feb 2012 07:17:41 +0530
Subject: Firewalls in service provider environments
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBB5C5@RWC-MBX1.corp.seven.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBB5C5@RWC-MBX1.corp.seven.com>
Message-ID: <CAArzuou_yr8aCtxQzg50CnHh7hy2zbPkbpXKjDsYiZxtLWvK_w@mail.gmail.com>

On Wed, Feb 8, 2012 at 4:04 AM, George Bonser <gbonser at seven.com> wrote:
> I typically also include traffic to/from:
>
> TCP/UDP port 0
> 169.254.0.0/16
> 192.0.2.0/24
> 198.51.100.0/24
> 203.0.113.0/24
>
> Been wondering if I should also block 198.18.0.0/15 as well.

suresh at frodo 17:46:08 :~$ nslookup 1.113.0.203.bogons.cymru.com
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   1.113.0.203.bogons.cymru.com
Address: 127.0.0.2

Also available as a bgp feed, for years now.   Saves you updating your
martian ACLs from time to time.

-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From ryan at u13.net  Tue Feb  7 21:20:07 2012
From: ryan at u13.net (Ryan Rawdon)
Date: Tue, 7 Feb 2012 22:20:07 -0500
Subject: report botnet C&C?
Message-ID: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>

Assuming it is not a futile/wasted effort, where is the current best place/resource to report an active botnet C&C to?

From steve.bertrand at gmail.com  Tue Feb  7 21:20:13 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Tue, 07 Feb 2012 22:20:13 -0500
Subject: Firewalls in service provider environments
In-Reply-To: <CAArzuou_yr8aCtxQzg50CnHh7hy2zbPkbpXKjDsYiZxtLWvK_w@mail.gmail.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBB5C5@RWC-MBX1.corp.seven.com>
 <CAArzuou_yr8aCtxQzg50CnHh7hy2zbPkbpXKjDsYiZxtLWvK_w@mail.gmail.com>
Message-ID: <4F31E9ED.90506@gmail.com>

On 2012.02.07 20:47, Suresh Ramasubramanian wrote:
> On Wed, Feb 8, 2012 at 4:04 AM, George Bonser<gbonser at seven.com>  wrote:
>> I typically also include traffic to/from:
>>
>> TCP/UDP port 0
>> 169.254.0.0/16
>> 192.0.2.0/24
>> 198.51.100.0/24
>> 203.0.113.0/24
>>
>> Been wondering if I should also block 198.18.0.0/15 as well.
>
> suresh at frodo 17:46:08 :~$ nslookup 1.113.0.203.bogons.cymru.com
> Server:         127.0.0.1
> Address:        127.0.0.1#53
>
> Non-authoritative answer:
> Name:   1.113.0.203.bogons.cymru.com
> Address: 127.0.0.2
>
> Also available as a bgp feed, for years now.   Saves you updating your
> martian ACLs from time to time.

Amen. v4 and v6 lists are available via free BGP feed (via v4 and v6 
peering) from Cymru. Dynamic simplicity within community's finest standards.

Works wonders for those who have s/RTBH deployed.



From rdobbins at arbor.net  Tue Feb  7 21:23:03 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Wed, 8 Feb 2012 03:23:03 +0000
Subject: report botnet C&C?
In-Reply-To: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
References: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
Message-ID: <DAF7F985-3A7A-4141-8993-637F86D21B2E@arbor.net>


On Feb 8, 2012, at 10:20 AM, Ryan Rawdon wrote:

> Assuming it is not a futile/wasted effort, where is the current best place/resource to report an active botnet C&C to?

Probably the abuse contact for the network in question, if contact info is available.  

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From lists at 1337.mx  Tue Feb  7 21:26:56 2012
From: lists at 1337.mx (toor)
Date: Wed, 8 Feb 2012 11:26:56 +0800
Subject: report botnet C&C?
In-Reply-To: <DAF7F985-3A7A-4141-8993-637F86D21B2E@arbor.net>
References: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
 <DAF7F985-3A7A-4141-8993-637F86D21B2E@arbor.net>
Message-ID: <CALjCmpkUGPKbZTS5ALUxt=trqaqtqCrTXDOTHT+WP33Hm6HRSA@mail.gmail.com>

It may be worth reporting it to Shadow Server:
http://www.shadowserver.org/wiki/pmwiki.php/Contact/ContactUs

On Wed, Feb 8, 2012 at 11:23 AM, Dobbins, Roland <rdobbins at arbor.net> wrote:
>
> On Feb 8, 2012, at 10:20 AM, Ryan Rawdon wrote:
>
>> Assuming it is not a futile/wasted effort, where is the current best place/resource to report an active botnet C&C to?
>
> Probably the abuse contact for the network in question, if contact info is available.
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
> ? ? ? ? ? ? ? ?The basis of optimism is sheer terror.
>
> ? ? ? ? ? ? ? ? ? ? ? ? ?-- Oscar Wilde
>
>


From graham at g-rock.net  Tue Feb  7 21:55:12 2012
From: graham at g-rock.net (graham)
Date: Tue, 07 Feb 2012 21:55:12 -0600
Subject: Anyone from Kraus Electronic/CableTV lurking?
Message-ID: <CB574E40.4B565%graham@g-rock.net>

I tried to reach Kraus Electronic / Cable TV through various means. Anyone
know how to reach their NOC?
They?re announcing 12.198.32.0/20 (they only been swiped a /22), which is
getting into my 12.198.40.0/22 assignment.

On hold with AT&T, of course.

-graham

From morrowc.lists at gmail.com  Tue Feb  7 22:23:38 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 7 Feb 2012 23:23:38 -0500
Subject: Anyone from Kraus Electronic/CableTV lurking?
In-Reply-To: <CB574E40.4B565%graham@g-rock.net>
References: <CB574E40.4B565%graham@g-rock.net>
Message-ID: <CAL9jLaaQ1OC2mLBHvF+D+_YDzXTbUruc=zRUZm-C6PVEx=DWdw@mail.gmail.com>

On Tue, Feb 7, 2012 at 10:55 PM, graham <graham at g-rock.net> wrote:
> I tried to reach Kraus Electronic / Cable TV through various means. Anyone
> know how to reach their NOC?
> They?re announcing 12.198.32.0/20 (they only been swiped a /22), which is
> getting into my 12.198.40.0/22 assignment.
>
> On hold with AT&T, of course.
>

if only there were some way... for isp's to keep track of their
assignments to their customers, and say tell everyone else in the
world in a fashion that's mechanically useful.

:(

(Oddly I thought ATT prefix + packet filtered all their customers?
maybe this customer shrank out of their /20 and you got their
seconds?)

-chris


From graham at g-rock.net  Tue Feb  7 22:30:50 2012
From: graham at g-rock.net (graham)
Date: Tue, 07 Feb 2012 22:30:50 -0600
Subject: Anyone from Kraus Electronic/CableTV lurking?
In-Reply-To: <CAL9jLaaQ1OC2mLBHvF+D+_YDzXTbUruc=zRUZm-C6PVEx=DWdw@mail.gmail.com>
Message-ID: <CB57569A.4B570%graham@g-rock.net>


> 
> (Oddly I thought ATT prefix + packet filtered all their customers?
> maybe this customer shrank out of their /20 and you got their
> seconds?)
> 
> -chris

I thought so too; they were pretty explicit with mine ;-)

However, someone worked some magic somewhere ... I am seeing part of my nets
come back to life.

-graham




From kilobit at gmail.com  Wed Feb  8 01:56:25 2012
From: kilobit at gmail.com (bas)
Date: Wed, 8 Feb 2012 08:56:25 +0100
Subject: UDP port 80 DDoS attack
In-Reply-To: <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
Message-ID: <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>

Roland,
On Mon, Feb 6, 2012 at 2:43 AM, Dobbins, Roland <rdobbins at arbor.net> wrote:
>
> S/RTBH can be rapidly shifted in order to deal with changing purported source IPs, and it isn't limited to /32s.

The big drawback with S/RTBH is that it is a DoS method in itself.

Say eyeball provider X has implemented automated S/RTBH, and I have a
grudge against them.
I would simply DoS a couple of the subscribers with spoofed source IP
addresses from google, youtube, netflow and hulu.
The automated S/RTBH drops all packets coming from those IP addresses.
Presto; many angry consumers call the ISP's helpdesk.

The same goes for hosting networks, I just need to identify what kind
of service my intended victim is dependent on. (i.e. paypal).
Then DoS any part of the hosters network with spoofed source addresses
of paypal, the automated S/RTBH makes sure the entire hosting network
is not able to reach paypal anymore.
Presto, mission achieved.

Bas


From gbonser at seven.com  Wed Feb  8 02:04:42 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 8 Feb 2012 08:04:42 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>



> -----Original Message-----
> From: bas 
> Sent: Tuesday, February 07, 2012 11:56 PM
> To: Dobbins, Roland; nanog
> Subject: Re: UDP port 80 DDoS attack
> 
> Say eyeball provider X has implemented automated S/RTBH, and I have a
> grudge against them.
> I would simply DoS a couple of the subscribers *with spoofed source IP*
> addresses from google, youtube, netflow and hulu.
> The automated S/RTBH drops all packets coming from those IP addresses.
> Presto; many angry consumers call the ISP's helpdesk.

Comes back to providers allowing "spoofed" traffic into their networks from customers.  That seems to me to be the low-hanging fruit here.



From mpetach at netflight.com  Wed Feb  8 02:05:09 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Wed, 8 Feb 2012 00:05:09 -0800
Subject: 2012.02.07 NANOG54 day 2 notes, afternoon session
Message-ID: <CAEmG1=r7S1L7hF+DemP-7X+e1Ks28WFetTdG1gKB=0Tvb1HY7w@mail.gmail.com>

I'm so sorry; I thought I would have time to send these
out after the peering track, but I got pulled into some
conversations which ended up lasting until 2330 hours,
and ran right on through the social event.  So, the
afternoon session notes ended up having to wait until
I got back to my room.  Apologies for the delay,
they're now up at

http://kestrel3.netflight.com/2012.02.07-nanog54-afternoon-session.txt

and apache has been restarted on the box
for those who tried to get the notes earlier
and got nothing but a timeout.

Thanks!

Matt


From rdobbins at arbor.net  Wed Feb  8 02:29:31 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Wed, 8 Feb 2012 08:29:31 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
Message-ID: <367B263E-3E18-48C6-829F-1F8C84FFFAEF@arbor.net>


On Feb 8, 2012, at 2:56 PM, bas wrote:

> The big drawback with S/RTBH is that it is a DoS method in itself.

I'm not an advocate of *automated* S/RTBH, and I am an advocate of whitelisting various well-known 'golden networks/IPs' via prefix-lists in order to avoid this issue in part; also, note that the concept of partial service recovery incorporates the notion of some legitimate traffic/users being blocked in order to maintain the availability of the targeted server/service/application for the majority of legitimate traffic/users. 

Also note that S/RTBH isn't a universal panacea; it's just one tool in the toolbox.  flowspec is more flexible due to its layer-4 granularity; and other types of tools such as IDMS are even more flexible and incorporate much richer classification technology.

It's important to understand that this isn't a theoretical discussion - I've personally utilized/helped others to utilize S/RTBH to successfully mitigate large-scale DDoS attacks, and it's a lowest-common-denominator in terms of a somewhat dynamic mitigation mechanism.  Let's not make the perfect the enemy of the merely good.

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From keegan.holley at sungard.com  Wed Feb  8 02:31:05 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 8 Feb 2012 03:31:05 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
Message-ID: <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>

2012/2/8 George Bonser <gbonser at seven.com>

>
>
> > -----Original Message-----
> > From: bas
> > Sent: Tuesday, February 07, 2012 11:56 PM
> > To: Dobbins, Roland; nanog
> > Subject: Re: UDP port 80 DDoS attack
> >
> > Say eyeball provider X has implemented automated S/RTBH, and I have a
> > grudge against them.
> > I would simply DoS a couple of the subscribers *with spoofed source IP*
> > addresses from google, youtube, netflow and hulu.
> > The automated S/RTBH drops all packets coming from those IP addresses.
> > Presto; many angry consumers call the ISP's helpdesk.
>
> Comes back to providers allowing "spoofed" traffic into their networks
> from customers.  That seems to me to be the low-hanging fruit here.
>
>
>
How do you stop it?  Granted, traffic from 10/8 or 127.0.0.1 coming in via
an upstream is obvious, but that's about it.  There's nothing in a packet
that will tell you where it came from compared to the source IP field in
the IP header.  uRPF is a problem for anyone who's sufficiently multihomed
since it causes asymmetric routing.

From gbonser at seven.com  Wed Feb  8 03:03:48 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 8 Feb 2012 09:03:48 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>



>From: Keegan Holley 

>How do you stop it?? 

A provider knows what destination IP traffic they route TO a customer, don't they?  That should be the only source IPs they accept FROM a customer.


If you don't route it TO the customer, you shouldn't accept it FROM the customer unless you have made special arrangements with them and verified they are entitled to source the traffic from the desired IPs.




From keegan.holley at sungard.com  Wed Feb  8 03:12:21 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 8 Feb 2012 04:12:21 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
Message-ID: <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>

It works in theory, but to get every ISP and hosting provider to ACL their
edges and maintain those ACL's for every customer no matter how large might
be a bit difficult.  Also, what about non-BGP customers or customers that
just accept a default route? Or even customers that just want return
traffic to come in a different link for some reason.  ISP's would suddenly
become giant traffic registries.

2012/2/8 George Bonser <gbonser at seven.com>

>
>
> >From: Keegan Holley
>
> >How do you stop it?
>
> A provider knows what destination IP traffic they route TO a customer,
> don't they?  That should be the only source IPs they accept FROM a customer.
>
>
> If you don't route it TO the customer, you shouldn't accept it FROM the
> customer unless you have made special arrangements with them and verified
> they are entitled to source the traffic from the desired IPs.
>
>
>
>

From gbonser at seven.com  Wed Feb  8 03:51:15 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 8 Feb 2012 09:51:15 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>



>From: Keegan Holley 
> Subject: Re: UDP port 80 DDoS attack

> It works in theory, but to get every ISP and hosting provider to ACL their edges and maintain those ACL's for every customer no matter how large might be a bit difficult.? 

You don't have to ACL in most cases. RPF works for most.  There will be a few, relatively darned few, that you will need to ACL, but RPF takes care of a large number of them.

Besides, I never meant to imply that this business was easy and not "difficult".


> Also, what about non-BGP customers or customers that just accept a default route?  

I don't follow.  The ISP still knows what traffic gets routed TO them.  You only accept FROM them what you route TO them, even if you hand them a default route.


> Or even customers that just want return traffic to come in a different link for some reason.

Still don't follow.  I am not talking about having a firewall that is stateful.  I am talking packet by packet.  If you don't route it to them, you don't accept it from them unless you have made arrangements otherwise, which will be a small percentage of your customers. Sure, some might be multihomed but it is easy enough to verify that they have the networks in question SWIPed to them or a call to the other provider can clear that up in a few minutes.  It isn't THAT hard.


> ISP's would suddenly become giant traffic registries.


No, we have registries to act as registries, the ISPs should be checking them, and double checking.  It isn't something that is going to change every day or every week. Once you get it set up, it is going to be stable for a while.  Sure, it means a little more work in setting up a customer, but it also means that if all your neighbors do the same thing, you field many fewer calls dealing with stupid DoS crap.



From gbonser at seven.com  Wed Feb  8 03:56:44 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 8 Feb 2012 09:56:44 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>

> No, we have registries to act as registries, the ISPs should be
> checking them, and double checking.  It isn't something that is going
> to change every day or every week. Once you get it set up, it is going
> to be stable for a while.  Sure, it means a little more work in setting
> up a customer, but it also means that if all your neighbors do the same
> thing, you field many fewer calls dealing with stupid DoS crap.
> 

I'll put it another way. Any provider that does not police their customer traffic has no business whining about DoS problems.



From kilobit at gmail.com  Wed Feb  8 07:03:19 2012
From: kilobit at gmail.com (bas)
Date: Wed, 8 Feb 2012 14:03:19 +0100
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
Message-ID: <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>

On Wed, Feb 8, 2012 at 10:56 AM, George Bonser <gbonser at seven.com> wrote:
> I'll put it another way. Any provider that does not police their customer traffic has no business whining about DoS problems.

Most of us prevent their customers from sending out spoofed traffic.

77% of all networks seem to think so.
http://spoofer.csail.mit.edu/summary.php

However the remaining networks allow spoofed traffic to egress their networks.

When that traffic enters my network, I have no method whatsoever to
differentiate it from any other traffic.
I could ask my upstream where they see it coming from, which will be
quite hard if they do not have pretty fancy systems.
But if they receive it from a peer, I am as good as lost in trying to
find the culprit.

Bas


From kilobit at gmail.com  Wed Feb  8 07:07:19 2012
From: kilobit at gmail.com (bas)
Date: Wed, 8 Feb 2012 14:07:19 +0100
Subject: UDP port 80 DDoS attack
In-Reply-To: <367B263E-3E18-48C6-829F-1F8C84FFFAEF@arbor.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <367B263E-3E18-48C6-829F-1F8C84FFFAEF@arbor.net>
Message-ID: <CAEs2ZiJAP6gMZVE6XY_xb+cCD26e6hA1rHY19T-Rby8zFbg8Xw@mail.gmail.com>

On Wed, Feb 8, 2012 at 9:29 AM, Dobbins, Roland <rdobbins at arbor.net> wrote:
>
> On Feb 8, 2012, at 2:56 PM, bas wrote:
>
>> The big drawback with S/RTBH is that it is a DoS method in itself.
>
> I'm not an advocate of *automated* S/RTBH, and I am an advocate of whitelisting various well-known 'golden networks/IPs'

So I would need to find out which networks you would have classified
as "golden" and use those as sources for my DDoS.

Either I can achieve DoS with S/RTBH, or I can abuse the "golden
networks" to circumvent S/RTBH.

As far as I see it S/RTBH is in no way a solution against smart
attackers, of course it does help against all the kiddie attacks out
there.

Bas


From rdobbins at arbor.net  Wed Feb  8 07:15:37 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Wed, 8 Feb 2012 13:15:37 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CAEs2ZiJAP6gMZVE6XY_xb+cCD26e6hA1rHY19T-Rby8zFbg8Xw@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <367B263E-3E18-48C6-829F-1F8C84FFFAEF@arbor.net>
 <CAEs2ZiJAP6gMZVE6XY_xb+cCD26e6hA1rHY19T-Rby8zFbg8Xw@mail.gmail.com>
Message-ID: <57E4018B-5E7E-4F0E-97E5-C8220A99ACD1@arbor.net>

On Feb 8, 2012, at 8:07 PM, bas wrote:

> As far as I see it S/RTBH is in no way a solution against smart attackers, of course it does help against all the kiddie attacks out
> there.

Once again, I've used S/RTBH myself and helped others use it many, many times, including to defend against attacks with shifting purported source IPs.  flowspec, IDMS and other tools are very useful as well, but S/RTBH is supported on a lot of hardware, if operators choose to configure it.

It is not a panacea.  It is one tool in the toolbox.  

Folks can either choose to make use of it or choose not to do so; it is operationally proven, it does work, and it's certainly better than nothing.  YMMV.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From matt at mattreath.com  Wed Feb  8 08:25:18 2012
From: matt at mattreath.com (Matthew Reath)
Date: Wed, 8 Feb 2012 08:25:18 -0600
Subject: Firewalls in service provider environments
In-Reply-To: <CAALUyuRJ4pob=97fk=ph39ey3zvpbNC4COtzMBaeOai+LfDGxw@mail.gmail.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
 <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>
 <CAALUyuRJ4pob=97fk=ph39ey3zvpbNC4COtzMBaeOai+LfDGxw@mail.gmail.com>
Message-ID: <62055779754543ae83e3c0fe4cdad677.squirrel@mail.mattreath.com>

> On Tue, Feb 7, 2012 at 4:35 PM, Matthew Reath <matt at mattreath.com> wrote:
>
>> > One of my customers has a list like that. They can't understand why
>> > one in every hundred or so TCP connections on port 443 fails.
>> >
>> > Hint: you forgot "access-list 102 permit tcp any any established"
>> > after "access-list 102 deny   ip host 255.255.255.255 any". The
>> > destination port in one direction is the source port in the other and
>> > many of those are dynamic source ports picked by Windows. Unless you
>> > restrict that filter to just packets attempting to initiate a new
>> > connection, you're shooting yourself in the foot.
>>
>> Yeah agreed.  The only place this gets applied is inbound on the
>> interface
>> facing an upstream provider. ACLs ingress from end customers are much
>> different. In theory this could cause issues with externally initiated
>> traffic that use lets say 8888 as its random source port.
>>
>
> If you apply the ACL you showed as an inbound ACL on your provider facing
> interfaces, you will be breaking any connections that exit your network
> with source ports from your list of bad ports.  For example, you connect
> out from x.x.x.x:8888 to y.y.y.y:80, then the response packets coming back
> into your network will be from y.y.y.y:80 to x.x.x.x:8888 and will be
> dropped by your ACL.
>
> This seems to be a common mistake, and is often missed because it
> manifests
> as one-in-thousands failures of TCP connections.  People tend to just try
> a
> second time and it works and never investigate why they had one random
> failure.
>

Good point. Adding in an established entry, although may open you up for
TCP/SYN sort of packets is a better trade off than affecting customer
traffic.

-Matt



From morrowc.lists at gmail.com  Wed Feb  8 09:01:33 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 8 Feb 2012 10:01:33 -0500
Subject: Firewalls in service provider environments
In-Reply-To: <62055779754543ae83e3c0fe4cdad677.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
 <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>
 <CAALUyuRJ4pob=97fk=ph39ey3zvpbNC4COtzMBaeOai+LfDGxw@mail.gmail.com>
 <62055779754543ae83e3c0fe4cdad677.squirrel@mail.mattreath.com>
Message-ID: <CAL9jLaZ_VrKhT0V4k85qFN7jRkcDDcwYj_e4+HsvE9f7ee-pzw@mail.gmail.com>

On Wed, Feb 8, 2012 at 9:25 AM, Matthew Reath <matt at mattreath.com> wrote:

> Good point. Adding in an established entry, although may open you up for
> TCP/SYN sort of packets is a better trade off than affecting customer
> traffic.

'established' is explicitly NOT 'syn' ...
maybe you meant 'ack flood' ? (or rst flood? or .... but certainly not
syn flood)


From keegan.holley at sungard.com  Wed Feb  8 09:12:50 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 8 Feb 2012 10:12:50 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
Message-ID: <21C0E0A6-99FB-4385-9355-629BDB5ECD9B@sungard.com>

Providers don't even check the registries for bgp advertisements. See the thread on hijacked routes for proof.   Not to mention how do you handle a small transit AS?  Do you trust that they have the correct filters as well?  Do you start reading their AS paths and try to filter based on the registry for folks down stream?  Then there's the RLDRAM issue.  Most edge boxes will just run out if ACL's.  Lastly there's no contractual obligation to play traffic cop for the entire Internet so providers would be dropping traffic that they can legitimately bill for.

Sent from my iPhone

On Feb 8, 2012, at 4:56 AM, George Bonser <gbonser at seven.com> wrote:

>> No, we have registries to act as registries, the ISPs should be
>> checking them, and double checking.  It isn't something that is going
>> to change every day or every week. Once you get it set up, it is going
>> to be stable for a while.  Sure, it means a little more work in setting
>> up a customer, but it also means that if all your neighbors do the same
>> thing, you field many fewer calls dealing with stupid DoS crap.
>> 
> 
> I'll put it another way. Any provider that does not police their customer traffic has no business whining about DoS problems.
> 
> 


From keegan.holley at sungard.com  Wed Feb  8 09:18:29 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 8 Feb 2012 10:18:29 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
Message-ID: <A8AD3365-BD70-48D8-86A1-1815EEA878C0@sungard.com>



On Feb 8, 2012, at 4:51 AM, George Bonser <gbonser at seven.com> wrote:

> 
> 
>> From: Keegan Holley 
>> Subject: Re: UDP port 80 DDoS attack
> 
>> It works in theory, but to get every ISP and hosting provider to ACL their edges and maintain those ACL's for every customer no matter how large might be a bit difficult.  
> 
> You don't have to ACL in most cases. RPF works for most.  There will be a few, relatively darned few, that you will need to ACL, but RPF takes care of a large number of them.
> 

RPF on the whole Internet would pretty much lead to an instant outage.  What happens when you have two upstreams and one has an incoming route to you but your out going route for which ever of their customers talking to you doesn't agree?  Instant outage.  Multiply that by the entire table and then add churn.  I'd give it a week before everyone turned it off,  if you could even get them to enable it to begin with.
 
> 
>> Also, what about non-BGP customers or customers that just accept a default route?  
> 
> I don't follow.  The ISP still knows what traffic gets routed TO them.  You only accept FROM them what you route TO them, even if you hand them a default route.
> 
> 
>> Or even customers that just want return traffic to come in a different link for some reason.
> 
> Still don't follow.  I am not talking about having a firewall that is stateful.  I am talking packet by packet.  If you don't route it to them, you don't accept it from them unless you have made arrangements otherwise, which will be a small percentage of your customers. Sure, some might be multihomed but it is easy enough to verify that they have the networks in question SWIPed to them or a call to the other provider can clear that up in a few minutes.  It isn't THAT hard.
> 
> 
>> ISP's would suddenly become giant traffic registries.
> 
> 
> No, we have registries to act as registries, the ISPs should be checking them, and double checking.  It isn't something that is going to change every day or every week. Once you get it set up, it is going to be stable for a while.  Sure, it means a little more work in setting up a customer, but it also means that if all your neighbors do the same thing, you field many fewer calls dealing with stupid DoS crap.
> 
> 


From morrowc.lists at gmail.com  Wed Feb  8 09:33:49 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 8 Feb 2012 10:33:49 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <21C0E0A6-99FB-4385-9355-629BDB5ECD9B@sungard.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <21C0E0A6-99FB-4385-9355-629BDB5ECD9B@sungard.com>
Message-ID: <CAL9jLaYVq8_97KxUzg-FoW+jaD_cS43Mf3r1LjOASAJgyCaF6A@mail.gmail.com>

On Wed, Feb 8, 2012 at 10:12 AM, Keegan Holley
<keegan.holley at sungard.com> wrote:
> Providers don't even check the registries for bgp advertisements. See the thread on hijacked routes for proof. ? Not to mention how do you handle a small transit AS? ?Do you trust that they

to be fair: "Some Providers do not check registries for 'right to use'
information about prefixes their customers wish to announce to them
over BGP."


From ariev at vayner.net  Wed Feb  8 09:28:24 2012
From: ariev at vayner.net (Arie Vayner)
Date: Wed, 8 Feb 2012 17:28:24 +0200
Subject: [c-nsp] ASR opinions..
In-Reply-To: <201202011150.48562.mtinka@globaltransit.net>
References: <COL111-W278BAD1227E170E373779DDA2C0@phx.gbl>
 <201109021756.56518.mtinka@globaltransit.net>
 <CAOMUSPY+F0ens+7sHDOFMJpJdBiVdVn0t6fYTF7RHGPKaSB_Dw@mail.gmail.com>
 <201202011150.48562.mtinka@globaltransit.net>
Message-ID: <CAP9danc2E3pFzHtcSYfZqisq-GVQjo55WJR7qy-2M+i07mCTQA@mail.gmail.com>

Mark,

I made sure with the BU, and they confirmed that ASR1001 with 8GB RAM can
handle 1M routes per the data sheet.
The difference between ASR1001 and ASR1002 with EFP5 is due to a more
powerful integrated RP on ASR1001 (Not really RP2, but closer to RP2 than
RP1) and more memory (4GB is max on RP1)

Arie

On Wed, Feb 1, 2012 at 5:50 AM, Mark Tinka <mtinka at globaltransit.net> wrote:

> On Tuesday, January 31, 2012 06:38:10 AM Christopher J.
> Pilkington wrote:
>
> > Does anyone have a link to a definitive document clearly
> > showing FIB numbers for the ASR1001?  I've got an email
> > into our Cisco SE, but I don't think they're motivated
> > to sell us a lower-end box. :-)
>
> On that link, Tables 1 and 3 contradict each other re: the
> ASR1001.
>
> However, I confirmed with our SE, and he says no way the
> ASR1001 supports anything more than 512,000 v4 entries and
> 128,000 v6 entries (which is Table 3).
>
> Maybe someone on the list from Cisco can help fix the
> documentation.
>
> Mark.
>

From keegan.holley at sungard.com  Wed Feb  8 09:53:16 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 8 Feb 2012 10:53:16 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <57E4018B-5E7E-4F0E-97E5-C8220A99ACD1@arbor.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <367B263E-3E18-48C6-829F-1F8C84FFFAEF@arbor.net>
 <CAEs2ZiJAP6gMZVE6XY_xb+cCD26e6hA1rHY19T-Rby8zFbg8Xw@mail.gmail.com>
 <57E4018B-5E7E-4F0E-97E5-C8220A99ACD1@arbor.net>
Message-ID: <CABO8Q6Qrp3qrbWk0KO+TqA=M63sYUXcT2rijm0DS-bHxSsLcKA@mail.gmail.com>

2012/2/8 Dobbins, Roland <rdobbins at arbor.net>

> On Feb 8, 2012, at 8:07 PM, bas wrote:
>
> > As far as I see it S/RTBH is in no way a solution against smart
> attackers, of course it does help against all the kiddie attacks out
> > there.
>
> Once again, I've used S/RTBH myself and helped others use it many, many
> times, including to defend against attacks with shifting purported source
> IPs.  flowspec, IDMS and other tools are very useful as well, but S/RTBH is
> supported on a lot of hardware, if operators choose to configure it.
>
> It is not a panacea.  It is one tool in the toolbox.
>
> Folks can either choose to make use of it or choose not to do so; it is
> operationally proven, it does work, and it's certainly better than nothing.
>  YMMV.
>
>
I agree.  I think RTBH is a broadsword not a scalpel.  It's a tool in the
tool box and there is a danger of dropping legitimate traffic with both
S/RTBH and D/RTBH.  BGP isn't a security protocol.  It's not even that
great of a routing protocol.

From twilde at cymru.com  Wed Feb  8 10:55:48 2012
From: twilde at cymru.com (Tim Wilde)
Date: Wed, 08 Feb 2012 11:55:48 -0500
Subject: report botnet C&C?
In-Reply-To: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
References: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
Message-ID: <4F32A914.7060304@cymru.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/7/2012 10:20 PM, Ryan Rawdon wrote:
> Assuming it is not a futile/wasted effort, where is the current
> best place/resource to report an active botnet C&C to?

Team Cymru is always happy to hear about C&Cs, your best bet for
sending to us is to use support at cymru.com.

Thanks,
Tim Wilde

- -- 
Tim Wilde, Software Engineer, Team Cymru, Inc.
twilde at cymru.com | +1-847-378-3333 | http://www.team-cymru.org/
-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAk8yqRQACgkQluRbRini9tiX9ACeOLiCon9Hz8TQ8MOdTbL5Jbvx
Tl0AmgMu135iJScJwbx3kxbwMaqWuaBm
=Hldr
-----END PGP SIGNATURE-----


From ktokash at hotmail.com  Wed Feb  8 10:59:23 2012
From: ktokash at hotmail.com (keith tokash)
Date: Wed, 8 Feb 2012 08:59:23 -0800
Subject: IPv6 explicit BGP group configs
Message-ID: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>


Hi,

I'm prepping an environment for v6 and I'm wondering what, if
 any, benefit there is to splitting v4 and v6 into separate groups.  
We're running Junipers and things are fairly neat and ordered; we have 
multiple links to a few providers in many sites, so we group them and 
apply the policies at the group level.  We could stick the new v6 
neighbors into the same group and apply the policies at the neighbor 
level, or create new groups (i.e. Level3 and Level3v6).

This 
might sound a little nit-picky, but I'm concerned that there's a nuance 
I'm not thinking of right now and I don't want to be "that guy" who puts
 something in place and is cursed for a decade.

Thanks,
Keith Tokash 		 	   		  

From bicknell at ufp.org  Wed Feb  8 11:25:19 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 8 Feb 2012 09:25:19 -0800
Subject: IPv6 explicit BGP group configs
In-Reply-To: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>
References: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>
Message-ID: <20120208172519.GA62714@ussenterprise.ufp.org>

In a message written on Wed, Feb 08, 2012 at 08:59:23AM -0800, keith tokash wrote:
> I'm prepping an environment for v6 and I'm wondering what, if
>  any, benefit there is to splitting v4 and v6 into separate groups.  
> We're running Junipers and things are fairly neat and ordered; we have 
> multiple links to a few providers in many sites, so we group them and 
> apply the policies at the group level.  We could stick the new v6 
> neighbors into the same group and apply the policies at the neighbor 
> level, or create new groups (i.e. Level3 and Level3v6).

I'm going to answer with a very specific bit of administriva, but
I think it illustrates the sort of thing you want to think about.

When adding a BGP address family like IPv6 it can be done by sending
the routes down an existing BGP session (e.g. IPv4 transport carrying
IPv4 and IPv6 routes), or by having two sessions, an IPv4 transport
with IPv4 routes, and an IPv6 transport with IPv6 routes.

Most ISP's do the latter.   There are a pile of reasons, but here's
one of the easiest.  Imagine a world in the future where we are
removing IPv4 from the network as we're now IPv6 only.  If one
transport was used, it must now be torn down and rebuilt over IPv6,
causing an outage for everything and a lot of work for your engineers.
If you used two transports, you can remove the IPv4 and the IPv6
keeps working just fine.

Lather, rince, reapply to everything you can do on routers.  How you
group config statements, how you write your management tools, and so on.
I would generally advise, where possible, to treat them like ships in
the night.  Keep them in separate areas.  It allows you to add IPv6
without disturbing IPv4, and some day will allow you to remove IPv4
without disturbing IPv6.

YMMV.  Batteries not included.  Not all vendors support all features.
No warranty expressed or implied.  Do not taunt happy fun ball.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120208/41f43e3e/attachment.bin>

From Grzegorz at Janoszka.pl  Wed Feb  8 11:33:17 2012
From: Grzegorz at Janoszka.pl (Grzegorz Janoszka)
Date: Wed, 08 Feb 2012 18:33:17 +0100
Subject: IPv6 explicit BGP group configs
In-Reply-To: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>
References: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>
Message-ID: <4F32B1DD.10502@Janoszka.pl>

On 08-02-12 17:59, keith tokash wrote:
> I'm prepping an environment for v6 and I'm wondering what, if
>  any, benefit there is to splitting v4 and v6 into separate groups.  
> We're running Junipers and things are fairly neat and ordered; we have 
> multiple links to a few providers in many sites, so we group them and 
> apply the policies at the group level.  We could stick the new v6 
> neighbors into the same group and apply the policies at the neighbor 
> level, or create new groups (i.e. Level3 and Level3v6).

Sometimes we have the same group for v4 and v6, but in most cases we
have different ones. One of the basic reasons is different max-pref setting.

Most policies can be used in two address families, you can also match
prefixes, but you cannot have v4 and v6 prefixes in one term. So in your
policies you have to have at least two terms - one for v4 prefixes, one
for v6 prefixes.

-- 
Grzegorz Janoszka


From joelja at bogus.com  Wed Feb  8 11:36:50 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Wed, 08 Feb 2012 09:36:50 -0800
Subject: IPv6 explicit BGP group configs
In-Reply-To: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>
References: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>
Message-ID: <4F32B2B2.1090407@bogus.com>

On 2/8/12 08:59 , keith tokash wrote:
> 
> Hi,

I've done it either way, I prefer to put the v6 peers in a different
group  than the v4 peers so that I can group the policies at the group
rather than neighbor level.

> I'm prepping an environment for v6 and I'm wondering what, if
>  any, benefit there is to splitting v4 and v6 into separate groups.  
> We're running Junipers and things are fairly neat and ordered; we have 
> multiple links to a few providers in many sites, so we group them and 
> apply the policies at the group level.  We could stick the new v6 
> neighbors into the same group and apply the policies at the neighbor 
> level, or create new groups (i.e. Level3 and Level3v6).
> 
> This 
> might sound a little nit-picky, but I'm concerned that there's a nuance 
> I'm not thinking of right now and I don't want to be "that guy" who puts
>  something in place and is cursed for a decade.
> 
> Thanks,
> Keith Tokash 		 	   		  
> 



From bicknell at ufp.org  Wed Feb  8 11:58:21 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 8 Feb 2012 09:58:21 -0800
Subject: IPv6 explicit BGP group configs
In-Reply-To: <4F32B1DD.10502@Janoszka.pl>
References: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>
 <4F32B1DD.10502@Janoszka.pl>
Message-ID: <20120208175821.GA64216@ussenterprise.ufp.org>

In a message written on Wed, Feb 08, 2012 at 06:33:17PM +0100, Grzegorz Janoszka wrote:
> Most policies can be used in two address families, you can also match
> prefixes, but you cannot have v4 and v6 prefixes in one term. So in your
> policies you have to have at least two terms - one for v4 prefixes, one
> for v6 prefixes.

Another thing IOS-XR fixes!

route-policy my-example
  if destination in my-ipv4-prefix-list or destination in my-ipv6-prefix-list then
    set community 1234
    set med 0
    done
  endif
end-policy

In 99.99% of the cases it allows you to have one policy for both IPv4
and IPv6, and add the parameter passing I discussed the other day and
it's almost like something was thinking of routing engineers when they
wrote it. :P

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120208/7a4ad2b5/attachment.bin>

From gbonser at seven.com  Wed Feb  8 12:26:42 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 8 Feb 2012 18:26:42 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>

> 77% of all networks seem to think so.
> http://spoofer.csail.mit.edu/summary.php

And it would be the remaining 23% that really need to understand how difficult they are making life for the rest of the Internet.

> However the remaining networks allow spoofed traffic to egress their
> networks.
> 
> When that traffic enters my network, I have no method whatsoever to
> differentiate it from any other traffic.

I'm not really thinking about traffic coming from the Internet.  I'm thinking about its originating location.  Correct, once it gets into the Internet, you really have no way to tell.

> I could ask my upstream where they see it coming from, which will be
> quite hard if they do not have pretty fancy systems.

At that point the game is really hard, agreed.  And if it is distributed, it could be coming from any number of places or from every single one of their upstreams.


> But if they receive it from a peer, I am as good as lost in trying to
> find the culprit.

Agreed.  That's why it is important to stop it at the source.

> Bas


From keegan.holley at sungard.com  Wed Feb  8 12:42:48 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 8 Feb 2012 13:42:48 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>
Message-ID: <CABO8Q6QN+9TFNMRJOnt8JHJRGyQNdJ2Qyvso+RmopQe9cnGKXw@mail.gmail.com>

2012/2/8 George Bonser <gbonser at seven.com>

> > 77% of all networks seem to think so.
> > http://spoofer.csail.mit.edu/summary.php
>
> And it would be the remaining 23% that really need to understand how
> difficult they are making life for the rest of the Internet.
>

23% of 4.29 billion addresses is still more than enough to ruin anyone's
day.

From Sandra.Murphy at sparta.com  Wed Feb  8 12:49:27 2012
From: Sandra.Murphy at sparta.com (Murphy, Sandra)
Date: Wed, 8 Feb 2012 18:49:27 +0000
Subject: remote participation - IETF sidr wg interim meeting
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6086E96@Hermes.columbia.ads.sparta.com>

A WebEx session has been arranged for remote participation in the interim sidr meeting Thu 9 Mar.

Below is the WebEx announcement of the meeting.

--Sandy

=======================================================
The IETF SIDR co-chairs invite you to attend this online meeting. 
Topic: IETF WebEx 
Date: Thursday, February 9, 2012 
Time: 9:00 am, Pacific Standard Time (San Francisco, GMT-08:00) 
Meeting Number: 969 770 530 
Meeting Password: (This meeting does not require a password.) 

------------------------------------------------------- 
To join the online meeting (Now from mobile devices!) 
------------------------------------------------------- 
1. Go to https://workgreen.webex.com/workgreen/j.php?ED=190625237&UID=0&RT=MiM0 
2. If requested, enter your name and email address. 
3. If a password is required, enter the meeting password: (This meeting does not require a password.) 
4. Click "Join". 
To view in other time zones or languages, please click the link: 
https://workgreen.webex.com/workgreen/j.php?ED=190625237&UID=0&ORT=MiM0 

------------------------------------------------------- 
To join the audio conference only 
------------------------------------------------------- 
To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. 
Call-in toll-free number (US/Canada): 1-877-668-4490 
Call-in toll number (US/Canada): 1-408-792-6300 
Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=190625237&tollFree=1 
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 
Access code:969 770 530 

------------------------------------------------------- 
For assistance 
------------------------------------------------------- 
1. Go to https://workgreen.webex.com/workgreen/mc 
2. On the left navigation bar, click "Support". 

You can contact support at: 
amorris at amsl.com 
1-510-492-4081 

To add this meeting to your calendar program (for example Microsoft Outlook), click this link: 
https://workgreen.webex.com/workgreen/j.php?ED=190625237&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=ANsxg25yn/5HHE9KPUeXZtnbWAMNqdqowJxTiz7JHE8=&RT=MiM0 

The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php. 

Sign up for a free trial of WebEx 
http://www.webex.com/go/mcemfreetrial 
http://www.webex.com 

CCP:+14087926300x969770530# 

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. 

From nicolai-nanog at chocolatine.org  Wed Feb  8 13:04:33 2012
From: nicolai-nanog at chocolatine.org (Nicolai)
Date: Wed, 8 Feb 2012 13:04:33 -0600
Subject: report botnet C&C?
In-Reply-To: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
References: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
Message-ID: <20120208190433.GA19246@vectra.student.iastate.edu>

On Tue, Feb 07, 2012 at 10:20:07PM -0500, Ryan Rawdon wrote:
> Assuming it is not a futile/wasted effort, where is the current best
> place/resource to report an active botnet C&C to?

I don't know if there's a single best option, but there are several good
ones.  In addition to Cymru I'd mention abuse.ch, which runs several
public botnet C&C trackers.

 http://www.abuse.ch

Nicolai


From drew.weaver at thenap.com  Wed Feb  8 13:23:27 2012
From: drew.weaver at thenap.com (Drew Weaver)
Date: Wed, 8 Feb 2012 14:23:27 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>
Message-ID: <F3318834F1F89D46857972DD4B411D70052CA02411@exchange>

Stop paying transit providers for delivering spoofed packets to the edge of your network and they will very quickly develop methods of proving that the traffic isn't spoofed, or block it altogether. =)

-Drew


-----Original Message-----
From: George Bonser [mailto:gbonser at seven.com] 
Sent: Wednesday, February 08, 2012 1:27 PM
To: bas; nanog
Subject: RE: UDP port 80 DDoS attack

> 77% of all networks seem to think so.
> http://spoofer.csail.mit.edu/summary.php

And it would be the remaining 23% that really need to understand how difficult they are making life for the rest of the Internet.

> However the remaining networks allow spoofed traffic to egress their 
> networks.
> 
> When that traffic enters my network, I have no method whatsoever to 
> differentiate it from any other traffic.

I'm not really thinking about traffic coming from the Internet.  I'm thinking about its originating location.  Correct, once it gets into the Internet, you really have no way to tell.

> I could ask my upstream where they see it coming from, which will be 
> quite hard if they do not have pretty fancy systems.

At that point the game is really hard, agreed.  And if it is distributed, it could be coming from any number of places or from every single one of their upstreams.


> But if they receive it from a peer, I am as good as lost in trying to 
> find the culprit.

Agreed.  That's why it is important to stop it at the source.

> Bas



From drew.weaver at thenap.com  Wed Feb  8 13:27:20 2012
From: drew.weaver at thenap.com (Drew Weaver)
Date: Wed, 8 Feb 2012 14:27:20 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <273be36298d3b47f04ef10bab7c38112@imap>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <273be36298d3b47f04ef10bab7c38112@imap>
Message-ID: <F3318834F1F89D46857972DD4B411D70052CA02412@exchange>

Hi,

Just a general note on the UDP 80 style DoS attacks.

I'm not entirely certain that UDP 80 attacks are always related to the gameserver bug that you're citing below.

We have seen in the wild php scripts that are hard coded to use UDP 80 to deliver DoS attacks towards their targets.

Basically it's just GET /script.php?ip.of.victim and instant UDP 80 flood, I've also seen perl versions of the same script.. most notably UDP.PL

What would be interesting is to see just how much UDP 80 traffic exists on the Internet at any given moment.

I don't know if Arbor's ATLAS really tracks traffic in that way but it would be interesting to get a semi-global view of just how many PPS/BPS are being wasted on these types of floods.

Maybe even as a research paper =)

-Drew


-----Original Message-----
From: Fredrik Holmqvist / I2B [mailto:fredrik at i2b.se] 
Sent: Sunday, February 05, 2012 6:47 PM
To: nanog at nanog.org
Subject: Re: UDP port 80 DDoS attack

Hi.

We had a customer that was attacked by the same "game server feature".
We received aprox 10 Gbit of traffic against the customer.

The attacker sends spoofed packets to the game server with the target IP as "source", the gameserver sends replies back via UDP to the target host. The attacker sends a couple of hundred packets per second and thus generating a 10 Mbit UDP flood.

There is fixes/workarounds for the game servers, just a matter of the admin taking care of it.
See: http://rankgamehosting.ru/index.php?showtopic=1320

The "attacking" IPs aren't spoofed, so just compile a list and send e-mails to each provider.

We had 1000+ IPs gathered and sent 100+ abuse e-mails, only received reply from less than 20%.
Sad that people care so little about mitigating DDoS/UDP/ICMP floods.


On Sun, 5 Feb 2012 18:36:13 -0500, Ray Gasnick III <rgasnick at milestechnologies.com> wrote:
> We just saw a huge flux of traffic occur this morning that spiked one 
> of our upstream ISPs gear and killed the layer 2 link on another 
> becuase of a DDoS attack on UDP port 80.
> 
> 
> 
> Wireshark shows this appears to be from a compromised game server 
> (call of duty) with source IPs in a variety of different prefixes.
> 
> 
> 
> Only solution thus far was to dump the victim IP address in our block 
> into the BGP Black hole community with one of our 2 providers and 
> completely stop advertising to the other.
> 
> 
> 
> Anybody see this recently and have any tips on mitigation,  reply on 
> or off list.
> 
> 
> 
> Thank You,
> 
> Ray Gasnick III
> CISSP, Technology Specialist: Network Security & Infrastructure Miles 
> Technologies 
> www.milestechnologies.com<http://www.milestechnologies.com/>
> 
> Phone: (856) 439-0999 x127
> Direct: (856) 793-3821
> How am I doing?  Email my manager at
> itmanager at milestechnologies.com<mailto:itmanager at milestechnologies.com
> >
> 
> Computer Networking ? IT Support ? Business Software ? Website Design 
> ? Online Marketing & PR

--
Fredrik Holmqvist
I2B (Internet 2 Business)
070-740 5033



From matt at mattreath.com  Wed Feb  8 13:28:41 2012
From: matt at mattreath.com (Matthew Reath)
Date: Wed, 8 Feb 2012 13:28:41 -0600
Subject: Firewalls in service provider environments
In-Reply-To: <CAL9jLaZ_VrKhT0V4k85qFN7jRkcDDcwYj_e4+HsvE9f7ee-pzw@mail.gmail.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
 <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>
 <CAALUyuRJ4pob=97fk=ph39ey3zvpbNC4COtzMBaeOai+LfDGxw@mail.gmail.com>
 <62055779754543ae83e3c0fe4cdad677.squirrel@mail.mattreath.com>
 <CAL9jLaZ_VrKhT0V4k85qFN7jRkcDDcwYj_e4+HsvE9f7ee-pzw@mail.gmail.com>
Message-ID: <eaa0923a170c9499a91402401253e064.squirrel@mail.mattreath.com>

> On Wed, Feb 8, 2012 at 9:25 AM, Matthew Reath <matt at mattreath.com> wrote:
>
>> Good point. Adding in an established entry, although may open you up for
>> TCP/SYN sort of packets is a better trade off than affecting customer
>> traffic.
>
> 'established' is explicitly NOT 'syn' ...
> maybe you meant 'ack flood' ? (or rst flood? or .... but certainly not
> syn flood)
>

If I had an 'established' entry on an inbound ACL to filter traffic coming
from my upstream provider wouldn't SYN ACK (2nd step in handshake) packets
be allowed to pass the ACL because of this?

But I see your point a connection initiation from external sources with
just the SYN flag set would not be allowed.  However if a session is
initiated internally the returning SYN ACK from the external server would
be allowed as would ACK and data packets with ACK set.





From gbonser at seven.com  Wed Feb  8 13:50:42 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 8 Feb 2012 19:50:42 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CAL9jLaYVq8_97KxUzg-FoW+jaD_cS43Mf3r1LjOASAJgyCaF6A@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <21C0E0A6-99FB-4385-9355-629BDB5ECD9B@sungard.com>
 <CAL9jLaYVq8_97KxUzg-FoW+jaD_cS43Mf3r1LjOASAJgyCaF6A@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBE561@RWC-MBX1.corp.seven.com>



> -----Original Message-----
> From: christopher.morrow
> 
> to be fair: "Some Providers do not check registries for 'right to use'
> information about prefixes their customers wish to announce to them
> over BGP."

Maybe not but I would think that in practice it would be something like:

1. Provider initially filters traffic based on the address range they have issued to the customer.
2. If the customer brings their own IP addresses, the provider does a quick check to see if those have been SWIPed to the customer
3. If the customer wants the filtration opened up to include additional IPs, the do the same as #2
4. If the customer has no record of having control of those IPs, a quick call to the listed assignee of those numbers would verify that the customer is mutual and is properly sourcing traffic in that IP range and filters are adjusted accordingly. 

In about 99% of cases that would be the end of the story and everything runs merrily along after that.  Sure, there are going to be corner cases but if someone starts playing whack-a-mole with IP address assignments and is asking for frequent changes, that might be a tip-off that they might be trouble.

It *does* involve maintaining some record of the configuration settings someplace in case of equipment changes/failures, etc. but that would be a small price to pay for reducing the amount of time spent chasing DoS complaints.  It has to be a community effort with a set of best practices developed and applied by the community.  


From me at anuragbhatia.com  Wed Feb  8 13:51:17 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 9 Feb 2012 01:21:17 +0530
Subject: Question regarding anycasting in CDN setup
In-Reply-To: <CAAAas8E7oytFJuFWtxWt_BEugh8yBGSpLY2edYP03jVAHwsk2w@mail.gmail.com>
References: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
 <CAAAas8E7oytFJuFWtxWt_BEugh8yBGSpLY2edYP03jVAHwsk2w@mail.gmail.com>
Message-ID: <CAJ0+aXaQEbKDawh2JTE+EeogCkDLX1BheTxPN5JZy1TtsBHjrw@mail.gmail.com>

Nice explanation!


Thanks Mike.

Appreciate it.

On Thu, Feb 2, 2012 at 6:08 AM, Mike Jones <mike at mikejones.in> wrote:

> On 1 February 2012 20:25, Anurag Bhatia <me at anuragbhatia.com> wrote:
> <snip>
> > Now my question here is - why this setup and not simply using having a A
> > record for googlehosted.l.googleusercontent.com. which comes from any
> > anycasted IP address space? Why not anycasting at CDN itself rather then
> > only at DNS layer?
>
> You are confusing anycasting with offering different results.
>
> I can have an anycast DNS setup where all my servers give the same
> response (example: most DNS providers), I can also have a single DNS
> server give 192.0.2.80 out to queries sourced from a US IP Address,
> 198.51.100.80 for queries sourced from a German IP Address and
> 203.0.113.80 to queries sourced from a Chinese address (djbdns has a
> module for this for example).
>
> I would guess that google probably have a highly customised algorithm
> which uses a combination of source IP and the node that your query
> arrived at as part of the process for deciding what answer to give
> you, along with dozens of other internal factors.
>
> Although I do sometimes wonder why they use CNAME chains in cases
> where the same servers are authoritative for the target name anyway.
>
> If you were wondering why they direct you to the unicast addresses for
> the local datacentre instead of just giving an anycast address which
> your nearest datacentre would answer, well their algorithm might
> decide that it wants to serve you content from the second closest
> datacentre because the closest one is near capacity, anycast can't do
> that.
>
> - Mike
>



-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
Linkedin: http://linkedin.anuragbhatia.com

From me at anuragbhatia.com  Wed Feb  8 13:58:07 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 9 Feb 2012 01:28:07 +0530
Subject: Question regarding anycasting in CDN setup
In-Reply-To: <CAJ0+aXaQEbKDawh2JTE+EeogCkDLX1BheTxPN5JZy1TtsBHjrw@mail.gmail.com>
References: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
 <CAAAas8E7oytFJuFWtxWt_BEugh8yBGSpLY2edYP03jVAHwsk2w@mail.gmail.com>
 <CAJ0+aXaQEbKDawh2JTE+EeogCkDLX1BheTxPN5JZy1TtsBHjrw@mail.gmail.com>
Message-ID: <CAJ0+aXbEoCsbhM9bmn9zEwxMf153AJg_cEXD+zKaMurg4WGe3Q@mail.gmail.com>

Mike

 I can also have a single DNS
> server give 192.0.2.80 out to queries sourced from a US IP Address,
> 198.51.100.80 for queries sourced from a German IP Address and
> 203.0.113.80 to queries sourced from a Chinese address (djbdns has a
> module for this for example).


I have never did such setup, but I assume it works as you say. I wonder how
it finds a US based system from IP quickly (since it's DNS server)?


Thanks.
On Thu, Feb 9, 2012 at 1:21 AM, Anurag Bhatia <me at anuragbhatia.com> wrote:

> Nice explanation!
>
>
> Thanks Mike.
>
> Appreciate it.
>
> On Thu, Feb 2, 2012 at 6:08 AM, Mike Jones <mike at mikejones.in> wrote:
>
>> On 1 February 2012 20:25, Anurag Bhatia <me at anuragbhatia.com> wrote:
>> <snip>
>> > Now my question here is - why this setup and not simply using having a A
>> > record for googlehosted.l.googleusercontent.com. which comes from any
>> > anycasted IP address space? Why not anycasting at CDN itself rather then
>> > only at DNS layer?
>>
>> You are confusing anycasting with offering different results.
>>
>> I can have an anycast DNS setup where all my servers give the same
>> response (example: most DNS providers), I can also have a single DNS
>> server give 192.0.2.80 out to queries sourced from a US IP Address,
>> 198.51.100.80 for queries sourced from a German IP Address and
>> 203.0.113.80 to queries sourced from a Chinese address (djbdns has a
>> module for this for example).
>>
>> I would guess that google probably have a highly customised algorithm
>> which uses a combination of source IP and the node that your query
>> arrived at as part of the process for deciding what answer to give
>> you, along with dozens of other internal factors.
>>
>> Although I do sometimes wonder why they use CNAME chains in cases
>> where the same servers are authoritative for the target name anyway.
>>
>> If you were wondering why they direct you to the unicast addresses for
>> the local datacentre instead of just giving an anycast address which
>> your nearest datacentre would answer, well their algorithm might
>> decide that it wants to serve you content from the second closest
>> datacentre because the closest one is near capacity, anycast can't do
>> that.
>>
>> - Mike
>>
>
>
>
> --
>
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
>
> Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
> Linkedin: http://linkedin.anuragbhatia.com
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
Linkedin: http://linkedin.anuragbhatia.com

From brett at the-watsons.org  Wed Feb  8 14:04:22 2012
From: brett at the-watsons.org (Brett Watson)
Date: Wed, 8 Feb 2012 12:04:22 -0800
Subject: Question regarding anycasting in CDN setup
In-Reply-To: <CAJ0+aXbEoCsbhM9bmn9zEwxMf153AJg_cEXD+zKaMurg4WGe3Q@mail.gmail.com>
References: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
 <CAAAas8E7oytFJuFWtxWt_BEugh8yBGSpLY2edYP03jVAHwsk2w@mail.gmail.com>
 <CAJ0+aXaQEbKDawh2JTE+EeogCkDLX1BheTxPN5JZy1TtsBHjrw@mail.gmail.com>
 <CAJ0+aXbEoCsbhM9bmn9zEwxMf153AJg_cEXD+zKaMurg4WGe3Q@mail.gmail.com>
Message-ID: <A6F55B28-8153-48C0-82A9-8CF13BE0BDD9@the-watsons.org>


On Feb 8, 2012, at 11:58 AM, Anurag Bhatia wrote:

> Mike
> 
> I can also have a single DNS
>> server give 192.0.2.80 out to queries sourced from a US IP Address,
>> 198.51.100.80 for queries sourced from a German IP Address and
>> 203.0.113.80 to queries sourced from a Chinese address (djbdns has a
>> module for this for example).
> 
> 
> I have never did such setup, but I assume it works as you say. I wonder how
> it finds a US based system from IP quickly (since it's DNS server)?

Here is *one* method if you obtain a feed of geo-ip data from someone like Maxmind:

http://phix.me/geodns/


Several DNS providers have different methods and different geo-ip data vendors.

-b

From nanog-post at rsuc.gweep.net  Wed Feb  8 14:07:30 2012
From: nanog-post at rsuc.gweep.net (Joe Provo)
Date: Wed, 8 Feb 2012 15:07:30 -0500
Subject: Question regarding anycasting in CDN setup
In-Reply-To: <CAJ0+aXbEoCsbhM9bmn9zEwxMf153AJg_cEXD+zKaMurg4WGe3Q@mail.gmail.com>
References: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
 <CAAAas8E7oytFJuFWtxWt_BEugh8yBGSpLY2edYP03jVAHwsk2w@mail.gmail.com>
 <CAJ0+aXaQEbKDawh2JTE+EeogCkDLX1BheTxPN5JZy1TtsBHjrw@mail.gmail.com>
 <CAJ0+aXbEoCsbhM9bmn9zEwxMf153AJg_cEXD+zKaMurg4WGe3Q@mail.gmail.com>
Message-ID: <20120208200730.GA12862@gweep.net>

On Thu, Feb 09, 2012 at 01:28:07AM +0530, Anurag Bhatia wrote:
[snip]
> I have never did such setup, but I assume it works as you say. I wonder how
> it finds a US based system from IP quickly (since it's DNS server)?
 

Drop "ip geolocation" or "internet geolocation" into Your Favorite 
Search Engine. Short answer is some folks just refer to databases
published/generated by others, some folks use DNS guesses, and some
folks measure packet arrival. And most often, there is a combination 
of methods used.

-- 
         RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG


From mpetach at netflight.com  Wed Feb  8 14:46:33 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Wed, 8 Feb 2012 12:46:33 -0800
Subject: 2012.02.08 NANOG54 day 3 morning session notes
Message-ID: <CAEmG1=odct+tn66dX7AF0-YE0WZp3BVvQpGeXgtoGNLG-uPHeQ@mail.gmail.com>

I've posted my notes from this morning's session
at

http://kestrel3.netflight.com/2012.02.08-nanog54-morning-session.txt

I wonder if perhaps we don't keep asking for NEBS
compliance just because we don't have another
easy acronym to put on the RFQs that represents
what *our* industry needs, vs the telco industry?

Thanks again for another awesome NANOG!

Matt


From jra at baylink.com  Wed Feb  8 15:16:33 2012
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 8 Feb 2012 16:16:33 -0500 (EST)
Subject: 2012.02.08 NANOG54 day 3 morning session notes
In-Reply-To: <CAEmG1=odct+tn66dX7AF0-YE0WZp3BVvQpGeXgtoGNLG-uPHeQ@mail.gmail.com>
Message-ID: <18674615.1407.1328735793144.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Matthew Petach" <mpetach at netflight.com>

> I've posted my notes from this morning's session
> at
> 
> http://kestrel3.netflight.com/2012.02.08-nanog54-morning-session.txt
> 
> I wonder if perhaps we don't keep asking for NEBS
> compliance just because we don't have another
> easy acronym to put on the RFQs that represents
> what *our* industry needs, vs the telco industry?

Well, there is a difference between NEBS Compliant (which lots of people
make, and lots can use) and NEBS Certified (which entails paying money to
Telcordia, I think, and probably requires 23" racking, which most of us
don't care about...

Cheers,
-- jr 'at least, there used to be' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From henry at AegisInfoSys.com  Wed Feb  8 15:23:35 2012
From: henry at AegisInfoSys.com (Henry Yen)
Date: Wed, 8 Feb 2012 16:23:35 -0500
Subject: Firewalls in service provider environments
In-Reply-To: <62055779754543ae83e3c0fe4cdad677.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
 <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>
 <CAALUyuRJ4pob=97fk=ph39ey3zvpbNC4COtzMBaeOai+LfDGxw@mail.gmail.com>
 <62055779754543ae83e3c0fe4cdad677.squirrel@mail.mattreath.com>
Message-ID: <20120208212335.GX3627@nntp.AegisInfoSys.com>

On Wed, Feb 08, 2012 at 08:25:18AM -0600, Matthew Reath wrote:
> > If you apply the ACL you showed as an inbound ACL on your provider facing
> > interfaces, you will be breaking any connections that exit your network
> > with source ports from your list of bad ports.  For example, you connect
> > out from x.x.x.x:8888 to y.y.y.y:80, then the response packets coming back
> > into your network will be from y.y.y.y:80 to x.x.x.x:8888 and will be
> > dropped by your ACL.

> Good point. Adding in an established entry, although may open you up for
> TCP/SYN sort of packets is a better trade off than affecting customer
> traffic.

I've always thought that reflexive access lists were quite elegant,
and a much better method than established, albeit for edge networks.

Do they not work in the SP space?

--
Henry Yen                                       Aegis Information Systems, Inc.
Senior Systems Programmer                       Hicksville, New York


From marka at isc.org  Wed Feb  8 16:14:22 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 09 Feb 2012 09:14:22 +1100
Subject: UDP port 80 DDoS attack
In-Reply-To: Your message of "Wed, 08 Feb 2012 19:50:42 -0000."
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBE561@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <21C0E0A6-99FB-4385-9355-629BDB5ECD9B@sungard.com>
 <CAL9jLaYVq8_97KxUzg-FoW+ja
 D_cS43Mf3r1LjOASAJgyCaF6A@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBE561@RWC-MBX1.corp.seven.com>
Message-ID: <20120208221422.D2EB31D05153@drugs.dv.isc.org>


In message <596B74B410EE6B4CA8A30C3AF1A155EA09CBE561 at RWC-MBX1.corp.seven.com>, G
eorge Bonser writes:
> 
> 
> > -----Original Message-----
> > From: christopher.morrow
> >=20
> > to be fair: "Some Providers do not check registries for 'right to use'
> > information about prefixes their customers wish to announce to them
> > over BGP."
> 
> Maybe not but I would think that in practice it would be something like:
> 
> 1. Provider initially filters traffic based on the address range they have =
> issued to the customer.
> 2. If the customer brings their own IP addresses, the provider does a quick=
>  check to see if those have been SWIPed to the customer
> 3. If the customer wants the filtration opened up to include additional IPs=
> , the do the same as #2
> 4. If the customer has no record of having control of those IPs, a quick ca=
> ll to the listed assignee of those numbers would verify that the customer i=
> s mutual and is properly sourcing traffic in that IP range and filters are =
> adjusted accordingly.=20
> 
> In about 99% of cases that would be the end of the story and everything run=
> s merrily along after that.  Sure, there are going to be corner cases but i=
> f someone starts playing whack-a-mole with IP address assignments and is as=
> king for frequent changes, that might be a tip-off that they might be troub=
> le.
> 
> It *does* involve maintaining some record of the configuration settings som=
> eplace in case of equipment changes/failures, etc. but that would be a smal=
> l price to pay for reducing the amount of time spent chasing DoS complaints=
> .  It has to be a community effort with a set of best practices developed a=
> nd applied by the community. =20

And with cryptographically signed assignments this can be completely
automated.  Tie the DHCPv6 server into the RPKI system and DHCPv6
PD can do the right stuff so that the other ISP serving the customer
can know that these address are legal from the customer.

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


From cra at WPI.EDU  Wed Feb  8 17:41:41 2012
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 8 Feb 2012 18:41:41 -0500
Subject: RoadRunner/Adelphia AS14065 contact
In-Reply-To: <4F0DEDA5.7070000@gmail.com>
References: <4F0DEDA5.7070000@gmail.com>
Message-ID: <20120208234141.GZ5968@angus.ind.WPI.EDU>

On Wed, Jan 11, 2012 at 12:14:29PM -0800, chk wrote:
> If there is a Roadrunner contact monitoring the list can you please  
> contact me off list regarding a routing issue from ns1/2.adelphia.net

Did you ever get any response?  I'm having a similar issue:

For the past couple months, we have been unable to query the
authoritative DNS servers for adelphia.net on IP addresses
75.180.129.58 and 75.180.129.59 from our campus network IP block
130.215.0.0/16, using either TCP or UDP:

>dig +short +norec @75.180.129.58 adelphia.net. mx
;; connection timed out; no servers could be reached

>dig +short +norec @75.180.129.59 adelphia.net. mx
;; connection timed out; no servers could be reached

>dig +tcp +short +norec @75.180.129.58 adelphia.net. mx
;; communications error to 75.180.129.58#53: end of file

>dig +tcp +short +norec @75.180.129.59 adelphia.net. mx
;; communications error to 75.180.129.59#53: end of file

This is causing email failures to anyone with an @adelphia.net email
address.

I can ping the DNS servers from 130.215.0.0/16:

>ping  -c3 75.180.129.58 
PING 75.180.129.58 (75.180.129.58) 56(84) bytes of data.
64 bytes from 75.180.129.58: icmp_req=1 ttl=241 time=26.9 ms
64 bytes from 75.180.129.58: icmp_req=2 ttl=241 time=26.7 ms
64 bytes from 75.180.129.58: icmp_req=3 ttl=241 time=26.7 ms

--- 75.180.129.58 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 26.711/26.797/26.953/0.110 ms

>ping -c3 75.180.129.59
PING 75.180.129.59 (75.180.129.59) 56(84) bytes of data.
64 bytes from 75.180.129.59: icmp_req=1 ttl=241 time=25.9 ms
64 bytes from 75.180.129.59: icmp_req=2 ttl=241 time=26.1 ms
64 bytes from 75.180.129.59: icmp_req=3 ttl=241 time=25.5 ms

--- 75.180.129.59 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 25.523/25.871/26.120/0.285 ms

And I can make a TCP port 53 connection which gets immediately closed:

>telnet 75.180.129.58 53
Trying 75.180.129.58...
Connected to 75.180.129.58.
Escape character is '^]'.
Connection closed by foreign host.

>telnet 75.180.129.59 53
Trying 75.180.129.59...
Connected to 75.180.129.59.
Escape character is '^]'.
Connection closed by foreign host.

It is acting as if there is an ACL or firewall rule that is blocking
130.215.0.0/16 from accessing DNS port 53 on the DNS servers at
75.180.129.58 and 75.180.129.59.

I've already ruled out any firewalls on our end, as well as any
routing issues.  I can see the UDP port 53 packets going out, but
there is no reply.  I can see the 3-way TCP port 53 handshake packets
going out and coming in, but the other end closes the connection
immediately.

If I use a non-130.215.0.0/16 source IP from my router, I get a normal
response via both UDP and TCP:

% dig -b 207.210.142.142 +short +norec @75.180.129.58 adelphia.net. mx
10 cdptpa-smtpin01.mail.rr.com.
20 cdptpa-smtpin02.mail.rr.com.

% dig -b 207.210.142.142 +short +tcp +norec @75.180.129.58 adelphia.net. mx
10 cdptpa-smtpin01.mail.rr.com.
20 cdptpa-smtpin02.mail.rr.com.

I'd appreciate if someone could help me find a clueful contact at
TW/RoadRunner/Adelphia/Comcast/whoever they are now.  I've tried all
the contacts in WHOIS for adelphia.net, the IP block, and ASN.  I've
tried the NOC List on puck.nether.net--no matches.

Thanks,
Chuck


From johnl at iecc.com  Wed Feb  8 20:03:30 2012
From: johnl at iecc.com (John Levine)
Date: 9 Feb 2012 02:03:30 -0000
Subject: Slow IN-ADDR.ARPA responses
Message-ID: <20120209020330.6513.qmail@joyce.lan>

I'm seeing surprisingly slow responses from some of the IN-ADDR
servers, like 300ms or more.  Are they being attacked by script
kiddies of something?

R's,
John



From markk at arin.net  Wed Feb  8 20:23:59 2012
From: markk at arin.net (Mark Kosters)
Date: Thu, 9 Feb 2012 02:23:59 +0000
Subject: Slow IN-ADDR.ARPA responses
In-Reply-To: <20120209020330.6513.qmail@joyce.lan>
Message-ID: <CB589765.59670%markk@arin.net>

Hi John

I checked the traffic graphs for the server we operate
(a.in-addr-servers.arpa) and it has normal traffic loads. Have not heard
of any report of issues with the other operators.

Regards,
Mark

On 2/8/12 9:03 PM, "John Levine" <johnl at iecc.com> wrote:

>I'm seeing surprisingly slow responses from some of the IN-ADDR
>servers, like 300ms or more.  Are they being attacked by script
>kiddies of something?
>
>R's,
>John
>
>



From marka at isc.org  Wed Feb  8 20:37:23 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 09 Feb 2012 13:37:23 +1100
Subject: RoadRunner/Adelphia AS14065 contact
In-Reply-To: Your message of "Wed, 08 Feb 2012 18:41:41 CDT."
 <20120208234141.GZ5968@angus.ind.WPI.EDU>
References: <4F0DEDA5.7070000@gmail.com>
 <20120208234141.GZ5968@angus.ind.WPI.EDU>
Message-ID: <20120209023723.1C36B1D076A4@drugs.dv.isc.org>


In message <20120208234141.GZ5968 at angus.ind.WPI.EDU>, Chuck Anderson writes:
> On Wed, Jan 11, 2012 at 12:14:29PM -0800, chk wrote:
> > If there is a Roadrunner contact monitoring the list can you please  
> > contact me off list regarding a routing issue from ns1/2.adelphia.net
> 
> Did you ever get any response?  I'm having a similar issue:
> 
> For the past couple months, we have been unable to query the
> authoritative DNS servers for adelphia.net on IP addresses
> 75.180.129.58 and 75.180.129.59 from our campus network IP block
> 130.215.0.0/16, using either TCP or UDP:
> 
> >dig +short +norec @75.180.129.58 adelphia.net. mx
> ;; connection timed out; no servers could be reached
> 
> >dig +short +norec @75.180.129.59 adelphia.net. mx
> ;; connection timed out; no servers could be reached
> 
> >dig +tcp +short +norec @75.180.129.58 adelphia.net. mx
> ;; communications error to 75.180.129.58#53: end of file
> 
> >dig +tcp +short +norec @75.180.129.59 adelphia.net. mx
> ;; communications error to 75.180.129.59#53: end of file
> 
> This is causing email failures to anyone with an @adelphia.net email
> address.
> 
> I can ping the DNS servers from 130.215.0.0/16:
> 
> >ping  -c3 75.180.129.58 
> PING 75.180.129.58 (75.180.129.58) 56(84) bytes of data.
> 64 bytes from 75.180.129.58: icmp_req=1 ttl=241 time=26.9 ms
> 64 bytes from 75.180.129.58: icmp_req=2 ttl=241 time=26.7 ms
> 64 bytes from 75.180.129.58: icmp_req=3 ttl=241 time=26.7 ms
> 
> --- 75.180.129.58 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2001ms
> rtt min/avg/max/mdev = 26.711/26.797/26.953/0.110 ms
> 
> >ping -c3 75.180.129.59
> PING 75.180.129.59 (75.180.129.59) 56(84) bytes of data.
> 64 bytes from 75.180.129.59: icmp_req=1 ttl=241 time=25.9 ms
> 64 bytes from 75.180.129.59: icmp_req=2 ttl=241 time=26.1 ms
> 64 bytes from 75.180.129.59: icmp_req=3 ttl=241 time=25.5 ms
> 
> --- 75.180.129.59 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2002ms
> rtt min/avg/max/mdev = 25.523/25.871/26.120/0.285 ms
> 
> And I can make a TCP port 53 connection which gets immediately closed:
> 
> >telnet 75.180.129.58 53
> Trying 75.180.129.58...
> Connected to 75.180.129.58.
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> >telnet 75.180.129.59 53
> Trying 75.180.129.59...
> Connected to 75.180.129.59.
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> It is acting as if there is an ACL or firewall rule that is blocking
> 130.215.0.0/16 from accessing DNS port 53 on the DNS servers at
> 75.180.129.58 and 75.180.129.59.
> 
> I've already ruled out any firewalls on our end, as well as any
> routing issues.  I can see the UDP port 53 packets going out, but
> there is no reply.  I can see the 3-way TCP port 53 handshake packets
> going out and coming in, but the other end closes the connection
> immediately.
> 
> If I use a non-130.215.0.0/16 source IP from my router, I get a normal
> response via both UDP and TCP:
> 
> % dig -b 207.210.142.142 +short +norec @75.180.129.58 adelphia.net. mx
> 10 cdptpa-smtpin01.mail.rr.com.
> 20 cdptpa-smtpin02.mail.rr.com.
> 
> % dig -b 207.210.142.142 +short +tcp +norec @75.180.129.58 adelphia.net. mx
> 10 cdptpa-smtpin01.mail.rr.com.
> 20 cdptpa-smtpin02.mail.rr.com.
> 
> I'd appreciate if someone could help me find a clueful contact at
> TW/RoadRunner/Adelphia/Comcast/whoever they are now.  I've tried all
> the contacts in WHOIS for adelphia.net, the IP block, and ASN.  I've
> tried the NOC List on puck.nether.net--no matches.
> 
> Thanks,
> Chuck
> 

Sounds like a bad "bogus" acl.

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


From johnl at iecc.com  Wed Feb  8 20:46:31 2012
From: johnl at iecc.com (John Levine)
Date: 9 Feb 2012 02:46:31 -0000
Subject: Slow IN-ADDR.ARPA responses
In-Reply-To: <CB589765.59670%markk@arin.net>
Message-ID: <20120209024631.7962.qmail@joyce.lan>

>I checked the traffic graphs for the server we operate
>(a.in-addr-servers.arpa) and it has normal traffic loads. Have not heard
>of any report of issues with the other operators.

Actually, the A server is the only one that's responding quickly,
viewed from my DSL line hanging off gblx:

A   26ms
B   83ms
C  308ms
D  136ms
E  248ms
F   96ms

An acquaintance at LinkedIn tells me that they're seeing the same issue.

Doing a traceroute to the C server, it looks pretty snappy as far as
London, then slow as soon as it's in Afrinic's network.  I think it's
usually faster than that.  For the E server, the link between HE in
California and Australia seems slow.

R's,
John


From khomyakov.andrey at gmail.com  Wed Feb  8 22:54:46 2012
From: khomyakov.andrey at gmail.com (Andrey Khomyakov)
Date: Wed, 8 Feb 2012 23:54:46 -0500
Subject: BGP history in enterprise?
Message-ID: <CAB31LOOugj-Ys8npH=HEdB8DphGhE5K66=ZNHyS+cmQj1Pyv6A@mail.gmail.com>

Looking for something to keep track of BGP route changes in a large
enterprise. Found http://www.ibgplay.org/, but I can't seem to get in touch
with them to obtain that free license needed to start the service.
Does anyone know of something that would do what bgplay does or
alternatively how to get in touch with the ibgplay folks for that license...

Thanks,

--Andrey

From nenolod at systeminplace.net  Wed Feb  8 23:11:10 2012
From: nenolod at systeminplace.net (William Pitcock)
Date: Wed, 8 Feb 2012 23:11:10 -0600
Subject: report botnet C&C?
In-Reply-To: <20120208190433.GA19246@vectra.student.iastate.edu>
References: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
 <20120208190433.GA19246@vectra.student.iastate.edu>
Message-ID: <CC6A7792-C9E6-4577-A05E-5908FEB0FDD3@systeminplace.net>

hi,

On Feb 8, 2012, at 1:04 PM, Nicolai wrote:

> On Tue, Feb 07, 2012 at 10:20:07PM -0500, Ryan Rawdon wrote:
>> Assuming it is not a futile/wasted effort, where is the current best
>> place/resource to report an active botnet C&C to?
> 
> I don't know if there's a single best option, but there are several good
> ones.  In addition to Cymru I'd mention abuse.ch, which runs several
> public botnet C&C trackers.

DroneBL does investigate and track C&Cs, or at least, did when I ran it.  I would assume that it still does, so you may wish to contact them.

William



From me at anuragbhatia.com  Thu Feb  9 03:41:14 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 9 Feb 2012 15:11:14 +0530
Subject: Slow IN-ADDR.ARPA responses
In-Reply-To: <20120209024631.7962.qmail@joyce.lan>
References: <CB589765.59670%markk@arin.net>
 <20120209024631.7962.qmail@joyce.lan>
Message-ID: <CAJ0+aXYZ0XkPDpJZHLnxy52iNb9B8_zO3MmoCUeAjXpuWmiaQQ@mail.gmail.com>

Hi John


I have seen similar cases in past with root servers itself. Usually
problems are that local anycasted node here goes down and thus traffic is
redirected to other nearest server in Europe causing high latency. Can you
share traceroute result of a good Vs bad node say A Vs C. Can you see both
coming from within your country?

On Thu, Feb 9, 2012 at 8:16 AM, John Levine <johnl at iecc.com> wrote:

> >I checked the traffic graphs for the server we operate
> >(a.in-addr-servers.arpa) and it has normal traffic loads. Have not heard
> >of any report of issues with the other operators.
>
> Actually, the A server is the only one that's responding quickly,
> viewed from my DSL line hanging off gblx:
>
> A   26ms
> B   83ms
> C  308ms
> D  136ms
> E  248ms
> F   96ms
>
> An acquaintance at LinkedIn tells me that they're seeing the same issue.
>
> Doing a traceroute to the C server, it looks pretty snappy as far as
> London, then slow as soon as it's in Afrinic's network.  I think it's
> usually faster than that.  For the E server, the link between HE in
> California and Australia seems slow.
>
> R's,
> John
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
Linkedin: http://linkedin.anuragbhatia.com

From sven at cb3rob.net  Thu Feb  9 07:07:50 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Thu, 9 Feb 2012 13:07:50 +0000 (UTC)
Subject: UDP port 80 DDoS attack
In-Reply-To: <F3318834F1F89D46857972DD4B411D70052CA02411@exchange>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>
 <F3318834F1F89D46857972DD4B411D70052CA02411@exchange>
Message-ID: <Pine.LNX.4.64.1202091305420.22348@a84-22-97-10.cb3rob.net>


> Stop paying transit providers for delivering spoofed packets to the edge of your network and they will very quickly develop methods of proving that the traffic isn't spoofed, or block it altogether. =)
>
> -Drew

yes, very smart idea... which makes it completely impossible to have 
multihomed networks or simply kick out tunnel originated traffic over 
default gateways ... so, no, thanks.

we usually do it the other way around, if providers block "spoofed" 
traffic, we tell them to put their serverfarms somewhere else as thats not 
very optimized for tunnel termination at their facilities :P

(yes leaseweb, that means you ;)

>
>
> -----Original Message-----
> From: George Bonser [mailto:gbonser at seven.com]
> Sent: Wednesday, February 08, 2012 1:27 PM
> To: bas; nanog
> Subject: RE: UDP port 80 DDoS attack
>
>> 77% of all networks seem to think so.
>> http://spoofer.csail.mit.edu/summary.php
>
> And it would be the remaining 23% that really need to understand how difficult they are making life for the rest of the Internet.
>
>> However the remaining networks allow spoofed traffic to egress their
>> networks.
>>
>> When that traffic enters my network, I have no method whatsoever to
>> differentiate it from any other traffic.
>
> I'm not really thinking about traffic coming from the Internet.  I'm thinking about its originating location.  Correct, once it gets into the Internet, you really have no way to tell.
>
>> I could ask my upstream where they see it coming from, which will be
>> quite hard if they do not have pretty fancy systems.
>
> At that point the game is really hard, agreed.  And if it is distributed, it could be coming from any number of places or from every single one of their upstreams.
>
>
>> But if they receive it from a peer, I am as good as lost in trying to
>> find the culprit.
>
> Agreed.  That's why it is important to stop it at the source.
>
>> Bas
>
>


From streiner at cluebyfour.org  Thu Feb  9 10:18:45 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Thu, 9 Feb 2012 11:18:45 -0500 (EST)
Subject: BGP history in enterprise?
In-Reply-To: <CAB31LOOugj-Ys8npH=HEdB8DphGhE5K66=ZNHyS+cmQj1Pyv6A@mail.gmail.com>
References: <CAB31LOOugj-Ys8npH=HEdB8DphGhE5K66=ZNHyS+cmQj1Pyv6A@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202091117410.3280@whammy.cluebyfour.org>

On Wed, 8 Feb 2012, Andrey Khomyakov wrote:

> Looking for something to keep track of BGP route changes in a large
> enterprise. Found http://www.ibgplay.org/, but I can't seem to get in touch
> with them to obtain that free license needed to start the service.
> Does anyone know of something that would do what bgplay does or
> alternatively how to get in touch with the ibgplay folks for that license...

If you're looking for changes that make it into the global BGP view, try 
http://bgplay.routeviews.org/

jms


From leigh.porter at ukbroadband.com  Thu Feb  9 11:31:39 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Thu, 9 Feb 2012 17:31:39 +0000
Subject: 10G switchrecommendaton
In-Reply-To: <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
Message-ID: <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Brent Jones [mailto:brent at brentrjones.com]
> Sent: 27 January 2012 06:33
> To: Rodrick Brown
> Cc: nanog list
> Subject: Re: 10G switchrecommendaton
> 
> On Thu, Jan 26, 2012 at 8:40 PM, Rodrick Brown
> <rodrick.brown at gmail.com>wrote:
> 
> > Not to mention Arista's cli runs a busybox Linux inside!
> >
> > Sent from my iPhone
> >
> >
> >
> Last I checked, Arista used Fedora Linux, with x86 dual-core CPUs and
> 4GB
> RAM.
> Their CLI was written in Python or Perl as well, and they encourage
> hacking
> it for cool new things.

Based on this thread I has Arista in today for a show'n'tell and it is pretty impressive both in terms of features (features that you actually use) and pricing.

So a couple of evals on the way...

--
Leigh





______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


From adrian.minta at gmail.com  Thu Feb  9 11:59:27 2012
From: adrian.minta at gmail.com (Adrian Minta)
Date: Thu, 09 Feb 2012 19:59:27 +0200
Subject: 10G switchrecommendaton
In-Reply-To: <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
Message-ID: <4F34097F.2030504@gmail.com>

Cisco has finally release a new 10G switch, Catalyst 4500-X:
http://www.cisco.com/en/US/products/ps12332/index.html

Does anyone know the price range, or the FCS date for this ?



From mehmet at icann.org  Thu Feb  9 12:16:42 2012
From: mehmet at icann.org (Mehmet Akcin)
Date: Thu, 9 Feb 2012 10:16:42 -0800
Subject: Slow IN-ADDR.ARPA responses
In-Reply-To: <20120209020330.6513.qmail@joyce.lan>
References: <20120209020330.6513.qmail@joyce.lan>
Message-ID: <DA01FEF1-14E3-4064-A9C5-579068EDAF7A@icann.org>


On Feb 8, 2012, at 6:03 PM, John Levine wrote:

> I'm seeing surprisingly slow responses from some of the IN-ADDR
> servers, like 300ms or more.  Are they being attacked by script
> kiddies of something?
> 
> R's,
> John
> 
> 


We operate B.* and we don't see anything unusual in our locations.

thanks

Mehmet


From gbonser at seven.com  Thu Feb  9 14:24:44 2012
From: gbonser at seven.com (George Bonser)
Date: Thu, 9 Feb 2012 20:24:44 +0000
Subject: 10G switchrecommendaton
In-Reply-To: <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CC03F4@RWC-MBX1.corp.seven.com>

> 
> Based on this thread I has Arista in today for a show'n'tell and it is
> pretty impressive both in terms of features (features that you actually
> use) and pricing.
> 
> So a couple of evals on the way...
> 
> --
> Leigh

It's pretty good gear.  The only problem I've had with it is the limitation of IGMP not working on mLAG VLANs.





From johnl at iecc.com  Thu Feb  9 14:38:45 2012
From: johnl at iecc.com (John Levine)
Date: 9 Feb 2012 20:38:45 -0000
Subject: Slow IN-ADDR.ARPA responses
In-Reply-To: <DA01FEF1-14E3-4064-A9C5-579068EDAF7A@icann.org>
Message-ID: <20120209203845.45692.qmail@joyce.lan>

>We operate B.* and we don't see anything unusual in our locations.

Seems to have been routing problems with C.  The B server looks fine
from here, too.  Thanks, all.

R's,
John


From efinley.lists at gmail.com  Thu Feb  9 14:55:52 2012
From: efinley.lists at gmail.com (Elliot Finley)
Date: Thu, 9 Feb 2012 13:55:52 -0700
Subject: 10G switchrecommendaton
In-Reply-To: <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
Message-ID: <CACRGtSO2NN4kCB0PDMZ4zF0Jzj-_UB5EC6p-5HkCu84t0Sy0FQ@mail.gmail.com>

On Thu, Feb 9, 2012 at 10:31 AM, Leigh Porter
<leigh.porter at ukbroadband.com> wrote:
> Based on this thread I has Arista in today for a show'n'tell and it is pretty impressive both in terms of features (features that you actually use) and pricing.
>
> So a couple of evals on the way...

Let us know how the eval goes if you would.

Thanks,
Elliot


From ltd at interlink.com.au  Thu Feb  9 15:13:13 2012
From: ltd at interlink.com.au (lincoln dale)
Date: Fri, 10 Feb 2012 08:13:13 +1100
Subject: 10G switchrecommendaton
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CC03F4@RWC-MBX1.corp.seven.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC03F4@RWC-MBX1.corp.seven.com>
Message-ID: <CAAUJCVNkJ9dEBeywQvOmxr5OuTH+o7n2o0aQ1LDvv_D5dN6bnA@mail.gmail.com>

On Fri, Feb 10, 2012 at 7:24 AM, George Bonser <gbonser at seven.com> wrote:

> It's pretty good gear.  The only problem I've had with it is the
> limitation of IGMP not working on mLAG VLANs.
>

IGMP should work just fine with MLAG.  IGMP state is sync'd between the
MLAG pair. Happy to talk about this more off-list if you wish.


cheers,

lincoln.
(ltd at aristanetworks.com)

From gbonser at seven.com  Thu Feb  9 15:17:21 2012
From: gbonser at seven.com (George Bonser)
Date: Thu, 9 Feb 2012 21:17:21 +0000
Subject: 10G switchrecommendaton
In-Reply-To: <CAAUJCVNkJ9dEBeywQvOmxr5OuTH+o7n2o0aQ1LDvv_D5dN6bnA@mail.gmail.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC03F4@RWC-MBX1.corp.seven.com>
 <CAAUJCVNkJ9dEBeywQvOmxr5OuTH+o7n2o0aQ1LDvv_D5dN6bnA@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CC0481@RWC-MBX1.corp.seven.com>

Feb  9 07:42:21 SJC-AGS-01 IgmpSnooping: %IGMPSNOOPING-4-IGMPV3_UNSUPPORTED: IGMPv3 querier detected on interface Port-Channel1 (message repeated 34 times in 625.028 secs)

SJC-AGS-01#sho ver
Arista DCS-7124S-F
Hardware version:    06.02
Serial number:       JSH10130054
System MAC address:  001c.7308.752f

Software image version: 4.6.4
Architecture:           i386
Internal build version: 4.6.4-434606.EOS464

Sure, we can discuss it.



From: lincoln dale [mailto:ltd at interlink.com.au]
Sent: Thursday, February 09, 2012 1:13 PM
To: George Bonser
Cc: Leigh Porter; nanog list
Subject: Re: 10G switchrecommendaton

On Fri, Feb 10, 2012 at 7:24 AM, George Bonser <gbonser at seven.com<mailto:gbonser at seven.com>> wrote:
It's pretty good gear.  The only problem I've had with it is the limitation of IGMP not working on mLAG VLANs.

IGMP should work just fine with MLAG.  IGMP state is sync'd between the MLAG pair. Happy to talk about this more off-list if you wish.


cheers,

lincoln.
(ltd at aristanetworks.com<mailto:ltd at aristanetworks.com>)

From ltd at interlink.com.au  Thu Feb  9 15:47:19 2012
From: ltd at interlink.com.au (lincoln dale)
Date: Fri, 10 Feb 2012 08:47:19 +1100
Subject: 10G switchrecommendaton
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CC0481@RWC-MBX1.corp.seven.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC03F4@RWC-MBX1.corp.seven.com>
 <CAAUJCVNkJ9dEBeywQvOmxr5OuTH+o7n2o0aQ1LDvv_D5dN6bnA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC0481@RWC-MBX1.corp.seven.com>
Message-ID: <CAAUJCVP+eDV0A5yFM9nZfbmu9Cijv=MqXrkNj54SwurO4qqR4Q@mail.gmail.com>

hi George,

IGMPv3 snooping has been supported since EOS 4.7.  Its enabled by default
in EOS 4.8.x.

In terms of specifics, there is support for both IGMPv3 snooping & IGMPv3
querier. There isn't currently support for IGMPv3 snooping querier.


cheers,

lincoln.

On Fri, Feb 10, 2012 at 8:17 AM, George Bonser <gbonser at seven.com> wrote:

>  Feb  9 07:42:21 SJC-AGS-01 IgmpSnooping:
> %IGMPSNOOPING-4-IGMPV3_UNSUPPORTED: IGMPv3 querier detected on interface
> Port-Channel1 (message repeated 34 times in 625.028 secs)****
>
> ** **
>
> SJC-AGS-01#sho ver****
>
> Arista DCS-7124S-F****
>
> Hardware version:    06.02****
>
> Serial number:       JSH10130054****
>
> System MAC address:  001c.7308.752f****
>
> ** **
>
> Software image version: 4.6.4****
>
> Architecture:           i386****
>
> Internal build version: 4.6.4-434606.EOS464****
>
> ** **
>
> Sure, we can discuss it.****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* lincoln dale [mailto:ltd at interlink.com.au]
> *Sent:* Thursday, February 09, 2012 1:13 PM
> *To:* George Bonser
> *Cc:* Leigh Porter; nanog list
> *Subject:* Re: 10G switchrecommendaton****
>
> ** **
>
> On Fri, Feb 10, 2012 at 7:24 AM, George Bonser <gbonser at seven.com> wrote:
> ****
>
> It's pretty good gear.  The only problem I've had with it is the
> limitation of IGMP not working on mLAG VLANs.****
>
>
> IGMP should work just fine with MLAG.  IGMP state is sync'd between the
> MLAG pair. Happy to talk about this more off-list if you wish.
>
>
> cheers,
>
> lincoln.
> (ltd at aristanetworks.com)****
>

From gbonser at seven.com  Thu Feb  9 16:48:31 2012
From: gbonser at seven.com (George Bonser)
Date: Thu, 9 Feb 2012 22:48:31 +0000
Subject: 10G switchrecommendaton
In-Reply-To: <CAAUJCVP+eDV0A5yFM9nZfbmu9Cijv=MqXrkNj54SwurO4qqR4Q@mail.gmail.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC03F4@RWC-MBX1.corp.seven.com>
 <CAAUJCVNkJ9dEBeywQvOmxr5OuTH+o7n2o0aQ1LDvv_D5dN6bnA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC0481@RWC-MBX1.corp.seven.com>
 <CAAUJCVP+eDV0A5yFM9nZfbmu9Cijv=MqXrkNj54SwurO4qqR4Q@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CC05E4@RWC-MBX1.corp.seven.com>

Hi, Lincoln,

*sigh*

Ok, I see what happened.  We just went through a software upgrade cycle on that unit and it got upgraded to the end of 4.6 instead of being upgraded to the latest release version of EOS. Looks like another upgrade needs to be done, probably to 4.8.3

Thanks.

George


From: lincoln dale [mailto:ltd at interlink.com.au]
Sent: Thursday, February 09, 2012 1:47 PM
To: George Bonser
Cc: Leigh Porter; nanog list
Subject: Re: 10G switchrecommendaton

hi George,

IGMPv3 snooping has been supported since EOS 4.7.  Its enabled by default in EOS 4.8.x.

In terms of specifics, there is support for both IGMPv3 snooping & IGMPv3 querier. There isn't currently support for IGMPv3 snooping querier.


cheers,

lincoln.
On Fri, Feb 10, 2012 at 8:17 AM, George Bonser <gbonser at seven.com<mailto:gbonser at seven.com>> wrote:
Feb  9 07:42:21 SJC-AGS-01 IgmpSnooping: %IGMPSNOOPING-4-IGMPV3_UNSUPPORTED: IGMPv3 querier detected on interface Port-Channel1 (message repeated 34 times in 625.028 secs)

SJC-AGS-01#sho ver
Arista DCS-7124S-F
Hardware version:    06.02
Serial number:       JSH10130054
System MAC address:  001c.7308.752f

Software image version: 4.6.4
Architecture:           i386
Internal build version: 4.6.4-434606.EOS464

Sure, we can discuss it.



From: lincoln dale [mailto:ltd at interlink.com.au<mailto:ltd at interlink.com.au>]
Sent: Thursday, February 09, 2012 1:13 PM
To: George Bonser
Cc: Leigh Porter; nanog list
Subject: Re: 10G switchrecommendaton

On Fri, Feb 10, 2012 at 7:24 AM, George Bonser <gbonser at seven.com<mailto:gbonser at seven.com>> wrote:
It's pretty good gear.  The only problem I've had with it is the limitation of IGMP not working on mLAG VLANs.

IGMP should work just fine with MLAG.  IGMP state is sync'd between the MLAG pair. Happy to talk about this more off-list if you wish.


cheers,

lincoln.
(ltd at aristanetworks.com<mailto:ltd at aristanetworks.com>)


From davidianwalker at gmail.com  Thu Feb  9 00:13:03 2012
From: davidianwalker at gmail.com (David Walker)
Date: Thu, 9 Feb 2012 16:43:03 +1030
Subject: Firewalls in service provider environments
In-Reply-To: <20120208212335.GX3627@nntp.AegisInfoSys.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
 <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>
 <CAALUyuRJ4pob=97fk=ph39ey3zvpbNC4COtzMBaeOai+LfDGxw@mail.gmail.com>
 <62055779754543ae83e3c0fe4cdad677.squirrel@mail.mattreath.com>
 <20120208212335.GX3627@nntp.AegisInfoSys.com>
Message-ID: <CABE=bRN+6FkJiYWp1s9O71Z6-A6YVyJEmppuwu-omMoTsBU2iQ@mail.gmail.com>

I'm an end user but I refer to these from time to time:

http://www.ietf.org/rfc/rfc3013.txt
http://www.ietf.org/rfc/rfc3871.txt

I suppose the salient question is what kind of customers are we talking about.

Best wishes.


From steve.bertrand at gmail.com  Wed Feb  8 17:49:43 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Wed, 08 Feb 2012 18:49:43 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <F3318834F1F89D46857972DD4B411D70052CA02411@exchange>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>
 <F3318834F1F89D46857972DD4B411D70052CA02411@exchange>
Message-ID: <4F330A17.2010806@gmail.com>

On 2012.02.08 14:23, Drew Weaver wrote:
> Stop paying transit providers for delivering spoofed packets to the edge of your network and they will very quickly develop methods of proving that the traffic isn't spoofed, or block it altogether. =)

I firmly believe in this recourse, amongst others...

If you know that your provider allows spoofed traffic, let the community 
know about it.

In all aspects of life, a problem must be 'fixed' at the source. All of 
the small-medium size ops have to connect to the big-boys somewhere, and 
what I've seen in this industry is that the big-boys are generally 
compliant.

Steve


From justine at cs.washington.edu  Thu Feb  9 19:01:06 2012
From: justine at cs.washington.edu (Justine Sherry)
Date: Thu, 9 Feb 2012 17:01:06 -0800
Subject: Middlebox Report and Thank You!
Message-ID: <CAGoufOA8O-cP6mxGW5iKzcVX9xXQ7HU=MPGD6Rh4LFpWQUpduQ@mail.gmail.com>

Hello NANOG!

I emailed you a few months ago asking for help understanding typical
middlebox deployments in enterprise networks. 57 of you responded - thank
you so much!

Several of you asked if I'd share the data post-study; I've put together a
brief report on our findings here:
http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-24.pdf
If you have any questions, comments, or feedback, please don't hesitate to
contact me.

Thanks again for your help and support for our research!

Best,
Justine

From chesteve at gmail.com  Thu Feb  9 19:20:11 2012
From: chesteve at gmail.com (Christian Esteve)
Date: Thu, 9 Feb 2012 23:20:11 -0200
Subject: Middlebox Report and Thank You!
In-Reply-To: <CAGoufOA8O-cP6mxGW5iKzcVX9xXQ7HU=MPGD6Rh4LFpWQUpduQ@mail.gmail.com>
References: <CAGoufOA8O-cP6mxGW5iKzcVX9xXQ7HU=MPGD6Rh4LFpWQUpduQ@mail.gmail.com>
Message-ID: <CAEj5p9SMz__TVkhAMoyX7hEMiPKhbP8X1nkXbZ72srA2GfU-yg@mail.gmail.com>

Thank you Justine!

your research recalled me to a recent middlebox-related publication:

"An Untold Story of Middleboxes in Cellular Networks"
by Zhaoguang Wang, Zhiyun Qian, Qiang Xu, Zhuoqing Morley Mao, and
Ming Zhang, Proceedings of SIGCOMM 2011.
(http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p374.pdf)

In the news:
MIT Technology Review
http://www.technologyreview.com/communications/38435/?a=f
Slashdot
http://mobile.slashdot.org/story/11/08/26/159225/Mobile-Carriers-Impose-Handicaps-On-Smartphones
cnet news
http://news.cnet.com/8301-30686_3-20107040-266/carriers-may-be-handicapping-cell-phone-networks/


Keep on your good work!

Cheers,
Christian

-- 
Christian Esteve Rothenberg, Ph.D.
Converged Networks Division (DRC)
Tel.:+55 19-3705-4479 / Cel.: +55 19-8193-7087
esteve at cpqd.com.br
www.cpqd.com.br

On Thu, Feb 9, 2012 at 23:01, Justine Sherry <justine at cs.washington.edu> wrote:
>
> Hello NANOG!
>
> I emailed you a few months ago asking for help understanding typical
> middlebox deployments in enterprise networks. 57 of you responded - thank
> you so much!
>
> Several of you asked if I'd share the data post-study; I've put together a
> brief report on our findings here:
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-24.pdf
> If you have any questions, comments, or feedback, please don't hesitate to
> contact me.
>
> Thanks again for your help and support for our research!
>
> Best,
> Justine




--
Christian


From tknchris at gmail.com  Thu Feb  9 21:00:50 2012
From: tknchris at gmail.com (chris)
Date: Thu, 9 Feb 2012 22:00:50 -0500
Subject: Middlebox Report and Thank You!
In-Reply-To: <CAEj5p9SMz__TVkhAMoyX7hEMiPKhbP8X1nkXbZ72srA2GfU-yg@mail.gmail.com>
References: <CAGoufOA8O-cP6mxGW5iKzcVX9xXQ7HU=MPGD6Rh4LFpWQUpduQ@mail.gmail.com>
 <CAEj5p9SMz__TVkhAMoyX7hEMiPKhbP8X1nkXbZ72srA2GfU-yg@mail.gmail.com>
Message-ID: <CAKnNFz82tw7usn-G7KVDSx5m2bUVbfS8BSV+UBa07LCd2bONgA@mail.gmail.com>

Look how much time people waste with those all in one devices :) As soon as
I get the feeling something is very appliancey I run the other direction

On Thu, Feb 9, 2012 at 8:20 PM, Christian Esteve <chesteve at gmail.com> wrote:

> Thank you Justine!
>
> your research recalled me to a recent middlebox-related publication:
>
> "An Untold Story of Middleboxes in Cellular Networks"
> by Zhaoguang Wang, Zhiyun Qian, Qiang Xu, Zhuoqing Morley Mao, and
> Ming Zhang, Proceedings of SIGCOMM 2011.
> (http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p374.pdf)
>
> In the news:
> MIT Technology Review
> http://www.technologyreview.com/communications/38435/?a=f
> Slashdot
>
> http://mobile.slashdot.org/story/11/08/26/159225/Mobile-Carriers-Impose-Handicaps-On-Smartphones
> cnet news
>
> http://news.cnet.com/8301-30686_3-20107040-266/carriers-may-be-handicapping-cell-phone-networks/
>
>
> Keep on your good work!
>
> Cheers,
> Christian
>
> --
> Christian Esteve Rothenberg, Ph.D.
> Converged Networks Division (DRC)
> Tel.:+55 19-3705-4479 / Cel.: +55 19-8193-7087
> esteve at cpqd.com.br
> www.cpqd.com.br
>
> On Thu, Feb 9, 2012 at 23:01, Justine Sherry <justine at cs.washington.edu>
> wrote:
> >
> > Hello NANOG!
> >
> > I emailed you a few months ago asking for help understanding typical
> > middlebox deployments in enterprise networks. 57 of you responded - thank
> > you so much!
> >
> > Several of you asked if I'd share the data post-study; I've put together
> a
> > brief report on our findings here:
> > http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-24.pdf
> > If you have any questions, comments, or feedback, please don't hesitate
> to
> > contact me.
> >
> > Thanks again for your help and support for our research!
> >
> > Best,
> > Justine
>
>
>
>
> --
> Christian
>
>

From keegan.holley at sungard.com  Thu Feb  9 22:21:48 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Thu, 9 Feb 2012 23:21:48 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <4F330A17.2010806@gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>
 <F3318834F1F89D46857972DD4B411D70052CA02411@exchange>
 <4F330A17.2010806@gmail.com>
Message-ID: <CABO8Q6THE8wi7e7gfkxNF74hvfwhNSiz=TRFXdz-R1bbP89_vg@mail.gmail.com>

2012/2/8 Steve Bertrand <steve.bertrand at gmail.com>

> On 2012.02.08 14:23, Drew Weaver wrote:
>
>> Stop paying transit providers for delivering spoofed packets to the edge
>> of your network and they will very quickly develop methods of proving that
>> the traffic isn't spoofed, or block it altogether. =)
>>
>
> I firmly believe in this recourse, amongst others...
>

How do you tell the spoofed packets from the non-spoofed ones?  Especially
if you have more than one provider.

>
> If you know that your provider allows spoofed traffic, let the community
> know about it.
>

According to a company wide NDA I'm only allowed to disclose that to the
best of my knowledge my upstreams permits packets sent from users or other
NSP's who may or may not permit or generate packets.  The source IP
addresses are checked to be valid 32 bit numbers before being sent to my
routers. My upstreams to the best of their knowledge have never sent me a
single spoofed packet and will refrain from doing so unless they receive
written consent from me, in triplicate. ;)

>
> In all aspects of life, a problem must be 'fixed' at the source. All of
> the small-medium size ops have to connect to the big-boys somewhere, and
> what I've seen in this industry is that the big-boys are generally
> compliant.
>

As long as compliant means completely indifferent to your concerns and
unwilling to change or compromise in any meaningful while sucking money
away faster than the government.  They are all very very compliant and a
pleasure to do business with.

From jtk at cymru.com  Fri Feb 10 10:53:49 2012
From: jtk at cymru.com (John Kristoff)
Date: Fri, 10 Feb 2012 10:53:49 -0600
Subject: UDP port 80 DDoS attack
In-Reply-To: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
Message-ID: <20120210105349.77eb72b3@w520.localdomain>

On Sun, 5 Feb 2012 18:36:13 -0500
Ray Gasnick III <rgasnick at milestechnologies.com> wrote:

> Only solution thus far was to dump the victim IP address in our block
> into the BGP Black hole community with one of our 2 providers and
> completely stop advertising to the other.

Drew mentioned udp.pl and I also it could have been this script running
on some compromised Unix-based host(s) as well.  If the traffic did not
appear to be widely distributed, that is, not spoofed, then this is
even more likely.  If that was the case, filtering based on the sender
address(es) may help better mitigate the attack without taking the
target entirely offline for everyone else.

John


From smb at cs.columbia.edu  Fri Feb 10 10:56:57 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Fri, 10 Feb 2012 11:56:57 -0500
Subject: Dear RIPE: Please don't encourage phishing
Message-ID: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>

I received the enclosed note, apparently from RIPE (and the headers check out).
Why are you sending messages with clickable objects that I'm supposed to use to
change my password?

-------

From: RIPE_DBannounce at ripe.net
Subject: Advisory notice on passwords in the RIPE Database
Date: February 9, 2012 1:16:15 PM EST
To: XXXXXXXX

[Apologies for duplicate e-mails]

Dear Colleagues,

We are contacting you with some advice on the passwords used in the RIPE
Database.  There is no immediate concern and this notice is only advisory.
At the request of the RIPE community, the RIPE NCC recently deployed an
MD5 password hash change.

Before this change was implemented, there was a lot of discussion on the
Database Working Group mailing list about the vulnerabilities of MD5
passwords with public hashes.  The hashes can now only be seen by the user
of the MNTNER object.  As a precaution, now that the hashes are hidden,
we strongly recommend that you change all MD5 passwords used by your MNTNER
objects in the RIPE Database at your earliest convenience.  When choosing
new passwords, make them as strong as possible.

To make it easier for you to change your password(s) we have improved
Webupdates.  On the modify page there is an extra button after the "auth:"
attribute field.  Click this button for a pop up window that will encrypt
a password and enter it directly into the "auth:" field.

Webupdates: https://apps.db.ripe.net/webupdates/search.html

There is a RIPE Labs article explaining details of the security changes
and the new process to modify a MNTNER object in the RIPE Database:
https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database

We are sending you this email because this address is referenced in the
MNTNER objects in the RIPE Database listed below.

If you have any concerns about your passwords or need further advice please
contact our Customer Services team at ripe-dbm at ripe.net.  (You cannot reply
to this email.)

Regards,

Denis Walker
Business Analyst
RIPE NCC Database Group

Referencing MNTNER objects in the RIPE Database:
maint-rgnet







From richard.barnes at gmail.com  Fri Feb 10 11:18:29 2012
From: richard.barnes at gmail.com (Richard Barnes)
Date: Fri, 10 Feb 2012 09:18:29 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
Message-ID: <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>

So because of phishing, nobody should send messages with URLs in them?



On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin <smb at cs.columbia.edu> wrote:
> I received the enclosed note, apparently from RIPE (and the headers check out).
> Why are you sending messages with clickable objects that I'm supposed to use to
> change my password?
>
> -------
>
> From: RIPE_DBannounce at ripe.net
> Subject: Advisory notice on passwords in the RIPE Database
> Date: February 9, 2012 1:16:15 PM EST
> To: XXXXXXXX
>
> [Apologies for duplicate e-mails]
>
> Dear Colleagues,
>
> We are contacting you with some advice on the passwords used in the RIPE
> Database. ?There is no immediate concern and this notice is only advisory.
> At the request of the RIPE community, the RIPE NCC recently deployed an
> MD5 password hash change.
>
> Before this change was implemented, there was a lot of discussion on the
> Database Working Group mailing list about the vulnerabilities of MD5
> passwords with public hashes. ?The hashes can now only be seen by the user
> of the MNTNER object. ?As a precaution, now that the hashes are hidden,
> we strongly recommend that you change all MD5 passwords used by your MNTNER
> objects in the RIPE Database at your earliest convenience. ?When choosing
> new passwords, make them as strong as possible.
>
> To make it easier for you to change your password(s) we have improved
> Webupdates. ?On the modify page there is an extra button after the "auth:"
> attribute field. ?Click this button for a pop up window that will encrypt
> a password and enter it directly into the "auth:" field.
>
> Webupdates: https://apps.db.ripe.net/webupdates/search.html
>
> There is a RIPE Labs article explaining details of the security changes
> and the new process to modify a MNTNER object in the RIPE Database:
> https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database
>
> We are sending you this email because this address is referenced in the
> MNTNER objects in the RIPE Database listed below.
>
> If you have any concerns about your passwords or need further advice please
> contact our Customer Services team at ripe-dbm at ripe.net. ?(You cannot reply
> to this email.)
>
> Regards,
>
> Denis Walker
> Business Analyst
> RIPE NCC Database Group
>
> Referencing MNTNER objects in the RIPE Database:
> maint-rgnet
>
>
>
>
>
>


From smb at cs.columbia.edu  Fri Feb 10 11:28:22 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Fri, 10 Feb 2012 12:28:22 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
Message-ID: <D566F764-8028-41A5-8323-7E5DBA4D2C2B@cs.columbia.edu>

If they're intended as a path to log in with a typed password, that's correct.
Sad, but correct.

On Feb 10, 2012, at 12:18 PM, Richard Barnes wrote:

> So because of phishing, nobody should send messages with URLs in them?
> 
> 
> 
> On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin <smb at cs.columbia.edu> wrote:
>> I received the enclosed note, apparently from RIPE (and the headers check out).
>> Why are you sending messages with clickable objects that I'm supposed to use to
>> change my password?
>> 
>> -------
>> 
>> From: RIPE_DBannounce at ripe.net
>> Subject: Advisory notice on passwords in the RIPE Database
>> Date: February 9, 2012 1:16:15 PM EST
>> To: XXXXXXXX
>> 
>> [Apologies for duplicate e-mails]
>> 
>> Dear Colleagues,
>> 
>> We are contacting you with some advice on the passwords used in the RIPE
>> Database.  There is no immediate concern and this notice is only advisory.
>> At the request of the RIPE community, the RIPE NCC recently deployed an
>> MD5 password hash change.
>> 
>> Before this change was implemented, there was a lot of discussion on the
>> Database Working Group mailing list about the vulnerabilities of MD5
>> passwords with public hashes.  The hashes can now only be seen by the user
>> of the MNTNER object.  As a precaution, now that the hashes are hidden,
>> we strongly recommend that you change all MD5 passwords used by your MNTNER
>> objects in the RIPE Database at your earliest convenience.  When choosing
>> new passwords, make them as strong as possible.
>> 
>> To make it easier for you to change your password(s) we have improved
>> Webupdates.  On the modify page there is an extra button after the "auth:"
>> attribute field.  Click this button for a pop up window that will encrypt
>> a password and enter it directly into the "auth:" field.
>> 
>> Webupdates: https://apps.db.ripe.net/webupdates/search.html
>> 
>> There is a RIPE Labs article explaining details of the security changes
>> and the new process to modify a MNTNER object in the RIPE Database:
>> https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database
>> 
>> We are sending you this email because this address is referenced in the
>> MNTNER objects in the RIPE Database listed below.
>> 
>> If you have any concerns about your passwords or need further advice please
>> contact our Customer Services team at ripe-dbm at ripe.net.  (You cannot reply
>> to this email.)
>> 
>> Regards,
>> 
>> Denis Walker
>> Business Analyst
>> RIPE NCC Database Group
>> 
>> Referencing MNTNER objects in the RIPE Database:
>> maint-rgnet
>> 
>> 
>> 
>> 
>> 
>> 
> 


		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From randy at psg.com  Fri Feb 10 11:29:30 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 10 Feb 2012 09:29:30 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
Message-ID: <m2sjiivbph.wl%randy@psg.com>

> So because of phishing, nobody should send messages with URLs in them?

more and more these days, i have taken to not clicking the update messages, 
but going to the web site manyually to get it.

waaaay to much phishing, and it is getting subtle and good.

randy


From corey at sequestered.net  Fri Feb 10 11:32:37 2012
From: corey at sequestered.net (Corey Quinn)
Date: Fri, 10 Feb 2012 09:32:37 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m2sjiivbph.wl%randy@psg.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
Message-ID: <4C9F8DC3-2FCB-457A-BAB9-195264C42ACF@sequestered.net>


On Feb 10, 2012, at 9:29 AM, Randy Bush wrote:

>> So because of phishing, nobody should send messages with URLs in them?
> 
> more and more these days, i have taken to not clicking the update messages, 
> but going to the web site manyually to get it.
> 
> waaaay to much phishing, and it is getting subtle and good.


Concur.

It seems as if they're no longer written by non-native English speakers, which goes a long way towards making them more insidious.  While still perfectly intelligible, most folks who use English as a second language don't speak in the same voice as, say, Wells Fargo corporate communications.


-- Corey 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/f2ba6f11/attachment.bin>

From bill at herrin.us  Fri Feb 10 11:35:56 2012
From: bill at herrin.us (William Herrin)
Date: Fri, 10 Feb 2012 12:35:56 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
Message-ID: <CAP-guGXScbK_Dzc5dMdxF4Jr4CHgV_0iMd-Xkxei9WX5tkusOA@mail.gmail.com>

On Fri, Feb 10, 2012 at 12:18 PM, Richard Barnes
<richard.barnes at gmail.com> wrote:
> On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin <smb at cs.columbia.edu> wrote:
>> I received the enclosed note, apparently from RIPE (and the headers check out).
>> Why are you sending messages with clickable objects that I'm supposed to use to
>> change my password?
>> [...]
>> attribute field.  Click this button for a pop up window that will encrypt
>> a password and enter it directly into the "auth:" field.

> So because of phishing, nobody should send messages with URLs in them?

url != clickable object


No problem with URLs in email.

No problem with clickable objects that are unrelated to security.

Minor problem with URLs that lead to changing passwords but can be
mitigated by making the URL very plain and easy to read, even by a
non-techie. They'll at least have to see the thing, even if the mail
client automagically makes it clickable.

Big problem with clickable objects which lead to PII (personally
identifiable information) or passwords. That's how phishing works -- a
disguised url that you either see at all or whose incorrect nature
slips right past your brain. The only known working solution is to
train folks to *never* click security-related URLs in email. Copy and
paste only, and only if they're readable and read right.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jra at baylink.com  Fri Feb 10 11:37:01 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 10 Feb 2012 12:37:01 -0500 (EST)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4C9F8DC3-2FCB-457A-BAB9-195264C42ACF@sequestered.net>
Message-ID: <27959862.1933.1328895421815.JavaMail.root@benjamin.baylink.com>

> It seems as if they're no longer written by non-native English
> speakers, which goes a long way towards making them more insidious.
> While still perfectly intelligible, most folks who use English as a
> second language don't speak in the same voice as, say, Wells Fargo
> corporate communications.

Most people who use English as their milk language don't speak in the same
voice as Wells Fargo Corporate Communications.  :-)

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


From bicknell at ufp.org  Fri Feb 10 11:37:01 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Feb 2012 09:37:01 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m2sjiivbph.wl%randy@psg.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
Message-ID: <20120210173701.GA79917@ussenterprise.ufp.org>

In a message written on Fri, Feb 10, 2012 at 09:29:30AM -0800, Randy Bush wrote:
> more and more these days, i have taken to not clicking the update messages, 
> but going to the web site manyually to get it.
> 
> waaaay to much phishing, and it is getting subtle and good.

We know how to sign and encrypt web sites.

We know how to sign and encrypt e-mail.

We even know how to compare keys between the web site and e-mail via a
variety of mechanisms.

We know how to sign DNS.

Remind me again why we live in this sad word Randy (correcly) described?

There's no reason my mail client shouldn't validate the signed e-mail
came from the same entity as the signed web site I'd previously logged
into, and give me a green light that the link actually points to said
same web site with the same key.  It should be transparent, and secure
for the user.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/a33ed5fb/attachment.bin>

From dwhite at olp.net  Fri Feb 10 11:37:52 2012
From: dwhite at olp.net (Dan White)
Date: Fri, 10 Feb 2012 11:37:52 -0600
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
Message-ID: <20120210173752.GA5173@dan.olp.net>

The line gets crossed when you send an unsolicited message that includes a
clickable change password link, that a phisher would find interesting
to emulate.

After the fact, if a phisher gets one of your customers to click on such a
link, you'd like to tell them them in response, or preemptively, that your
company never asks for sensitive information via email.

With good policies in place, the customer should not be receiving clickable
links via email that ask them for a password, except for a scenario where
they've actively generated that email in response to an "I forgot my
password" link on a website.

On 02/10/12?09:18?-0800, Richard Barnes wrote:
>So because of phishing, nobody should send messages with URLs in them?
>
>
>
>On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin <smb at cs.columbia.edu> wrote:
>> I received the enclosed note, apparently from RIPE (and the headers check out).
>> Why are you sending messages with clickable objects that I'm supposed to use to
>> change my password?
>>
>> -------
>>
>> From: RIPE_DBannounce at ripe.net
>> Subject: Advisory notice on passwords in the RIPE Database
>> Date: February 9, 2012 1:16:15 PM EST
>> To: XXXXXXXX
>>
>> [Apologies for duplicate e-mails]
>>
>> Dear Colleagues,
>>
>> We are contacting you with some advice on the passwords used in the RIPE
>> Database. ?There is no immediate concern and this notice is only advisory.
>> At the request of the RIPE community, the RIPE NCC recently deployed an
>> MD5 password hash change.
>>
>> Before this change was implemented, there was a lot of discussion on the
>> Database Working Group mailing list about the vulnerabilities of MD5
>> passwords with public hashes. ?The hashes can now only be seen by the user
>> of the MNTNER object. ?As a precaution, now that the hashes are hidden,
>> we strongly recommend that you change all MD5 passwords used by your MNTNER
>> objects in the RIPE Database at your earliest convenience. ?When choosing
>> new passwords, make them as strong as possible.
>>
>> To make it easier for you to change your password(s) we have improved
>> Webupdates. ?On the modify page there is an extra button after the "auth:"
>> attribute field. ?Click this button for a pop up window that will encrypt
>> a password and enter it directly into the "auth:" field.
>>
>> Webupdates: https://apps.db.ripe.net/webupdates/search.html
>>
>> There is a RIPE Labs article explaining details of the security changes
>> and the new process to modify a MNTNER object in the RIPE Database:
>> https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database
>>
>> We are sending you this email because this address is referenced in the
>> MNTNER objects in the RIPE Database listed below.
>>
>> If you have any concerns about your passwords or need further advice please
>> contact our Customer Services team at ripe-dbm at ripe.net. ?(You cannot reply
>> to this email.)
>>
>> Regards,
>>
>> Denis Walker
>> Business Analyst
>> RIPE NCC Database Group
>>
>> Referencing MNTNER objects in the RIPE Database:
>> maint-rgnet
>>
>>
>>
>>
>>
>>
>
>

-- 
Dan White
BTC Broadband
Ph  918.366.0248 (direct)   main: (918)366-8000
Fax 918.366.6610            email: dwhite at olp.net
http://www.btcbroadband.com


From jeroen at unfix.org  Fri Feb 10 11:46:43 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Fri, 10 Feb 2012 18:46:43 +0100
Subject: PGP,
 S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage
 phishing)
In-Reply-To: <20120210173701.GA79917@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
Message-ID: <4F355803.4040402@unfix.org>

On 2012-02-10 18:37 , Leo Bicknell wrote:
[..]

> There's no reason my mail client shouldn't validate the signed e-mail
> came from the same entity as the signed web site I'd previously logged
> into, and give me a green light that the link actually points to said
> same web site with the same key.  It should be transparent, and secure
> for the user.

That is a rather nice idea. Most people, especially the common ones, do
not use PGP or heck even S/MIME though and only when one is included in
the web-of-trust can one actually verify these. Of course when that is
done, one should be able to match up email address and website URL quite
easily and your trick will work, at least one can then state:
  "the sender, who is verified by trust, is pointing to his/her
   own website."

The problem still lies in the issue that most people, even on this very
list, do not use PGP or S/MIME. (and that there are two standards does
not help much there either ;)

Greets,
 Jeroen


From randy at psg.com  Fri Feb 10 11:48:18 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 10 Feb 2012 09:48:18 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120210173701.GA79917@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
 <20120210173701.GA79917@ussenterprise.ufp.org>
Message-ID: <m2pqdma8bh.wl%randy@psg.com>

> There's no reason my mail client shouldn't validate the signed e-mail
> came from the same entity as the signed web site I'd previously logged
> into, and give me a green light that the link actually points to said
> same web site with the same key.  It should be transparent, and secure
> for the user.

my paranoid side is not comfortable with the certs that come for free
with my browser.  see the ietf dane wg.

randy


From randy at psg.com  Fri Feb 10 11:51:01 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 10 Feb 2012 09:51:01 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4C9F8DC3-2FCB-457A-BAB9-195264C42ACF@sequestered.net>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
 <4C9F8DC3-2FCB-457A-BAB9-195264C42ACF@sequestered.net>
Message-ID: <m2obt6a86y.wl%randy@psg.com>

> While still perfectly intelligible, most folks who use English as a
> second language don't speak in the same voice as, say, Wells Fargo
> corporate communications.

yep.  if it's intelligible, it can't really be from wells fargo corp
comms.

randy


From Valdis.Kletnieks at vt.edu  Fri Feb 10 11:51:02 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 10 Feb 2012 12:51:02 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Fri, 10 Feb 2012 09:37:01 PST."
 <20120210173701.GA79917@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
 <20120210173701.GA79917@ussenterprise.ufp.org>
Message-ID: <76758.1328896262@turing-police.cc.vt.edu>

On Fri, 10 Feb 2012 09:37:01 PST, Leo Bicknell said:

> We know how to sign and encrypt web sites.
>
> We know how to sign and encrypt e-mail.
>
> We even know how to compare keys between the web site and e-mail via a
> variety of mechanisms.
>
> We know how to sign DNS.
>
> Remind me again why we live in this sad word Randy (correcly) described?

Obi-Wan Kenobi: "(shocked) How could this have happened?? We're
        supposed to be smarter than this."
Anakin Skywalker: "Apparently not."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/f5dde42b/attachment.bin>

From jra at baylink.com  Fri Feb 10 12:00:10 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 10 Feb 2012 13:00:10 -0500 (EST)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CAP-guGXScbK_Dzc5dMdxF4Jr4CHgV_0iMd-Xkxei9WX5tkusOA@mail.gmail.com>
Message-ID: <30780538.1943.1328896810308.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "William Herrin" <bill at herrin.us>

> Big problem with clickable objects which lead to PII (personally
> identifiable information) or passwords. That's how phishing works -- a
> disguised url that you either see at all or whose incorrect nature
> slips right past your brain. The only known working solution is to
> train folks to *never* click security-related URLs in email. Copy and
> paste only, and only if they're readable and read right.

And right there, Bill, is the part we so rarely understand, and it kills us:

Even lots of *technical* people just don't understand what "a security-
related URL" *is*, and there's almost always no way to teach them.

So it's necessary to throw the baby out with the bathwater, and tell them
never to click on a link...  MUA's that support HTML at all, much less
they fail to tell the user when a text URL doesn't match the actual link,
are the underlying culprits here...

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


From bicknell at ufp.org  Fri Feb 10 12:01:06 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Feb 2012 10:01:06 -0800
Subject: PGP,
 S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage
 phishing)
In-Reply-To: <4F355803.4040402@unfix.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <4F355803.4040402@unfix.org>
Message-ID: <20120210180106.GB80127@ussenterprise.ufp.org>

In a message written on Fri, Feb 10, 2012 at 06:46:43PM +0100, Jeroen Massar wrote:
> The problem still lies in the issue that most people, even on this very
> list, do not use PGP or S/MIME. (and that there are two standards does
> not help much there either ;)

The problem space is still certificate management.

I bet (nearly) everyone on the list uses an e-mail client that can
decode S/MIME.  mutt, pine, Outlook, OSX Mail, gmail, they all do
it.  We all have browsers that do SSL.

OSX at least has a central certificate store (Keychain), although
it's not up to the tasks of the world I wish to have.  Other OS's
provide no central store, so each application maintains their own
key store.  We have a very real problem of pre-loading the key
store, for instance root certificate trust for X.509 certificates.

We need a central certificate store on every platform, easy, secure ways
to transfer/sync it (to say, moble devices), and a bit of UI goo.
Imagine a capability as simple as being able to add a description to a
cert in your key store.  I should be able to download my bank's cert,
verify it (call and check finger print, check a trusted third party,
web of trust, probably multiple ways, automated, would be best) and then
tag it "Leo's Bank".

When I get e-mail from it, or go to it with my web browser it should now
say "Leo's Bank" in all of my software, telling me not only do I have
the little padlock, but it's the certificate I personally validated.

When I click on a link in e-mail it should pass the URL AND KEY to
the next program (e.g. my browser).  My browser can then silently
load if they are the same, or give me a big pop up "The person who
sent this e-mail is different from the person who runs this web
site."

It's all UI.  No new technology, protocols, encryption formats or other
things are needed.  It's making end user software act in a responsible
way.

Of course I'd also prefer my bank allowed me to provide my certificate
to them, and they crypto authenticated me (perhaps in addition to
passwords and pins).  This should all be two-way.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/de56882a/attachment.bin>

From bhmccie at gmail.com  Fri Feb 10 12:03:53 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 10 Feb 2012 12:03:53 -0600
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <76758.1328896262@turing-police.cc.vt.edu>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <76758.1328896262@turing-police.cc.vt.edu>
Message-ID: <4F355C09.6050808@gmail.com>

Leo,
     This has nothing to do with the competency of the folks on the 
nanog list. It's a safe rule in general. Why? Because the stupid on the 
Internet outnumbers all of us. It's just easier to not send clickable 
links then it is to have the call center lit up because your users are 
getting hijacked.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/10/2012 11:51 AM, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 10 Feb 2012 09:37:01 PST, Leo Bicknell said:
>
>> We know how to sign and encrypt web sites.
>>
>> We know how to sign and encrypt e-mail.
>>
>> We even know how to compare keys between the web site and e-mail via a
>> variety of mechanisms.
>>
>> We know how to sign DNS.
>>
>> Remind me again why we live in this sad word Randy (correcly) described?
> Obi-Wan Kenobi: "(shocked) How could this have happened?? We're
>          supposed to be smarter than this."
> Anakin Skywalker: "Apparently not."
>


From randy at psg.com  Fri Feb 10 12:04:10 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 10 Feb 2012 10:04:10 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120210173701.GA79917@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
 <20120210173701.GA79917@ussenterprise.ufp.org>
Message-ID: <m2k43ua7l1.wl%randy@psg.com>

> We know how to sign and encrypt e-mail.

there is a public key distribution and trust problem

> We know how to sign DNS.

not very reliably yet

randy


From malayter at gmail.com  Fri Feb 10 12:26:15 2012
From: malayter at gmail.com (Ryan Malayter)
Date: Fri, 10 Feb 2012 10:26:15 -0800 (PST)
Subject: Iran blocking essentially all encyrpted protocols
Message-ID: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>

Haven't seen this come through on NANOG yet:
http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars

Can anyone with the ability confirm that TCP/443 traffic from Iran has
stopped?


From d3e3e3 at gmail.com  Fri Feb 10 12:28:12 2012
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 10 Feb 2012 13:28:12 -0500
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
References: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
Message-ID: <CAF4+nEH2oX+BTj7sA7RD_kpXRA4edL8JTBBt+cERaSQqMdcy-A@mail.gmail.com>

Probably better than Iran doing man-in-the-middle...

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street,?Milford, MA 01757 USA
?d3e3e3 at gmail.com


On Fri, Feb 10, 2012 at 1:26 PM, Ryan Malayter <malayter at gmail.com> wrote:
> Haven't seen this come through on NANOG yet:
> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
>
> Can anyone with the ability confirm that TCP/443 traffic from Iran has
> stopped?
>


From jra at baylink.com  Fri Feb 10 12:29:34 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 10 Feb 2012 13:29:34 -0500 (EST)
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
Message-ID: <31899020.1967.1328898574799.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Ryan Malayter" <malayter at gmail.com>

> Haven't seen this come through on NANOG yet:
> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
> 
> Can anyone with the ability confirm that TCP/443 traffic from Iran has
> stopped?

Lauren scooped you on Privacy by about 6 minutes.  :-)

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


From james at smithwaysecurity.com  Fri Feb 10 12:35:49 2012
From: james at smithwaysecurity.com (James Smith)
Date: Fri, 10 Feb 2012 14:35:49 -0400
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <31899020.1967.1328898574799.JavaMail.root@benjamin.baylink.com>
References: <31899020.1967.1328898574799.JavaMail.root@benjamin.baylink.com>
Message-ID: <CEEA6F7F607649E3913DDDEB6079DFF7@smithwaIntell>

correct, it's down in Iran,
A few of my contacts got back to me confirming this  a few hours ago.

-----Original Message----- 
From: Jay Ashworth
Sent: Friday, February 10, 2012 2:29 PM
To: NANOG
Subject: Re: Iran blocking essentially all encyrpted protocols

----- Original Message -----
> From: "Ryan Malayter" <malayter at gmail.com>

> Haven't seen this come through on NANOG yet:
> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
>
> Can anyone with the ability confirm that TCP/443 traffic from Iran has
> stopped?

Lauren scooped you on Privacy by about 6 minutes.  :-)

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



From bill at herrin.us  Fri Feb 10 12:52:45 2012
From: bill at herrin.us (William Herrin)
Date: Fri, 10 Feb 2012 13:52:45 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <30780538.1943.1328896810308.JavaMail.root@benjamin.baylink.com>
References: <CAP-guGXScbK_Dzc5dMdxF4Jr4CHgV_0iMd-Xkxei9WX5tkusOA@mail.gmail.com>
 <30780538.1943.1328896810308.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAP-guGWBT_hA-Dneut55BP7ddpq94yxjnYrJPFjz6urkVYuM7A@mail.gmail.com>

On Fri, Feb 10, 2012 at 1:00 PM, Jay Ashworth <jra at baylink.com> wrote:
>> From: "William Herrin" <bill at herrin.us>
>> Big problem with clickable objects which lead to PII (personally
>> identifiable information) or passwords. That's how phishing works -- a
>> disguised url that you either see at all or whose incorrect nature
>> slips right past your brain. The only known working solution is to
>> train folks to *never* click security-related URLs in email. Copy and
>> paste only, and only if they're readable and read right.
>
> And right there, Bill, is the part we so rarely understand, and it kills us:
>
> Even lots of *technical* people just don't understand what "a security-
> related URL" *is*, and there's almost always no way to teach them.
>
> So it's necessary to throw the baby out with the bathwater, and tell them
> never to click on a link...

Hi Jay,

And if we could just train people to never send or accept email
attachments, we could get rid of email-spread viruses. Not gonna
happen -- the functionality is too useful.

Security isn't just about what you can train someone to do... it's
also about what you can convince them to do when you're not standing
behind them watching -- the instructions that they're willing to
internalize. You can't convince people never to click links in an
email. It's too useful.

You might, however, be able to convince the average person that if a
link they clicked from an email asks for a password or asks for any
personal information then the message was probably from an
impersonator trying to steal the user's identity and they should
report it immediately lest they be victimized.

Regards,
Bill


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jra at baylink.com  Fri Feb 10 12:59:36 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 10 Feb 2012 13:59:36 -0500 (EST)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CAP-guGWBT_hA-Dneut55BP7ddpq94yxjnYrJPFjz6urkVYuM7A@mail.gmail.com>
Message-ID: <662122.1983.1328900376952.JavaMail.root@benjamin.baylink.com>

---- Original Message -----
> From: "William Herrin" <bill at herrin.us>

> And if we could just train people to never send or accept email
> attachments, we could get rid of email-spread viruses. Not gonna
> happen -- the functionality is too useful.
> 
> Security isn't just about what you can train someone to do... it's
> also about what you can convince them to do when you're not standing
> behind them watching -- the instructions that they're willing to
> internalize. You can't convince people never to click links in an
> email. It's too useful.

I did admit that it was throwing the baby out with the bathwater.

Being able to drive across someone's golf course to get to work is
convenient for me as well, but I'm still forbidden to do it.  This is a
tragedy of the commons problem -- since the biggest target for zombies
on PCs is probably spambots ...

> You might, however, be able to convince the average person that if a
> link they clicked from an email asks for a password or asks for any
> personal information then the message was probably from an
> impersonator trying to steal the user's identity and they should
> report it immediately lest they be victimized.

Yup.  Just like Steve just did in the posting that started this.

Y'know: the thing that only looked like a phish.

Cheers,
-- jr 'and don't even get me started on e-cards' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From cscora at apnic.net  Fri Feb 10 12:59:54 2012
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 11 Feb 2012 04:59:54 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201202101859.q1AIxsq7018374@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 11 Feb, 2012

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              397602
    Prefixes after maximum aggregation:                          169606
    Deaggregation factor:                                          2.34
    Unique aggregates announced to Internet:                     192311
Total ASes present in the Internet Routing Table:                 40086
    Prefixes per ASN:                                              9.92
Origin-only ASes present in the Internet Routing Table:           32739
Origin ASes announcing only one prefix:                           15528
Transit ASes present in the Internet Routing Table:                5400
Transit-only ASes present in the Internet Routing Table:            147
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      33
    Max AS path prepend of ASN (48687)                               24
Prefixes from unregistered ASNs in the Routing Table:               328
    Unregistered ASNs in the Routing Table:                         127
Number of 32-bit ASNs allocated by the RIRs:                       2272
Number of 32-bit ASNs visible in the Routing Table:                1947
Prefixes from 32-bit ASNs in the Routing Table:                    4674
Special use prefixes present in the Routing Table:                    2
Prefixes being announced from unallocated address space:            137
Number of addresses announced to Internet:                   2513929424
    Equivalent to 149 /8s, 215 /16s and 132 /24s
    Percentage of available address space announced:               67.8
    Percentage of allocated address space announced:               67.8
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               92.0
Total number of prefixes smaller than registry allocations:      168841

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                    98087
    Total APNIC prefixes after maximum aggregation:               31681
    APNIC Deaggregation factor:                                    3.10
Prefixes being announced from the APNIC address blocks:           94410
    Unique aggregates announced from the APNIC address blocks:    39147
APNIC Region origin ASes present in the Internet Routing Table:    4652
    APNIC Prefixes per ASN:                                       20.29
APNIC Region origin ASes announcing only one prefix:               1239
APNIC Region transit ASes present in the Internet Routing Table:    737
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         20
Number of APNIC region 32-bit ASNs visible in the Routing Table:    143
Number of APNIC addresses announced to Internet:              635706656
    Equivalent to 37 /8s, 228 /16s and 29 /24s
    Percentage of available APNIC address space announced:         80.6

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8,
                       182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
                       219/8, 220/8, 221/8, 222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    148238
    Total ARIN prefixes after maximum aggregation:                75329
    ARIN Deaggregation factor:                                     1.97
Prefixes being announced from the ARIN address blocks:           120188
    Unique aggregates announced from the ARIN address blocks:     49415
ARIN Region origin ASes present in the Internet Routing Table:    14905
    ARIN Prefixes per ASN:                                         8.06
ARIN Region origin ASes announcing only one prefix:                5689
ARIN Region transit ASes present in the Internet Routing Table:    1576
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          22
Number of ARIN region 32-bit ASNs visible in the Routing Table:      15
Number of ARIN addresses announced to Internet:               804413120
    Equivalent to 47 /8s, 242 /16s and 94 /24s
    Percentage of available ARIN address space announced:          63.9

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 173/8,
                       174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8,
                       208/8, 209/8, 214/8, 215/8, 216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                     98764
    Total RIPE prefixes after maximum aggregation:                52358
    RIPE Deaggregation factor:                                     1.89
Prefixes being announced from the RIPE address blocks:            90594
    Unique aggregates announced from the RIPE address blocks:     56087
RIPE Region origin ASes present in the Internet Routing Table:    16308
    RIPE Prefixes per ASN:                                         5.56
RIPE Region origin ASes announcing only one prefix:                7997
RIPE Region transit ASes present in the Internet Routing Table:    2598
Average RIPE Region AS path length visible:                         4.7
    Max RIPE Region AS path length visible:                          33
Number of RIPE region 32-bit ASNs visible in the Routing Table:    1344
Number of RIPE addresses announced to Internet:               500587080
    Equivalent to 29 /8s, 214 /16s and 90 /24s
    Percentage of available RIPE address space announced:          80.6

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   38648
    Total LACNIC prefixes after maximum aggregation:               8064
    LACNIC Deaggregation factor:                                   4.79
Prefixes being announced from the LACNIC address blocks:          38261
    Unique aggregates announced from the LACNIC address blocks:   19517
LACNIC Region origin ASes present in the Internet Routing Table:   1572
    LACNIC Prefixes per ASN:                                      24.34
LACNIC Region origin ASes announcing only one prefix:               439
LACNIC Region transit ASes present in the Internet Routing Table:   290
Average LACNIC Region AS path length visible:                       4.4
    Max LACNIC Region AS path length visible:                        24
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   441
Number of LACNIC addresses announced to Internet:              96512392
    Equivalent to 5 /8s, 192 /16s and 169 /24s
    Percentage of available LACNIC address space announced:        63.9

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   9015
    Total AfriNIC prefixes after maximum aggregation:              2096
    AfriNIC Deaggregation factor:                                  4.30
Prefixes being announced from the AfriNIC address blocks:          7029
    Unique aggregates announced from the AfriNIC address blocks:   2148
AfriNIC Region origin ASes present in the Internet Routing Table:   511
    AfriNIC Prefixes per ASN:                                     13.76
AfriNIC Region origin ASes announcing only one prefix:              164
AfriNIC Region transit ASes present in the Internet Routing Table:  117
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    4
Number of AfriNIC addresses announced to Internet:             30893056
    Equivalent to 1 /8s, 215 /16s and 100 /24s
    Percentage of available AfriNIC address space announced:       46.0

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2471      11101         979   Korea Telecom (KIX)
17974     1729        503          36   PT TELEKOMUNIKASI INDONESIA
 7545     1642        303          85   TPG Internet Pty Ltd
 4755     1532        385         156   TATA Communications formerly 
 7552     1393       1064           7   Vietel Corporation
 9829     1172        989          28   BSNL National Internet Backbo
 4808     1149       2112         314   CNCGROUP IP network: China169
 9583     1124         83         482   Sify Limited
24560     1014        385         167   Bharti Airtel Ltd., Telemedia
18101      950        130         155   Reliance Infocom Ltd Internet

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3442       3807         201   bellsouth.net, inc. 
 7029     3391       1014         159   Windstream Communications Inc
18566     2093        382         177   Covad Communications 
 1785     1868        680         125   PaeTec Communications, Inc.
20115     1625       1550         631   Charter Communications 
 4323     1610       1062         385   Time Warner Telecom
22773     1511       2910         109   Cox Communications, Inc.
30036     1392        244         751   Mediacom Communications Corp 
19262     1386       4687         396   Verizon Global Networks 
 7018     1307       6995         849   AT&T WorldNet Services

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8402     1719        480          15   Corbina telecom
 2118     1385         97          13   EUnet/RELCOM Autonomous Syste
15557     1095       2161          63   LDCOM NETWORKS
34984      650        188         172   BILISIM TELEKOM
 6830      644       1927         413   UPC Distribution Services
20940      608        195         470   Akamai Technologies European 
12479      584        642          53   Uni2 Autonomous System
31148      538         37           9   FreeNet ISP
 3320      533       8450         399   Deutsche Telekom AG
 8551      530        360          81   Bezeq International

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1751        324         162   TVCABLE BOGOTA 
28573     1655       1085          69   NET Servicos de Comunicao S.A
 8151     1475       3003         342   UniNet S.A. de C.V. 
 7303     1263        758         182   Telecom Argentina Stet-France
26615      896        664          33   Tim Brasil S.A.
11172      694         95          75   Servicios Alestra S.A de C.V 
27947      655         67         105   Telconet S.A
22047      581        322          17   VTR PUNTO NET S.A. 
 3816      551        237          91   Empresa Nacional de Telecomun
 7738      550       1050          31   Telecomunicacoes da Bahia S.A

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8452     1235        958          13   TEDATA
24863      829        155          43   LINKdotNET AS number
 6713      485        649          18   Itissalat Al-MAGHRIB
 3741      278        939         229   The Internet Solution 
15706      238         32           6   Sudatel Internet Exchange Aut
33776      236         13          14   Starcomms Nigeria Limited
12258      197         28          62   Vodacom Internet Company 
24835      193         80           8   RAYA Telecom - Egypt
29571      189         17          11   Ci Telecom Autonomous system 
16637      163        664          82   MTN Network Solutions

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3442       3807         201   bellsouth.net, inc. 
 7029     3391       1014         159   Windstream Communications Inc
 4766     2471      11101         979   Korea Telecom (KIX)
18566     2093        382         177   Covad Communications 
 1785     1868        680         125   PaeTec Communications, Inc.
10620     1751        324         162   TVCABLE BOGOTA 
17974     1729        503          36   PT TELEKOMUNIKASI INDONESIA
 8402     1719        480          15   Corbina telecom
28573     1655       1085          69   NET Servicos de Comunicao S.A
 7545     1642        303          85   TPG Internet Pty Ltd

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
 7029      3391        3232      Windstream Communications Inc
18566      2093        1916      Covad Communications 
 1785      1868        1743      PaeTec Communications, Inc.
 8402      1719        1704      Corbina telecom
17974      1729        1693      PT TELEKOMUNIKASI INDONESIA
10620      1751        1589      TVCABLE BOGOTA 
28573      1655        1586      NET Servicos de Comunicao S.A
 7545      1642        1557      TPG Internet Pty Ltd
 4766      2471        1492      Korea Telecom (KIX)
22773      1511        1402      Cox Communications, Inc.

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.103.0/24        7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
32873   UNALLOCATED  12.46.100.0/23       10912       InterNAP Network Ser

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
128.0.0.0/21         12654     RIPE NCC RIS Project
128.0.24.0/24        12654     RIPE NCC RIS Project

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
14.192.0.0/22        45464     Room 201, TGU Bldg
14.192.4.0/22        45464     Room 201, TGU Bldg
14.192.8.0/22        45464     Room 201, TGU Bldg
14.192.12.0/22       45464     Room 201, TGU Bldg
14.192.16.0/22       45464     Room 201, TGU Bldg
14.192.20.0/22       45464     Room 201, TGU Bldg
14.192.24.0/22       45464     Room 201, TGU Bldg
14.192.28.0/22       45464     Room 201, TGU Bldg
37.98.200.0/21       56687     Nimad Rah Khoozestan PLC
37.98.208.0/20        8374     Polkomtel S.A.

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:19       /9:12      /10:27      /11:80      /12:231     
/13:458     /14:816     /15:1469    /16:12130   /17:6197    /18:10311   
/19:20471   /20:28291   /21:29233   /22:39842   /23:37018   /24:207333  
/25:1195    /26:1434    /27:775     /28:169     /29:59      /30:14      
/31:0       /32:18      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 7029     3047          3391      Windstream Communications Inc
 6389     2112          3442      bellsouth.net, inc. 
18566     2042          2093      Covad Communications 
 8402     1698          1719      Corbina telecom
10620     1645          1751      TVCABLE BOGOTA 
30036     1351          1392      Mediacom Communications Corp 
11492     1118          1155      Cable One 
 1785     1065          1868      PaeTec Communications, Inc.
15557     1045          1095      LDCOM NETWORKS
 8452     1041          1235      TEDATA

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:505       2:689       4:14        5:1         6:3         8:385    
  12:1958     13:1        14:596      15:11       16:3        17:7      
  20:9        23:133      24:1724     27:1197     31:901      32:65     
  33:2        34:2        36:9        37:177      38:776      40:115    
  41:3174     42:93       43:1        44:3        46:1281     47:3      
  49:322      50:512      52:13       54:2        55:9        56:3      
  57:38       58:962      59:491      60:344      61:1195     62:949    
  63:2008     64:4130     65:2285     66:4426     67:2039     68:1174   
  69:3159     70:927      71:412      72:1795     74:2654     75:463    
  76:322      77:976      78:936      79:502      80:1228     81:881    
  82:569      83:529      84:582      85:1154     86:742      87:919    
  88:334      89:1547     90:271      91:4479     92:538      93:1328   
  94:1357     95:1084     96:418      97:310      98:814      99:38     
 100:4       101:141     103:776     106:65      107:152     108:150    
 109:1486    110:694     111:848     112:432     113:530     114:597    
 115:763     116:868     117:727     118:899     119:1254    120:361    
 121:683     122:1621    123:1071    124:1337    125:1369    128:542    
 129:189     130:212     131:589     132:164     133:21      134:231    
 135:60      136:216     137:153     138:286     139:145     140:488    
 141:262     142:385     143:411     144:520     145:70      146:484    
 147:242     148:728     149:274     150:165     151:196     152:447    
 153:170     154:7       155:403     156:211     157:368     158:156    
 159:515     160:322     161:244     162:341     163:187     164:529    
 165:391     166:556     167:457     168:762     169:147     170:832    
 171:111     172:2       173:1733    174:603     175:416     176:515    
 177:481     178:1247    180:1180    181:65      182:715     183:278    
 184:425     185:1       186:2050    187:842     188:1031    189:1169   
 190:5474    192:5970    193:5525    194:4327    195:3393    196:1299   
 197:181     198:3619    199:4378    200:5718    201:1736    202:8496   
 203:8625    204:4346    205:2440    206:2736    207:2804    208:4069   
 209:3566    210:2747    211:1477    212:2042    213:1847    214:864    
 215:96      216:5000    217:1477    218:548     219:340     220:1252   
 221:558     222:325     223:280    

End of report


From sh.vahabzadeh at gmail.com  Fri Feb 10 13:03:06 2012
From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh)
Date: Fri, 10 Feb 2012 22:33:06 +0330
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
References: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
Message-ID: <D4CC1941-285F-46E6-BC5B-E426A6BB7657@gmail.com>

Yes I am from Iran and outgoing TCP/443 has been stoped ;)

--
Regards,
Shahab Vahabzadeh, Network Engineer and System Administrator

PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81  C2EE 76A2 46C2 5367 BF90

On Feb 10, 2012, at 9:56 PM, Ryan Malayter <malayter at gmail.com> wrote:

> Haven't seen this come through on NANOG yet:
> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
> 
> Can anyone with the ability confirm that TCP/443 traffic from Iran has
> stopped?
> 


From malayter at gmail.com  Fri Feb 10 13:11:18 2012
From: malayter at gmail.com (Ryan Malayter)
Date: Fri, 10 Feb 2012 11:11:18 -0800 (PST)
Subject: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't
 encourage phishing)
In-Reply-To: <20120210180106.GB80127@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <4F355803.4040402@unfix.org> <20120210180106.GB80127@ussenterprise.ufp.org>
Message-ID: <7f28e83f-a4da-4c47-9e03-77ff4dcf7062@f30g2000yqh.googlegroups.com>



On Feb 10, 12:01?pm, Leo Bicknell <bickn... at ufp.org> wrote:
> OSX at least has a central certificate store (Keychain), although
> it's not up to the tasks of the world I wish to have. ?Other OS's
> provide no central store, so each application maintains their own
> key store.

Windows has had its own centralized certificate store and APIs since
NT 4.0's release in 1996.

Firefox and Java are the only mainstream software can think of on
Windows that insists on using their own certificate stores (really
just a "pile of world-readable files") instead of the built-in per-
machine+per-user certificate store on Windows.


From jcdill.lists at gmail.com  Fri Feb 10 13:12:03 2012
From: jcdill.lists at gmail.com (JC Dill)
Date: Fri, 10 Feb 2012 11:12:03 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <30780538.1943.1328896810308.JavaMail.root@benjamin.baylink.com>
References: <30780538.1943.1328896810308.JavaMail.root@benjamin.baylink.com>
Message-ID: <4F356C03.8060808@gmail.com>

On 10/02/12 10:00 AM, Jay Ashworth wrote:
> Even lots of*technical*  people just don't understand what "a security-
> related URL"*is*, and there's almost always no way to teach them.

Freakonomics recently aired a story about the problem of getting Doctors 
to follow hand hygiene rules and wash their hands as frequently as they 
are supposed to (upon entering and leaving each patient's room) to avoid 
spreading disease.  One of the biggest problems with changing behavior 
with doctors (and with technical people) is that the smarter people are, 
the more they chafe at being told they aren't doing things the correct way.

The most effective step they took to counter-act the hand-washing 
problems was using a screen-saver on all the public terminals, showing 
the consequences of not-washing - an image of a petri dish showing the 
bacteria results from a hand-print of a doctor's hand.

http://www.freakonomics.com/2012/01/24/how-to-get-doctors-to-wash-their-hands-visual-edition/


If you wanted to have a similar effect at $workplace, try a similar 
visual (e.g. a mockup of 2 screenshots, first clicking on a link in 
email then typing in a password on a webpage with a phishing URL (with a 
typo)) as the screen saver on all company computers; as the first slide 
in all in-house ppt presentations; on the wall at all card-lock entry 
doors, etc.

jc


From rsk at gsp.org  Fri Feb 10 13:16:12 2012
From: rsk at gsp.org (Rich Kulawiec)
Date: Fri, 10 Feb 2012 14:16:12 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <D566F764-8028-41A5-8323-7E5DBA4D2C2B@cs.columbia.edu>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <D566F764-8028-41A5-8323-7E5DBA4D2C2B@cs.columbia.edu>
Message-ID: <20120210191612.GA13913@gsp.org>

On Fri, Feb 10, 2012 at 12:28:22PM -0500, Steven Bellovin wrote:
> If they're intended as a path to log in with a typed password, that's correct.
> Sad, but correct.

I agree.  Training your customers/clients to click on URLs in email
messages is precisely equivalent to training them to be phish victims.

I teach people to (carefully!) bookmark the sites that they use which
require passwords, and to always use those bookmarks -- that is, *never*
to use the links in any mail message or on any web page.

(Of course, an attacker in control of their browser could manipulate the
bookmarks, but there is little reason for an attacker who's already gotten
that far to do so.)

---rsk


From jra at baylink.com  Fri Feb 10 13:44:29 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 10 Feb 2012 14:44:29 -0500 (EST)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F356C03.8060808@gmail.com>
Message-ID: <13990481.1993.1328903069177.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "JC Dill" <jcdill.lists at gmail.com>

> If you wanted to have a similar effect at $workplace, try a similar
> visual (e.g. a mockup of 2 screenshots, first clicking on a link in
> email then typing in a password on a webpage with a phishing URL (with a
> typo)) as the screen saver on all company computers; as the first slide
> in all in-house ppt presentations; on the wall at all card-lock entry
> doors, etc.

The problem is you need the 3rd visual...

a picture of an abandoned factory, with the doors flapping in the wind, 
bceause the company went out of business because someone got spearphished.

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


From Valdis.Kletnieks at vt.edu  Fri Feb 10 13:53:14 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 10 Feb 2012 14:53:14 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Fri, 10 Feb 2012 14:44:29 EST."
 <13990481.1993.1328903069177.JavaMail.root@benjamin.baylink.com>
References: <13990481.1993.1328903069177.JavaMail.root@benjamin.baylink.com>
Message-ID: <116972.1328903594@turing-police.cc.vt.edu>

On Fri, 10 Feb 2012 14:44:29 EST, Jay Ashworth said:

> a picture of an abandoned factory, with the doors flapping in the wind,
> bceause the company went out of business because someone got spearphished.

Has this ever been spotted in the wild?  Serious question - most of the well-publicized
spearphishing attacks lately the victim company is still around.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/da396d23/attachment.bin>

From jra at baylink.com  Fri Feb 10 13:57:02 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 10 Feb 2012 14:57:02 -0500 (EST)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <116972.1328903594@turing-police.cc.vt.edu>
Message-ID: <27384450.2017.1328903822394.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Valdis Kletnieks" <Valdis.Kletnieks at vt.edu>

> On Fri, 10 Feb 2012 14:44:29 EST, Jay Ashworth said:
> > a picture of an abandoned factory, with the doors flapping in the wind,
> > bceause the company went out of business because someone got spearphished.
> 
> Has this ever been spotted in the wild? Serious question - most of the
> well-publicized spearphishing attacks lately the victim company is still 
> around.

I don't know that we would have any way to know that a demised company went
down due to a spearphish... but yes, I was exaggerating.

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


From marshall.eubanks at gmail.com  Fri Feb 10 14:07:15 2012
From: marshall.eubanks at gmail.com (Marshall Eubanks)
Date: Fri, 10 Feb 2012 15:07:15 -0500
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <D4CC1941-285F-46E6-BC5B-E426A6BB7657@gmail.com>
References: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
 <D4CC1941-285F-46E6-BC5B-E426A6BB7657@gmail.com>
Message-ID: <CAJNg7VJBtM_bNOto0gsZzxMNjbUNSXFOhqACxoZAaVb+-asYCQ@mail.gmail.com>

And in response

http://www.forbes.com/sites/andygreenberg/2012/02/10/as-iran-cracks-down-online-tor-tests-undetectable-encrypted-connections/

(quoting) :

?Basically, say you want to look like an XMPP chat instead of SSL,? he
writes to me, referring to a protocol for instant messaging as the
decoy for the encrypted SSL communications. ?Obfsproxy should start
up, you choose XMPP, and obfsproxy should emulate XMPP to the point
where even a sophisticated [deep packet inspection] device cannot find
anything suspicious.?

Regards
Marshall

On Fri, Feb 10, 2012 at 2:03 PM, Shahab Vahabzadeh
<sh.vahabzadeh at gmail.com> wrote:
> Yes I am from Iran and outgoing TCP/443 has been stoped ;)
>
> --
> Regards,
> Shahab Vahabzadeh, Network Engineer and System Administrator
>
> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 ?C2EE 76A2 46C2 5367 BF90
>
> On Feb 10, 2012, at 9:56 PM, Ryan Malayter <malayter at gmail.com> wrote:
>
>> Haven't seen this come through on NANOG yet:
>> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
>>
>> Can anyone with the ability confirm that TCP/443 traffic from Iran has
>> stopped?
>>
>


From bicknell at ufp.org  Fri Feb 10 14:08:26 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Feb 2012 12:08:26 -0800
Subject: PGP,
 S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage
 phishing)
In-Reply-To: <7f28e83f-a4da-4c47-9e03-77ff4dcf7062@f30g2000yqh.googlegroups.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <4F355803.4040402@unfix.org> <20120210180106.GB80127@ussenterprise.ufp.org>
 <7f28e83f-a4da-4c47-9e03-77ff4dcf7062@f30g2000yqh.googlegroups.com>
Message-ID: <20120210200826.GA85969@ussenterprise.ufp.org>

In a message written on Fri, Feb 10, 2012 at 11:11:18AM -0800, Ryan Malayter wrote:
> Windows has had its own centralized certificate store and APIs since
> NT 4.0's release in 1996.

You are correct that I maligned Windows in a way I shouldn't have
done.  Indeed, I've been very impressed with the software they make
to manage certificates in the enterprise before, making it quite
easy to roll out per user certificates for VPN's or E-Mail and dump
it in the certificate store.

I think my view was incorrectly colored by the fact that the API
is not used by many programs (open source in particular) where as
OSX has had some traction with the Keychain.

It would be nice to get something approximating a cross platform API,
even if all that means is the ability to do the same operations on all
major platforms.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/cd0fb21b/attachment.bin>

From smb at cs.columbia.edu  Fri Feb 10 14:20:57 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Fri, 10 Feb 2012 15:20:57 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m2sjiivbph.wl%randy@psg.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
Message-ID: <8D6F5DEF-21AF-43C0-B6AC-6E718D527646@cs.columbia.edu>


On Feb 10, 2012, at 12:29 30PM, Randy Bush wrote:

>> So because of phishing, nobody should send messages with URLs in them?
> 
> more and more these days, i have taken to not clicking the update messages, 
> but going to the web site manyually to get it.

Yup -- I wrote about that a while back (https://www.cs.columbia.edu/~smb/blog/2011-10/2011-10-02.html)
> 
> waaaay to much phishing, and it is getting subtle and good.
> 


What's the line -- "I know I'm paranoid, but am I paranoid enough?"

		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From smb at cs.columbia.edu  Fri Feb 10 14:26:12 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Fri, 10 Feb 2012 15:26:12 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120210173701.GA79917@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
Message-ID: <7A06A06D-5A68-4806-B8C1-7020707C36BB@cs.columbia.edu>


On Feb 10, 2012, at 12:37 01PM, Leo Bicknell wrote:

> In a message written on Fri, Feb 10, 2012 at 09:29:30AM -0800, Randy Bush wrote:
>> more and more these days, i have taken to not clicking the update messages, 
>> but going to the web site manyually to get it.
>> 
>> waaaay to much phishing, and it is getting subtle and good.
> 
> We know how to sign and encrypt web sites.
> 
> We know how to sign and encrypt e-mail.
> 
> We even know how to compare keys between the web site and e-mail via a
> variety of mechanisms.
> 
> We know how to sign DNS.
> 
> Remind me again why we live in this sad word Randy (correcly) described?
> 
> There's no reason my mail client shouldn't validate the signed e-mail
> came from the same entity as the signed web site I'd previously logged
> into, and give me a green light that the link actually points to said
> same web site with the same key.  It should be transparent, and secure
> for the user.

The really hard parts are (a) getting the users to pay attention to the
validation state (or, more precisely, the lack thereof on a phishing
email, and (b) get them to do it *correctly*.

Some of the browser password managers have protection against phishing as
a very useful side-effect: if they don't recognize the URL, they won't pony
up the correct login and password.  That's much better than hoping that
someone notices the absence of a little icon that means "this was signed".

The "correctly" part has to do with the PKI mess.


		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From jra at baylink.com  Fri Feb 10 14:30:35 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 10 Feb 2012 15:30:35 -0500 (EST)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <8D6F5DEF-21AF-43C0-B6AC-6E718D527646@cs.columbia.edu>
Message-ID: <9602735.2051.1328905835691.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Steven Bellovin" <smb at cs.columbia.edu>

> What's the line -- "I know I'm paranoid, but am I paranoid enough?"

"Just because people say you're paranoid, that doesn't mean that there
*aren't* people out to get you."

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


From bill at herrin.us  Fri Feb 10 15:15:19 2012
From: bill at herrin.us (William Herrin)
Date: Fri, 10 Feb 2012 16:15:19 -0500
Subject: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't
 encourage phishing)
In-Reply-To: <20120210180106.GB80127@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <4F355803.4040402@unfix.org> <20120210180106.GB80127@ussenterprise.ufp.org>
Message-ID: <CAP-guGWh4+4kg1Jr1HLpF9voWYdrt9zyx9cRVXyZTL2i83etvw@mail.gmail.com>

On Fri, Feb 10, 2012 at 1:01 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Fri, Feb 10, 2012 at 06:46:43PM +0100, Jeroen Massar wrote:
>> The problem still lies in the issue that most people, even on this very
>> list, do not use PGP or S/MIME. (and that there are two standards does
>> not help much there either ;)
>
> The problem space is still certificate management.

The problem space is that most folks won't catch the difference
between an email and link from ripe.net, ripe.org and ripe.ca. The
game is lost long before a purely technical version of validating the
message source becomes an issue.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From eesslinger at fpu-tn.com  Fri Feb 10 15:19:24 2012
From: eesslinger at fpu-tn.com (Eric J Esslinger)
Date: Fri, 10 Feb 2012 15:19:24 -0600
Subject: couple of questions regarding 'lifeline' and large scale nat...
Message-ID: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>

We're toying with the idea of a low bitrate 'lifeline' internet on our cable system, maybe even bundled with a certain level of cable service.

First question, if you happen to be doing something like this, what bit rates are you providing.
Second question, though 'real' internet customers all get real IP's, what would you think of doing something like this with 'large scale' nat instead. Understand, we're only talking about basic internet, something like a 256k/96k (or similar) connect, not something that would be used by a serious user. (One thing we are looking at is some older dial up users we still have, most of which could go onto cable just fine but don't want to pay the price).

Also when I say large scale, I doubt I'd have more than a few thousand customers for this. We're not a large ISP/cable company by any means.

__________________________
Eric Esslinger
Information Services Manager - Fayetteville Public Utilities
http://www.fpu-tn.com/
(931)433-1522 ext 165

This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Eric J Esslinger.vcf
Type: text/x-vcard
Size: 498 bytes
Desc: Eric J Esslinger.vcf
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/bc4a8cdc/attachment.vcf>

From bicknell at ufp.org  Fri Feb 10 15:37:55 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Feb 2012 13:37:55 -0800
Subject: PGP,
 S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage
 phishing)
In-Reply-To: <CAP-guGWh4+4kg1Jr1HLpF9voWYdrt9zyx9cRVXyZTL2i83etvw@mail.gmail.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <4F355803.4040402@unfix.org> <20120210180106.GB80127@ussenterprise.ufp.org>
 <CAP-guGWh4+4kg1Jr1HLpF9voWYdrt9zyx9cRVXyZTL2i83etvw@mail.gmail.com>
Message-ID: <20120210213755.GA88812@ussenterprise.ufp.org>

In a message written on Fri, Feb 10, 2012 at 04:15:19PM -0500, William Herrin wrote:
> The problem space is that most folks won't catch the difference
> between an email and link from ripe.net, ripe.org and ripe.ca. The
> game is lost long before a purely technical version of validating the
> message source becomes an issue.

You're reply is along the lines of what several other folks have
told me privately, and I think they all miss the mark of where I
am going with my suggestion.

Hypothetically, I get an e-mail from ripe.ca, which uses some trick
(perhaps as simple as HTML text and link that go to different places)
to visually show me ripe.net and actually sends me to ripe.org.

Let's also assume I have a ripe.net account and have been to that
web site before.

The software can do a pile of things that make life better for the user:

1) When I reach ripe.org (from the phish above), my browser can say:

   "This is an SSL web site asking for a login and password, and yet,
    you've never been here before.  Maybe you would prefer to register,
    or leave if you came here incorrectly."

   That's all client side UI, and would make even novice users stop
   and think about what happened.

2) Let's say the e-mail was signed, by ripe.ca, the original sender.
   When my e-mail client passes the URL to my browser, it can also pass
   the details of the ripe.ca key.  My browser can then say "You got
   an e-mail from Key ABC, but went to a web site run by XYZ, are you
   sure this is what you want to do?"  Of course if everything matches,
   it can be silent.

Specifically I am NOT suggesting to ever trust a root-CA, or the
details in a certificate.  Indeed, browsers could ship with no
certificates what so ever in my scheme.  The key is comparing
multiple sources of information.  Most folks might not know the
difference between ripe.ca and ripe.net.  The existing CA scheme
may allow both of them to get the common name "R?seaux IP Europ?ens",
confusing even the technical who look close.  But it's trivial for
the software to say Cert in E-mail != Cert in Web, or even that
they don't have a common branch in the tree (in a large org they
may have the same parent, for instance).

As I've also said, a good UI feature would be the ability to add a
description to a cert locally.  Once I'm sure my banks web site is legit
I should be able to add "Leo's Bank" in the cert store locally.  Now
when my web browser or e-mail client use that cert to validate a message
they can display "Leo's Bank" next to it.  I can easily look for that
and know I went back to the same place.  I click on a link in my e-mail
and see no description, I know something went wrong.

Does my scheme stop all phishing.  Heck no.  If we wait for a perfect
solution we'll never have any solution.  Look at NANOG.  Bandy Rush is
here somewhere.  It's why many years ago I set my mailer to PGP all
e-mail to NANOG.  See an e-mail from me not signed, don't trust it.
Does that stop all impersonation on NANOG.  Heck no, but if we all did
it, and subscribed to the web of trust, it would all but stop it.

Users hate encryption and ignore the warnings not because they don't
want to be secure, or are idiots.  They do it because the darn software
is broken, confusing, and has the worst UI's ever invented.  If the
industry fixes it, encryption will be much more widespread.  Small
steps, like banks allowing users to upload an cert to their account
profile, and then communicate via two-way authenticated e-mail would go
a long way to traning the user community how this should work.  End user
ISP's (cable, DSL) issuing e-mail certs automatically and installing
them as part of their install package would be a quantum leap forward.

It's not hard, people just don't do it.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/742945ee/attachment.bin>

From bicknell at ufp.org  Fri Feb 10 15:43:41 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Feb 2012 13:43:41 -0800
Subject: couple of questions regarding 'lifeline' and large scale nat...
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
References: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
Message-ID: <20120210214341.GB88812@ussenterprise.ufp.org>

In a message written on Fri, Feb 10, 2012 at 03:19:24PM -0600, Eric J Esslinger wrote:
> First question, if you happen to be doing something like this, what bit rates are you providing.

Comcast has a program with some of the best marketing around it right
now, their Internet Essentials service: http://www.internetessentials.com/

$9.95/month, 1.5Mbps down, 384kbps up.

> Second question, though 'real' internet customers all get real IP's, what would you think of doing something like this with 'large scale' nat instead.

Carriers do not want to run NAT's.  You can go read the archives of the
CGN (Carrier Grade NAT) discussions where folks are looking at moving
the NAT into the service provider due to IPv4 exhaustion.

UPNP, NAT-PMP, the ability to enter static bypasses (DMZ's, NAT
passthrough), combined with the problems of some applications that
make thousands of TCP connections in a short order eating up ports
makes it a nightmare to manage and debug.  Of course, if they are
doing illegal things you'd better keep some detailed records of who did
what when a LEO comes knocking.

The key to a low cost service is making it as low cost as possible,
moving the NAT inside the carrier will had a huge amount of headache and
support costs, not what you want.

A possibly relevant question with IPv4 exhaustion coming is could you
make this service IPv6 only so you don't have to find IPv4 addresses for
it.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/40887ce0/attachment.bin>

From cidr-report at potaroo.net  Fri Feb 10 16:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 10 Feb 2012 22:00:00 GMT
Subject: BGP Update Report
Message-ID: <201202102200.q1AM003Z055387@wattle.apnic.net>

BGP Update Report
Interval: 02-Feb-12 -to- 09-Feb-12 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS8402            53549  3.4%      29.9 -- CORBINA-AS OJSC "Vimpelcom"
 2 - AS28683           32704  2.1%     536.1 -- BENINTELECOM
 3 - AS9829            26878  1.7%      39.6 -- BSNL-NIB National Internet Backbone
 4 - AS12479           26390  1.7%     303.3 -- UNI2-AS France Telecom Espana SA
 5 - AS45271           23588  1.5%     168.5 -- ICLNET-AS-AP 5th Floor, Windsor Building, Off: CST Road
 6 - AS32528           22752  1.4%    7584.0 -- ABBOTT Abbot Labs
 7 - AS8452            21248  1.3%      52.7 -- TE-AS TE-AS
 8 - AS23154           20456  1.3%    6818.7 -- SANMINA-SCI Sanmina-SCI Corporation
 9 - AS5800            19469  1.2%      64.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
10 - AS7552            17101  1.1%      19.6 -- VIETEL-AS-AP Vietel Corporation
11 - AS24560           16978  1.1%      39.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
12 - AS20632           15343  1.0%    1180.2 -- PETERSTAR-AS PeterStar
13 - AS2118            15208  1.0%      17.4 -- RELCOM-AS OOO "NPO Relcom"
14 - AS17974           14308  0.9%      15.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
15 - AS6503            12775  0.8%       7.6 -- Axtel, S.A.B. de C.V.
16 - AS6066            12372  0.8%    6186.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
17 - AS5976            11800  0.8%     119.2 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
18 - AS6713            11470  0.7%      25.9 -- IAM-AS
19 - AS29126           11373  0.7%   11373.0 -- DATIQ-AS Datiq B.V.
20 - AS12975           10309  0.7%      45.4 -- PALTEL-AS PALTEL Autonomous System


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS29126           11373  0.7%   11373.0 -- DATIQ-AS Datiq B.V.
 2 - AS32528           22752  1.4%    7584.0 -- ABBOTT Abbot Labs
 3 - AS23154           20456  1.3%    6818.7 -- SANMINA-SCI Sanmina-SCI Corporation
 4 - AS6066            12372  0.8%    6186.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
 5 - AS5868             1882  0.1%    1882.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
 6 - AS8163             1257  0.1%    1257.0 -- METROTEL REDES S.A.
 7 - AS20632           15343  1.0%    1180.2 -- PETERSTAR-AS PeterStar
 8 - AS53362             882  0.1%     882.0 -- MIXIT-AS - Mixit, Inc.
 9 - AS21271             810  0.1%     810.0 -- SOTELMABGP
10 - AS27704             595  0.0%     595.0 -- Tiendas Comercial Mexicana, S.A. de C.V.
11 - AS17408            3497  0.2%     582.8 -- ABOVE-AS-AP AboveNet Communications Taiwan
12 - AS51896             567  0.0%     567.0 -- HRINGDU-AS Hringdu ehf
13 - AS1997             1643  0.1%     547.7 -- IBMDES-AS - IBM Dallas Engineering & Scientific
14 - AS28683           32704  2.1%     536.1 -- BENINTELECOM
15 - AS36980             512  0.0%     512.0 -- JOHNHOLT-ASN
16 - AS39843            1415  0.1%     471.7 -- RATECOM-AS ZAO "Ratecom"
17 - AS48068             448  0.0%     448.0 -- VISONIC Visonic Ltd
18 - AS56886             440  0.0%     440.0 -- REDSTAR-AS OOO "Red Star"
19 - AS676               437  0.0%     437.0 -- United Nations Development Programme
20 - AS37296             432  0.0%     432.0 -- AFCOMSAT


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 148.164.14.0/24   20430  1.2%   AS23154 -- SANMINA-SCI Sanmina-SCI Corporation
 2 - 84.204.132.0/24   15228  0.9%   AS20632 -- PETERSTAR-AS PeterStar
 3 - 217.170.24.0/21   11373  0.7%   AS29126 -- DATIQ-AS Datiq B.V.
 4 - 130.36.34.0/24    11372  0.7%   AS32528 -- ABBOTT Abbot Labs
 5 - 130.36.35.0/24    11372  0.7%   AS32528 -- ABBOTT Abbot Labs
 6 - 122.161.0.0/16    10381  0.6%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
 7 - 62.36.252.0/22     8257  0.5%   AS12479 -- UNI2-AS France Telecom Espana SA
 8 - 202.92.235.0/24    8179  0.5%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 9 - 190.67.172.0/22    6746  0.4%   AS3816  -- COLOMBIA TELECOMUNICACIONES S.A. ESP
10 - 62.36.249.0/24     6209  0.4%   AS12479 -- UNI2-AS France Telecom Espana SA
11 - 204.29.239.0/24    6186  0.4%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
12 - 150.225.0.0/16     6186  0.4%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
13 - 62.36.241.0/24     5685  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
14 - 62.36.210.0/24     5463  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
15 - 194.63.9.0/24      5322  0.3%   AS1273  -- CW Cable and Wireless Worldwide plc
16 - 41.43.219.0/24     4202  0.2%   AS8452  -- TE-AS TE-AS
17 - 41.43.222.0/24     4150  0.2%   AS8452  -- TE-AS TE-AS
18 - 205.73.118.0/24    4059  0.2%   AS5976  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
19 - 205.73.116.0/23    3969  0.2%   AS5976  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
20 - 41.43.233.0/24     3643  0.2%   AS8452  -- TE-AS TE-AS

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Feb 10 16:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 10 Feb 2012 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201202102200.q1AM00W4055381@wattle.apnic.net>

This report has been generated at Fri Feb 10 21:12:37 2012 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        03-02-12    397625      230154
        04-02-12    398129      229956
        05-02-12    397792      230223
        06-02-12    397996      230469
        07-02-12    398139      230795
        08-02-12    398862      230787
        09-02-12    399071      230735
        10-02-12    398957      231557


AS Summary
         40190  Number of ASes in routing system
         16851  Number of ASes announcing only one prefix
          3442  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      109981184  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 10Feb12 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     399616   231551   168065    42.1%   All ASes

AS6389      3442      204     3238    94.1%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS7029      3432     1743     1689    49.2%   WINDSTREAM - Windstream
                                               Communications Inc
AS18566     2093      413     1680    80.3%   COVAD - Covad Communications
                                               Co.
AS4766      2475     1002     1473    59.5%   KIXS-AS-KR Korea Telecom
AS22773     1510      118     1392    92.2%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS2118      1385       14     1371    99.0%   RELCOM-AS OOO "NPO Relcom"
AS4323      1611      387     1224    76.0%   TWTC - tw telecom holdings,
                                               inc.
AS28573     1659      497     1162    70.0%   NET Servicos de Comunicao S.A.
AS4755      1531      402     1129    73.7%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS1785      1871      791     1080    57.7%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS7552      1393      358     1035    74.3%   VIETEL-AS-AP Vietel
                                               Corporation
AS10620     1751      739     1012    57.8%   Telmex Colombia S.A.
AS19262     1386      397      989    71.4%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS7303      1263      371      892    70.6%   Telecom Argentina S.A.
AS26615      897       33      864    96.3%   Tim Celular S.A.
AS8402      1645      824      821    49.9%   CORBINA-AS OJSC "Vimpelcom"
AS4808      1149      342      807    70.2%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS8151      1477      675      802    54.3%   Uninet S.A. de C.V.
AS18101      952      156      796    83.6%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS24560     1014      329      685    67.6%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS9498       885      204      681    76.9%   BBIL-AP BHARTI Airtel Ltd.
AS9394       882      207      675    76.5%   CRNET CHINA RAILWAY
                                               Internet(CRNET)
AS7545      1643      979      664    40.4%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS3356      1096      455      641    58.5%   LEVEL3 Level 3 Communications
AS30036     1384      761      623    45.0%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS17974     1728     1119      609    35.2%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS17676      681       75      606    89.0%   GIGAINFRA Softbank BB Corp.
AS15557     1095      510      585    53.4%   LDCOMNET Societe Francaise du
                                               Radiotelephone S.A
AS4804       660       95      565    85.6%   MPX-AS Microplex PTY LTD
AS3549       986      430      556    56.4%   GBLX Global Crossing Ltd.

Total      44976    14630    30346    67.5%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        14.192.0.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.4.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.8.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.12.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.16.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.20.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.24.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.28.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        37.114.8.0/21        AS20608 T-SYSTEMS-ITALIA-AS T-Systems Italia Autonomous System
        37.114.192.0/18      AS51074 MABNA Gostaresh Ertebatate Mabna Co. Ltd.
        37.115.0.0/16        AS15895 KSNET-AS Kyivstar GSM
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.129.0.0/19        AS3901  ARRAKIS - Higher Technology Services
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.143.0/24      AS3356  LEVEL3 Level 3 Communications
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.44.16.0/20        AS15054 HAMELTRONICS - Hameltronics, LLC
        98.159.96.0/20       AS46975 
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas S.A.
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        172.45.1.0/24        AS3356  LEVEL3 Level 3 Communications
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        176.108.32.0/20      AS31042 SERBIA-BROADBAND-AS Serbia BroadBand-Srpske Kablovske mreze d.o.o.
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        193.0.22.0/23        AS3333  RIPE-NCC-AS RIPE Network Coordination Centre
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.23.84.0/24       AS8151  Uninet S.A. de C.V.
        200.24.73.0/24       AS26061 Equant Colombia
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.86.32.0/20       AS18255 BRISBANE-AP Brisbane City Council
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.140.128.0/19     AS9583  SIFY-AS-IN Sify Limited
        202.160.152.0/22     AS10113 EFTEL-AS-AP Eftel Limited.
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.80.128.0/23      AS9260  MULTINET-PK NSP,ISP,HFC,DSL,DIALUP,Data Network Connectivity solutions,
        203.80.130.0/23      AS9260  MULTINET-PK NSP,ISP,HFC,DSL,DIALUP,Data Network Connectivity solutions,
        203.142.219.0/24     AS45149 
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - KNOLOGY,  Inc.
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.91.56.0/21       AS22241 IC2NET - IC2NET
        208.91.56.0/24       AS22241 IC2NET - IC2NET
        208.91.57.0/24       AS22241 IC2NET - IC2NET
        208.91.58.0/24       AS22241 IC2NET - IC2NET
        208.91.59.0/24       AS22241 IC2NET - IC2NET
        208.91.60.0/24       AS22241 IC2NET - IC2NET
        208.91.61.0/24       AS22241 IC2NET - IC2NET
        208.91.62.0/24       AS22241 IC2NET - IC2NET
        208.91.63.0/24       AS22241 IC2NET - IC2NET
        209.133.224.0/19     AS4323  TWTC - tw telecom holdings, inc.
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        209.222.240.0/22     AS19747 
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.12.160.0/20      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From mansaxel at besserwisser.org  Fri Feb 10 16:24:39 2012
From: mansaxel at besserwisser.org (=?iso-8859-1?Q?M=E5ns?= Nilsson)
Date: Fri, 10 Feb 2012 23:24:39 +0100
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m2sjiivbph.wl%randy@psg.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
Message-ID: <20120210222435.GF27669@besserwisser.org>

On Fri, Feb 10, 2012 at 09:29:30AM -0800, Randy Bush wrote:
> > So because of phishing, nobody should send messages with URLs in them?
> 
> more and more these days, i have taken to not clicking the update messages, 
> but going to the web site manyually to get it.

Web site? With the RIPE db one communicates using PGP email for data
in and port 43 queries for data out. The web site is for signing up to
RIPE meetings. Yes, RIPE NCC, I think that you put a lot of resources into
new fancy guish junk, and tend to forget how things should be done, and
some things -- the horror! -- are only possible to accomplish using the
web site and some forgotten password. To me, that is much more annoying
than the side projects that people are griping over.

</rant>
 
> waaaay to much phishing, and it is getting subtle and good.

Indeed. 

-- 
M?ns


From rsk at gsp.org  Fri Feb 10 17:46:30 2012
From: rsk at gsp.org (Rich Kulawiec)
Date: Fri, 10 Feb 2012 18:46:30 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120210173701.GA79917@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
 <20120210173701.GA79917@ussenterprise.ufp.org>
Message-ID: <20120210234630.GA23186@gsp.org>

On Fri, Feb 10, 2012 at 09:37:01AM -0800, Leo Bicknell wrote:
> Remind me again why we live in this sad word Randy (correcly) described?

Because banks and many other institutions have prioritized all-singing,
all-dancing, bloated, horribly-badly-marked-up HTML email with
"stationary" and logos and pictures and web bugs far, FAR ahead of
security, privacy, accessability, portability and other -ilities that
I'm too lazy to enumerate just now.  Besides: it's not like it's *their*
accounts that will get hosed or *their* money that will get lost.
Things like that only happen to the little people.

See also this related note:

	http://www.mail-archive.com/infowarrior%40attrition.org/msg08436.html

---rsk


From brandon at rd.bbc.co.uk  Fri Feb 10 18:09:37 2012
From: brandon at rd.bbc.co.uk (Brandon Butterworth)
Date: Sat, 11 Feb 2012 00:09:37 GMT
Subject: Dear RIPE: Please don't encourage phishing
Message-ID: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>

> So it's necessary to throw the baby out with the bathwater, and tell them
> never to click on a link...

That baby was ugly anyway

brandon


From jeff-kell at utc.edu  Fri Feb 10 18:12:37 2012
From: jeff-kell at utc.edu (Jeff Kell)
Date: Fri, 10 Feb 2012 19:12:37 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120210234630.GA23186@gsp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <20120210234630.GA23186@gsp.org>
Message-ID: <4F35B275.5000605@utc.edu>

There used to be the old programming benchmark of how large a "program"
(in lines, as well as compiled bytes) it took to say "Hello, world."

The 21st century benchmark might now well be the size of a "Hello,
world" e-mail.

Or a web page with a similar statement.

Jeff

On 2/10/2012 6:46 PM, Rich Kulawiec wrote:
> On Fri, Feb 10, 2012 at 09:37:01AM -0800, Leo Bicknell wrote:
>> Remind me again why we live in this sad word Randy (correcly) described?
> Because banks and many other institutions have prioritized all-singing,
> all-dancing, bloated, horribly-badly-marked-up HTML email with
> "stationary" and logos and pictures and web bugs far, FAR ahead of
> security, privacy, accessability, portability and other -ilities that
> I'm too lazy to enumerate just now.  Besides: it's not like it's *their*
> accounts that will get hosed or *their* money that will get lost.
> Things like that only happen to the little people.
>
> See also this related note:
>
> 	http://www.mail-archive.com/infowarrior%40attrition.org/msg08436.html
>
> ---rsk
>



From mohta at necom830.hpcl.titech.ac.jp  Fri Feb 10 18:19:46 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 11 Feb 2012 09:19:46 +0900
Subject: couple of questions regarding 'lifeline' and large scale nat...
In-Reply-To: <20120210214341.GB88812@ussenterprise.ufp.org>
References: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
 <20120210214341.GB88812@ussenterprise.ufp.org>
Message-ID: <4F35B422.1020403@necom830.hpcl.titech.ac.jp>

Leo Bicknell wrote:

> UPNP, NAT-PMP, the ability to enter static bypasses (DMZ's, NAT
> passthrough), combined with the problems of some applications that
> make thousands of TCP connections in a short order eating up ports
> makes it a nightmare to manage and debug.

The applications can simply be debugged to use socket option
of REUSEPORT.

I pointed it out so along with static port mapping at the last
meeting in "Track: IPv4 runout, Doing More with Less".

> Of course, if they are
> doing illegal things you'd better keep some detailed records of who did
> what when a LEO comes knocking.

Are you saying we MUST record all the IP addresses and
port numbers of all peers of your customers to prevent
illegal things?

If so, we have to do so, even if you are not using NAT,
I'm afraid.

If not and we only have to have information on which
port is used by which customer, static port mapping
is just fine.

Anyway, developers of virus software will be quite
cooperative to use REUSEPORT, to hide symptoms that
the virus software is installed.

> The key to a low cost service is making it as low cost as possible,
> moving the NAT inside the carrier will had a huge amount of headache and
> support costs, not what you want.

Use NAT with static port mapping (and same port numbers are used
in and out), there is no headache and support cost caused by NAT.

> A possibly relevant question with IPv4 exhaustion coming is could you
> make this service IPv6 only so you don't have to find IPv4 addresses for
> it.

IPv6 means considerably more amount of headache and
support costs than using NAT cleverly and simply.

						Masataka Ohta


From lstewart at superb.net  Fri Feb 10 18:24:11 2012
From: lstewart at superb.net (Landon Stewart)
Date: Fri, 10 Feb 2012 16:24:11 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
Message-ID: <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>

On 10 February 2012 16:09, Brandon Butterworth <brandon at rd.bbc.co.uk> wrote:

> > So it's necessary to throw the baby out with the bathwater, and tell them
> > never to click on a link...
>
> That baby was ugly anyway
>
>
HAHAHA.

My $0.02 on this issue is if the message is rich text I hover over the link
and see where it actually sends me.  If I don't know what that link is then
I don't click it.  Not sure how long it's going to take, probably a
generation, for people to use some sense before mindlessly clicking on
stuff.

Banks and businesses that keep sensitive information in a protected area on
the web for you should start sending messages in PLAIN TEXT so you have to
copy/paste the link if you don't already have it book marked or don't want
to type it.  Sure it's not all flashy and there's no nice pictures and junk
but if you get an email from your bank that's not in plain text and
contains hyperlinks then you'll know it's fake before you even read it.

---
Landon Stewart <lstewart at superb.net <mailto"LStewart at Superb.Net>>
Manager of Systems and Engineering
Superb Internet Corp - 888-354-6128 x 4199
Web hosting and more "Ahead of the Rest": www.superb.net

From randy at psg.com  Fri Feb 10 18:45:34 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 10 Feb 2012 16:45:34 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
Message-ID: <m27gzu9p01.wl%randy@psg.com>

> My $0.02 on this issue is if the message is rich text I hover over the link
> and see where it actually sends me.

idn has made this unsafe

randy


From bicknell at ufp.org  Fri Feb 10 19:00:36 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Feb 2012 17:00:36 -0800
Subject: couple of questions regarding 'lifeline' and large scale nat...
In-Reply-To: <4F35B422.1020403@necom830.hpcl.titech.ac.jp>
References: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
 <20120210214341.GB88812@ussenterprise.ufp.org>
 <4F35B422.1020403@necom830.hpcl.titech.ac.jp>
Message-ID: <20120211010036.GA95294@ussenterprise.ufp.org>

In a message written on Sat, Feb 11, 2012 at 09:19:46AM +0900, Masataka Ohta wrote:
> The applications can simply be debugged to use socket option
> of REUSEPORT.

"Simple" is subjective.  Keep in mind many users will have a home
gateway which also does NAT.  And indeed double NAT in the home (router
doing NAT, third party device doing NAT) is depressingly common.  That
means some of the troubleshooting will be via a triple-NAT if the
carrier is performing the conversion.

> Are you saying we MUST record all the IP addresses and
> port numbers of all peers of your customers to prevent
> illegal things?

If the carrier NAT's, maybe.

Today port information need not be stored, because an IP is assigned
to a customer.  Law enforcement can come request who was using an
IP, and be given the customer information.  It's what everyone has
come to expect.

It's also not just what is legally required, but what is administratively
friendly.  Will the law say you have to track ports with carrier
grade NAT, probably not.  Will law enforcement spend a lot more
time with your staff trying to track down bad people costing you
time and money if you don't, probably.

Large operations tend to find that having a cost effective and staff
time effective way to deal with law enforcement is very important.

> IPv6 means considerably more amount of headache and
> support costs than using NAT cleverly and simply.

When IPv4 addresses are selling for $100 an address that equation
changes quickly.  That day may be only a few months or years off.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/d2b38012/attachment.bin>

From mohta at necom830.hpcl.titech.ac.jp  Fri Feb 10 19:16:36 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 11 Feb 2012 10:16:36 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m27gzu9p01.wl%randy@psg.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
Message-ID: <4F35C174.1090605@necom830.hpcl.titech.ac.jp>

Randy Bush wrote:

>> My $0.02 on this issue is if the message is rich text I hover over the link
>> and see where it actually sends me.
> 
> idn has made this unsafe

I pointed it out at IETF Munich in 1997 that with an example of:

	MICROSOFT.COM

where 'C' of MICROSOFT is actually a Cyrillic character.

But, people insisted working on useless IDN.

						Masataka Ohta


From choprboy at dakotacom.net  Fri Feb 10 19:25:48 2012
From: choprboy at dakotacom.net (Adrian)
Date: Fri, 10 Feb 2012 18:25:48 -0700
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
Message-ID: <201202101825.48610.choprboy@dakotacom.net>

On Friday 10 February 2012 17:24, Landon Stewart wrote:
> My $0.02 on this issue is if the message is rich text I hover over the link
> and see where it actually sends me.  If I don't know what that link is then
> I don't click it.


Oh really? How about trying this.... Go to Google and search "is my url safe":
http://www.google.com/search?q=is+my+url+safe

Now hover over that second link reportedly to faq.ssl.com and look at what 
your browser reports:
http://faq.ssl.com/article.aspx?id=10068

Now look at the page code or copy/paste the URL somewhere else... Where does 
that link really go?
....
http://www.google.com/url?q=http://faq.ssl.com/article.aspx%3Fid%3D10068&sa=U&ei=JcI1T_DRKJDXiAKauoSvCg&ved=0CBgQFjAB&usg=AFQjCNHSmrhtgWQczEe1j0LhdMdUW5x4LA

So much for looking at what mouse-over shows....


Adrian



From joe at nethead.com  Fri Feb 10 19:36:44 2012
From: joe at nethead.com (Joe Hamelin)
Date: Fri, 10 Feb 2012 17:36:44 -0800
Subject: couple of questions regarding 'lifeline' and large scale nat...
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
References: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
Message-ID: <CAO0-hXaeAXKqddyGDhwK662HfWGaknR6BovxJcQehtNb_sq09Q@mail.gmail.com>

On Fri, Feb 10, 2012 at 1:19 PM, Eric J Esslinger <eesslinger at fpu-tn.com>wrote:

> We're toying with the idea of a low bitrate 'lifeline' internet on our
> cable system, maybe even bundled with a certain level of cable service.
>
> First question, if you happen to be doing something like this, what bit
> rates are you providing.
>

Well, a lifeline telephone is effectively 64kb/s, up and down.  Makes me
remember when I had my first ISDN line and was happy to get beyond dial-up
rates.


> Second question, though 'real' internet customers all get real IP's, what
> would you think of doing something like this with 'large scale' nat
> instead. Understand, we're only talking about basic internet, something
> like a 256k/96k (or similar) connect, not something that would be used by a
> serious user. (One thing we are looking at is some older dial up users we
> still have, most of which could go onto cable just fine but don't want to
> pay the price).
>

Force SMTP to something sane, block all the 139, etc. MS ports.  Basic web,
telnet, and ssh.  Set it up like a coffee house.  Use a proxy and make them
register.  It's not like they are chatting 911, ya know.  If they have NAT
issues, then they need a real account.  If they can get to google,
wikimedia, or what ever a high school student needs to research papers,
then they have what they need for a life-line.  Let chat protocols through,
that's low bandwidth.  I'm guessing that this is done as a favor to the
customer that won't/can't pay for a real account.  But let them know it's
not a real account.  This is just to give them a taste of real IP and not a
solution to all their problems.  Shove them a NATted DHCP address and if
they can't figure that out then refer them to the local wizkid or a better
plan with support.  Let them know up front that this is a basic service and
don't expect phone support.  If you're a cable company then they can call
and say the cable is out.

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

From Valdis.Kletnieks at vt.edu  Fri Feb 10 20:41:41 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 10 Feb 2012 21:41:41 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Fri, 10 Feb 2012 16:24:11 PST."
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
Message-ID: <136898.1328928101@turing-police.cc.vt.edu>

On Fri, 10 Feb 2012 16:24:11 PST, Landon Stewart said:
> I don't click it.  Not sure how long it's going to take, probably a
> generation, for people to use some sense before mindlessly clicking on
> stuff.

Only if you find a way to keep more idiots from being born. :)

I don't think anybody wants to go there.  At least not on this list.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/7fb5c008/attachment.bin>

From Vinny_Abello at Dell.com  Fri Feb 10 22:47:42 2012
From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com)
Date: Sat, 11 Feb 2012 04:47:42 +0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
Message-ID: <FD9B2CB2B33E394FAE3B74669547605712B0059E@DFWX10HMPTC01.AMER.DELL.COM>

Unfortunately that's not under control of those businesses. This plain text email you sent comes across with clickable mailto and http links in your signature in most modern email clients despite you having sent it in plain text. "Helpful" email program defaults won't force people to copy and paste the URL. They just create the hyperlink for people based on the pattern in the plain text message. It seems anything beginning with www or http(s):// will be converted to a clickable link out of convenience to the user. It's always that endless struggle of security vs. convenience...

-Vinny

-----Original Message-----
From: Landon Stewart [mailto:lstewart at superb.net] 
Sent: Friday, February 10, 2012 7:24 PM
To: Brandon Butterworth
Cc: nanog at nanog.org
Subject: Re: Dear RIPE: Please don't encourage phishing

On 10 February 2012 16:09, Brandon Butterworth <brandon at rd.bbc.co.uk> wrote:

> > So it's necessary to throw the baby out with the bathwater, and tell them
> > never to click on a link...
>
> That baby was ugly anyway
>
>
HAHAHA.

My $0.02 on this issue is if the message is rich text I hover over the link
and see where it actually sends me.  If I don't know what that link is then
I don't click it.  Not sure how long it's going to take, probably a
generation, for people to use some sense before mindlessly clicking on
stuff.

Banks and businesses that keep sensitive information in a protected area on
the web for you should start sending messages in PLAIN TEXT so you have to
copy/paste the link if you don't already have it book marked or don't want
to type it.  Sure it's not all flashy and there's no nice pictures and junk
but if you get an email from your bank that's not in plain text and
contains hyperlinks then you'll know it's fake before you even read it.

---
Landon Stewart <lstewart at superb.net <mailto"LStewart at Superb.Net>>
Manager of Systems and Engineering
Superb Internet Corp - 888-354-6128 x 4199
Web hosting and more "Ahead of the Rest": www.superb.net


From carlos at race.com  Sat Feb 11 00:54:29 2012
From: carlos at race.com (Carlos Alcantar)
Date: Sat, 11 Feb 2012 06:54:29 +0000
Subject: couple of questions regarding 'lifeline' and large scale nat...
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
Message-ID: <CB5B4FED.5DB2F%carlos@race.com>

You might also want to think about it's not to far off that the gov starts
supplementing those cost of these users, with all the changes being made
in USF.  Possible why comcast has started taking on these users to get a
good head count.  Does anyone know with these low end comcast package does
the user still need to pay the $5 modem rental fee?

Carlos Alcantar
Race Communications / Race Team Member
101 Haskins Way, So. San Francisco, CA. 94080
Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com





-----Original Message-----
From: Eric J Esslinger <eesslinger at fpu-tn.com>
Date: Fri, 10 Feb 2012 15:19:24 -0600
To: "nanog at nanog.org" <nanog at nanog.org>
Subject: couple of questions regarding 'lifeline' and large scale nat...

We're toying with the idea of a low bitrate 'lifeline' internet on our
cable system, maybe even bundled with a certain level of cable service.

First question, if you happen to be doing something like this, what bit
rates are you providing.
Second question, though 'real' internet customers all get real IP's, what
would you think of doing something like this with 'large scale' nat
instead. Understand, we're only talking about basic internet, something
like a 256k/96k (or similar) connect, not something that would be used by
a serious user. (One thing we are looking at is some older dial up users
we still have, most of which could go onto cable just fine but don't want
to pay the price).

Also when I say large scale, I doubt I'd have more than a few thousand
customers for this. We're not a large ISP/cable company by any means.

__________________________
Eric Esslinger
Information Services Manager - Fayetteville Public Utilities
http://www.fpu-tn.com/
(931)433-1522 ext 165

This message may contain confidential and/or proprietary information and
is intended for the person/entity to whom it was originally addressed. Any
use by others is strictly prohibited.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5571 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120211/c7d34b28/attachment-0001.bin>

From mohta at necom830.hpcl.titech.ac.jp  Sat Feb 11 02:19:57 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 11 Feb 2012 17:19:57 +0900
Subject: couple of questions regarding 'lifeline' and large scale nat...
In-Reply-To: <20120211010036.GA95294@ussenterprise.ufp.org>
References: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
 <20120210214341.GB88812@ussenterprise.ufp.org>
 <4F35B422.1020403@necom830.hpcl.titech.ac.jp>
 <20120211010036.GA95294@ussenterprise.ufp.org>
Message-ID: <4F3624AD.9080805@necom830.hpcl.titech.ac.jp>

Leo Bicknell wrote:

>> The applications can simply be debugged to use socket option
>> of REUSEPORT.
> 
> "Simple" is subjective. 

To "the problems of some applications that make thousands of
TCP connections in a short order eating up ports makes it a
nightmare to manage and debug", I gave you an objectively
simple answer.

> Keep in mind many users will have a home
> gateway which also does NAT.  And indeed double NAT in the home (router
> doing NAT, third party device doing NAT) is depressingly common.

Double NAT does not make things worse, as long as "static
bypasses" exist, which is your assumption.

OTOH, the double NAT, some of which may or may not IPv6 capable,
makes IPv6 deployment hard, if not impossible.

> That
> means some of the troubleshooting will be via a triple-NAT if the
> carrier is performing the conversion.

The carrier should have a trouble shooting equipment within
its private network, which means trouble shooting over
the double NAT with IPv4 is much easier than with IPv6.

>> Are you saying we MUST record all the IP addresses and
>> port numbers of all peers of your customers to prevent
>> illegal things?
> 
> If the carrier NAT's, maybe.

> Today port information need not be stored, because an IP is assigned
> to a customer.

Wrong.

With your requirement to record IP address of peers, a carrier
must record port numbers of peers of its customer, if some
carriers of the peers use NAT.

Note that there already are carriers who use NAT.

Note also that, recording peers' IPv4 address needs 4Bs,
recording peers' IPv4 addresses and port numbers needs 6Bs
and recording peers' IPv6 addresses needs 16Bs.

> Law enforcement can come request who was using an
> IP, and be given the customer information.  It's what everyone has
> come to expect.

That's completely different from recording information of peers
of your customer.

> Large operations tend to find that having a cost effective and staff
> time effective way to deal with law enforcement is very important.

True. And, see the double NAT example you mentioned.

>> IPv6 means considerably more amount of headache and
>> support costs than using NAT cleverly and simply.
> 
> When IPv4 addresses are selling for $100 an address that equation
> changes quickly.  That day may be only a few months or years off.

Sorry, are you seriously saying that paying $100 once for a
customer is so much expense for a carrier?

Even if so, the carrier should deploy NAT, because $100 is
paid only once for hundreds of customers.

Moreover, wide deployment of NAT will further reduce prices
of IPv4 addresses.


						Masataka Ohta


From sh.vahabzadeh at gmail.com  Sat Feb 11 04:09:16 2012
From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh)
Date: Sat, 11 Feb 2012 13:39:16 +0330
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <CAJNg7VJBtM_bNOto0gsZzxMNjbUNSXFOhqACxoZAaVb+-asYCQ@mail.gmail.com>
References: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
 <D4CC1941-285F-46E6-BC5B-E426A6BB7657@gmail.com>
 <CAJNg7VJBtM_bNOto0gsZzxMNjbUNSXFOhqACxoZAaVb+-asYCQ@mail.gmail.com>
Message-ID: <0C2F9F90-97C9-4425-A5F0-E69ED3B78298@gmail.com>

It is not accessible to with XMPP, yahoo google none of them is not accessible from Iran.
I have not try obfsproxy but as a ordinary connection we do not have https :)

--
Regards,
Shahab Vahabzadeh, Network Engineer and System Administrator

PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81  C2EE 76A2 46C2 5367 BF90

On Feb 10, 2012, at 11:37 PM, Marshall Eubanks <marshall.eubanks at gmail.com> wrote:

> And in response
> 
> http://www.forbes.com/sites/andygreenberg/2012/02/10/as-iran-cracks-down-online-tor-tests-undetectable-encrypted-connections/
> 
> (quoting) :
> 
> ?Basically, say you want to look like an XMPP chat instead of SSL,? he
> writes to me, referring to a protocol for instant messaging as the
> decoy for the encrypted SSL communications. ?Obfsproxy should start
> up, you choose XMPP, and obfsproxy should emulate XMPP to the point
> where even a sophisticated [deep packet inspection] device cannot find
> anything suspicious.?
> 
> Regards
> Marshall
> 
> On Fri, Feb 10, 2012 at 2:03 PM, Shahab Vahabzadeh
> <sh.vahabzadeh at gmail.com> wrote:
>> Yes I am from Iran and outgoing TCP/443 has been stoped ;)
>> 
>> --
>> Regards,
>> Shahab Vahabzadeh, Network Engineer and System Administrator
>> 
>> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81  C2EE 76A2 46C2 5367 BF90
>> 
>> On Feb 10, 2012, at 9:56 PM, Ryan Malayter <malayter at gmail.com> wrote:
>> 
>>> Haven't seen this come through on NANOG yet:
>>> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
>>> 
>>> Can anyone with the ability confirm that TCP/443 traffic from Iran has
>>> stopped?
>>> 
>> 


From neil at tonal.clara.co.uk  Sat Feb 11 10:04:02 2012
From: neil at tonal.clara.co.uk (Neil Harris)
Date: Sat, 11 Feb 2012 16:04:02 +0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
Message-ID: <4F369172.501@tonal.clara.co.uk>

On 11/02/12 01:16, Masataka Ohta wrote:
> Randy Bush wrote:
>
>>> My $0.02 on this issue is if the message is rich text I hover over the link
>>> and see where it actually sends me.
>> idn has made this unsafe
> I pointed it out at IETF Munich in 1997 that with an example of:
>
> 	MICROSOFT.COM
>
> where 'C' of MICROSOFT is actually a Cyrillic character.
>
> But, people insisted working on useless IDN.
>
> 						Masataka Ohta
>
>


Techniques to deal with this sort of spoofing already exist: see

http://www.mozilla.org/projects/security/tld-idn-policy-list.html

for one quite effective approach.

-- Neil




From randy at psg.com  Sat Feb 11 11:09:25 2012
From: randy at psg.com (Randy Bush)
Date: Sat, 11 Feb 2012 09:09:25 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F369172.501@tonal.clara.co.uk>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
Message-ID: <m2sjihpa9m.wl%randy@psg.com>

>>>> My $0.02 on this issue is if the message is rich text I hover over the link
>>>> and see where it actually sends me.
>>> idn has made this unsafe
> Techniques to deal with this sort of spoofing already exist: see
> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
> for one quite effective approach.

and grandma is gonna use this?  with internet exploder or safari?

let's try to remember that there are normal human beings on the net
these years (bummer that, eh?), and this list is kind of about serving
them.

randy


From tknchris at gmail.com  Sat Feb 11 11:13:14 2012
From: tknchris at gmail.com (chris)
Date: Sat, 11 Feb 2012 12:13:14 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m2sjihpa9m.wl%randy@psg.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
Message-ID: <CAKnNFz8vf4ue_pvisWHmOkQRWH-pp15ncL08YYBRtUAbowz=OA@mail.gmail.com>

The internet was way cooler before that

chris
On Feb 11, 2012 12:09 PM, "Randy Bush" <randy at psg.com> wrote:

> >>>> My $0.02 on this issue is if the message is rich text I hover over
> the link
> >>>> and see where it actually sends me.
> >>> idn has made this unsafe
> > Techniques to deal with this sort of spoofing already exist: see
> > http://www.mozilla.org/projects/security/tld-idn-policy-list.html
> > for one quite effective approach.
>
> and grandma is gonna use this?  with internet exploder or safari?
>
> let's try to remember that there are normal human beings on the net
> these years (bummer that, eh?), and this list is kind of about serving
> them.
>
> randy
>
>

From javier at kjsl.org  Sat Feb 11 11:18:15 2012
From: javier at kjsl.org (Javier Henderson)
Date: Sat, 11 Feb 2012 12:18:15 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CAKnNFz8vf4ue_pvisWHmOkQRWH-pp15ncL08YYBRtUAbowz=OA@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <CAKnNFz8vf4ue_pvisWHmOkQRWH-pp15ncL08YYBRtUAbowz=OA@mail.gmail.com>
Message-ID: <710F66C0-9A26-4350-AA18-76FD161DB976@kjsl.org>


On Feb 11, 2012, at 12:13 PM, chris wrote:

> The internet was way cooler before that

Yes, and a lot of us could run open relays on our SMTP servers to help each other out, and a full usenet feed fit on a plain ol' 9600 baud link.

But no way I could have at home the kind of bandwidth I can get today for a very reasonable price, and so on.

-jav



From Valdis.Kletnieks at vt.edu  Sat Feb 11 12:28:57 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 11 Feb 2012 13:28:57 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Sat, 11 Feb 2012 09:09:25 PST."
 <m2sjihpa9m.wl%randy@psg.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
Message-ID: <170508.1328984937@turing-police.cc.vt.edu>

On Sat, 11 Feb 2012 09:09:25 PST, Randy Bush said:
> >>>> My $0.02 on this issue is if the message is rich text I hover over the link
> >>>> and see where it actually sends me.
> >>> idn has made this unsafe
> > Techniques to deal with this sort of spoofing already exist: see
> > http://www.mozilla.org/projects/security/tld-idn-policy-list.html
> > for one quite effective approach.

Nice.  Basically, unless the TLD registrar has a public policy that basically says
"We don't allow names with cyrillic C to collide with MICROSOFT", their hostnames
all get displayed as xn--gobbledygook.

(The actual policy for the .UA registrar is more subtle. They *do* in fact
allow "U+0441 Cyrillic Small Letter ES" which is visually a C to us Latin-glyph
users.  However, they require at least one character that's visually unique to
Cyrillic in the domain name.  They also don't allow mixed Cyrillic/Latin
scripts in one domain name).  Or so http://www.hostmaster.ua/idn/
tells me after Google Translate gets done with it. ;)

> and grandma is gonna use this?  with internet exploder or safari?

If the manufacturers of IE and Safari can't come up with a similar policy,
then the people at Mozilla can use "We protect you from malicious names"
as a marketing diffferentiation feature.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120211/851e32f4/attachment.bin>

From kmedcalf at dessus.com  Sat Feb 11 15:37:31 2012
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sat, 11 Feb 2012 14:37:31 -0700
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <FD9B2CB2B33E394FAE3B74669547605712B0059E@DFWX10HMPTC01.AMER.DELL.COM>
Message-ID: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>

> Unfortunately that's not under control of those businesses. This plain text
> email you sent comes across with clickable mailto and http links in your
> signature in most modern email clients despite you having sent it in plain
> text. "Helpful" email program defaults won't force people to copy and paste
> the URL. They just create the hyperlink for people based on the pattern in
> the plain text message. It seems anything beginning with www or http(s)://
> will be converted to a clickable link out of convenience to the user. It's
> always that endless struggle of security vs. convenience...

At least it is what is says, and the effect is precisely the same as if one copied and pasted the link into the browser.

What is truly evil is non text/plain email.  Anyone who permits or assists in the rendering of non-plaintext email deserves whatever befalls them -- and they should not be permitted zero-liability for their stupidity and ignorance.

They end-user is of course entitled to cross-claim against the manufacturer of the defective system or device which rendered the message in a deceptive way (such as Dell and Microsoft in particular).

---
()? ascii ribbon campaign against html e-mail
/\? www.asciiribbon.org





From richard.barnes at gmail.com  Sat Feb 11 15:50:10 2012
From: richard.barnes at gmail.com (Richard Barnes)
Date: Sat, 11 Feb 2012 13:50:10 -0800
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <CAJNg7VJBtM_bNOto0gsZzxMNjbUNSXFOhqACxoZAaVb+-asYCQ@mail.gmail.com>
References: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
 <D4CC1941-285F-46E6-BC5B-E426A6BB7657@gmail.com>
 <CAJNg7VJBtM_bNOto0gsZzxMNjbUNSXFOhqACxoZAaVb+-asYCQ@mail.gmail.com>
Message-ID: <CACB24Ms1afYu-CTXYFw0nQ-yMF2uWvHsKqx9f21gDk5-YY+hiA@mail.gmail.com>

FWIW: A colleague in Iran was able to connect to a server in the US
using HTTPS on a non-standard port (9999).  It appears that the
Iranian government is not blocking TLS/HTTPS per se, but just port
443.  So in principle, if there were just some HTTPS proxies using
non-standard ports, then people would be able to get out.  At least
until (1) the addresses of the proxies become known to the regime, or
(2) they start blocking cross-border TLS altogether.

--Richard



On Fri, Feb 10, 2012 at 12:07 PM, Marshall Eubanks
<marshall.eubanks at gmail.com> wrote:
> And in response
>
> http://www.forbes.com/sites/andygreenberg/2012/02/10/as-iran-cracks-down-online-tor-tests-undetectable-encrypted-connections/
>
> (quoting) :
>
> ?Basically, say you want to look like an XMPP chat instead of SSL,? he
> writes to me, referring to a protocol for instant messaging as the
> decoy for the encrypted SSL communications. ?Obfsproxy should start
> up, you choose XMPP, and obfsproxy should emulate XMPP to the point
> where even a sophisticated [deep packet inspection] device cannot find
> anything suspicious.?
>
> Regards
> Marshall
>
> On Fri, Feb 10, 2012 at 2:03 PM, Shahab Vahabzadeh
> <sh.vahabzadeh at gmail.com> wrote:
>> Yes I am from Iran and outgoing TCP/443 has been stoped ;)
>>
>> --
>> Regards,
>> Shahab Vahabzadeh, Network Engineer and System Administrator
>>
>> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 ?C2EE 76A2 46C2 5367 BF90
>>
>> On Feb 10, 2012, at 9:56 PM, Ryan Malayter <malayter at gmail.com> wrote:
>>
>>> Haven't seen this come through on NANOG yet:
>>> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
>>>
>>> Can anyone with the ability confirm that TCP/443 traffic from Iran has
>>> stopped?
>>>
>>
>


From alan at clegg.com  Sat Feb 11 16:56:52 2012
From: alan at clegg.com (Alan Clegg)
Date: Sat, 11 Feb 2012 17:56:52 -0500
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <CACB24Ms1afYu-CTXYFw0nQ-yMF2uWvHsKqx9f21gDk5-YY+hiA@mail.gmail.com>
References: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
 <D4CC1941-285F-46E6-BC5B-E426A6BB7657@gmail.com>
 <CAJNg7VJBtM_bNOto0gsZzxMNjbUNSXFOhqACxoZAaVb+-asYCQ@mail.gmail.com>
 <CACB24Ms1afYu-CTXYFw0nQ-yMF2uWvHsKqx9f21gDk5-YY+hiA@mail.gmail.com>
Message-ID: <4F36F234.8010106@clegg.com>

On 2/11/2012 4:50 PM, Richard Barnes wrote:
> FWIW: A colleague in Iran was able to connect to a server in the US
> using HTTPS on a non-standard port (9999).  It appears that the
> Iranian government is not blocking TLS/HTTPS per se, but just port
> 443.  So in principle, if there were just some HTTPS proxies using
> non-standard ports, then people would be able to get out.  At least
> until (1) the addresses of the proxies become known to the regime, or
> (2) they start blocking cross-border TLS altogether.

Or applications (and providers) knew how to use SRV records...

AlanC
-- 
alan at clegg.com | 1.919.355.8851

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120211/900bae32/attachment.bin>

From mohta at necom830.hpcl.titech.ac.jp  Sat Feb 11 18:09:22 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sun, 12 Feb 2012 09:09:22 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F369172.501@tonal.clara.co.uk>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
Message-ID: <4F370332.4050709@necom830.hpcl.titech.ac.jp>

Neil Harris wrote:

> Techniques to deal with this sort of spoofing already exist: see
> 
> http://www.mozilla.org/projects/security/tld-idn-policy-list.html

It does not make sense that .COM allows Cyrillic characters:

http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html

i script of a domain name is Cyrillic.

Domain names do not have such property as script.

Is the following domain name:

	CCC.COM

Latin or Cyrillic?

> for one quite effective approach.

The only reasonable thing to do is to disable so called
IDN.

					Masataka Ohta

PS

Isn't it obvious from the page you referred that IDN is
not internationalization but an uncoordinated
collection of poor localizations?


From mysidia at gmail.com  Sat Feb 11 18:10:03 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 11 Feb 2012 18:10:03 -0600
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
Message-ID: <CAAAwwbV-MXyvaXbnvEgdTHTtBf9hsk3SzLBLN46a8z9ed4PSbw@mail.gmail.com>

On Fri, Feb 10, 2012 at 10:56 AM, Steven Bellovin <smb at cs.columbia.edu> wrote:

You know, clickable objects in automated business communications are a
standard practice,
the larger the organization sending the message,  the more complicated
and annoying their standard e-mail template full of HTML eyecandy, the
more clickable links   to improve accessibility,  and  banks among the
worst offenders.
Those encourage phishing,   because  HTML just provides way too many
methods of  faking a URL,  or making a 'button'  or 'link'  go to
somewhere else besides what is suggested by the e-mail text.

All an e-mail user needs to do is click on one unknown link,  to  be
quietly diverted to a fake website,  that will then ask the user to
"change" a password;   it makes no difference whether the e-mail
itself is  about passwords or  a security issue or not.
Convincing the user to "log in" can be done while they are visiting
the fake website.



There are plenty of phishers that rely on convincing users to hit the
'reply' button and divulge sensitive info,  with no  clickable items
in the message  at all.

But this particular item from RIPE here appears to be a plain text message...
text/plain

The message from RIPE is darn benign, and does not really encourage
phishing moreso.
When was the last time you saw a phishing attempt in a  text/plain
e-mail showing the name of  a HTTPS location
on  the real organization's web site ?

If sending out a web address "encourages phishers",  then what are
they supposed to provide to make  sure maintainer users  can easily
and quickly change their password?

RIPEs not encouraging phishing by sending such a message.   MUA
developers who  included   text/html     MIME type support and support
creating clickable objects in a HTML message  have encouraged
convincing phishing  very much so.


What RIPE did there is a perfectly example of what should be done.
Send plain text e-mail with the URL location to review,  no  HTML
doodads.

They have no control of your e-mail client  that for some reason
perhaps turns a plaintext URL into something you can click.

> I received the enclosed note, apparently from RIPE (and the headers check out).
> Why are you sending messages with clickable objects that I'm supposed to use to
> change my password?
>


--
-JH


From mohta at necom830.hpcl.titech.ac.jp  Sat Feb 11 19:25:53 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sun, 12 Feb 2012 10:25:53 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <170508.1328984937@turing-police.cc.vt.edu>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
Message-ID: <4F371521.7090809@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks at vt.edu wrote:

> (The actual policy for the .UA registrar is more subtle. They *do* in fact
> allow "U+0441 Cyrillic Small Letter ES" which is visually a C to us Latin-glyph
> users.  However, they require at least one character that's visually unique to
> Cyrillic in the domain name.

Unique within what?

Is a Cyrillic character, which looks like Latin E with diaeresis,
a unique Cyrillic character?

Is "CYRILLIC CAPITAL LETTER GHE", which looks like Greek Gamma,
a unique Cyrillic character?

Is Greek Gamma, which looks like "CYRILLIC CAPITAL LETTER GHE",
a unique Greek character?

> They also don't allow mixed Cyrillic/Latin
> scripts in one domain name).

Is a Russian word containing no unique (unique to ASCII)
Cyrillic characters encoded as Latin character using ASCII,
even though a Russian word containing unique (whatever unique
means) Cyrillic character encoded as Cyrillic characters?

It is obvious that such confused scheme encourage phishing
a lot.

> If the manufacturers of IE and Safari can't come up with a similar policy,
> then the people at Mozilla can use "We protect you from malicious names"
> as a marketing diffferentiation feature.

The only protection is to disable IDN.

					Masataka Ohta


From johnl at iecc.com  Sat Feb 11 19:31:18 2012
From: johnl at iecc.com (John Levine)
Date: 12 Feb 2012 01:31:18 -0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <170508.1328984937@turing-police.cc.vt.edu>
Message-ID: <20120212013118.28066.qmail@joyce.lan>

>Nice.  Basically, unless the TLD registrar has a public policy that basically says
>"We don't allow names with cyrillic C to collide with MICROSOFT", their hostnames
>all get displayed as xn--gobbledygook.

More or less.  ICANN has been wrestling with the lookalike character
issue in domain names for about a decade.  I think it's fair to say
that everyone agrees that all solutions are less than totally
satisfactory.

R's,
John


From neil at tonal.clara.co.uk  Sat Feb 11 19:34:17 2012
From: neil at tonal.clara.co.uk (Neil Harris)
Date: Sun, 12 Feb 2012 01:34:17 +0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F370332.4050709@necom830.hpcl.titech.ac.jp>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
 <4F370332.4050709@necom830.hpcl.titech.ac.jp>
Message-ID: <4F371719.9030207@tonal.clara.co.uk>

On 12/02/12 00:09, Masataka Ohta wrote:
> Neil Harris wrote:
>
>> Techniques to deal with this sort of spoofing already exist: see
>>
>> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
> It does not make sense that .COM allows Cyrillic characters:
>
> http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html
>
> i script of a domain name is Cyrillic.
>
> Domain names do not have such property as script.
>
> Is the following domain name:
>
> 	CCC.COM
>
> Latin or Cyrillic?
>
>> for one quite effective approach.
> The only reasonable thing to do is to disable so called
> IDN.
>
> 					Masataka Ohta
>
> PS
>
> Isn't it obvious from the page you referred that IDN is
> not internationalization but an uncoordinated
> collection of poor localizations?
>

I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN
safer, given that it already exists.

Lots of people have thought about this quite carefully. See RFC 4290 for
a technical discussion of the thinking behind this policy, and RFC 5992
for a policy mechanism designed to resolve the problem you raised in
your example above.

You will notice that the .com domain does not appear on the Mozilla IDN
whitelist.

-- N.





From sven at cb3rob.net  Sat Feb 11 21:34:58 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Sun, 12 Feb 2012 03:34:58 +0000 (UTC)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F371719.9030207@tonal.clara.co.uk>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <4F370332.4050709@necom830.hpcl.titech.ac.jp>
 <4F371719.9030207@tonal.clara.co.uk>
Message-ID: <Pine.LNX.4.64.1202120332570.10731@a84-22-97-10.cb3rob.net>

yes, domain names that cannot be typed in with any keyboard/charset on any 
computer out there, excellent idea, devide and conquerer, i wonder who 
came up with that idiotic plan again, probably the ITU or one of their 
infiltrants in icann.

how about, we simply don't code any software or adjust any platforms to 
support it, if nobody uses it, no problem :P

(or just deliberately break it as its nothing more than a "devide and 
conquerer" attempt of the UN anyway ;)

On Sun, 12 Feb 2012, Neil Harris wrote:

> On 12/02/12 00:09, Masataka Ohta wrote:
>> Neil Harris wrote:
>>
>>> Techniques to deal with this sort of spoofing already exist: see
>>>
>>> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
>> It does not make sense that .COM allows Cyrillic characters:
>>
>> http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html
>>
>> i script of a domain name is Cyrillic.
>>
>> Domain names do not have such property as script.
>>
>> Is the following domain name:
>>
>> 	CCC.COM
>>
>> Latin or Cyrillic?
>>
>>> for one quite effective approach.
>> The only reasonable thing to do is to disable so called
>> IDN.
>>
>> 					Masataka Ohta
>>
>> PS
>>
>> Isn't it obvious from the page you referred that IDN is
>> not internationalization but an uncoordinated
>> collection of poor localizations?
>>
>
> I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN
> safer, given that it already exists.
>
> Lots of people have thought about this quite carefully. See RFC 4290 for
> a technical discussion of the thinking behind this policy, and RFC 5992
> for a policy mechanism designed to resolve the problem you raised in
> your example above.
>
> You will notice that the .com domain does not appear on the Mozilla IDN
> whitelist.
>
> -- N.
>
>
>
>


From sven at cb3rob.net  Sat Feb 11 21:47:24 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Sun, 12 Feb 2012 03:47:24 +0000 (UTC)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F371719.9030207@tonal.clara.co.uk>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <4F370332.4050709@necom830.hpcl.titech.ac.jp>
 <4F371719.9030207@tonal.clara.co.uk>
Message-ID: <Pine.LNX.4.64.1202120338130.10731@a84-22-97-10.cb3rob.net>

as if it wasn't annoying enough already that some n00bs are using URI's 
with characters you can't type in (and in most cases don't even display 
correctly), icann has a better idea! hostnames you can't type in!

all those struggeling regimes that want to keep local control over our 
internets are gonna be so proud of them :P

(and that despite the fact that it's perfectly well possible to write -any 
language out there- in the first 7 bits of ascii)

yay, a step back in time, everyone back to their cave and write on the 
wall with a piece of stone in characters nobody can read!

so far for progress...

we used to develop stuff so that people could communicate with one 
another, whatever went wrong, when did it move to "preventing people from 
communicating with one another"...

i don't have keyboards with a million or so keys on it, do you?

and no, i don't know the alt-codes for weird russian or japanese crap.

if we wanted local shit only, we could just have stuck with tv and radio 
and telephones and fax machines.

so; we're not implementing any of that, we'll deliberately make any 
software we produce go nuts on it and cause errors all over the place, and 
we strongly urge any nerd out there to do exactly the same.


On Sun, 12 Feb 2012, Neil Harris wrote:

> On 12/02/12 00:09, Masataka Ohta wrote:
>> Neil Harris wrote:
>>
>>> Techniques to deal with this sort of spoofing already exist: see
>>>
>>> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
>> It does not make sense that .COM allows Cyrillic characters:
>>
>> http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html
>>
>> i script of a domain name is Cyrillic.
>>
>> Domain names do not have such property as script.
>>
>> Is the following domain name:
>>
>> 	CCC.COM
>>
>> Latin or Cyrillic?
>>
>>> for one quite effective approach.
>> The only reasonable thing to do is to disable so called
>> IDN.
>>
>> 					Masataka Ohta
>>
>> PS
>>
>> Isn't it obvious from the page you referred that IDN is
>> not internationalization but an uncoordinated
>> collection of poor localizations?
>>
>
> I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN
> safer, given that it already exists.
>
> Lots of people have thought about this quite carefully. See RFC 4290 for
> a technical discussion of the thinking behind this policy, and RFC 5992
> for a policy mechanism designed to resolve the problem you raised in
> your example above.
>
> You will notice that the .com domain does not appear on the Mozilla IDN
> whitelist.
>
> -- N.
>
>
>
>


From Valdis.Kletnieks at vt.edu  Sat Feb 11 22:39:48 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 11 Feb 2012 23:39:48 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Sun, 12 Feb 2012 03:47:24 GMT."
 <Pine.LNX.4.64.1202120338130.10731@a84-22-97-10.cb3rob.net>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
 <4F370332.4050709@necom830.hpcl.titech.ac.jp>
 <4F371719.9030207@tonal.clara.co.uk>
 <Pine.LNX.4.64.1202120338130.10731@a84-22-97-10.cb3rob.net>
Message-ID: <191698.1329021588@turing-police.cc.vt.edu>

On Sun, 12 Feb 2012 03:47:24 GMT, Sven Olaf Kamphuis said:

> (and that despite the fact that it's perfectly well possible to write -any
> language out there- in the first 7 bits of ascii)

And it's *equally* possible to write "any language out there" using a
7-bit encoding of the Cyrillic character set.

Let me know how you'd enjoy doing that.

Oh, that would suck because Cyrillic isn't very similar to your native
character set?  Welcome to the way the vast majority of the world feels.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120211/5ec17531/attachment-0001.bin>

From mohta at necom830.hpcl.titech.ac.jp  Sat Feb 11 23:07:26 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sun, 12 Feb 2012 14:07:26 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F371719.9030207@tonal.clara.co.uk>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
 <4F370332.4050709@necom830.hpcl.titech.ac.jp>
 <4F371719.9030207@tonal.clara.co.uk>
Message-ID: <4F37490E.2000604@necom830.hpcl.titech.ac.jp>

Neil Harris wrote:

> I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN
> safer, given that it already exists.

It's like trying to make DES safer.

> Lots of people have thought about this quite carefully.

Not at all. They (including some Japanese) just wished IDN
work ignoring technical reality.

> See RFC 4290 for
> a technical discussion of the thinking behind this policy,

Technically speaking, there are several sets of frequently
used different but similar Japanese characters most people
do not distinguish so vigorously.

For example, "Sai" of "Saitoh", the tenth most frequent
Japanese family name, is represented by 4 similar but
different characters, which is distinguished by people
named "Saitoh" but not distinguished by most others,
which means phishing is unavoidable.

That is, RFC4290 covering such Japanese characters is
not technical from the beginning.

> and RFC 5992
> for a policy mechanism designed to resolve the problem you raised in
> your example above.

It is nothing more than a political statement, because
there is no reasonable way to use tables in Appendix A.

> You will notice that the .com domain does not appear on the Mozilla IDN
> whitelist.

Which means IDN can not be "Internationalized" at all and
selling IDN is nothing more than a fraud.

					Masataka Ohta


From Valdis.Kletnieks at vt.edu  Sat Feb 11 23:13:27 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 12 Feb 2012 00:13:27 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Sun, 12 Feb 2012 10:25:53 +0900."
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
Message-ID: <192978.1329023607@turing-police.cc.vt.edu>

On Sun, 12 Feb 2012 10:25:53 +0900, Masataka Ohta said:
> Valdis.Kletnieks at vt.edu wrote:
>
> > (The actual policy for the .UA registrar is more subtle. They *do* in fact
> > allow "U+0441 Cyrillic Small Letter ES" which is visually a C to us Latin-glyph
> > users.  However, they require at least one character that's visually unique to
> > Cyrillic in the domain name.
>
> Unique within what?
>
> Is a Cyrillic character, which looks like Latin E with diaeresis,
> a unique Cyrillic character?
>
> Is "CYRILLIC CAPITAL LETTER GHE", which looks like Greek Gamma,
> a unique Cyrillic character?
>
> Is Greek Gamma, which looks like "CYRILLIC CAPITAL LETTER GHE",
> a unique Greek character?

Doesn't actually matter, because the .ua registry isn't allowing Greek Gamma
or Latin-E-with-diaresis, in domain names.  So you can't find a domain
bankname-containing-ghe.ua and spoof it with bankname-containing-gamma.ua.

I suppose you *could* find a 'greek-bankame-containing-gamma-and-only-chars-spoofable-in-cyrillic.gr'
and create a 'bankname-containing-ghe-and-cyrillic.ua'.  But quite frankly,
turning off IDN doesn't fix that problem - greekbank.gr is spoofable
by greekbank.ua and greekbank.com.  We *already* have companies
that will register 'foobar.com', 'foobar.net', 'foobar.org' and every other variant
they can to prevent squatters in the other TLDs.

> > They also don't allow mixed Cyrillic/Latin
> > scripts in one domain name).
>
> Is a Russian word containing no unique (unique to ASCII)
> Cyrillic characters encoded as Latin character using ASCII,
> even though a Russian word containing unique (whatever unique
> means) Cyrillic character encoded as Cyrillic characters?

No, it means you get to pick 'all-latin-chars.ua' or 'all-cyrillic-chars.ua'.
And due to the requirement that a cyrillic name have a special char
in it, you can's spoof an all-latin-chars.ua name.

> The only protection is to disable IDN.

You also have to ban the use of numbers in domain names, because you
need to prevent people being tricked by micros0ft.com and m1crosoft.com.

Good luck on that.

Oh, and 'i' and 'l' need to be banned as well, because a san-serif uppercase I
looks a lot like a san-serif lowercase l. (In fact, in the font I'm currently using,
the two are pixel-identical).

I don't see anybody calling for the banning of 'i' and 'l' in domain names due to that.

It's interesting how some people are insisting that the IDN code has to be
*perfect* and make it *totally* impossible to create a phishable spoof of
a domain - but aren't willing to take the extra step of banning the characters
in the Latin Ascii charset that are spoofable.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120212/bf03e128/attachment.bin>

From mohta at necom830.hpcl.titech.ac.jp  Sat Feb 11 23:25:05 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sun, 12 Feb 2012 14:25:05 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <191698.1329021588@turing-police.cc.vt.edu>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
 <4F370332.4050709@necom830.hpcl.titech.ac.jp>
 <4F371719.9030207@tonal.clara.co.uk>
 <Pine.LNX.4.64.1202120338130.10731@a84-22-97-10.cb3rob.net>
 <191698.1329021588@turing-police.cc.vt.edu>
Message-ID: <4F374D31.7070508@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks at vt.edu wrote:

>> (and that despite the fact that it's perfectly well possible to write -any
>> language out there- in the first 7 bits of ascii)

Yes, any language including FORTRAN.

> And it's *equally* possible to write "any language out there" using a
> 7-bit encoding of the Cyrillic character set.

Yes, any language including FORTRAN, because KOI-7, a
7-bit encoding of the Cyrillic character set, includes
all the uppercase Latin characters.

> Oh, that would suck because Cyrillic isn't very similar to your native
> character set?  Welcome to the way the vast majority of the world feels.

See how the vast majority of the world feels.

http://en.wikipedia.org/wiki/ISO/IEC_646
Since the portion of ISO/IEC 646 shared by all countries
(the "invariant set") specified only those letters used
in the ISO basic Latin alphabet,

						Masataka Ohta


From mysidia at gmail.com  Sat Feb 11 23:45:08 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 11 Feb 2012 23:45:08 -0600
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <192978.1329023607@turing-police.cc.vt.edu>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
Message-ID: <CAAAwwbV955qaaW7WisHf09GuxYVsw5dj8qXeHS16VXvpfVg-AA@mail.gmail.com>

On Sat, Feb 11, 2012 at 11:13 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Sun, 12 Feb 2012 10:25:53 +0900, Masataka Ohta said:
>> Valdis.Kletnieks at vt.edu wrote:
> It's interesting how some people are insisting that the IDN code has to be
> *perfect* and make it *totally* impossible to create a phishable spoof of
> a domain - but aren't willing to take the extra step of banning the characters
> in the Latin Ascii charset that are spoofable.
[snip]

There aren't really any characters in the latin ASCII charset that are
so spoofable.
0 and O,   |, I, l,  and 1  do come close,  depending on the font
chosen.     This is easily avoidable, because there are so few
spoofable characters,  you can easily just avoid using a spoofable one
in your domain name,   or register all variants.  These are minor
compared to the issues you get expanding the possible URL  character
sets to all unicode, through IDN support.

The extended character sets available under IDN provide a large number
of spoofable characters from various different charsets that are
indistinguishable.


For phishing to not be a serious risk, IDN implementations have to
have some kind of security policy.

A start would be: don't display IDN characters,   unless   they are
within a character set the user is expected to be familiar with.   For
example,  for a web browser that ships in North America,  only the
locally relevant IDN character sets should be enabled  by default.

If you should want to see IDN characters from Cyrillic character sets,
 or  Chinese Ideographs,
there should be a requirement you very deliberately install support
for specific character set you need.


Or install a localized browser that has the specific IDN charsets
allowed by policy.
There should also be a browser-enforced policy that different charsets
cannot be mixed in the same domain name.

Then any increase in phishing risk is limited to regions / language
localized  browsers
where the character set with spoofable characters makes sense  and is
in common use.


Ideally there  should be a table of every pair of characters that
"look somewhat similar to each other"   in every character set,   and
every registrar  ensuring  appearance uniqueness for every  new domain
registration.


--
-JH


From joelja at bogus.com  Sun Feb 12 00:57:36 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Sat, 11 Feb 2012 22:57:36 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <Pine.LNX.4.64.1202120332570.10731@a84-22-97-10.cb3rob.net>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
 <4F370332.4050709@necom830.hpcl.titech.ac.jp>
 <4F371719.9030207@tonal.clara.co.uk>
 <Pine.LNX.4.64.1202120332570.10731@a84-22-97-10.cb3rob.net>
Message-ID: <4F3762E0.7050909@bogus.com>

On 2/11/12 19:34 , Sven Olaf Kamphuis wrote:
> yes, domain names that cannot be typed in with any keyboard/charset on
> any computer out there, excellent idea, devide and conquerer, i wonder
> who came up with that idiotic plan again, probably the ITU or one of
> their infiltrants in icann.

If it's worth shoveling blame indiscriminately it's worth informing
yourself a little about the timeline and the actors involved.

http://en.wikipedia.org/wiki/Internationalized_domain_name

> how about, we simply don't code any software or adjust any platforms to
> support it, if nobody uses it, no problem :P
> 
> (or just deliberately break it as its nothing more than a "devide and
> conquerer" attempt of the UN anyway ;)
> 
> On Sun, 12 Feb 2012, Neil Harris wrote:
> 
>> On 12/02/12 00:09, Masataka Ohta wrote:
>>> Neil Harris wrote:
>>>
>>>> Techniques to deal with this sort of spoofing already exist: see
>>>>
>>>> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
>>> It does not make sense that .COM allows Cyrillic characters:
>>>
>>> http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html
>>>
>>> i script of a domain name is Cyrillic.
>>>
>>> Domain names do not have such property as script.
>>>
>>> Is the following domain name:
>>>
>>>     CCC.COM
>>>
>>> Latin or Cyrillic?
>>>
>>>> for one quite effective approach.
>>> The only reasonable thing to do is to disable so called
>>> IDN.
>>>
>>>                     Masataka Ohta
>>>
>>> PS
>>>
>>> Isn't it obvious from the page you referred that IDN is
>>> not internationalization but an uncoordinated
>>> collection of poor localizations?
>>>
>>
>> I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN
>> safer, given that it already exists.
>>
>> Lots of people have thought about this quite carefully. See RFC 4290 for
>> a technical discussion of the thinking behind this policy, and RFC 5992
>> for a policy mechanism designed to resolve the problem you raised in
>> your example above.
>>
>> You will notice that the .com domain does not appear on the Mozilla IDN
>> whitelist.
>>
>> -- N.
>>
>>
>>
>>
> 



From drc at virtualized.org  Sun Feb 12 01:16:16 2012
From: drc at virtualized.org (David Conrad)
Date: Sat, 11 Feb 2012 23:16:16 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F3762E0.7050909@bogus.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
 <4F370332.4050709@necom830.hpcl.titech.ac.jp>
 <4F371719.9030207@tonal.clara.co.uk>
 <Pine.LNX.4.64.1202120332570.10731@a84-22-97-10.cb3rob.net>
 <4F3762E0.7050909@bogus.com>
Message-ID: <D032D1F2-9696-4FE6-9E48-95A9B6925392@virtualized.org>

On Feb 11, 2012, at 10:57 PM, Joel jaeggli wrote:
> On 2/11/12 19:34 , Sven Olaf Kamphuis wrote:
>> yes, domain names that cannot be typed in with any keyboard/charset on
>> any computer out there, excellent idea, devide and conquerer, i wonder
>> who came up with that idiotic plan again, probably the ITU or one of
>> their infiltrants in icann.
> 
> If it's worth shoveling blame indiscriminately it's worth informing
> yourself a little about the timeline and the actors involved.
> 
> http://en.wikipedia.org/wiki/Internationalized_domain_name

You mean he's serious?  I thought he was just being an ironic troll...

Regards,
-drc




From mohta at necom830.hpcl.titech.ac.jp  Sun Feb 12 01:59:36 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sun, 12 Feb 2012 16:59:36 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <192978.1329023607@turing-police.cc.vt.edu>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
Message-ID: <4F377168.9040903@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks at vt.edu wrote:

> Doesn't actually matter, because the .ua registry isn't allowing Greek Gamma
> or Latin-E-with-diaresis, in domain names.

Such local conventions have nothing to do with internationalization.

> But quite frankly,
> turning off IDN doesn't fix that problem - greekbank.gr is spoofable
> by greekbank.ua and greekbank.com.

The problem is greekbank.gr is spoofable as greekbank.gr.

>> Is a Russian word containing no unique (unique to ASCII)
>> Cyrillic characters encoded as Latin character using ASCII,
>> even though a Russian word containing unique (whatever unique
>> means) Cyrillic character encoded as Cyrillic characters?
> 
> No, it means you get to pick 'all-latin-chars.ua' or 'all-cyrillic-chars.ua'.
> And due to the requirement that a cyrillic name have a special char
> in it, you can's spoof an all-latin-chars.ua name.

That "a cyrillic name have a special char in it" makes it
impossible to have a Cyrillic representation of an Ukrainian
word containing no special chars and is impractical.

>> The only protection is to disable IDN.
>
> You also have to ban the use of numbers in domain names, because you
> need to prevent people being tricked by micros0ft.com and m1crosoft.com.

No, the simple solution against such a simple problem is to
use proper font, because all the people know that '0' and 'o'
are different characters and treat them differently.

						Masataka Ohta


From vinny at abellohome.net  Sun Feb 12 03:44:13 2012
From: vinny at abellohome.net (Vinny Abello)
Date: Sun, 12 Feb 2012 04:44:13 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
References: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
Message-ID: <4F3789ED.2030708@abellohome.net>

On 2/11/2012 4:37 PM, Keith Medcalf wrote:
>> Unfortunately that's not under control of those businesses. This
>> plain text email you sent comes across with clickable mailto and
>> http links in your signature in most modern email clients despite
>> you having sent it in plain text. "Helpful" email program
>> defaults won't force people to copy and paste the URL. They just
>> create the hyperlink for people based on the pattern in the plain
>> text message. It seems anything beginning with www or http(s):// 
>> will be converted to a clickable link out of convenience to the
>> user. It's always that endless struggle of security vs.
>> convenience...
> 
> At least it is what is says, and the effect is precisely the same
> as if one copied and pasted the link into the browser.
> 
> What is truly evil is non text/plain email.  Anyone who permits or
> assists in the rendering of non-plaintext email deserves whatever
> befalls them -- and they should not be permitted zero-liability for
> their stupidity and ignorance.
> 
> They end-user is of course entitled to cross-claim against the
> manufacturer of the defective system or device which rendered the
> message in a deceptive way (such as Dell and Microsoft in
> particular).

The average person won't know that "it is what it says" if it's
possible for it not to be... which I think is what you're driving at
with eliminating that as a possibility. And the effect is the same,
but the time to do it is different. I wouldn't want to have to use web
sites with no hyperlinks and I was expected to just copy and paste
every URL I wanted to follow into the address bar.

However, the vast majority of the Internet population (and human
beings in general) like aesthetically pleasing things and therefore
don't want to upgrade to mutt and lynx to be safe on the Internet.
HTML based email looks much better despite embedded hidden <evil>
tags. All recent email clients I've come across give you anti-phishing
warnings in one way or another if the URL does not match the actual
link. I honestly can't remember the last time I've seen a phishing
email because they are so easy to detect before they even get to your
inbox. Sure, you could also keep the HTML and disable the links (which
I've seen done), but then you inconvenience people. Things take too
long as it is now anyway despite the constant advancements we see
constantly. We need to speed technology up more and make them easier
AND safer. Technology needs to be unobtrusive to the end user and get
out of their way.

I personally don't believe the mantra of stripping away technology to
solve problems rather than applying technology and advancing standards
is the answer just because technology makes something dangerous for
the average consumer. Despite all the car fatalities on a yearly basis
and the constant safety advancements we have in the auto industry, I
have never heard people say we should get rid of cars and go back to
horses. Of course scam emails are much more prevalent than car
fatalities by far, but they're also less serious.

Most of the younger generation I know doesn't even use email. They
have it as a formality because things require it and exchange
everything via Facebook or video chat or IM... which simply means this
concern over the trickery of immoral scammers on the average
unsuspecting person will just shift mediums as has throughout history.
It's already prevalent on these mediums now.

Not sure what the jab at Dell was specifically other than the email
address I posted from originally. As far as I have seen, Dell doesn't
make email clients. That's like someone holding Sony/Samsung/LG liable
because their TV showed them a TV program they didn't want to see.

Anyway, just my $0.02 wrapped in rambling from a tired mind. Sorry if
some of this didn't make sense as a result. :)

-Vinny

P.S. I prefer plain-text email. ;)


From lists at internetpolicyagency.com  Sun Feb 12 09:30:40 2012
From: lists at internetpolicyagency.com (Roland Perry)
Date: Sun, 12 Feb 2012 15:30:40 +0000
Subject: PGP,
 S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage
 phishing)
In-Reply-To: <20120210213755.GA88812@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <4F355803.4040402@unfix.org> <20120210180106.GB80127@ussenterprise.ufp.org>
 <CAP-guGWh4+4kg1Jr1HLpF9voWYdrt9zyx9cRVXyZTL2i83etvw@mail.gmail.com>
 <20120210213755.GA88812@ussenterprise.ufp.org>
Message-ID: <Vw+8ueQgs9NPFAOQ@perry.co.uk>

In article <20120210213755.GA88812 at ussenterprise.ufp.org>, Leo Bicknell 
<bicknell at ufp.org> writes
>Hypothetically, I get an e-mail from ripe.ca

Or from ripen.cc which is one of their actual domains (used briefly as a 
url shortener).
-- 
Roland Perry


From johnl at iecc.com  Sun Feb 12 10:52:01 2012
From: johnl at iecc.com (John Levine)
Date: 12 Feb 2012 16:52:01 -0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
Message-ID: <20120212165201.19594.qmail@joyce.lan>

>What is truly evil is non text/plain email.

Have we fallen through a time warp into 1996?

R's,
John
-- 
Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly


From cdel at firsthand.net  Sun Feb 12 11:23:49 2012
From: cdel at firsthand.net (Christian de Larrinaga)
Date: Sun, 12 Feb 2012 17:23:49 +0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120212013118.28066.qmail@joyce.lan>
References: <20120212013118.28066.qmail@joyce.lan>
Message-ID: <146B95B9-51B5-4E2B-96AF-BEB7FB13FEC1@firsthand.net>

The DNS "industry" is putting us a long way from when RFC 2826 was written. 

Christian
 
On 12 Feb 2012, at 01:31, John Levine wrote:

>> Nice.  Basically, unless the TLD registrar has a public policy that basically says
>> "We don't allow names with cyrillic C to collide with MICROSOFT", their hostnames
>> all get displayed as xn--gobbledygook.
> 
> More or less.  ICANN has been wrestling with the lookalike character
> issue in domain names for about a decade.  I think it's fair to say
> that everyone agrees that all solutions are less than totally
> satisfactory.
> 
> R's,
> John
> 



From johnl at iecc.com  Sun Feb 12 11:40:12 2012
From: johnl at iecc.com (John R. Levine)
Date: 12 Feb 2012 12:40:12 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <146B95B9-51B5-4E2B-96AF-BEB7FB13FEC1@firsthand.net>
References: <20120212013118.28066.qmail@joyce.lan>
 <146B95B9-51B5-4E2B-96AF-BEB7FB13FEC1@firsthand.net>
Message-ID: <alpine.BSF.2.00.1202121238280.21410@joyce.lan>

> The DNS "industry" is putting us a long way from when RFC 2826 was written.

That's true, but you can't just blow off the majority of people in the 
world who use languages that you can't write in the ASCII character set.

It's a hard problem.  I wouldn't say that ICANN's approach has been 
optimal, but I also wouldn't say there's an obvious solution they've 
missed.

Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly


From johnl at iecc.com  Sun Feb 12 12:06:25 2012
From: johnl at iecc.com (John Levine)
Date: 12 Feb 2012 18:06:25 -0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
Message-ID: <20120212180625.22375.qmail@joyce.lan>

>>What is truly evil is non text/plain email.
>
>Have we fallen through a time warp into 1996?

Evidently yes.  Look, it's a known-not-to-work SMTP callback:

><kmedcalf at dessus.com>:
>Connected to 69.172.205.65 but sender was rejected.
>Remote host said: 578 johnl at iecc.com address rejected with reverse-check

-- 
Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly


From rsk at gsp.org  Sun Feb 12 12:19:10 2012
From: rsk at gsp.org (Rich Kulawiec)
Date: Sun, 12 Feb 2012 13:19:10 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F3789ED.2030708@abellohome.net>
References: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
 <4F3789ED.2030708@abellohome.net>
Message-ID: <20120212181910.GA16374@gsp.org>

On Sun, Feb 12, 2012 at 04:44:13AM -0500, Vinny Abello wrote:
> All recent email clients I've come across give you anti-phishing
> warnings in one way or another if the URL does not match the actual link. 

Which is great, but doesn't help you if the URL and the link are:

	http://firstnationalbank.example.com

because a significant number of users will only see "firstnationalbank"
and ".com".

That's why I recommend that banks et.al. don't put *any* URLs in their
messages.  If they make this an explicit policy and pound it into the
heads of their customers that ANY message containing a URL is not from
them, and that they should always use their bookmarks to get to the
bank's site, then they're training their customers to be phish-resistant.

---rsk


From sven at cb3rob.net  Sun Feb 12 13:15:28 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Sun, 12 Feb 2012 19:15:28 +0000 (UTC)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120212181910.GA16374@gsp.org>
References: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
 <4F3789ED.2030708@abellohome.net> <20120212181910.GA16374@gsp.org>
Message-ID: <Pine.LNX.4.64.1202121913310.10731@a84-22-97-10.cb3rob.net>

>
> That's why I recommend that banks et.al. don't put *any* URLs in their
> messages.  If they make this an explicit policy and pound it into the
> heads of their customers that ANY message containing a URL is not from
> them, and that they should always use their bookmarks to get to the
> bank's site, then they're training their customers to be phish-resistant.

they do, and the next thing you know, someone in marketing sends out an 
email with an url -anyway-.

considering the fact that banks don't seem to like to be contacted by 
emails nor get replies (noreply at ...) i'd strongly suggest them not to use 
crappy obsolete SMTP at all but rather present the users with their 
messages they don't want to distribute by paper mail -after- logging into 
their online banking system, where they can use all the html, links, flash 
*kuch* etc they want.

>
> ---rsk
>


From sven at cb3rob.net  Sun Feb 12 13:22:06 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Sun, 12 Feb 2012 19:22:06 +0000 (UTC)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120212181910.GA16374@gsp.org>
References: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
 <4F3789ED.2030708@abellohome.net> <20120212181910.GA16374@gsp.org>
Message-ID: <Pine.LNX.4.64.1202121919390.10731@a84-22-97-10.cb3rob.net>

btw, i'm quite sure that -banks- of all things have the resources to just 
take the transaction part for consumers -off their pcs- and simply send 
them a dedicated device with an ethernet port to do the transactions on.

the same way they do in shops.

no more bothering with "omg what if they click a link, get phished and end 
up in the transaction interface", as there simply won't be a web based 
transaction interface.

guess the "its not allowed to cost anything" mentality of banks towards 
the internet is mostly gone (About time too ;) so they could consider 
other options besides "using the hardware that's allready there and owned 
by the customer (and full of virusses and spyware ;)"

-- 
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=========================================================================
Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
          D-13359                   Registration:    HRA 42834 B
          BERLIN                    Phone:           +31/(0)87-8747479
          Germany                   GSM:             +49/(0)152-26410799
RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
=========================================================================
<penpen> C3P0, der elektrische Westerwelle
http://www.facebook.com/cb3rob
=========================================================================

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Sun, 12 Feb 2012, Rich Kulawiec wrote:

> On Sun, Feb 12, 2012 at 04:44:13AM -0500, Vinny Abello wrote:
>> All recent email clients I've come across give you anti-phishing
>> warnings in one way or another if the URL does not match the actual link.
>
> Which is great, but doesn't help you if the URL and the link are:
>
> 	http://firstnationalbank.example.com
>
> because a significant number of users will only see "firstnationalbank"
> and ".com".
>
> That's why I recommend that banks et.al. don't put *any* URLs in their
> messages.  If they make this an explicit policy and pound it into the
> heads of their customers that ANY message containing a URL is not from
> them, and that they should always use their bookmarks to get to the
> bank's site, then they're training their customers to be phish-resistant.
>
> ---rsk
>


From jeff-kell at utc.edu  Sun Feb 12 13:27:56 2012
From: jeff-kell at utc.edu (Jeff Kell)
Date: Sun, 12 Feb 2012 14:27:56 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <alpine.BSF.2.00.1202121238280.21410@joyce.lan>
References: <20120212013118.28066.qmail@joyce.lan>
 <146B95B9-51B5-4E2B-96AF-BEB7FB13FEC1@firsthand.net>
 <alpine.BSF.2.00.1202121238280.21410@joyce.lan>
Message-ID: <4F3812BC.4030604@utc.edu>

Heck, even Klingon made it to the private UTF-8 registry,
http://en.wikipedia.org/wiki/Klingon_writing_systems

:)

Jeff



From johnl at iecc.com  Sun Feb 12 13:47:56 2012
From: johnl at iecc.com (John Levine)
Date: 12 Feb 2012 19:47:56 -0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <Pine.LNX.4.64.1202121919390.10731@a84-22-97-10.cb3rob.net>
Message-ID: <20120212194756.26077.qmail@joyce.lan>

In article <Pine.LNX.4.64.1202121919390.10731 at a84-22-97-10.cb3rob.net> you write:
>btw, i'm quite sure that -banks- of all things have the resources to just 
>take the transaction part for consumers -off their pcs- and simply send 
>them a dedicated device with an ethernet port to do the transactions on.

More likely USB, but yes, a doozit with a small screen to display the
amount and recipient of a transaction and a verification code you type
in, and sufficient crypto to set up a secure channel back to the bank
would fix a lot of phishing.

I don't understand bank security at all.  HSBC recently sent me a
Digipass 270 with a 12 button keyboard and a one-line display that is
apparently able to do signatures, but all they use it for is a PIN.
That's helpful against password theft, but not MITM.

R's,
John


From vinny at abellohome.net  Sun Feb 12 13:49:12 2012
From: vinny at abellohome.net (Vinny Abello)
Date: Sun, 12 Feb 2012 14:49:12 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120212181910.GA16374@gsp.org>
References: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
 <4F3789ED.2030708@abellohome.net> <20120212181910.GA16374@gsp.org>
Message-ID: <4F3817B8.8050902@abellohome.net>

On 2/12/2012 1:19 PM, Rich Kulawiec wrote:
> On Sun, Feb 12, 2012 at 04:44:13AM -0500, Vinny Abello wrote:
>> All recent email clients I've come across give you anti-phishing 
>> warnings in one way or another if the URL does not match the
>> actual link.
> 
> Which is great, but doesn't help you if the URL and the link are:
> 
> http://firstnationalbank.example.com
> 
> because a significant number of users will only see
> "firstnationalbank" and ".com".
> 
> That's why I recommend that banks et.al. don't put *any* URLs in
> their messages.  If they make this an explicit policy and pound it
> into the heads of their customers that ANY message containing a URL
> is not from them, and that they should always use their bookmarks
> to get to the bank's site, then they're training their customers to
> be phish-resistant.

Yes, very true. I unfortunately see average people fall for these
types of things all the time. Ultimately, the issue is getting the end
user educated. However, I've also seen users get a message drilled
into their heads for 10 years that an email admin will never ask for
their passwords, yet they eagerly give them away to some random
scammer that says they need their password or their account will be
shut off, signed by "the email team"... and suddenly their email
account is spewing spam from random IP addresses all over the net.
<sigh> The weakest link is ultimately the person behind the device.
We're attempting to make technology fix stupid, which is often harder
for the people designing the technology. They would never think
sticking their hand down a garbage disposal is a good idea, but there
are people out there that do this. :( Likewise, a person wouldn't
click on a link if it's blatantly obvious the link doesn't point to
the real web site, right? :) Obviously no. To be very effective,
security design needs to assume the biggest threat to the security of
anything is the person on the good side of the fence who will open the
gate.

Lately, I get calls on a weekly basis from people trying to steal my
credit card from me. If I have time I like to have fun with them,
eating up their time so they have less of it to scam people who don't
know any better. (Look on Youtube for people doing this. It's
hilarious). These scammers have been around for at least 5 years or
longer and nobody has yet fixed this problem, which is also
astounding. As a result, customers who don't recognize the scam get
their credit card whacked with random charges because they didn't
think anything was wrong with giving away their credit card info and
social security number to a random stranger who calls them and claims
to be able to lower their interest rate. So at the same time making
people aware the real emails will not contain links, banks should be
doing a better job telling people not to give away their credit card
info to anyone in a situation similar to this. It should be better
handled by all banks and companies in genereal as a global security
education process. I don't believe it should be limited just to email
or Internet related usage of the bank or company's resources.

I'm probably not giving people enough credit, but social engineering
is likely the most effective hacking technique that exists because it
targets the weakest link and often works. That's currently the easiest
thing to target because security has improved so much over the years
on the technological end. I'm not sure about others, but the most
prevalent security threats I see today are vastly different than the
ones from ten to fifteen years prior.

-Vinny


From Valdis.Kletnieks at vt.edu  Sun Feb 12 13:55:48 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 12 Feb 2012 14:55:48 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Sun, 12 Feb 2012 16:59:36 +0900."
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
Message-ID: <223001.1329076548@turing-police.cc.vt.edu>

On Sun, 12 Feb 2012 16:59:36 +0900, Masataka Ohta said:
> The problem is greekbank.gr is spoofable as greekbank.gr.

That would be the .gr registry's problem then.  They could take the same
solution as the .ua registry -force lowercase and allow all-latin or all-greek
names.

Oh, what do you know... they *do* do something similar.
https://grweb.ics.forth.gr/tomcat_docs/AP592_012_2011_.pdf
See page 5 and 6, in particular:

8. Any [.gr] Domain Names that are homographs of a [.gr] Domain Name
already assigned shall be automatically reserved for the Holder of the
above assigned [.gr] Domain Name and shall be activated following the
Holder's submission of an activation declaration to the Registry.

So how do you spoof greekbank.gr with greekbank.gr under those rules?

> No, the simple solution against such a simple problem is to
> use proper font, because all the people know that '0' and 'o'
> are different characters and treat them differently.

Well then, if all that's required is a "proper font",  what is the problem with
your Saitoh families? You said they were "represented by 4 similar but
different characters, which is distinguished by people named "Saitoh" but not
distinguished by most others,"  Why can't *they* use a "proper font" that makes
the difference between the 4 characters recognizable?  After all, *they*
know the 4 characters are different and can treat them differently, right?

(And no, it's *not* "different for kanji" - it's the exact same problem and you
know it.  In both cases, (I/l and your Sai issue), the problem is similar
glyphs.  Don't bother replying to suggest a fix for the lower-l/upper-I issue
unless the *same* fix applies to your Sai issue).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120212/cea7a669/attachment.bin>

From mohta at necom830.hpcl.titech.ac.jp  Sun Feb 12 20:39:35 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 13 Feb 2012 11:39:35 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <223001.1329076548@turing-police.cc.vt.edu>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
Message-ID: <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks at vt.edu wrote:

>> The problem is greekbank.gr is spoofable as greekbank.gr.
> 
> That would be the .gr registry's problem then.

As it is the problem of IDN, same problem exist everywhere.

> They could take the same
> solution as the .ua registry -force lowercase and allow all-latin or all-greek
> names.

DNS does not allow .ua registry force lowercase for ASCII.

> So how do you spoof greekbank.gr with greekbank.gr under those rules?

I merely used your example.

> Well then, if all that's required is a "proper font",  what is the problem with
> your Saitoh families?

All that's required is a "proper font" for ASCII.

Beyond ASCII, you almost automatically loss.

For example, in ISO8859-1 context, uppercase of 'y' with
diaeresis is not 'Y' with diaeresis, because there is no
'Y' with diaeresis in ISO8859-1, which is bad enough.

So, I can understand your attempt to insist on lowercase,
but it does not work because DNS does not allow it.

						Masataka Ohta


From smb at cs.columbia.edu  Sun Feb 12 21:22:18 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Sun, 12 Feb 2012 22:22:18 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <192978.1329023607@turing-police.cc.vt.edu>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
Message-ID: <16B9F1F7-DB0B-42DC-B5BC-14FCF9FA32CB@cs.columbia.edu>

> 
> 
> Oh, and 'i' and 'l' need to be banned as well, because a san-serif uppercase I
> looks a lot like a san-serif lowercase l. (In fact, in the font I'm currently using,
> the two are pixel-identical).
> 
> I don't see anybody calling for the banning of 'i' and 'l' in domain names due to that.

The very first phishing message I ever saw was from paypa1.com.


		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From mysidia at gmail.com  Sun Feb 12 21:52:16 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 12 Feb 2012 21:52:16 -0600
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
Message-ID: <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>

2012/2/12 Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>:
> Valdis.Kletnieks at vt.edu wrote:
[snip]
> So, I can understand your attempt to insist on lowercase,
> but it does not work because DNS does not allow it.
[snip]

Not exactly...  DNS is case-insensitive when you are talking about
7-bit ASCII;  the set of alphabetic characters that can appear in a
DNS label;  with no punycode.

IDN means that non-ASCII characters are represented using punycode.

As soon as you have a browser parsing  punycode stuff,  any string
containing unicode characters has a unique punycode encoding / RFC
3491 / RFC 3492.


The symbols represented in the punycode encodings are not case sensitive.


Uppercase A-Z  vs Lowercase a-z in the generalized variable-length
integers   are not distinct,
the punycode representation itself cannot really be case sensitive,
but the codepoint represented by the encoding,  the result of decoding
the punycode  is case-preserving.

--
-JH


From nanog-poster at axu.tm  Sun Feb 12 22:50:51 2012
From: nanog-poster at axu.tm (Aleksi Suhonen)
Date: Mon, 13 Feb 2012 06:50:51 +0200
Subject: IPv6 explicit BGP group configs
Message-ID: <4F3896AB.6040203@axu.tm>

Hello,

keith tokash wrote:
> I'm prepping an environment for v6 and I'm wondering what, if
>  any, benefit there is to splitting v4 and v6 into separate groups.
> We're running Junipers and things are fairly neat and ordered;

I haven't really looked very hard, since I subscribe to the stated 
reasons for keeping v4 and v6 sessions apart. (migration, max-pfx, ...)

BUT

To my knowledge, JunOS doesn't even support using a single TCP session 
to exchange routes of all address families. If someone knows how to do 
this - if even for just IPv4 and IPv6 unicast - let me know ... ;-)

-- 
         Aleksi Suhonen / Axu TM Oy
         World Wide Web: www.axu.tm


From owen at delong.com  Sun Feb 12 23:01:52 2012
From: owen at delong.com (Owen DeLong)
Date: Sun, 12 Feb 2012 21:01:52 -0800
Subject: IPv6 explicit BGP group configs
In-Reply-To: <4F3896AB.6040203@axu.tm>
References: <4F3896AB.6040203@axu.tm>
Message-ID: <8FAFB9AF-D464-4E10-AD1B-C5C5397D46AA@delong.com>

It has limitations, but, it's documented pretty well in the excellent Day One/Day Two Juniper books for IPv6 written by Chris Grundemann. 

However, as others have said, I strongly subscribe to the school of "don't do that, it leads to unnecessary pain and provides little benefit.

Owen

On Feb 12, 2012, at 8:50 PM, Aleksi Suhonen wrote:

> Hello,
> 
> keith tokash wrote:
>> I'm prepping an environment for v6 and I'm wondering what, if
>> any, benefit there is to splitting v4 and v6 into separate groups.
>> We're running Junipers and things are fairly neat and ordered;
> 
> I haven't really looked very hard, since I subscribe to the stated reasons for keeping v4 and v6 sessions apart. (migration, max-pfx, ...)
> 
> BUT
> 
> To my knowledge, JunOS doesn't even support using a single TCP session to exchange routes of all address families. If someone knows how to do this - if even for just IPv4 and IPv6 unicast - let me know ... ;-)
> 
> -- 
>        Aleksi Suhonen / Axu TM Oy
>        World Wide Web: www.axu.tm



From randy at psg.com  Sun Feb 12 23:36:54 2012
From: randy at psg.com (Randy Bush)
Date: Sun, 12 Feb 2012 21:36:54 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
Message-ID: <m2lio7mgzt.wl%randy@psg.com>

> DNS is case-insensitive when you are talking about 7-bit ASCII

< pedantry >

dns itself is purely eight bit transparent.  one can even have a dot as
a non-separator.  p.r.c could be a tld.  it's strictly length/value.

of course, everyone and their dog has placed restrictions on it for this
use or that.

randy


From mysidia at gmail.com  Sun Feb 12 23:47:11 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 12 Feb 2012 23:47:11 -0600
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m2lio7mgzt.wl%randy@psg.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
Message-ID: <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>

On Sun, Feb 12, 2012 at 11:36 PM, Randy Bush <randy at psg.com> wrote:
>> DNS is case-insensitive when you are talking about 7-bit ASCII
> < pedantry >
> dns itself is purely eight bit transparent. ?one can even have a dot as
> a non-separator. ?p.r.c could be a tld. ?it's strictly length/value.

That's true, but  there is no standard character representation for
octet values  128 - 255.
If you use them in a DNS record,  they are just binary values that
don't refer to a specific printable symbol.

Only octets in the range from  65 to 90 (uppercase) and  977 to 122
(lowercase)
have a case equivalent for DNS resolution.

And IDN  uses 7-bit ASCII  DNS records.

--
-JH


From randy at psg.com  Sun Feb 12 23:51:21 2012
From: randy at psg.com (Randy Bush)
Date: Sun, 12 Feb 2012 21:51:21 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
Message-ID: <m2ipjbmgbq.wl%randy@psg.com>

>> dns itself is purely eight bit transparent. ?one can even have a dot as
>> a non-separator. ?p.r.c could be a tld. ?it's strictly length/value.
> That's true, but  there is no standard character representation for
> octet values  128 - 255.

utf-8 is the one used in the ietf community.

> Only octets in the range from 65 to 90 (uppercase) and 977 to 122
> (lowercase) have a case equivalent for DNS resolution.

dns resolution is eight bit clear.

randy


From bmanning at vacation.karoshi.com  Sun Feb 12 23:55:00 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Mon, 13 Feb 2012 05:55:00 +0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m2lio7mgzt.wl%randy@psg.com>
References: <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
Message-ID: <20120213055500.GA5555@vacation.karoshi.com.>

On Sun, Feb 12, 2012 at 09:36:54PM -0800, Randy Bush wrote:
> > DNS is case-insensitive when you are talking about 7-bit ASCII
> 
> < pedantry >
> 
> dns itself is purely eight bit transparent.  one can even have a dot as
> a non-separator.  p.r.c could be a tld.  it's strictly length/value.
> 
> of course, everyone and their dog has placed restrictions on it for this
> use or that.
> 
> randy

	ah, the good'ol days.   ^g.net as an early attempt for the visually impaired
	lasted for a couple months.   about the same time you received your IPv4 /33


/bill


From mohta at necom830.hpcl.titech.ac.jp  Mon Feb 13 00:11:30 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 13 Feb 2012 15:11:30 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
Message-ID: <4F38A992.7030000@necom830.hpcl.titech.ac.jp>

Jimmy Hess wrote:

> As soon as you have a browser parsing  punycode stuff,  any string
> containing unicode characters has a unique punycode encoding / RFC
> 3491 / RFC 3492.

Labels (not "any string") which happens to be pure ASCII
are still case insensitive, which is DNS.

Note that, according to Valdis;

: (The actual policy for the .UA registrar is more subtle.
: They *do* in fact allow "U+0441 Cyrillic Small Letter ES"
: which is visually a C to us Latin-glyph users.  However,
: they require at least one character that's visually unique
: to Cyrillic in the domain name.  They also don't allow
; mixed Cyrillic/Latin scripts in one domain name).

a label (not "domain name") of a Ukrainian word all the
characters of which have shapes identical to some ASCII
characters can only be represented using ASCII characters
only.

						Masataka Ohta


From marka at isc.org  Mon Feb 13 00:21:02 2012
From: marka at isc.org (Mark Andrews)
Date: Mon, 13 Feb 2012 17:21:02 +1100
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Sun, 12 Feb 2012 21:51:21 -0800."
 <m2ipjbmgbq.wl%randy@psg.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
 <m2ipjbmgbq.wl%randy@psg.com>
Message-ID: <20120213062102.D60461D37336@drugs.dv.isc.org>


In message <m2ipjbmgbq.wl%randy at psg.com>, Randy Bush writes:
> >> dns itself is purely eight bit transparent. =A0one can even have a dot as
> >> a non-separator. =A0p.r.c could be a tld. =A0it's strictly length/value.
> > That's true, but  there is no standard character representation for
> > octet values  128 - 255.
> 
> utf-8 is the one used in the ietf community.

I challenge you to find a RFC that say it is UTF-8.  

> > Only octets in the range from 65 to 90 (uppercase) and 977 to 122
> > (lowercase) have a case equivalent for DNS resolution.
> 
> dns resolution is eight bit clear.

It may be 8 bit clear but only 0-127 have defined meaning.

128-255 may be UTF-8 but they could equally be ISO-LATIN-*.

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


From randy at psg.com  Mon Feb 13 00:29:09 2012
From: randy at psg.com (Randy Bush)
Date: Sun, 12 Feb 2012 22:29:09 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120213062102.D60461D37336@drugs.dv.isc.org>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
 <m2ipjbmgbq.wl%randy@psg.com>
 <20120213062102.D60461D37336@drugs.dv.isc.org>
Message-ID: <m2ehtzmekq.wl%randy@psg.com>

>> dns resolution is eight bit clear.
> It may be 8 bit clear but only 0-127 have defined meaning.
> 128-255 may be UTF-8 but they could equally be ISO-LATIN-*.

nothing means anything


From alibaba123123 at gmail.com  Mon Feb 13 00:48:37 2012
From: alibaba123123 at gmail.com (ali baba)
Date: Mon, 13 Feb 2012 14:48:37 +0800
Subject: IP Transit with netflow report?
In-Reply-To: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
References: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
Message-ID: <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>

Hi Everyone,

Hope someone can help me out.. I have some IP Transit links with one of the
Tier1s and I need to know the source<>destination of traffic passing
though.. My provider gives me a straight "NO, we can provide this" and I am
wondering if anyone knows of any providers who gives out netflow report?

Cheers,
AB

From randy at psg.com  Mon Feb 13 00:50:57 2012
From: randy at psg.com (Randy Bush)
Date: Sun, 12 Feb 2012 22:50:57 -0800
Subject: IP Transit with netflow report?
In-Reply-To: <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
References: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
 <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
Message-ID: <m2bop3mdke.wl%randy@psg.com>

> Hope someone can help me out.. I have some IP Transit links with one of the
> Tier1s and I need to know the source<>destination of traffic passing
> though.. My provider gives me a straight "NO, we can provide this" and I am
> wondering if anyone knows of any providers who gives out netflow report?

would be very unusual.  export it from your router.

randy


From peterehiwe at gmail.com  Mon Feb 13 00:51:07 2012
From: peterehiwe at gmail.com (Peter Ehiwe)
Date: Mon, 13 Feb 2012 07:51:07 +0100
Subject: IP Transit with netflow report?
In-Reply-To: <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
References: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
 <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
Message-ID: <CADECfTV4oqLfT9XvOXgg+uZAjzQKePfr8foPeNA4i5rGmEJwdg@mail.gmail.com>

Why cant you do the netflow from your end?

On Mon, Feb 13, 2012 at 7:48 AM, ali baba <alibaba123123 at gmail.com> wrote:

> Hi Everyone,
>
> Hope someone can help me out.. I have some IP Transit links with one of the
> Tier1s and I need to know the source<>destination of traffic passing
> though.. My provider gives me a straight "NO, we can provide this" and I am
> wondering if anyone knows of any providers who gives out netflow report?
>
> Cheers,
> AB
>



-- 
Warm Regards

Peter(CCIE 23782).

From sethm at rollernet.us  Mon Feb 13 01:37:41 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Sun, 12 Feb 2012 23:37:41 -0800
Subject: IP Transit with netflow report?
In-Reply-To: <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
References: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
 <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
Message-ID: <4F38BDC5.90408@rollernet.us>

On 2/12/12 10:48 PM, ali baba wrote:
> Hi Everyone,
> 
> Hope someone can help me out.. I have some IP Transit links with one of the
> Tier1s and I need to know the source<>destination of traffic passing
> though.. My provider gives me a straight "NO, we can provide this" and I am
> wondering if anyone knows of any providers who gives out netflow report?
> 

None that I've ever head of. Export netflow from your router. It'll be
the same data.

~Seth



From gbonser at seven.com  Mon Feb 13 04:30:48 2012
From: gbonser at seven.com (George Bonser)
Date: Mon, 13 Feb 2012 10:30:48 +0000
Subject: IP Transit with netflow report?
In-Reply-To: <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
References: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
 <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CC7198@RWC-MBX1.corp.seven.com>

nfdump + NfSen

Do it yourself.


> -----Original Message-----
> From: ali baba [mailto:alibaba123123 at gmail.com]
> Sent: Sunday, February 12, 2012 10:49 PM
> To: nanog at nanog.org
> Subject: Re: IP Transit with netflow report?
> 
> Hi Everyone,
> 
> Hope someone can help me out.. I have some IP Transit links with one of
> the Tier1s and I need to know the source<>destination of traffic
> passing though.. My provider gives me a straight "NO, we can provide
> this" and I am wondering if anyone knows of any providers who gives out
> netflow report?
> 
> Cheers,
> AB


From rmaunier at neotelecoms.com  Mon Feb 13 04:53:03 2012
From: rmaunier at neotelecoms.com (Raphael MAUNIER)
Date: Mon, 13 Feb 2012 10:53:03 +0000
Subject: IP Transit with netflow report?
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CC7198@RWC-MBX1.corp.seven.com>
Message-ID: <CB5EA962.79E04%rmaunier@neotelecoms.com>

+1

Do it yourself :)

You can have a look at As-Stats. It's easy to install and maintain

https://neon1.net/as-stats/

Regards,
--
Rapha?l Maunier
NEO TELECOMS
CTO / Directeur Ing?nierie
AS8218







On 2/13/12 11:30 AM, "George Bonser" <gbonser at seven.com> wrote:

>nfdump + NfSen
>
>Do it yourself.
>
>
>> -----Original Message-----
>> From: ali baba [mailto:alibaba123123 at gmail.com]
>> Sent: Sunday, February 12, 2012 10:49 PM
>> To: nanog at nanog.org
>> Subject: Re: IP Transit with netflow report?
>> 
>> Hi Everyone,
>> 
>> Hope someone can help me out.. I have some IP Transit links with one of
>> the Tier1s and I need to know the source<>destination of traffic
>> passing though.. My provider gives me a straight "NO, we can provide
>> this" and I am wondering if anyone knows of any providers who gives out
>> netflow report?
>> 
>> Cheers,
>> AB
>



From matt at mt.au.com  Mon Feb 13 05:02:41 2012
From: matt at mt.au.com (Matt Taylor)
Date: Mon, 13 Feb 2012 22:02:41 +1100
Subject: IP Transit with netflow report?
In-Reply-To: <CB5EA962.79E04%rmaunier@neotelecoms.com>
References: <CB5EA962.79E04%rmaunier@neotelecoms.com>
Message-ID: <FDBCF4BE-A520-44CF-BA83-5569C1FE8BD9@mt.au.com>

Scrutinizer!
 

On 13/02/2012, at 9:53 PM, Raphael MAUNIER <rmaunier at neotelecoms.com> wrote:

> +1
> 
> Do it yourself :)
> 
> You can have a look at As-Stats. It's easy to install and maintain
> 
> https://neon1.net/as-stats/
> 
> Regards,
> --
> Rapha?l Maunier
> NEO TELECOMS
> CTO / Directeur Ing?nierie
> AS8218
> 
> 
> 
> 
> 
> 
> 
> On 2/13/12 11:30 AM, "George Bonser" <gbonser at seven.com> wrote:
> 
>> nfdump + NfSen
>> 
>> Do it yourself.
>> 
>> 
>>> -----Original Message-----
>>> From: ali baba [mailto:alibaba123123 at gmail.com]
>>> Sent: Sunday, February 12, 2012 10:49 PM
>>> To: nanog at nanog.org
>>> Subject: Re: IP Transit with netflow report?
>>> 
>>> Hi Everyone,
>>> 
>>> Hope someone can help me out.. I have some IP Transit links with one of
>>> the Tier1s and I need to know the source<>destination of traffic
>>> passing though.. My provider gives me a straight "NO, we can provide
>>> this" and I am wondering if anyone knows of any providers who gives out
>>> netflow report?
>>> 
>>> Cheers,
>>> AB
>> 
> 
> 


From alibaba123123 at gmail.com  Mon Feb 13 19:22:26 2012
From: alibaba123123 at gmail.com (ali baba)
Date: Tue, 14 Feb 2012 09:22:26 +0800
Subject: IP Transit with netflow report?
In-Reply-To: <FDBCF4BE-A520-44CF-BA83-5569C1FE8BD9@mt.au.com>
References: <CB5EA962.79E04%rmaunier@neotelecoms.com>
 <FDBCF4BE-A520-44CF-BA83-5569C1FE8BD9@mt.au.com>
Message-ID: <CAMdJjY1ge9XA7RkBCw8jXgAg9Aoft=06jGv9=G70ZDu-1kut2w@mail.gmail.com>

Ya, thks for the suggestion... been using Arbor and like the flexibility of
doing different reports on the fly. But, it is costing too much and newer
box only allow 5 routers?!! Having some hard time trying to get the
resources to do it in-house, as you guys know, mgmt loves to say forget it
and press the provider to give us..

Is there anyone out there providing such a thing as netflow-as-a-service?


On Monday, February 13, 2012, Matt Taylor <matt at mt.au.com> wrote:
> Scrutinizer!
>
>
> On 13/02/2012, at 9:53 PM, Raphael MAUNIER <rmaunier at neotelecoms.com>
wrote:
>
>> +1
>>
>> Do it yourself :)
>>
>> You can have a look at As-Stats. It's easy to install and maintain
>>
>> https://neon1.net/as-stats/
>>
>> Regards,
>> --
>> Rapha?l Maunier
>> NEO TELECOMS
>> CTO / Directeur Ing?nierie
>> AS8218
>>
>>
>>
>>
>>
>>
>>
>> On 2/13/12 11:30 AM, "George Bonser" <gbonser at seven.com> wrote:
>>
>>> nfdump + NfSen
>>>
>>> Do it yourself.
>>>
>>>
>>>> -----Original Message-----
>>>> From: ali baba [mailto:alibaba123123 at gmail.com]
>>>> Sent: Sunday, February 12, 2012 10:49 PM
>>>> To: nanog at nanog.org
>>>> Subject: Re: IP Transit with netflow report?
>>>>
>>>> Hi Everyone,
>>>>
>>>> Hope someone can help me out.. I have some IP Transit links with one of
>>>> the Tier1s and I need to know the source<>destination of traffic
>>>> passing though.. My provider gives me a straight "NO, we can provide
>>>> this" and I am wondering if anyone knows of any providers who gives out
>>>> netflow report?
>>>>
>>>> Cheers,
>>>> AB
>>>
>>
>>
>
>

From egermann at limanews.com  Mon Feb 13 19:40:47 2012
From: egermann at limanews.com (Eric Germann)
Date: Mon, 13 Feb 2012 17:40:47 -0800
Subject: IP Transit with netflow report?
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CC7198@RWC-MBX1.corp.seven.com>
References: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
 <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC7198@RWC-MBX1.corp.seven.com>
Message-ID: <730AF3879A3A3844B3FB5A881A3DFBC801015058078D@VA3DIAXVS091.RED001.local>

+1

Use it, love it.  Opened eyes on how much "social media traffic" (amongst other things) goes on on a daily basis.

EKG


-----Original Message-----
From: George Bonser [mailto:gbonser at seven.com] 
Sent: Monday, February 13, 2012 5:31 AM
To: ali baba; nanog at nanog.org
Subject: RE: IP Transit with netflow report?

nfdump + NfSen

Do it yourself.


> -----Original Message-----
> From: ali baba [mailto:alibaba123123 at gmail.com]
> Sent: Sunday, February 12, 2012 10:49 PM
> To: nanog at nanog.org
> Subject: Re: IP Transit with netflow report?
> 
> Hi Everyone,
> 
> Hope someone can help me out.. I have some IP Transit links with one of
> the Tier1s and I need to know the source<>destination of traffic
> passing though.. My provider gives me a straight "NO, we can provide
> this" and I am wondering if anyone knows of any providers who gives out
> netflow report?
> 
> Cheers,
> AB



From jloiacon at csc.com  Mon Feb 13 20:20:15 2012
From: jloiacon at csc.com (Joe Loiacono)
Date: Mon, 13 Feb 2012 21:20:15 -0500
Subject: IP Transit with netflow report?
In-Reply-To: <CAMdJjY1ge9XA7RkBCw8jXgAg9Aoft=06jGv9=G70ZDu-1kut2w@mail.gmail.com>
References: <CB5EA962.79E04%rmaunier@neotelecoms.com>
 <FDBCF4BE-A520-44CF-BA83-5569C1FE8BD9@mt.au.com>
 <CAMdJjY1ge9XA7RkBCw8jXgAg9Aoft=06jGv9=G70ZDu-1kut2w@mail.gmail.com>
Message-ID: <OF30F229C1.4DB6946C-ON852579A4.000C0BC1-852579A4.000CD725@csc.com>

Consider also FlowViewer w/ flow-tools. You can set up long-term graphs of
any filtered traffic you like (e.g., by AS, by IP range, by service (ie
port), or any combination, etc.) Keeps stats like peak, average, etc. (just
like MRTG, only for the filtered set of your choice.) Has an email alert
capability when usage crosses a max or min threshold.

Quick, easy install.

http://ensight.eos.nasa.gov/FlowViewer

Joe




From:	ali baba <alibaba123123 at gmail.com>
To:	Matt Taylor <matt at mt.au.com>
Cc:	"nanog at nanog.org" <nanog at nanog.org>
Date:	02/13/2012 08:22 PM
Subject:	Re: IP Transit with netflow report?



Ya, thks for the suggestion... been using Arbor and like the flexibility of
doing different reports on the fly. But, it is costing too much and newer
box only allow 5 routers?!! Having some hard time trying to get the
resources to do it in-house, as you guys know, mgmt loves to say forget it
and press the provider to give us..

Is there anyone out there providing such a thing as netflow-as-a-service?


On Monday, February 13, 2012, Matt Taylor <matt at mt.au.com> wrote:
> Scrutinizer!
>
>
> On 13/02/2012, at 9:53 PM, Raphael MAUNIER <rmaunier at neotelecoms.com>
wrote:
>
>> +1
>>
>> Do it yourself :)
>>
>> You can have a look at As-Stats. It's easy to install and maintain
>>
>> https://neon1.net/as-stats/
>>
>> Regards,
>> --
>> Rapha?l Maunier
>> NEO TELECOMS
>> CTO / Directeur Ing?nierie
>> AS8218
>>
>>
>>
>>
>>
>>
>>
>> On 2/13/12 11:30 AM, "George Bonser" <gbonser at seven.com> wrote:
>>
>>> nfdump + NfSen
>>>
>>> Do it yourself.
>>>
>>>
>>>> -----Original Message-----
>>>> From: ali baba [mailto:alibaba123123 at gmail.com]
>>>> Sent: Sunday, February 12, 2012 10:49 PM
>>>> To: nanog at nanog.org
>>>> Subject: Re: IP Transit with netflow report?
>>>>
>>>> Hi Everyone,
>>>>
>>>> Hope someone can help me out.. I have some IP Transit links with one
of
>>>> the Tier1s and I need to know the source<>destination of traffic
>>>> passing though.. My provider gives me a straight "NO, we can provide
>>>> this" and I am wondering if anyone knows of any providers who gives
out
>>>> netflow report?
>>>>
>>>> Cheers,
>>>> AB
>>>
>>
>>
>
>




From jra at baylink.com  Mon Feb 13 21:21:08 2012
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 13 Feb 2012 22:21:08 -0500 (EST)
Subject: Sonicwall 3500/netflow
Message-ID: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>

This will be my first time in Sonicwall territory.  I'm assuming this thing
will (effectively) *be* my edge router; does it support netflow, as has been
being discussed in the recent thread?

I'm likely going to have 100M from L3, with FiOS/150 and Roadrunner/50 for
backup/load bal; I don't think this will be a BGP application.  :-)

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


From gbonser at seven.com  Tue Feb 14 01:17:02 2012
From: gbonser at seven.com (George Bonser)
Date: Tue, 14 Feb 2012 07:17:02 +0000
Subject: IP Transit with netflow report?
In-Reply-To: <730AF3879A3A3844B3FB5A881A3DFBC801015058078D@VA3DIAXVS091.RED001.local>
References: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
 <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC7198@RWC-MBX1.corp.seven.com>
 <730AF3879A3A3844B3FB5A881A3DFBC801015058078D@VA3DIAXVS091.RED001.local>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CCABD6@RWC-MBX1.corp.seven.com>

> From: Eric Germann 
> Sent: Monday, February 13, 2012 5:41 PM
> To: George Bonser
> Cc: nanog at nanog.org
> Subject: RE: IP Transit with netflow report?
> 
> +1
> 
> Use it, love it.  Opened eyes on how much "social media traffic"
> (amongst other things) goes on on a daily basis.
> 
> EKG

And it works with sflow devices, too.  As a special added treat, the latest nfdump package in Debian sid comes with the sflow tools (yay! No more recompiling the package from source!) and it should be migrating to your favorite Debian derivative soon-ish (Ubuntu?).




From jay at miscreant.org  Tue Feb 14 04:58:41 2012
From: jay at miscreant.org (Jay Mitchell)
Date: Tue, 14 Feb 2012 21:58:41 +1100
Subject: Sonicwall 3500/netflow
In-Reply-To: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>
References: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>
Message-ID: <325D1DEE-D12B-4204-BBE4-B9B0A11D665A@miscreant.org>

According to the spec sheet it does, haven't had the opportunity to play with one to comment any further though.

http://www.sonicwall.com/us/products/NSA_3500.html#tab=specifications

--jay


On 14/02/2012, at 2:21 PM, Jay Ashworth <jra at baylink.com> wrote:

> This will be my first time in Sonicwall territory.  I'm assuming this thing
> will (effectively) *be* my edge router; does it support netflow, as has been
> being discussed in the recent thread?
> 
> I'm likely going to have 100M from L3, with FiOS/150 and Roadrunner/50 for
> backup/load bal; I don't think this will be a BGP application.  :-)
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
> 


From blake at pfankuch.me  Tue Feb 14 08:40:40 2012
From: blake at pfankuch.me (Blake Pfankuch)
Date: Tue, 14 Feb 2012 14:40:40 +0000
Subject: Sonicwall 3500/netflow
In-Reply-To: <325D1DEE-D12B-4204-BBE4-B9B0A11D665A@miscreant.org>
References: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>
 <325D1DEE-D12B-4204-BBE4-B9B0A11D665A@miscreant.org>
Message-ID: <CC75EEBF17C7374EA8309102B7B10C84860B1FFB@SHSBS.shenrons-house.local>

JRA,
	If you have questions contact me off list.  I would shoot for a little higher device to support that bandwidth if you are going to be enabling Services at all.  Also if you use services, make sure they are enabled only on 1 zone as to not double scan traffic.  Also I would skip the DPI-SSL services for now, as they are extremely throughput intensive.  The company I work for manages a few hundred Sonicwalls, some of them in a pretty complex setup.  SonicWall netflow is a little unique, they have a GUI feature called APPFlow which makes it pretty easy to trim down to watch exactly what you need (once you get the hang of it).  Some of the additional free features make the SonicWall very nice.  The SSLVPN portal is very handy for remote troubleshooting.  You can bind it to a VLAN interface with private addresses for management purposes as well as remote access.  

Careful though, they can either be a beast, or a joy to manage depending on how you set it up.

If you want to do entirely CLI management on the SonicWall, be prepared for a headache.  Everything is case sensitive, and not the cleanest.  If you build quick templates in your favorite text editor, it can be very simple to manage this way.  

SonicWall is pushing 5.8.1.4 firmwares to all of the partners as far as I know (maybe to everyone) if you call in with an issue.  Check the caveats though, we have a few conflicts related to VPN stuff as well as dynamic routing a few places.

Blake

-----Original Message-----
From: Jay Mitchell [mailto:jay at miscreant.org] 
Sent: Tuesday, February 14, 2012 3:59 AM
To: Jay Ashworth
Cc: NANOG
Subject: Re: Sonicwall 3500/netflow

According to the spec sheet it does, haven't had the opportunity to play with one to comment any further though.

http://www.sonicwall.com/us/products/NSA_3500.html#tab=specifications

--jay


On 14/02/2012, at 2:21 PM, Jay Ashworth <jra at baylink.com> wrote:

> This will be my first time in Sonicwall territory.  I'm assuming this 
> thing will (effectively) *be* my edge router; does it support netflow, 
> as has been being discussed in the recent thread?
> 
> I'm likely going to have 100M from L3, with FiOS/150 and Roadrunner/50 
> for backup/load bal; I don't think this will be a BGP application.  
> :-)
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
> 



From brandon.kim at brandontek.com  Tue Feb 14 09:49:00 2012
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Tue, 14 Feb 2012 10:49:00 -0500
Subject: Sonicwall 3500/netflow
In-Reply-To: <CC75EEBF17C7374EA8309102B7B10C84860B1FFB@SHSBS.shenrons-house.local>
References: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>,
 <325D1DEE-D12B-4204-BBE4-B9B0A11D665A@miscreant.org>,
 <CC75EEBF17C7374EA8309102B7B10C84860B1FFB@SHSBS.shenrons-house.local>
Message-ID: <BLU158-W51472FFDC4763D01968E7FDC7C0@phx.gbl>


I've been using 5.8 with no problems thus far. As for the CLI, yes it is CLUNKY.

But they are completely revamping it, it will be very similar to Cisco in the near future...




> From: blake at pfankuch.me
> To: jay at miscreant.org; jra at baylink.com
> Subject: RE: Sonicwall 3500/netflow
> Date: Tue, 14 Feb 2012 14:40:40 +0000
> CC: nanog at nanog.org
> 
> JRA,
> 	If you have questions contact me off list.  I would shoot for a little higher device to support that bandwidth if you are going to be enabling Services at all.  Also if you use services, make sure they are enabled only on 1 zone as to not double scan traffic.  Also I would skip the DPI-SSL services for now, as they are extremely throughput intensive.  The company I work for manages a few hundred Sonicwalls, some of them in a pretty complex setup..  SonicWall netflow is a little unique, they have a GUI feature called APPFlow which makes it pretty easy to trim down to watch exactly what you need (once you get the hang of it).  Some of the additional free features make the SonicWall very nice.  The SSLVPN portal is very handy for remote troubleshooting.  You can bind it to a VLAN interface with private addresses for management purposes as well as remote access.  
> 
> Careful though, they can either be a beast, or a joy to manage depending on how you set it up.
> 
> If you want to do entirely CLI management on the SonicWall, be prepared for a headache.  Everything is case sensitive, and not the cleanest.  If you build quick templates in your favorite text editor, it can be very simple to manage this way.  
> 
> SonicWall is pushing 5.8.1.4 firmwares to all of the partners as far as I know (maybe to everyone) if you call in with an issue.  Check the caveats though, we have a few conflicts related to VPN stuff as well as dynamic routing a few places.
> 
> Blake
> 
> -----Original Message-----
> From: Jay Mitchell [mailto:jay at miscreant.org] 
> Sent: Tuesday, February 14, 2012 3:59 AM
> To: Jay Ashworth
> Cc: NANOG
> Subject: Re: Sonicwall 3500/netflow
> 
> According to the spec sheet it does, haven't had the opportunity to play with one to comment any further though.
> 
> http://www.sonicwall.com/us/products/NSA_3500.html#tab=specifications
> 
> --jay
> 
> 
> On 14/02/2012, at 2:21 PM, Jay Ashworth <jra at baylink.com> wrote:
> 
> > This will be my first time in Sonicwall territory.  I'm assuming this 
> > thing will (effectively) *be* my edge router; does it support netflow, 
> > as has been being discussed in the recent thread?
> > 
> > I'm likely going to have 100M from L3, with FiOS/150 and Roadrunner/50 
> > for backup/load bal; I don't think this will be a BGP application.  
> > :-)
> > 
> > Cheers,
> > -- jra
> > -- 
> > Jay R. Ashworth                  Baylink                       jra at baylink.com
> > Designer                     The Things I Think                       RFC 2100
> > Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> > St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
> > 
> 
> 
 		 	   		  

From leigh.porter at ukbroadband.com  Tue Feb 14 09:53:43 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Tue, 14 Feb 2012 15:53:43 +0000
Subject: Sonicwall 3500/netflow
In-Reply-To: <BLU158-W51472FFDC4763D01968E7FDC7C0@phx.gbl>
References: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>, 
 <325D1DEE-D12B-4204-BBE4-B9B0A11D665A@miscreant.org>,
 <CC75EEBF17C7374EA8309102B7B10C84860B1FFB@SHSBS.shenrons-house.local>
 <BLU158-W51472FFDC4763D01968E7FDC7C0@phx.gbl>
Message-ID: <D181DDABABE57E4DB72FEE00331478644A71DF@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Brandon Kim [mailto:brandon.kim at brandontek.com]
> Sent: 14 February 2012 15:51
> To: blake at pfankuch.me; jay at miscreant.org; jra at baylink.com
> Cc: nanog group
> Subject: RE: Sonicwall 3500/netflow
> 
> 
> I've been using 5.8 with no problems thus far. As for the CLI, yes it
> is CLUNKY.
> 
> But they are completely revamping it, it will be very similar to Cisco
> in the near future...

Why do people like to base their CLIs on the really rather awful Cisco style interface rather than something with some more structure like Juniper?


--
Leigh Porter




______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


From brandon.kim at brandontek.com  Tue Feb 14 10:13:39 2012
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Tue, 14 Feb 2012 11:13:39 -0500
Subject: Sonicwall 3500/netflow
In-Reply-To: <D181DDABABE57E4DB72FEE00331478644A71DF@EALPO1.ukbroadband.com>
References: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>, ,
 <325D1DEE-D12B-4204-BBE4-B9B0A11D665A@miscreant.org>, ,
 <CC75EEBF17C7374EA8309102B7B10C84860B1FFB@SHSBS.shenrons-house.local>,
 <BLU158-W51472FFDC4763D01968E7FDC7C0@phx.gbl>,
 <D181DDABABE57E4DB72FEE00331478644A71DF@EALPO1.ukbroadband.com>
Message-ID: <BLU158-W40B5CECC4C1F25E8B5CC44DC7C0@phx.gbl>


Never messed around with Juniper....




> From: leigh.porter at ukbroadband.com
> To: brandon.kim at brandontek.com; blake at pfankuch.me; jay at miscreant.org; jra at baylink.com
> CC: nanog at nanog.org
> Subject: RE: Sonicwall 3500/netflow
> Date: Tue, 14 Feb 2012 15:53:43 +0000
> 
> 
> 
> > -----Original Message-----
> > From: Brandon Kim [mailto:brandon.kim at brandontek.com]
> > Sent: 14 February 2012 15:51
> > To: blake at pfankuch.me; jay at miscreant.org; jra at baylink.com
> > Cc: nanog group
> > Subject: RE: Sonicwall 3500/netflow
> > 
> > 
> > I've been using 5.8 with no problems thus far. As for the CLI, yes it
> > is CLUNKY.
> > 
> > But they are completely revamping it, it will be very similar to Cisco
> > in the near future...
> 
> Why do people like to base their CLIs on the really rather awful Cisco style interface rather than something with some more structure like Juniper?
> 
> 
> --
> Leigh Porter
> 
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
 		 	   		  

From lstewart at superb.net  Tue Feb 14 15:03:33 2012
From: lstewart at superb.net (Landon Stewart)
Date: Tue, 14 Feb 2012 13:03:33 -0800
Subject: Does anyone know anything about intelishift.com?
Message-ID: <CABgOHgvHRCvX9vksyZovrBoEyLb-Grv8f7EAEioyyxqNDHGH6A@mail.gmail.com>

Does anyone know if intelishift.com has a reputation that is good or bad?
 I have never heard of them before but need to know some more about them.
 If you have anything to share please let me know off-list.  We are seeing
some unscrupulous behaviour from them regarding marketing and spam.

---
Landon Stewart <lstewart at superb.net <mailto"LStewart at Superb.Net>>
Manager of Systems and Engineering
Superb Internet Corp - 888-354-6128 x 4199
Web hosting and more "Ahead of the Rest": www.superb.net

From jmilko at bandwidth.com  Tue Feb 14 15:32:44 2012
From: jmilko at bandwidth.com (James Milko)
Date: Tue, 14 Feb 2012 16:32:44 -0500
Subject: Clued contact at Brighthouse
Message-ID: <CAMiL-88tSmxvADx9kAkUzWzFmxyHREs++j_KLApyEuNjZPwFvA@mail.gmail.com>

Brighthouse seems to be announcing one of our prefixes.  Does anyone have a
contact for them that doesn't end up in residential support?

Thanks,
James Milko
Senior Network Engineer
www.inetwork.com
4001 Weston Parkway
Cary, NC 27513

inetwork is a division of Bandwidth

From jmilko at bandwidth.com  Tue Feb 14 16:32:22 2012
From: jmilko at bandwidth.com (James Milko)
Date: Tue, 14 Feb 2012 17:32:22 -0500
Subject: Clued contact at Brighthouse
In-Reply-To: <CAMiL-88tSmxvADx9kAkUzWzFmxyHREs++j_KLApyEuNjZPwFvA@mail.gmail.com>
References: <CAMiL-88tSmxvADx9kAkUzWzFmxyHREs++j_KLApyEuNjZPwFvA@mail.gmail.com>
Message-ID: <CAMiL-8-aGg=fsQ-OtKocfz+u5G2ekokOVs-Z4UPxK4jAXmwojA@mail.gmail.com>

Thanks to everyone who contacted us off list.  We got in touch with the
correct people over at Brighthouse and are working on it now.

Thanks,
James Milko
Senior Network Engineer
www.inetwork.com
4001 Weston Parkway
Cary, NC 27513

inetwork is a division of Bandwidth


On Tue, Feb 14, 2012 at 4:32 PM, James Milko <jmilko at bandwidth.com> wrote:

> Brighthouse seems to be announcing one of our prefixes.  Does anyone have
> a contact for them that doesn't end up in residential support?
>
> Thanks,
> James Milko
> Senior Network Engineer
> www.inetwork.com
> 4001 Weston Parkway
> Cary, NC 27513
>
> inetwork is a division of Bandwidth
>

From blake at pfankuch.me  Tue Feb 14 16:39:07 2012
From: blake at pfankuch.me (Blake Pfankuch)
Date: Tue, 14 Feb 2012 22:39:07 +0000
Subject: Sonicwall 3500/netflow
In-Reply-To: <BLU158-W40B5CECC4C1F25E8B5CC44DC7C0@phx.gbl>
References: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>, ,
 <325D1DEE-D12B-4204-BBE4-B9B0A11D665A@miscreant.org>, ,
 <CC75EEBF17C7374EA8309102B7B10C84860B1FFB@SHSBS.shenrons-house.local>,
 <BLU158-W51472FFDC4763D01968E7FDC7C0@phx.gbl>,
 <D181DDABABE57E4DB72FEE00331478644A71DF@EALPO1.ukbroadband.com>
 <BLU158-W40B5CECC4C1F25E8B5CC44DC7C0@phx.gbl>
Message-ID: <CC75EEBF17C7374EA8309102B7B10C84860B2429@SHSBS.shenrons-house.local>

I would be happy if it was Juniper or Cisco ish.  Right now it's just total crap :)

From: brandon.j.kim at live.com [mailto:brandon.j.kim at live.com] On Behalf Of Brandon Kim
Sent: Tuesday, February 14, 2012 9:14 AM
To: leigh.porter at ukbroadband.com; Blake Pfankuch; jay at miscreant.org; jra at baylink.com
Cc: nanog group
Subject: RE: Sonicwall 3500/netflow

Never messed around with Juniper....



> From: leigh.porter at ukbroadband.com<mailto:leigh.porter at ukbroadband.com>
> To: brandon.kim at brandontek.com<mailto:brandon.kim at brandontek.com>; blake at pfankuch.me<mailto:blake at pfankuch.me>; jay at miscreant.org<mailto:jay at miscreant.org>; jra at baylink.com<mailto:jra at baylink.com>
> CC: nanog at nanog.org<mailto:nanog at nanog.org>
> Subject: RE: Sonicwall 3500/netflow
> Date: Tue, 14 Feb 2012 15:53:43 +0000
>
>
>
> > -----Original Message-----
> > From: Brandon Kim [mailto:brandon.kim at brandontek.com]<mailto:[mailto:brandon.kim at brandontek.com]>
> > Sent: 14 February 2012 15:51
> > To: blake at pfankuch.me<mailto:blake at pfankuch.me>; jay at miscreant.org<mailto:jay at miscreant.org>; jra at baylink.com<mailto:jra at baylink.com>
> > Cc: nanog group
> > Subject: RE: Sonicwall 3500/netflow
> >
> >
> > I've been using 5.8 with no problems thus far. As for the CLI, yes it
> > is CLUNKY.
> >
> > But they are completely revamping it, it will be very similar to Cisco
> > in the near future...
>
> Why do people like to base their CLIs on the really rather awful Cisco style interface rather than something with some more structure like Juniper?
>
>
> --
> Leigh Porter
>
>
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________

From bortzmeyer at nic.fr  Wed Feb 15 03:44:38 2012
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Wed, 15 Feb 2012 10:44:38 +0100
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120213062102.D60461D37336@drugs.dv.isc.org>
References: <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
 <m2ipjbmgbq.wl%randy@psg.com>
 <20120213062102.D60461D37336@drugs.dv.isc.org>
Message-ID: <20120215094438.GA30846@nic.fr>

On Mon, Feb 13, 2012 at 05:21:02PM +1100,
 Mark Andrews <marka at isc.org> wrote 
 a message of 25 lines which said:

> > utf-8 is the one used in the ietf community.
> 
> I challenge you to find a RFC that say it is UTF-8.  

Challenge taken.

RFC 2277, "IETF Policy on Character Sets and Languages", section 3.1,
"Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY
specify, in addition, how to use other charsets [something DNS does
not do, so it must be UTF-8]"

RFC 5198 is a good reading, too.

So, basically, in IETF land, if the encoding is not specified, it is
UTF-8.



From Valdis.Kletnieks at vt.edu  Wed Feb 15 04:13:54 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 15 Feb 2012 05:13:54 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Wed, 15 Feb 2012 10:44:38 +0100."
 <20120215094438.GA30846@nic.fr>
References: <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
 <m2ipjbmgbq.wl%randy@psg.com> <20120213062102.D60461D37336@drugs.dv.isc.org>
 <20120215094438.GA30846@nic.fr>
Message-ID: <22591.1329300834@turing-police.cc.vt.edu>

On Wed, 15 Feb 2012 10:44:38 +0100, Stephane Bortzmeyer said:

> Challenge taken.
>
> RFC 2277, "IETF Policy on Character Sets and Languages", section 3.1,
> "Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY
> specify, in addition, how to use other charsets [something DNS does
> not do, so it must be UTF-8]"

(ooh.. an RFC lawyering fight. Goody goody, haven't had one in a while..  :)

That requires overlooking the minor detail that the DNS RFC predates that by quite
some time, and there's no combination of RFCs 2119 and 2277 that mandates
retrofitting grandfathered protocols by fiat.

It also requires overlooking the fact that 2277 is a BCP, not an Internet Standard, and
as such isn't itself binding, merely A Good Idea.

Nice try though. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120215/7af051c3/attachment.bin>

From rs at seastrom.com  Wed Feb 15 05:46:40 2012
From: rs at seastrom.com (Robert E. Seastrom)
Date: Wed, 15 Feb 2012 06:46:40 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <22591.1329300834@turing-police.cc.vt.edu> (Valdis Kletnieks's
 message of "Wed, 15 Feb 2012 05:13:54 -0500")
References: <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
 <m2ipjbmgbq.wl%randy@psg.com>
 <20120213062102.D60461D37336@drugs.dv.isc.org>
 <20120215094438.GA30846@nic.fr>
 <22591.1329300834@turing-police.cc.vt.edu>
Message-ID: <86mx8kqpy7.fsf@seastrom.com>


Valdis.Kletnieks at vt.edu writes:

> On Wed, 15 Feb 2012 10:44:38 +0100, Stephane Bortzmeyer said:
>
>> Challenge taken.
>>
>> RFC 2277, "IETF Policy on Character Sets and Languages", section 3.1,
>> "Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY
>> specify, in addition, how to use other charsets [something DNS does
>> not do, so it must be UTF-8]"
>
> (ooh.. an RFC lawyering fight. Goody goody, haven't had one in a while..  :)
>
> That requires overlooking the minor detail that the DNS RFC predates that by quite
> some time, and there's no combination of RFCs 2119 and 2277 that mandates
> retrofitting grandfathered protocols by fiat.
>
> It also requires overlooking the fact that 2277 is a BCP, not an Internet Standard, and
> as such isn't itself binding, merely A Good Idea.
>
> Nice try though. ;)

Valdis, re-read the original assertion and challenge.

Your attempt at RFC lawyering appears to be "Experimental" <grin>

-r



From marka at isc.org  Wed Feb 15 07:32:19 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 16 Feb 2012 00:32:19 +1100
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Wed, 15 Feb 2012 06:46:40 CDT."
 <86mx8kqpy7.fsf@seastrom.com>
References: <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
 <m2ipjbmgbq.wl%randy@psg.com> <20120213062102.D60461D37336@drugs.dv.isc.org>
 <20120215094438.GA30846@nic.fr> <22591.1329300834@turing-police.cc.vt.edu>
 <86mx8kqpy7.fsf@seastrom.com>
Message-ID: <20120215133219.DED4E1D6273B@drugs.dv.isc.org>


In message <86mx8kqpy7.fsf at seastrom.com>, "Robert E. Seastrom" writes:
> 
> Valdis.Kletnieks at vt.edu writes:
> 
> > On Wed, 15 Feb 2012 10:44:38 +0100, Stephane Bortzmeyer said:
> >
> >> Challenge taken.
> >>
> >> RFC 2277, "IETF Policy on Character Sets and Languages", section 3.1,
> >> "Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY
> >> specify, in addition, how to use other charsets [something DNS does
> >> not do, so it must be UTF-8]"
> >
> > (ooh.. an RFC lawyering fight. Goody goody, haven't had one in a while..  :)
> >
> > That requires overlooking the minor detail that the DNS RFC predates that by quite
> > some time, and there's no combination of RFCs 2119 and 2277 that mandates
> > retrofitting grandfathered protocols by fiat.
> >
> > It also requires overlooking the fact that 2277 is a BCP, not an Internet Standard, and
> > as such isn't itself binding, merely A Good Idea.
> >
> > Nice try though. ;)
> 
> Valdis, re-read the original assertion and challenge.
> 
> Your attempt at RFC lawyering appears to be "Experimental" <grin>

The Internationalised DNS uses IDNA suite of RFC's to encode UTF
into A-labels.  Before deciding to go the IDNA route, treating DNS
labels as UTF-8 was discussed, evaluated and rejected.

DNS labels are length tagged binary blobs with case folding of the
7 bit ascii values 'a'-'z' when performing lookups.  If a server
is fully compliant (and I don't think any is) answers should be
returned in a case preserving manner, including owner names.  The
intent of RFC 1035 was to be able to use the DNS to store and
retrieve binary data using binary keys.

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


From brunner at nic-naa.net  Wed Feb 15 11:00:25 2012
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Wed, 15 Feb 2012 12:00:25 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120215133219.DED4E1D6273B@drugs.dv.isc.org>
References: <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
 <m2ipjbmgbq.wl%randy@psg.com> <20120213062102.D60461D37336@drugs.dv.isc.org>
 <20120215094438.GA30846@nic.fr> <22591.1329300834@turing-police.cc.vt.edu>
 <86mx8kqpy7.fsf@seastrom.com> <20120215133219.DED4E1D6273B@drugs.dv.isc.org>
Message-ID: <4F3BE4A9.2030306@nic-naa.net>

On 2/15/12 8:32 AM, Mark Andrews wrote:
> ... Before deciding to go the IDNA route, treating DNS
> labels as UTF-8 was discussed, evaluated and rejected.

well, sort of. we started with "idn" as a wg label.

the smtp weenies opined that they'd never have a flag day and anything
other than a boot encoding in LDH would harm LDH limited mailers, so ...

the code point problem (or problems) was moved out of "infrastructure"
and into "applications", so the work product was labeled "idna", which
the successor wg had no alternative except to follow the "in a" set of
dependencies and assumptions.

as you observed, labels are length tagged binary blobs, and where the
blobs consist of 7 bit ascii values in the 'a'-'z' range, case folding
is performed in lookup.

what happens outside of that range is a path not taken, though i tried
in 2929 to leave that open for future work, the sentence which read
"text labels can, in fact, include any octet value including zero
octets but most current uses involve only [US-ASCII]." was, if memory
serves, proposed by a co-author to have been more restrictive.

i agree with the "rejected" statement, the "evaluated" and even the
"discussed" overstate the room available after the smtp weenies
weighed in on what was permissible in headers.

-e


From rps at maine.edu  Wed Feb 15 12:51:37 2012
From: rps at maine.edu (Ray Soucy)
Date: Wed, 15 Feb 2012 13:51:37 -0500
Subject: IP Transit with netflow report?
In-Reply-To: <FDBCF4BE-A520-44CF-BA83-5569C1FE8BD9@mt.au.com>
References: <CB5EA962.79E04%rmaunier@neotelecoms.com>
 <FDBCF4BE-A520-44CF-BA83-5569C1FE8BD9@mt.au.com>
Message-ID: <CALFTrnM1dgt8LoAvXqbkSUtKn+OHHpJ3gjf0SSgH6aA390tmKA@mail.gmail.com>

+1 for Scrutinizer, but to be fair a lot of our former students work there.

On Mon, Feb 13, 2012 at 6:02 AM, Matt Taylor <matt at mt.au.com> wrote:
> Scrutinizer!
>
>
> On 13/02/2012, at 9:53 PM, Raphael MAUNIER <rmaunier at neotelecoms.com> wrote:
>
>> +1
>>
>> Do it yourself :)
>>
>> You can have a look at As-Stats. It's easy to install and maintain
>>
>> https://neon1.net/as-stats/
>>
>> Regards,
>> --
>> Rapha?l Maunier
>> NEO TELECOMS
>> CTO / Directeur Ing?nierie
>> AS8218
>>
>>
>>
>>
>>
>>
>>
>> On 2/13/12 11:30 AM, "George Bonser" <gbonser at seven.com> wrote:
>>
>>> nfdump + NfSen
>>>
>>> Do it yourself.
>>>
>>>
>>>> -----Original Message-----
>>>> From: ali baba [mailto:alibaba123123 at gmail.com]
>>>> Sent: Sunday, February 12, 2012 10:49 PM
>>>> To: nanog at nanog.org
>>>> Subject: Re: IP Transit with netflow report?
>>>>
>>>> Hi Everyone,
>>>>
>>>> Hope someone can help me out.. I have some IP Transit links with one of
>>>> the Tier1s and I need to know the source<>destination of traffic
>>>> passing though.. My provider gives me a straight "NO, we can provide
>>>> this" and I am wondering if anyone knows of any providers who gives out
>>>> netflow report?
>>>>
>>>> Cheers,
>>>> AB
>>>
>>
>>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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


From jtk at cymru.com  Wed Feb 15 14:47:15 2012
From: jtk at cymru.com (John Kristoff)
Date: Wed, 15 Feb 2012 14:47:15 -0600
Subject: Common operational misconceptions
Message-ID: <20120215144715.18e65a55@w520.localdomain>

Hi friends,

As some of you may know, I occasionally teach networking to college
students and I frequently encounter misconceptions about some aspect
of networking that can take a fair amount of effort to correct.

For instance, a topic that has come up on this list before is how the
inappropriate use of classful terminology is rampant among students,
books and often other teachers.  Furthermore, the terminology isn't even
always used correctly in the original context of classful addressing.

I have a handful of common misconceptions that I'd put on a top 10 list,
but I'd like to solicit from this community what it considers to be the
most annoying and common operational misconceptions future operators
often come at you with.

I'd prefer replies off-list and can summarize back to the list if
there is interest.

John


From bhmccie at gmail.com  Wed Feb 15 14:57:58 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Wed, 15 Feb 2012 14:57:58 -0600
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <4F3C1C56.6040802@gmail.com>

Switching VS Bridging
Collision Domain VS Broadcast Domain

L2 in general is the layer that the new folks often misunderstand.

I once had someone ask me what a hub was. That pretty much told me how 
old I was....

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/15/2012 2:47 PM, John Kristoff wrote:
> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers.  Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
>
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
>
> John
>
>


From chipps at chipps.com  Wed Feb 15 15:10:44 2012
From: chipps at chipps.com (Kenneth M. Chipps Ph.D.)
Date: Wed, 15 Feb 2012 15:10:44 -0600
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <008501ccec26$47e8c010$d7ba4030$@chipps.com>

Keep the discussion on the list. I would like to know as well.

Kenneth M. Chipps Ph.D.

-----Original Message-----
From: John Kristoff [mailto:jtk at cymru.com] 
Sent: Wednesday, February 15, 2012 2:47 PM
To: nanog at nanog.org
Subject: Common operational misconceptions

Hi friends,

As some of you may know, I occasionally teach networking to college students
and I frequently encounter misconceptions about some aspect of networking
that can take a fair amount of effort to correct.

For instance, a topic that has come up on this list before is how the
inappropriate use of classful terminology is rampant among students, books
and often other teachers.  Furthermore, the terminology isn't even always
used correctly in the original context of classful addressing.

I have a handful of common misconceptions that I'd put on a top 10 list, but
I'd like to solicit from this community what it considers to be the most
annoying and common operational misconceptions future operators often come
at you with.

I'd prefer replies off-list and can summarize back to the list if there is
interest.

John





From mark at pcinw.net  Wed Feb 15 15:26:28 2012
From: mark at pcinw.net (Mark Grigsby)
Date: Wed, 15 Feb 2012 13:26:28 -0800
Subject: Common operational misconceptions
In-Reply-To: <008501ccec26$47e8c010$d7ba4030$@chipps.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <008501ccec26$47e8c010$d7ba4030$@chipps.com>
Message-ID: <CAKwRnJMZAxpS3r1HYLB0RYNbVfJqH6U95MaSi2L=K2g+9vktqQ@mail.gmail.com>

On Wed, Feb 15, 2012 at 1:10 PM, Kenneth M. Chipps Ph.D.
<chipps at chipps.com>wrote:

> Keep the discussion on the list. I would like to know as well.
>
> Kenneth M. Chipps Ph.D.
>
> -----Original Message-----
> From: John Kristoff [mailto:jtk at cymru.com]
> Sent: Wednesday, February 15, 2012 2:47 PM
> To: nanog at nanog.org
> Subject: Common operational misconceptions
>
> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students
> and I frequently encounter misconceptions about some aspect of networking
> that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students, books
> and often other teachers.  Furthermore, the terminology isn't even always
> used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but
> I'd like to solicit from this community what it considers to be the most
> annoying and common operational misconceptions future operators often come
> at you with.
>
> I'd prefer replies off-list and can summarize back to the list if there is
> interest.
>
> John
>
>
>
>
>

 I don't know how many times I have "Network Administrators" ask questions
like this...
Speaking in the context of configuring an ipsec tunnel..

    "I have my side built. Can you lock your side down to a specific
protocol? Our sets his device to TCP 104. Makes it nice for me when I set
my ACLs."

I am pretty sure that he meant protocol TCP and Port 104, but I do grind my
teeth when I have to go show them that a specific protocol number means
something completely different than what they were asking.

-- 
Mark Grigsby
Network Operations Manager
PCINW (Preferred Connections Inc., NW)
3555 Gateway St. Ste. 205
Springfield, OR  97477
Office  541-242-0808 ext 408
TF:   800-787-3806 ext 408
DID: 541-762-1171
Fax:  541-684-0283

From dwhite at olp.net  Wed Feb 15 15:52:01 2012
From: dwhite at olp.net (Dan White)
Date: Wed, 15 Feb 2012 15:52:01 -0600
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <20120215215200.GG3353@dan.olp.net>

On 02/15/12?14:47?-0600, John Kristoff wrote:
>Hi friends,
>
>As some of you may know, I occasionally teach networking to college
>students and I frequently encounter misconceptions about some aspect
>of networking that can take a fair amount of effort to correct.
>
>For instance, a topic that has come up on this list before is how the
>inappropriate use of classful terminology is rampant among students,
>books and often other teachers.  Furthermore, the terminology isn't even
>always used correctly in the original context of classful addressing.
>
>I have a handful of common misconceptions that I'd put on a top 10 list,
>but I'd like to solicit from this community what it considers to be the
>most annoying and common operational misconceptions future operators
>often come at you with.
>
>I'd prefer replies off-list and can summarize back to the list if
>there is interest.

I almost always see someone fill in the 'default gateway' field when
they're configuring a temporary address on their computer to communicate
with a device on the local network.

On the topic of VLANs, it's common to think of 'trunking' and something
that happens between switches. It's hard to get someone to ponder the
fact that trunking isn't an all or nothing concept, and that a server can
be configured to speak vlan.

Confusing ftp, sftp, ftps. Or telnet, telnets, ssh.

Packet loss at hop X in traceroute/mtr does not necessarily point to a
problem at hop X.

BGP does not magically load balance your ingress and egress traffic.

Just because it's down for you, doesn't mean it's down for everyone.

-- 
Dan White


From tias at netnod.se  Wed Feb 15 15:59:37 2012
From: tias at netnod.se (Mathias Wolkert)
Date: Wed, 15 Feb 2012 22:59:37 +0100
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <21EB6874-EC26-4BFF-805B-434D6C83F0D4@netnod.se>

Autoneg. The old timers that don't trust it after a few decades of decent code. Or those that lock one side and expect the other to adjust to that. 

/Tias

15 feb 2012 kl. 21:47 skrev John Kristoff <jtk at cymru.com>:

> Hi friends,
> 
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
> 
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers.  Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
> 
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
> 
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
> 
> John
> 


From bicknell at ufp.org  Wed Feb 15 16:06:53 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 15 Feb 2012 14:06:53 -0800
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <20120215220653.GA59477@ussenterprise.ufp.org>


Auto-neg, as someone already mentioned.

MD5 makes BGP peering sessions more secure. There was a nice recent
NANOG rant on that one.

One of my favorites from corporate america; if you run one application
on a server you can put in that apps port in the firewall and block
everything else and the server will be happy.  Evidently folks don't
know servers need to do things like make DNS queries, have remote access
to them, contact domain controllers or software update servers.  *sigh*

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120215/e227d507/attachment.bin>

From bhmccie at gmail.com  Wed Feb 15 16:09:22 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Wed, 15 Feb 2012 16:09:22 -0600
Subject: Common operational misconceptions
In-Reply-To: <20120215215200.GG3353@dan.olp.net>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215215200.GG3353@dan.olp.net>
Message-ID: <4F3C2D12.7010001@gmail.com>

"Packet loss at hop X in traceroute/mtr does not necessarily point to a
problem at hop X."

Good one.

Also, security as a whole seems to be confusing for folks. They've seen 
"Firewall" with Harrison Ford and therefore the FW is some secret master 
voodoo widget that only people from Area 51 can operate. They don't 
understand "header manipulation" vs "payload".

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/15/2012 3:52 PM, Dan White wrote:
> Packet loss at hop X in traceroute/mtr does not necessarily point to a
> problem at hop X. 


From dougb at dougbarton.us  Wed Feb 15 16:14:31 2012
From: dougb at dougbarton.us (Doug Barton)
Date: Wed, 15 Feb 2012 14:14:31 -0800
Subject: Common operational misconceptions
In-Reply-To: <20120215220653.GA59477@ussenterprise.ufp.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215220653.GA59477@ussenterprise.ufp.org>
Message-ID: <4F3C2E47.80903@dougbarton.us>

DNS only uses UDP
DNS only uses 512 byte UDP packets

or maybe just..

DNS is easy

-- 

	It's always a long day; 86400 doesn't fit into a short.

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120215/8cc9fa88/attachment.bin>

From johnl at iecc.com  Wed Feb 15 16:19:42 2012
From: johnl at iecc.com (John Levine)
Date: 15 Feb 2012 22:19:42 -0000
Subject: Models of DNS traffic and caches
Message-ID: <20120215221942.828.qmail@joyce.lan>

Are there any analytic or simulation models of DNS traffic and caches?

Say I have a DNS cache that handles two different kinds of traffic,
DNSBL lookups that are almost never reused, and web page lookups that
are frequently reused.  Is there a model that will predict whether
partitioning the cache would be a good idea, or capping TTL on the
DNSBLs, or other sorts of tricks?

Pointers are fine.  TIA.

R's,
John

-- 
Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly


From cra at WPI.EDU  Wed Feb 15 16:36:15 2012
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 15 Feb 2012 17:36:15 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <20120215223615.GN5968@angus.ind.WPI.EDU>

ICMP is bad, and should be completely blocked for "security".

On Wed, Feb 15, 2012 at 02:47:15PM -0600, John Kristoff wrote:
> Hi friends,
> 
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
> 
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers.  Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
> 
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
> 
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
> 
> John


From gbakos at alpinista.org  Wed Feb 15 16:36:32 2012
From: gbakos at alpinista.org (George Bakos)
Date: Wed, 15 Feb 2012 22:36:32 +0000
Subject: Anonymous planning a root-servers party
Message-ID: <20120215223632.7545efa0@alpinista.org>

As I hadn't seen it discussed here, I'll have to assume that many
NANOGers haven't seen the latest rant from Anonymous:

"To protest SOPA, Wallstreet, our irresponsible leaders and the
beloved bankers who are starving the world for their own selfish
needs out of sheer sadistic fun, On March 31, the Internet will go
Black. 
In order to shut the Internet down, one thing is to be done. Down the
13 root DNS servers of the Internet. Those servers are as follow:"

http://pastebin.com/XZ3EGsbc

13 servers. Sshhhhh! Don't anybody mention anycast - it's a secret.


From shortdudey123 at gmail.com  Wed Feb 15 16:40:47 2012
From: shortdudey123 at gmail.com (Grant Ridder)
Date: Wed, 15 Feb 2012 16:40:47 -0600
Subject: Anonymous planning a root-servers party
In-Reply-To: <20120215223632.7545efa0@alpinista.org>
References: <20120215223632.7545efa0@alpinista.org>
Message-ID: <CAPiURgUGbx0mV65vUXqSC+YdUjnAPpGAZ=kC1Z_bCZH5nx1-JQ@mail.gmail.com>

I really don't think  Anonymous is dumb enough to forget about anycast.  If
i remember right, another group tried to take down the root servers within
the past 5 or 6 years and only took out around 20 or 25.

-Grant

On Wed, Feb 15, 2012 at 4:36 PM, George Bakos <gbakos at alpinista.org> wrote:

> As I hadn't seen it discussed here, I'll have to assume that many
> NANOGers haven't seen the latest rant from Anonymous:
>
> "To protest SOPA, Wallstreet, our irresponsible leaders and the
> beloved bankers who are starving the world for their own selfish
> needs out of sheer sadistic fun, On March 31, the Internet will go
> Black.
> In order to shut the Internet down, one thing is to be done. Down the
> 13 root DNS servers of the Internet. Those servers are as follow:"
>
> http://pastebin.com/XZ3EGsbc
>
> 13 servers. Sshhhhh! Don't anybody mention anycast - it's a secret.
>
>

From jared at puck.nether.net  Wed Feb 15 16:42:11 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 15 Feb 2012 17:42:11 -0500
Subject: Anonymous planning a root-servers party
In-Reply-To: <20120215223632.7545efa0@alpinista.org>
References: <20120215223632.7545efa0@alpinista.org>
Message-ID: <5F40C962-FF7E-4197-BBA5-5E891104B17C@puck.nether.net>


On Feb 15, 2012, at 5:36 PM, George Bakos wrote:

> As I hadn't seen it discussed here, I'll have to assume that many
> NANOGers haven't seen the latest rant from Anonymous:
> 
> "To protest SOPA, Wallstreet, our irresponsible leaders and the
> beloved bankers who are starving the world for their own selfish
> needs out of sheer sadistic fun, On March 31, the Internet will go
> Black. 
> In order to shut the Internet down, one thing is to be done. Down the
> 13 root DNS servers of the Internet. Those servers are as follow:"
> 
> http://pastebin.com/XZ3EGsbc
> 
> 13 servers. Sshhhhh! Don't anybody mention anycast - it's a secret.

As is TCP, which requires a 3-way handshake, oh and the 41 day TTL on the . zone

2 day TTL on the served data pointing to the com zone, so any well-behaved server should only touch the root once every ~172800 seconds.

This means the activity would have to be sustained and unmitigated for many hours (days) to have a significant impact.

- Jared



From cabo at tzi.org  Wed Feb 15 16:49:25 2012
From: cabo at tzi.org (Carsten Bormann)
Date: Wed, 15 Feb 2012 23:49:25 +0100
Subject: Common operational misconceptions
In-Reply-To: <20120215223615.GN5968@angus.ind.WPI.EDU>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215223615.GN5968@angus.ind.WPI.EDU>
Message-ID: <FC93A3C8-7DC0-4325-BD72-5BEFF5ED37A6@tzi.org>

On Feb 15, 2012, at 23:36, Chuck Anderson wrote:

> security

That must be the top of the list:

Switches provide security (by traffic isolation)
DHCP provides security (by only letting in hosts we know)
MAC address filtering provides security (fill in the blanks?)
NAC provides security
NATs provide security
Firewalls provide security
Buying Vendor-_ provides security

Gr??e, Carsten



From tkapela at gmail.com  Wed Feb 15 16:51:44 2012
From: tkapela at gmail.com (Anton Kapela)
Date: Wed, 15 Feb 2012 16:51:44 -0600
Subject: Common operational misconceptions
In-Reply-To: <20120215223615.GN5968@angus.ind.WPI.EDU>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215223615.GN5968@angus.ind.WPI.EDU>
Message-ID: <CAJWBqEtLH60sXTRQ=ppP9-XVV56OeJ1hMtKancCyW_hQ1=9teA@mail.gmail.com>

On Wed, Feb 15, 2012 at 4:36 PM, Chuck Anderson <cra at wpi.edu> wrote:
> ICMP is bad, and should be completely blocked for "security".

I can't tell if this reply is to say "this ought to be done" or if
"this is often done, and should not be."

Clarify?

-tk


From eric at eparsonage.com  Wed Feb 15 16:51:45 2012
From: eric at eparsonage.com (Eric Parsonage)
Date: Thu, 16 Feb 2012 09:21:45 +1030
Subject: Anonymous planning a root-servers party
In-Reply-To: <5F40C962-FF7E-4197-BBA5-5E891104B17C@puck.nether.net>
References: <20120215223632.7545efa0@alpinista.org>
 <5F40C962-FF7E-4197-BBA5-5E891104B17C@puck.nether.net>
Message-ID: <D9FA5D45-E125-4BE4-9222-FFEDC207F1BB@eparsonage.com>

They could just mess with BGP announcements. If you can't route to the root servers they may as well not exist. 

-Eric


On 16/02/2012, at 9:12 AM, Jared Mauch wrote:

> 
> On Feb 15, 2012, at 5:36 PM, George Bakos wrote:
> 
>> As I hadn't seen it discussed here, I'll have to assume that many
>> NANOGers haven't seen the latest rant from Anonymous:
>> 
>> "To protest SOPA, Wallstreet, our irresponsible leaders and the
>> beloved bankers who are starving the world for their own selfish
>> needs out of sheer sadistic fun, On March 31, the Internet will go
>> Black. 
>> In order to shut the Internet down, one thing is to be done. Down the
>> 13 root DNS servers of the Internet. Those servers are as follow:"
>> 
>> http://pastebin.com/XZ3EGsbc
>> 
>> 13 servers. Sshhhhh! Don't anybody mention anycast - it's a secret.
> 
> As is TCP, which requires a 3-way handshake, oh and the 41 day TTL on the . zone
> 
> 2 day TTL on the served data pointing to the com zone, so any well-behaved server should only touch the root once every ~172800 seconds.
> 
> This means the activity would have to be sustained and unmitigated for many hours (days) to have a significant impact.
> 
> - Jared
> 
> 



From rsk at gsp.org  Wed Feb 15 16:52:44 2012
From: rsk at gsp.org (Rich Kulawiec)
Date: Wed, 15 Feb 2012 17:52:44 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <20120215225244.GA25272@gsp.org>

ICMP is evil.
Firewalls can be configured default-permit.
Firewalls can be configured unidirectionally.
Firewalls will solve our security issues.
Antivirus will solve our security issues.
IDS/IPS will solve our security issues.
Audits and checklists will solve our security issues.
Our network will never emit abuse or attacks.
Our users can be trained.
We must do something; this is something; let's do this.
We can add security later.
We're not a target.
We don't need to read our logs.
What logs?

(with apologies to Marcus Ranum, from whom I've shamelessly
cribbed several of these)

---rsk


From mike.lyon at gmail.com  Wed Feb 15 16:53:34 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Wed, 15 Feb 2012 14:53:34 -0800
Subject: Common operational misconceptions
In-Reply-To: <FC93A3C8-7DC0-4325-BD72-5BEFF5ED37A6@tzi.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215223615.GN5968@angus.ind.WPI.EDU>
 <FC93A3C8-7DC0-4325-BD72-5BEFF5ED37A6@tzi.org>
Message-ID: <CAFFgAjDwNmtOKs1y35dQSZ-w41Hh4U0onQ2r-KL1TpyVksnRUg@mail.gmail.com>

With security in mind:

Use other VLANs other than vlan1. Disable vlan1. Disable ports (physical
and logical) that aren't in use. Encrypt your passwords in your config, etc
etc etc...

On Wed, Feb 15, 2012 at 2:49 PM, Carsten Bormann <cabo at tzi.org> wrote:

> On Feb 15, 2012, at 23:36, Chuck Anderson wrote:
>
> > security
>
> That must be the top of the list:
>
> Switches provide security (by traffic isolation)
> DHCP provides security (by only letting in hosts we know)
> MAC address filtering provides security (fill in the blanks?)
> NAC provides security
> NATs provide security
> Firewalls provide security
> Buying Vendor-_ provides security
>
> Gr??e, Carsten
>
>
>


-- 
Mike Lyon
408-621-4826
mike.lyon at gmail.com

http://www.linkedin.com/in/mlyon

From cra at WPI.EDU  Wed Feb 15 17:02:58 2012
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 15 Feb 2012 18:02:58 -0500
Subject: Common operational misconceptions
In-Reply-To: <CAJWBqEtLH60sXTRQ=ppP9-XVV56OeJ1hMtKancCyW_hQ1=9teA@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215223615.GN5968@angus.ind.WPI.EDU>
 <CAJWBqEtLH60sXTRQ=ppP9-XVV56OeJ1hMtKancCyW_hQ1=9teA@mail.gmail.com>
Message-ID: <20120215230258.GQ5968@angus.ind.WPI.EDU>

On Wed, Feb 15, 2012 at 04:51:44PM -0600, Anton Kapela wrote:
> On Wed, Feb 15, 2012 at 4:36 PM, Chuck Anderson <cra at wpi.edu> wrote:
> > ICMP is bad, and should be completely blocked for "security".
> 
> I can't tell if this reply is to say "this ought to be done" or if
> "this is often done, and should not be."
> 
> Clarify?

This thread is about misconceptions.  What I said was a common
misconception that "all ICMP should be blocked for security reasons".
In reality, some kinds of ICMP are REQUIRED for proper functioning of
an internetwork for things like Path MTU Discovery (ICMP Fragmentation
Needed/Packet Too Big).  Other kinds of ICMP are good to allow for
being nice to the users and applications by informing them of an error
immediately rather than forcing them to wait for a timeout (ICMP
Destination Unreachable).


From marka at isc.org  Wed Feb 15 17:13:57 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 16 Feb 2012 10:13:57 +1100
Subject: Anonymous planning a root-servers party
In-Reply-To: Your message of "Wed, 15 Feb 2012 17:42:11 CDT."
 <5F40C962-FF7E-4197-BBA5-5E891104B17C@puck.nether.net>
References: <20120215223632.7545efa0@alpinista.org>
 <5F40C962-FF7E-4197-BBA5-5E891104B17C@puck.nether.net>
Message-ID: <20120215231357.1A77B1D65435@drugs.dv.isc.org>


In message <5F40C962-FF7E-4197-BBA5-5E891104B17C at puck.nether.net>, Jared Mauch 
writes:
> 
> On Feb 15, 2012, at 5:36 PM, George Bakos wrote:
> 
> > As I hadn't seen it discussed here, I'll have to assume that many
> > NANOGers haven't seen the latest rant from Anonymous:
> >=20
> > "To protest SOPA, Wallstreet, our irresponsible leaders and the
> > beloved bankers who are starving the world for their own selfish
> > needs out of sheer sadistic fun, On March 31, the Internet will go
> > Black.=20
> > In order to shut the Internet down, one thing is to be done. Down the
> > 13 root DNS servers of the Internet. Those servers are as follow:"
> >=20
> > http://pastebin.com/XZ3EGsbc
> >=20
> > 13 servers. Sshhhhh! Don't anybody mention anycast - it's a secret.
> 
> As is TCP, which requires a 3-way handshake, oh and the 41 day TTL on =
> the . zone
> 
> 2 day TTL on the served data pointing to the com zone, so any =
> well-behaved server should only touch the root once every ~172800 =
> seconds.
> 
> This means the activity would have to be sustained and unmitigated for =
> many hours (days) to have a significant impact.
> 
> - Jared

Or just slave the root zone.  1 million root servers is more robust
than the hundred or so we have today and given the root is signed
you can verify the answers returned.

One can have your own, offical, F root server instance if you want.
A number of ISP already have one.  I think a number of the other
root server operators do something similar.

One can hijack one of the official address and replace the A and AAAA
records with local address.  This one does cause issues for any one
wanting to lookup the hijacked address.

One can use static-stub in named and simlar mechanisms in other
nameservers to send root zone traffic to a local instance.

On can use multiple views, match-recursive and forwarder zones in
forward first mode to validate answer from the other view using
tsig to reach the other view.  You can also us this to get AD set
on answers from your local zones.

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


From jeff-kell at utc.edu  Wed Feb 15 17:18:21 2012
From: jeff-kell at utc.edu (Jeff Kell)
Date: Wed, 15 Feb 2012 18:18:21 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215230258.GQ5968@angus.ind.WPI.EDU>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215223615.GN5968@angus.ind.WPI.EDU>
 <CAJWBqEtLH60sXTRQ=ppP9-XVV56OeJ1hMtKancCyW_hQ1=9teA@mail.gmail.com>
 <20120215230258.GQ5968@angus.ind.WPI.EDU>
Message-ID: <4F3C3D3D.1070204@utc.edu>

(1) Block all ICMP (obviously some are required for normal operations,
unreachables, pMTU too large/DF set, etc).
(2) Block certain ports (blindly, w/o at least "established") taking out
legitimate ephemeral port usage.
(3) Local uRPF is unnecesary (or source spoofing mitigation in general)
(4) Automagical things are necessary (Microsoft proprietary, UPnP, Apple
Bonjour, mDNS, etc)
(5) WAN routing to multiple providers will automagically load-balance
automagically.  or for that matter...
(6) IGP routing across multiple paths will automagically load-balance
automagically.  Or for that matter...
(7) Port-channel (link aggregation) will load-balance automagically.
(8) Connectivity/throughput issues are always local or first-hop.  (We
have a gig connection, why am I not getting a gig throughput)

I'm sure there are more, but those were at the top of my head :)

Jeff




From algold at lncc.br  Wed Feb 15 17:23:13 2012
From: algold at lncc.br (Alexandre Grojsgold)
Date: Wed, 15 Feb 2012 21:23:13 -0200
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <4F3C3E61.6050401@lncc.br>


Telco provided VPN makes communication between your sites secure.

If you can use (virtual) circuits, even better.


-- Alg


From ask at develooper.com  Wed Feb 15 17:30:11 2012
From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=)
Date: Wed, 15 Feb 2012 15:30:11 -0800
Subject: SSL Certificates
In-Reply-To: <CA+kZPgYB4KBgbqEh9uS5+R=CcjH_s0uy9j-rnKL92sNes4ktaQ@mail.gmail.com>
References: <CA+kZPgYB4KBgbqEh9uS5+R=CcjH_s0uy9j-rnKL92sNes4ktaQ@mail.gmail.com>
Message-ID: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>


On Jan 6, 2012, at 6:15, Michael Carey wrote:

> Looking for a recommendation on who to buy affordable and reputable SSL
> certificates from?  Symantec, Thawte, and Comodo are the names that come to
> mind, just wondering if there are others folks use.

Almost everyone are basically just selling an "activation" with one of the SSL certificate authorities.

I usually buy a "RapidSSL" (Verisign) certificate from https://www.sslmatrix.com/ -- they seem to have some of the best prices and the rapidssl enrollment process is very efficient (at least for the cheap automatically "validated" products).


Ask

-- 
http://askask.com/

From meirea at charterschoolit.com  Wed Feb 15 18:00:51 2012
From: meirea at charterschoolit.com (Mario Eirea)
Date: Thu, 16 Feb 2012 00:00:51 +0000
Subject: Wireless Recommendations
In-Reply-To: <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
 <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>,
 <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>
Message-ID: <C95B38A68C80744C8B371447DB6EE98C041D7E@CSIT-SRV-MBX-01.charterschoolit.local>

Just be careful with Xirrus. A little known secret is that only 3 of those radios can be running in the 2.4ghz band at any time.

Mario Eirea
IT Department
Charter School IT
20803 Johnson Street
Pembroke Pines, FL  33029
Ph: 954-435-7827
Cell: 305-742-6524
Fax: 954-442-1762
________________________________________
From: Jonathan Lassoff [jof at thejof.com]
Sent: Tuesday, February 07, 2012 2:50 PM
To: Arzhel Younsi
Cc: Mario Eirea; nanog at nanog.org
Subject: Re: Wireless Recommendations

On Tue, Feb 7, 2012 at 11:19 AM, Arzhel Younsi <xionox at gmail.com> wrote:
> Xirrus say that they can support 640 clients with this device:
> http://www.xirrus.com/Products/Wireless-Arrays/XR-Series/XR-4000-Series
> I heard about it a couple weeks ago, didn't try it yet.

That's a pretty neat product -- it seems like it takes care of
spectrally isolating clients by utilizing 4 - 8 radios per AP-box and
8 - 24 directional sector antennas.

I feel like this addresses the suggestions that I and others gave to
utilize more APs rather than a big central one, but it just packages
it all into one box with many antennas.

Cheers,
jof


From jsw at inconcepts.biz  Wed Feb 15 18:10:04 2012
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Wed, 15 Feb 2012 19:10:04 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <CAPWAtbJ=e1JD1-=_5SQEzuJ1eh8gTEiSGfv987ecT61-s5RgMA@mail.gmail.com>

On Wed, Feb 15, 2012 at 3:47 PM, John Kristoff <jtk at cymru.com> wrote:
> I have a handful of common misconceptions that I'd put on a top 10 list,

By your classful addressing example, it sounds like these students are
what most nanog posters would consider to be entry-level.

RFC1918 is misused a lot by entry-level folks, most seem not to know
about 172.16.0.0/12

I think students should be able to learn how "traceroute" actually
works, which I have found, is a lot easier to teach as a conceptual
lesson than by just telling them "maybe the problem is in the return
path" without giving them any understanding of how or why.

MTU, Path MTU Detection, and MSS

NxGE isn't a serial 4Gbps link, and why this is so important

On the other hand, more than half of the CCIEs I have worked with are
clueless about all of the above.  :-/
-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From mohta at necom830.hpcl.titech.ac.jp  Wed Feb 15 18:13:34 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Thu, 16 Feb 2012 09:13:34 +0900
Subject: Anonymous planning a root-servers party
In-Reply-To: <20120215231357.1A77B1D65435@drugs.dv.isc.org>
References: <20120215223632.7545efa0@alpinista.org>
 <5F40C962-FF7E-4197-BBA5-5E891104B17C@puck.nether.net>
 <20120215231357.1A77B1D65435@drugs.dv.isc.org>
Message-ID: <4F3C4A2E.4020603@necom830.hpcl.titech.ac.jp>

Mark Andrews wrote:

> Or just slave the root zone.  1 million root servers is more robust
> than the hundred or so we have today

Good, I was serious to have said "not thousands but millions of"
servers when I proposed anycast root servers.

> and given the root is signed
> you can verify the answers returned.

With anycast, you can reach only a single server among servers
sharing an address even if you find some server compromised,
though you can try others with different addresses.

But, as most attacks will be DOS, DNSSEC capable servers are
weaker.

						Masataka Ohta


From ler762 at gmail.com  Wed Feb 15 18:17:57 2012
From: ler762 at gmail.com (Lee)
Date: Wed, 15 Feb 2012 19:17:57 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <CAD8GWssw53E6RqLS7x5YxJzG_+1BAHxarWQCBT6tVADCLvXiHA@mail.gmail.com>

traceroute shows _a_ path.  Your packets might have taken a different
path.  (& the return traffic yet another)

labeling something "backup link" on the network diagram doesn't make it one.

Lee


On 2/15/12, John Kristoff <jtk at cymru.com> wrote:
> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers.  Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
>
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
>
> John
>
>


From johnl at iecc.com  Wed Feb 15 18:17:00 2012
From: johnl at iecc.com (John Levine)
Date: 16 Feb 2012 00:17:00 -0000
Subject: SSL Certificates
In-Reply-To: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
Message-ID: <20120216001700.52490.qmail@joyce.lan>

>Almost everyone are basically just selling an "activation" with one of the SSL certificate authorities.
>
>I usually buy a "RapidSSL" (Verisign) certificate from https://www.sslmatrix.com/ -- they seem to have some of the best
>prices and the rapidssl enrollment process is very efficient (at least for the cheap automatically "validated"
>products).

I get my RapidSSL and Comodo from these guys.  Prices look about the same:

http://www.cheapssls.com/

If you order a cert for example.com, Comodo's also work for www.example.com, no
extra charge.

R's,
John



From mohta at necom830.hpcl.titech.ac.jp  Wed Feb 15 18:19:26 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Thu, 16 Feb 2012 09:19:26 +0900
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>

PKI is cryptographically secure.

IDN is internationalized.

IPv6 reduces router load by not allowing fragmentation.

IPv6 is operational.

						Masataka Ohta


From steve.bertrand at gmail.com  Wed Feb 15 18:23:21 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Wed, 15 Feb 2012 19:23:21 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <4F3C4C79.5080208@gmail.com>

On 2012.02.15 15:47, John Kristoff wrote:

> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.

It is ok to use non-rfc1918 (allocated/assigned) IP space internally, 
because this network will NEVER see the Internet.

Steve



From steve.bertrand at gmail.com  Wed Feb 15 18:31:50 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Wed, 15 Feb 2012 19:31:50 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3C4C79.5080208@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4C79.5080208@gmail.com>
Message-ID: <4F3C4E76.6050201@gmail.com>

On 2012.02.15 19:23, Steve Bertrand wrote:
> On 2012.02.15 15:47, John Kristoff wrote:
>
>> I have a handful of common misconceptions that I'd put on a top 10 list,
>> but I'd like to solicit from this community what it considers to be the
>> most annoying and common operational misconceptions future operators
>> often come at you with.
>
> It is ok to use non-rfc1918 (allocated/assigned) IP space internally,
> because this network will NEVER see the Internet.

...referring to space they don't own of course. Did a lot of IP address 
re-design for companies who suddenly couldn't reach microsoft.com years ago.


From michael at rancid.berkeley.edu  Wed Feb 15 18:46:44 2012
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Wed, 15 Feb 2012 16:46:44 -0800
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <4F3C51F4.2020305@rancid.berkeley.edu>

ULA is the IPv6 equivalent of RFC1918

RFCs are standards (i.e. all of them, or RFC is synonymous with standard)

The words "Internet" and "Web" can be used interchangeably

Not only does NAT provide "security," but it's NECESSARY for "security." 
  Alternatively, you can't possibly be as secure without NAT than with.

Link capacity is how fast the bits move through the wire

Security is the responsibility of the Security Group



From george.herbert at gmail.com  Wed Feb 15 18:49:53 2012
From: george.herbert at gmail.com (George Herbert)
Date: Wed, 15 Feb 2012 16:49:53 -0800
Subject: SSL Certificates
In-Reply-To: <20120216001700.52490.qmail@joyce.lan>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
Message-ID: <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>

On Wed, Feb 15, 2012 at 4:17 PM, John Levine <johnl at iecc.com> wrote:
>>Almost everyone are basically just selling an "activation" with one of the SSL certificate authorities.
>>
>>I usually buy a "RapidSSL" (Verisign) certificate from https://www.sslmatrix.com/ -- they seem to have some of the best
>>prices and the rapidssl enrollment process is very efficient (at least for the cheap automatically "validated"
>>products).
>
> I get my RapidSSL and Comodo from these guys. ?Prices look about the same:
>
> http://www.cheapssls.com/
>
> If you order a cert for example.com, Comodo's also work for www.example.com, no
> extra charge.


The problem with anything related to Verisign at the moment is that
they either don't know or haven't come clean yet how far the hackers
got into their infrastructure over the last few years.  The early
February 2012 announcements were woefully devoid of actual content.

The possibility of their root certs being compromised is nonzero.

There may be no problem; they also may be completely worthless.  Until
there's full disclosure...


-- 
-george william herbert
george.herbert at gmail.com


From nathan at atlasnetworks.us  Wed Feb 15 18:55:49 2012
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Thu, 16 Feb 2012 00:55:49 +0000
Subject: Common operational misconceptions
In-Reply-To: <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>

> IPv6 is operational.
 
How is this a misconception?  It works fine for me...

Nathan


From dlc at lampinc.com  Wed Feb 15 19:13:34 2012
From: dlc at lampinc.com (Dale Carstensen)
Date: Wed, 15 Feb 2012 18:13:34 -0700
Subject: Common operational misconceptions 
In-Reply-To: <20120215144715.18e65a55@w520.localdomain> 
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <20120216011051.1B73938D601@lampinc.com>

NANOG don't need no stinkin' glossary, everybody knows what our alphabet
soup means.

Getting a file by bittorrent will always be faster and stress the network
less than downloading it by FTP or HTTP.

The best wide-area network topology is exactly the same as that used by
the Bell network of decades ago.

Corollary of the above, the best back-up route between San Francisco
and Los Angeles in the event of a fiber cut in San Jose is Chicago
or Virginia, not Fresno or Bakersfield.

The only way to provide Metropolitan Optical Ethernet is to install a
Cisco router that costs over one million dollars.

Distance does not matter.  Serve your site from California or Virginia,
and it will work in the panhandle of Oklahoma or the Australian outback
just as well as a closer location would.

Fiber is just too fast, all networking should be wireless.

No traffic is ever wasteful, just get bigger pipes and all problems
will be solved.




From jbates at brightok.net  Wed Feb 15 19:20:38 2012
From: jbates at brightok.net (Jack Bates)
Date: Wed, 15 Feb 2012 19:20:38 -0600
Subject: Common operational misconceptions
In-Reply-To: <4F3C2D12.7010001@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215215200.GG3353@dan.olp.net> <4F3C2D12.7010001@gmail.com>
Message-ID: <4F3C59E6.2040504@brightok.net>

A few for me that come to mind which haven't been covered yet.

*) Latency, jitter, etc when pinging a router means  packets going 
through the router suffer the same fate.

Never fails that I get a call about the latency changes that occur every 
60 seconds, especially on software based routers. uh, huh.

*) admin/admin is okay in a private network behind a firewall

Oh, look, a console port!

*) Assign arbitrary MTUs in a layer 2 transport network based on exactly 
what customers order.

*) MTU/packet/frame/ping size means the same thing on all vendors.

*) If Wireshark looks right, it must be right (unless Windows discarded 
1 (and only 1) layer of 802.1q tags)

*) Upgrades should always be done, even when there's no relevant 
security or functionality that is needed in newer code.

Amazing how many code changes break things which don't necessarily show 
up in test environments but will show in production networks (Your mpls 
worked for months with an invalid router-id configured, and then broke 
when you change codes? DHCP worked fine, but after upgrade quit 
accepting <300 byte DHCP packets?).


Jack


From marka at isc.org  Wed Feb 15 19:32:31 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 16 Feb 2012 12:32:31 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Wed, 15 Feb 2012 14:14:31 -0800."
 <4F3C2E47.80903@dougbarton.us>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215220653.GA59477@ussenterprise.ufp.org> <4F3C2E47.80903@dougbarton.us>
Message-ID: <20120216013231.A0B801D66455@drugs.dv.isc.org>


In message <4F3C2E47.80903 at dougbarton.us>, Doug Barton writes:
> 
> DNS only uses UDP
> DNS only uses 512 byte UDP packets
> 
> or maybe just..
> 
> DNS is easy

Or that it is correct/does no harm to filter fragmented packet / icmp.

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


From meirea at charterschoolit.com  Wed Feb 15 20:07:36 2012
From: meirea at charterschoolit.com (Mario Eirea)
Date: Thu, 16 Feb 2012 02:07:36 +0000
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <742C02BD-93F9-4EC4-96FE-ADC2BFAE5E30@charterschoolit.com>

Something that makes me crawl out of my skin is when they refer to an access point as "router". 

-Mario Eirea

On Feb 15, 2012, at 3:47 PM, "John Kristoff" <jtk at cymru.com> wrote:

> Hi friends,
> 
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
> 
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers.  Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
> 
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
> 
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
> 
> John
> 


From shortdudey123 at gmail.com  Wed Feb 15 20:12:44 2012
From: shortdudey123 at gmail.com (Grant Ridder)
Date: Wed, 15 Feb 2012 20:12:44 -0600
Subject: Common operational misconceptions
In-Reply-To: <742C02BD-93F9-4EC4-96FE-ADC2BFAE5E30@charterschoolit.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <742C02BD-93F9-4EC4-96FE-ADC2BFAE5E30@charterschoolit.com>
Message-ID: <CAPiURgVe82WXB8Vo8pko8okvHVxCk3-BUcNMbiK6TJcp6k1sww@mail.gmail.com>

I whole-heartedly agree with that last one.

-Grant

On Wed, Feb 15, 2012 at 8:07 PM, Mario Eirea <meirea at charterschoolit.com>wrote:

> Something that makes me crawl out of my skin is when they refer to an
> access point as "router".
>
> -Mario Eirea
>
> On Feb 15, 2012, at 3:47 PM, "John Kristoff" <jtk at cymru.com> wrote:
>
> > Hi friends,
> >
> > As some of you may know, I occasionally teach networking to college
> > students and I frequently encounter misconceptions about some aspect
> > of networking that can take a fair amount of effort to correct.
> >
> > For instance, a topic that has come up on this list before is how the
> > inappropriate use of classful terminology is rampant among students,
> > books and often other teachers.  Furthermore, the terminology isn't even
> > always used correctly in the original context of classful addressing.
> >
> > I have a handful of common misconceptions that I'd put on a top 10 list,
> > but I'd like to solicit from this community what it considers to be the
> > most annoying and common operational misconceptions future operators
> > often come at you with.
> >
> > I'd prefer replies off-list and can summarize back to the list if
> > there is interest.
> >
> > John
> >
>
>

From steve.bertrand at gmail.com  Wed Feb 15 20:16:35 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Wed, 15 Feb 2012 21:16:35 -0500
Subject: Common operational misconceptions
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
Message-ID: <4F3C6703.4050607@gmail.com>

On 2012.02.15 19:55, Nathan Eisenberg wrote:
>> IPv6 is operational.
>
> How is this a misconception?  It works fine for me...

Imagine an operator who is v6 ignorant, with a home provider who 
implements v6 half-assed, and tries to access a v6 site that has perhaps 
v6-only accessible nameservers, when their provider who 'offers' v6 has 
resolvers that operate only over v4.

*huge* misconception about the operational status of IPv6 (imho).

Steve


From steve.bertrand at gmail.com  Wed Feb 15 20:25:53 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Wed, 15 Feb 2012 21:25:53 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
Message-ID: <4F3C6931.1030908@gmail.com>

On 2012.02.15 19:19, Masataka Ohta wrote:

> IPv6 is operational.

This is an intriguing statement. Any ops/eng I know who have claimed
this, actually know what they are talking about, so it is factual. I've
never heard anyone claim this in a way that could be a misconception.

I state further in this sub-thread how the opposite could be true though :)

Steve


From phil at cluestick.net  Wed Feb 15 20:27:17 2012
From: phil at cluestick.net (Phil Dyer)
Date: Wed, 15 Feb 2012 21:27:17 -0500
Subject: Common operational misconceptions
In-Reply-To: <FC93A3C8-7DC0-4325-BD72-5BEFF5ED37A6@tzi.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215223615.GN5968@angus.ind.WPI.EDU>
 <FC93A3C8-7DC0-4325-BD72-5BEFF5ED37A6@tzi.org>
Message-ID: <CAB+BaiMELqqzaP1+AwSDt8dT7SETfy-4QW=KsYwAsSruuNr3Lw@mail.gmail.com>

On Wed, Feb 15, 2012 at 5:49 PM, Carsten Bormann <cabo at tzi.org> wrote:
> On Feb 15, 2012, at 23:36, Chuck Anderson wrote:
>
>> security
>
> That must be the top of the list:

as a segue to....

> NATs provide security


From dhc2 at dcrocker.net  Wed Feb 15 20:37:42 2012
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Wed, 15 Feb 2012 18:37:42 -0800
Subject: Anonymous planning a root-servers party
In-Reply-To: <CAPiURgUGbx0mV65vUXqSC+YdUjnAPpGAZ=kC1Z_bCZH5nx1-JQ@mail.gmail.com>
References: <20120215223632.7545efa0@alpinista.org>
 <CAPiURgUGbx0mV65vUXqSC+YdUjnAPpGAZ=kC1Z_bCZH5nx1-JQ@mail.gmail.com>
Message-ID: <4F3C6BF6.6080609@dcrocker.net>



On 2/15/2012 2:40 PM, Grant Ridder wrote:
> I really don't think  Anonymous is dumb enough to forget about anycast.

Given their track record, it does seem advisable to take the threat seriously, 
whatever taking it seriously might mean...


>  If
> i remember right, another group tried to take down the root servers within
> the past 5 or 6 years and only took out around 20 or 25.

Some discussions about that I recall guessed that it was an experimental probe, 
for learning how to do a better attack.  (Remember that 9/11 was a revision of a 
prior attack on the towers.)

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


From marka at isc.org  Wed Feb 15 21:12:07 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 16 Feb 2012 14:12:07 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Wed, 15 Feb 2012 21:16:35 CDT."
 <4F3C6703.4050607@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
Message-ID: <20120216031208.132481D76BD5@drugs.dv.isc.org>


In message <4F3C6703.4050607 at gmail.com>, Steve Bertrand writes:
> On 2012.02.15 19:55, Nathan Eisenberg wrote:
> >> IPv6 is operational.
> >
> > How is this a misconception?  It works fine for me...
> 
> Imagine an operator who is v6 ignorant, with a home provider who 
> implements v6 half-assed, and tries to access a v6 site that has perhaps 
> v6-only accessible nameservers, when their provider who 'offers' v6 has 
> resolvers that operate only over v4.
>
> *huge* misconception about the operational status of IPv6 (imho).

This doesn't prove that IPv6 is not operational.  All it proves is
people can misconfigure things.  If you provide the recursive
nameservers with IPv6 access they will make queries over IPv6 even
if they only accept queries over IPv4.

If you want to know if your resolver talks IPv6 to the world and
supports 4096 EDNS UDP messages the following query will tell you.

		dig edns-v6-ok.isc.org txt

Similarly for IPv4.

		dig edns-v4-ok.isc.org txt

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


From mohta at necom830.hpcl.titech.ac.jp  Wed Feb 15 21:24:05 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Thu, 16 Feb 2012 12:24:05 +0900
Subject: Common operational misconceptions
In-Reply-To: <20120216031208.132481D76BD5@drugs.dv.isc.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
Message-ID: <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>

Mark Andrews wrote:

> This doesn't prove that IPv6 is not operational.  All it proves is
> people can misconfigure things.

How do operators configure their equipments to treat
ICMP packet too big generated against multicast and
unicast?

Note that, even if they do not enable inter-subnet
multicast in their domains, the ICMP packets may
still transit over or implode within their domains.

Note also that some network processors can't efficiently
distinguish ICMP packets generated against multicast and
unicast.

					Masataka Ohta


From w3yni1 at gmail.com  Wed Feb 15 21:26:11 2012
From: w3yni1 at gmail.com (Charles Mills)
Date: Wed, 15 Feb 2012 22:26:11 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
 <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>
Message-ID: <CAOF0KO92Bg3tzFa5PcF4ATka=-AqM8=9QegP6b+4-_3gHdRJaA@mail.gmail.com>

Not understanding RFC1918.  Actually got read the riot act by someone
because I worked for an organization that used 10.0.0.0/8 and that was
"their" network and "they" owned it.

Chuck

2012/2/15 Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>

> Mark Andrews wrote:
>
> > This doesn't prove that IPv6 is not operational.  All it proves is
> > people can misconfigure things.
>
> How do operators configure their equipments to treat
> ICMP packet too big generated against multicast and
> unicast?
>
> Note that, even if they do not enable inter-subnet
> multicast in their domains, the ICMP packets may
> still transit over or implode within their domains.
>
> Note also that some network processors can't efficiently
> distinguish ICMP packets generated against multicast and
> unicast.
>
>                                        Masataka Ohta
>
>

From faisal at snappydsl.net  Wed Feb 15 21:50:53 2012
From: faisal at snappydsl.net (Faisal Imtiaz)
Date: Wed, 15 Feb 2012 22:50:53 -0500
Subject: Wireless Recommendations
In-Reply-To: <C95B38A68C80744C8B371447DB6EE98C041D7E@CSIT-SRV-MBX-01.charterschoolit.local>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
 <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>,
 <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C041D7E@CSIT-SRV-MBX-01.charterschoolit.local>
Message-ID: <4F3C7D1D.7070203@snappydsl.net>

Is that because of Channel Spacing ? or some other reason ?

Regards.

Faisal Imtiaz
Snappy Internet&  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net


On 2/15/2012 7:00 PM, Mario Eirea wrote:
> Just be careful with Xirrus. A little known secret is that only 3 of those radios can be running in the 2.4ghz band at any time.
>
> Mario Eirea
> IT Department
> Charter School IT
> 20803 Johnson Street
> Pembroke Pines, FL  33029
> Ph: 954-435-7827
> Cell: 305-742-6524
> Fax: 954-442-1762
> ________________________________________
> From: Jonathan Lassoff [jof at thejof.com]
> Sent: Tuesday, February 07, 2012 2:50 PM
> To: Arzhel Younsi
> Cc: Mario Eirea; nanog at nanog.org
> Subject: Re: Wireless Recommendations
>
> On Tue, Feb 7, 2012 at 11:19 AM, Arzhel Younsi<xionox at gmail.com>  wrote:
>> Xirrus say that they can support 640 clients with this device:
>> http://www.xirrus.com/Products/Wireless-Arrays/XR-Series/XR-4000-Series
>> I heard about it a couple weeks ago, didn't try it yet.
> That's a pretty neat product -- it seems like it takes care of
> spectrally isolating clients by utilizing 4 - 8 radios per AP-box and
> 8 - 24 directional sector antennas.
>
> I feel like this addresses the suggestions that I and others gave to
> utilize more APs rather than a big central one, but it just packages
> it all into one box with many antennas.
>
> Cheers,
> jof
>
>



From jof at thejof.com  Wed Feb 15 21:54:29 2012
From: jof at thejof.com (Jonathan Lassoff)
Date: Wed, 15 Feb 2012 19:54:29 -0800
Subject: Wireless Recommendations
In-Reply-To: <4F3C7D1D.7070203@snappydsl.net>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
 <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>
 <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C041D7E@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3C7D1D.7070203@snappydsl.net>
Message-ID: <CAHsqw9vQTw7nZPzrvgtVqqRcc=aOgwsu1cNZLDRV6vP8HyPR=Q@mail.gmail.com>

On Wed, Feb 15, 2012 at 7:50 PM, Faisal Imtiaz <faisal at snappydsl.net> wrote:
> Is that because of Channel Spacing ? or some other reason ?

I would presume channel spacing. In FCC-land, there are only 3
non-overlapping 20 Mhz bandwidths available.

--j


From jbaino at gmail.com  Wed Feb 15 22:13:54 2012
From: jbaino at gmail.com (Jeremy)
Date: Wed, 15 Feb 2012 23:13:54 -0500
Subject: 802.11 MAC Point Coordination Function
Message-ID: <CAJCOWetn9o5cfm2LWS5z9-pb1SvPTmVm8GqstLt9fNZvzW2yaA@mail.gmail.com>

Hi All,
I'm doing some research on 802.11 quality of service, congestion control,
etc. I'm trying to find some information on the Point Coordination
Function, a polling based access control method, but I'm having a hard time
finding much in the way of vendor support. I have access to some cisco
1242's, 1140's and 1252's and I've been searching the Cisco's site and
can't find a real answer on whether or not it's supported let alone how to
configure it.

Does anyone have any experience with this? Does Cisco have some special
name for it aside from PCF? Any help would be appreciated!

Thanks,
Jeremy

From meirea at charterschoolit.com  Wed Feb 15 22:14:28 2012
From: meirea at charterschoolit.com (Mario Eirea)
Date: Thu, 16 Feb 2012 04:14:28 +0000
Subject: Wireless Recommendations
In-Reply-To: <CAHsqw9vQTw7nZPzrvgtVqqRcc=aOgwsu1cNZLDRV6vP8HyPR=Q@mail.gmail.com>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
 <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>
 <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C041D7E@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3C7D1D.7070203@snappydsl.net>,
 <CAHsqw9vQTw7nZPzrvgtVqqRcc=aOgwsu1cNZLDRV6vP8HyPR=Q@mail.gmail.com>
Message-ID: <C95B38A68C80744C8B371447DB6EE98C042796@CSIT-SRV-MBX-01.charterschoolit.local>

This is my guess too, i guess there is some bleed over from their antenna arrays.

Mario Eirea
IT Department
Charter School IT
20803 Johnson Street
Pembroke Pines, FL  33029
Ph: 954-435-7827
Cell: 305-742-6524
Fax: 954-442-1762
________________________________________
From: Jonathan Lassoff [jof at thejof.com]
Sent: Wednesday, February 15, 2012 10:54 PM
To: Faisal at snappydsl.net
Cc: nanog at nanog.org
Subject: Re: Wireless Recommendations

On Wed, Feb 15, 2012 at 7:50 PM, Faisal Imtiaz <faisal at snappydsl.net> wrote:
> Is that because of Channel Spacing ? or some other reason ?

I would presume channel spacing. In FCC-land, there are only 3
non-overlapping 20 Mhz bandwidths available.

--j



From marka at isc.org  Wed Feb 15 22:27:39 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 16 Feb 2012 15:27:39 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Thu, 16 Feb 2012 12:24:05 +0900."
 <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>
Message-ID: <20120216042740.5EA131D7F6FE@drugs.dv.isc.org>


In message <4F3C76D5.9040603 at necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
> 
> > This doesn't prove that IPv6 is not operational.  All it proves is
> > people can misconfigure things.
> 
> How do operators configure their equipments to treat
> ICMP packet too big generated against multicast and
> unicast?

Well you need to go out of your way to get a ICMP PTB for IPv6
multicast as the default is to fragment multicast packets at the
source at network minimum mtu (RFC3542 - May 2003).  That's not to
say it won't happen.

As for generation of PTB you rate limit them the way you do for
IPv4.

> Note that, even if they do not enable inter-subnet
> multicast in their domains, the ICMP packets may
> still transit over or implode within their domains.
> 
> Note also that some network processors can't efficiently
> distinguish ICMP packets generated against multicast and
> unicast.

And why do you need to distingish them?  You look at the inner
packet not the ICMP source if you want to rate limit return traffic.

> 					Masataka Ohta
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From joelja at bogus.com  Wed Feb 15 22:41:10 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Wed, 15 Feb 2012 20:41:10 -0800
Subject: Wireless Recommendations
In-Reply-To: <C95B38A68C80744C8B371447DB6EE98C042796@CSIT-SRV-MBX-01.charterschoolit.local>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
 <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>
 <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C041D7E@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3C7D1D.7070203@snappydsl.net>,
 <CAHsqw9vQTw7nZPzrvgtVqqRcc=aOgwsu1cNZLDRV6vP8HyPR=Q@mail.gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C042796@CSIT-SRV-MBX-01.charterschoolit.local>
Message-ID: <4F3C88E6.3000208@bogus.com>

On 2/15/12 20:14 , Mario Eirea wrote:
> This is my guess too, i guess there is some bleed over from their antenna arrays.

Even the most directional sector antenna in the world has a back lobe...
and there there's the clients...

there's no magic bullet you simply can't do it all in one ap with the
space available.

> Mario Eirea
> IT Department
> Charter School IT
> 20803 Johnson Street
> Pembroke Pines, FL  33029
> Ph: 954-435-7827
> Cell: 305-742-6524
> Fax: 954-442-1762
> ________________________________________
> From: Jonathan Lassoff [jof at thejof.com]
> Sent: Wednesday, February 15, 2012 10:54 PM
> To: Faisal at snappydsl.net
> Cc: nanog at nanog.org
> Subject: Re: Wireless Recommendations
> 
> On Wed, Feb 15, 2012 at 7:50 PM, Faisal Imtiaz <faisal at snappydsl.net> wrote:
>> Is that because of Channel Spacing ? or some other reason ?
> 
> I would presume channel spacing. In FCC-land, there are only 3
> non-overlapping 20 Mhz bandwidths available.
> 
> --j
> 
> 
> 



From steve.bertrand at gmail.com  Wed Feb 15 22:43:32 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Wed, 15 Feb 2012 23:43:32 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120216031208.132481D76BD5@drugs.dv.isc.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
Message-ID: <4F3C8974.9010308@gmail.com>

On 2012.02.15 22:12, Mark Andrews wrote:
> In message<4F3C6703.4050607 at gmail.com>, Steve Bertrand writes:
>> On 2012.02.15 19:55, Nathan Eisenberg wrote:
>>>> IPv6 is operational.
>>>
>>> How is this a misconception?  It works fine for me...
>>
>> Imagine an operator who is v6 ignorant, with a home provider who
>> implements v6 half-assed, and tries to access a v6 site that has perhaps
>> v6-only accessible nameservers, when their provider who 'offers' v6 has
>> resolvers that operate only over v4.
>>
>> *huge* misconception about the operational status of IPv6 (imho).
>
> This doesn't prove that IPv6 is not operational.  All it proves is
> people can misconfigure things.  If you provide the recursive
> nameservers with IPv6 access they will make queries over IPv6 even
> if they only accept queries over IPv4.
>
> If you want to know if your resolver talks IPv6 to the world and
> supports 4096 EDNS UDP messages the following query will tell you.
>
> 		dig edns-v6-ok.isc.org txt
>
> Similarly for IPv4.
>
> 		dig edns-v4-ok.isc.org txt

Thank you :)

Steve


From antti.ristimaki at gmx.com  Wed Feb 15 22:47:07 2012
From: antti.ristimaki at gmx.com (=?ISO-8859-1?Q?Antti_Ristim=E4ki?=)
Date: Thu, 16 Feb 2012 06:47:07 +0200
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <4F3C8A4B.1090309@gmx.com>

"IS-IS is a legacy protocol that nobody uses"


15.02.2012 22:47, John Kristoff kirjoitti:
> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers.  Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
>
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
>
> John
>



From chipps at chipps.com  Wed Feb 15 23:04:01 2012
From: chipps at chipps.com (Kenneth M. Chipps Ph.D.)
Date: Wed, 15 Feb 2012 23:04:01 -0600
Subject: Common operational misconceptions
In-Reply-To: <4F3C8A4B.1090309@gmx.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C8A4B.1090309@gmx.com>
Message-ID: <00e501ccec68$65aa8650$30ff92f0$@chipps.com>

How widespread would you say the use of IS-IS is?

Even more as to which routing protocols are used, not just in ISPs, what
percent would you give to the various ones. In other words X percent of
organizations use OSPS, Y percent use EIGRP, and so on.

-----Original Message-----
From: Antti Ristim?ki [mailto:antti.ristimaki at gmx.com] 
Sent: Wednesday, February 15, 2012 10:47 PM
To: John Kristoff
Cc: nanog at nanog.org
Subject: Re: Common operational misconceptions

"IS-IS is a legacy protocol that nobody uses"


15.02.2012 22:47, John Kristoff kirjoitti:
> Hi friends,
>
> As some of you may know, I occasionally teach networking to college 
> students and I frequently encounter misconceptions about some aspect 
> of networking that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the 
> inappropriate use of classful terminology is rampant among students, 
> books and often other teachers.  Furthermore, the terminology isn't 
> even always used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 
> list, but I'd like to solicit from this community what it considers to 
> be the most annoying and common operational misconceptions future 
> operators often come at you with.
>
> I'd prefer replies off-list and can summarize back to the list if 
> there is interest.
>
> John
>






From bmanning at vacation.karoshi.com  Wed Feb 15 23:16:18 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 16 Feb 2012 05:16:18 +0000
Subject: and now for something completely different
Message-ID: <20120216051618.GA2590@vacation.karoshi.com.>


Control of ground-state pluripotency by allelic regulation of Nanog

Nature advance online publication 12 February 2012. doi:10.1038/nature10807

Authors: Yusuke Miyanari & Maria-Elena Torres-Padilla

Pluripotency is established through genome-wide reprogramming during mammalian pre-implantation development, resulting in the formation of the naive epiblast. Reprogramming involves both the resetting of epigenetic marks and the activation of pluripotent-cell-specific genes such as Nanog and Oct4 (also known as Pou5f1). The tight regulation of these genes is crucial for reprogramming, but the mechanisms that regulate their expression in vivo have not been uncovered. Here we show that Nanog?but not Oct4?is monoallelically expressed in early pre-implantation embryos. Nanog then undergoes a progressive switch to biallelic expression during the transition towards ground-state pluripotency in the naive epiblast of the late blastocyst. Embryonic stem (ES) cells grown in leukaemia inhibitory factor (LIF) and serum express Nanog mainly monoallelically and show asynchronous replication of the Nanog locus, a feature of monoallelically expressed genes, but ES cells activate both alleles when cultured under 2i conditions, which mimic the pluripotent ground state in vitro. Live-cell imaging with reporter ES cells confirmed the allelic expression of Nanog and revealed allelic switching. The allelic expression of Nanog is regulated through the fibroblast growth factor?extracellular signal-regulated kinase signalling pathway, and it is accompanied by chromatin changes at the proximal promoter but occurs independently of DNA methylation. Nanog-heterozygous blastocysts have fewer inner-cell-mass derivatives and delayed primitive endoderm formation, indicating a role for the biallelic expression of Nanog in the timely maturation of the inner cell mass into a fully reprogrammed pluripotent epiblast. We suggest that the tight regulation of Nanog dose at the chromosome level is necessary for the acquisition of ground-state pluripotency during development. Our data highlight an unexpected role for allelic expression in controlling the dose of pluripotency factors in vivo, adding an extra level to the regulation of reprogramming.


From joelja at bogus.com  Wed Feb 15 23:57:35 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Wed, 15 Feb 2012 21:57:35 -0800
Subject: Common operational misconceptions
In-Reply-To: <00e501ccec68$65aa8650$30ff92f0$@chipps.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C8A4B.1090309@gmx.com> <00e501ccec68$65aa8650$30ff92f0$@chipps.com>
Message-ID: <4F3C9ACF.2050108@bogus.com>

On 2/15/12 21:04 , Kenneth M. Chipps Ph.D. wrote:
> How widespread would you say the use of IS-IS is?
>
> Even more as to which routing protocols are used, not just in ISPs, what
> percent would you give to the various ones. In other words X percent of
> organizations use OSPS, Y percent use EIGRP, and so on.

Using EIGRP implies your routed IGP dependent infrastructure is a
monoculture. That's probably infeasible without compromise even if you
are largely a Cisco shop.

ISIS is used in organizations other than ISPs.

> -----Original Message-----
> From: Antti Ristim?ki [mailto:antti.ristimaki at gmx.com] 
> Sent: Wednesday, February 15, 2012 10:47 PM
> To: John Kristoff
> Cc: nanog at nanog.org
> Subject: Re: Common operational misconceptions
> 
> "IS-IS is a legacy protocol that nobody uses"
> 
> 
> 15.02.2012 22:47, John Kristoff kirjoitti:
>> Hi friends,
>>
>> As some of you may know, I occasionally teach networking to college 
>> students and I frequently encounter misconceptions about some aspect 
>> of networking that can take a fair amount of effort to correct.
>>
>> For instance, a topic that has come up on this list before is how the 
>> inappropriate use of classful terminology is rampant among students, 
>> books and often other teachers.  Furthermore, the terminology isn't 
>> even always used correctly in the original context of classful addressing.
>>
>> I have a handful of common misconceptions that I'd put on a top 10 
>> list, but I'd like to solicit from this community what it considers to 
>> be the most annoying and common operational misconceptions future 
>> operators often come at you with.
>>
>> I'd prefer replies off-list and can summarize back to the list if 
>> there is interest.
>>
>> John
>>
> 
> 
> 
> 
> 
> 



From chipps at chipps.com  Thu Feb 16 00:00:04 2012
From: chipps at chipps.com (Kenneth M. Chipps Ph.D.)
Date: Thu, 16 Feb 2012 00:00:04 -0600
Subject: Common operational misconceptions
In-Reply-To: <4F3C9ACF.2050108@bogus.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C8A4B.1090309@gmx.com> <00e501ccec68$65aa8650$30ff92f0$@chipps.com>
 <4F3C9ACF.2050108@bogus.com>
Message-ID: <00f201ccec70$3a4c8f50$aee5adf0$@chipps.com>

"ISIS is used in organizations other than ISPs" Any examples you can share
of some other than ISPs?

-----Original Message-----
From: Joel jaeggli [mailto:joelja at bogus.com] 
Sent: Wednesday, February 15, 2012 11:58 PM
To: Kenneth M. Chipps Ph.D.
Cc: nanog at nanog.org
Subject: Re: Common operational misconceptions

On 2/15/12 21:04 , Kenneth M. Chipps Ph.D. wrote:
> How widespread would you say the use of IS-IS is?
>
> Even more as to which routing protocols are used, not just in ISPs, 
> what percent would you give to the various ones. In other words X 
> percent of organizations use OSPS, Y percent use EIGRP, and so on.

Using EIGRP implies your routed IGP dependent infrastructure is a
monoculture. That's probably infeasible without compromise even if you are
largely a Cisco shop.

ISIS is used in organizations other than ISPs.

> -----Original Message-----
> From: Antti Ristim?ki [mailto:antti.ristimaki at gmx.com]
> Sent: Wednesday, February 15, 2012 10:47 PM
> To: John Kristoff
> Cc: nanog at nanog.org
> Subject: Re: Common operational misconceptions
> 
> "IS-IS is a legacy protocol that nobody uses"
> 
> 
> 15.02.2012 22:47, John Kristoff kirjoitti:
>> Hi friends,
>>
>> As some of you may know, I occasionally teach networking to college 
>> students and I frequently encounter misconceptions about some aspect 
>> of networking that can take a fair amount of effort to correct.
>>
>> For instance, a topic that has come up on this list before is how the 
>> inappropriate use of classful terminology is rampant among students, 
>> books and often other teachers.  Furthermore, the terminology isn't 
>> even always used correctly in the original context of classful
addressing.
>>
>> I have a handful of common misconceptions that I'd put on a top 10 
>> list, but I'd like to solicit from this community what it considers 
>> to be the most annoying and common operational misconceptions future 
>> operators often come at you with.
>>
>> I'd prefer replies off-list and can summarize back to the list if 
>> there is interest.
>>
>> John
>>
> 
> 
> 
> 
> 
> 





From mohta at necom830.hpcl.titech.ac.jp  Thu Feb 16 00:11:32 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Thu, 16 Feb 2012 15:11:32 +0900
Subject: Common operational misconceptions
In-Reply-To: <20120216042740.5EA131D7F6FE@drugs.dv.isc.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>
 <20120216042740.5EA131D7F6FE@drugs.dv.isc.org>
Message-ID: <4F3C9E14.2060001@necom830.hpcl.titech.ac.jp>

Mark Andrews wrote:

> Well you need to go out of your way to get a ICMP PTB for IPv6
> multicast as the default is to fragment multicast packets at the
> source at network minimum mtu (RFC3542 - May 2003).  That's not to
> say it won't happen.

Yes, it will happen, because RFC3542 was, as was discussed
in IETF, written not to prohibit multicast PMTUD.

So, the problem is real.

> As for generation of PTB you rate limit them the way you do for
> IPv4.

A problem is that a lot of ICMP packet too big against unicast
is generated, because PMTUD requires hosts periodically try to
send a packet a little larger than the current PMTU.

BTW, that's why IPv6, which inhibit fragmentation by routers,
is no better than IPv4 with fragmentation enabled, because,
periodic generation of ICMP packet too big by routers is as
painful as periodic fragmentation by routers.

>> Note also that some network processors can't efficiently
>> distinguish ICMP packets generated against multicast and
>> unicast.

> And why do you need to distingish them?

We don't need to. Instead, we can just give up to use PMTUD
entirely and just send packets of 1280B or less. A problem
is that a tunnel over 1280B PMTU must always fragment 1280B
payload.

> You look at the inner
> packet not the ICMP source if you want to rate limit return traffic.

That is a possible problem.

Destination address of inner packet is located far inside
of the ICMP (beyond 64B) that it can not be used for
intrinsic filtering capability of some network processors.

					Masataka Ohta


From aftab.siddiqui at gmail.com  Thu Feb 16 00:20:37 2012
From: aftab.siddiqui at gmail.com (Aftab Siddiqui)
Date: Thu, 16 Feb 2012 11:20:37 +0500
Subject: Common operational misconceptions
In-Reply-To: <00f201ccec70$3a4c8f50$aee5adf0$@chipps.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C8A4B.1090309@gmx.com>
 <00e501ccec68$65aa8650$30ff92f0$@chipps.com>
 <4F3C9ACF.2050108@bogus.com>
 <00f201ccec70$3a4c8f50$aee5adf0$@chipps.com>
Message-ID: <CAK5YLgdv-uONoQhERb6g0V+EzevveXEEunCbiP2VecgP1n4_hg@mail.gmail.com>

Some recent questions from interview and lab sessions I took.

- I've allowed vlan X on trunk but still its not working? why do I have to
create it on every switch?
- any-any rules on firewall with AV enabled is better.
- ACL inboud/outbout misconcept. Always end up cutting the rope.
- BGP is for ISPs only.
- MPLS is for security and is fast.

Regards,

Aftab A. Siddiqui


On Thu, Feb 16, 2012 at 11:00 AM, Kenneth M. Chipps Ph.D. <chipps at chipps.com
> wrote:

> "ISIS is used in organizations other than ISPs" Any examples you can share
> of some other than ISPs?
>
> -----Original Message-----
> From: Joel jaeggli [mailto:joelja at bogus.com]
> Sent: Wednesday, February 15, 2012 11:58 PM
> To: Kenneth M. Chipps Ph.D.
> Cc: nanog at nanog.org
> Subject: Re: Common operational misconceptions
>
> On 2/15/12 21:04 , Kenneth M. Chipps Ph.D. wrote:
> > How widespread would you say the use of IS-IS is?
> >
> > Even more as to which routing protocols are used, not just in ISPs,
> > what percent would you give to the various ones. In other words X
> > percent of organizations use OSPS, Y percent use EIGRP, and so on.
>
> Using EIGRP implies your routed IGP dependent infrastructure is a
> monoculture. That's probably infeasible without compromise even if you are
> largely a Cisco shop.
>
> ISIS is used in organizations other than ISPs.
>
> > -----Original Message-----
> > From: Antti Ristim?ki [mailto:antti.ristimaki at gmx.com]
> > Sent: Wednesday, February 15, 2012 10:47 PM
> > To: John Kristoff
> > Cc: nanog at nanog.org
> > Subject: Re: Common operational misconceptions
> >
> > "IS-IS is a legacy protocol that nobody uses"
> >
> >
> > 15.02.2012 22:47, John Kristoff kirjoitti:
> >> Hi friends,
> >>
> >> As some of you may know, I occasionally teach networking to college
> >> students and I frequently encounter misconceptions about some aspect
> >> of networking that can take a fair amount of effort to correct.
> >>
> >> For instance, a topic that has come up on this list before is how the
> >> inappropriate use of classful terminology is rampant among students,
> >> books and often other teachers.  Furthermore, the terminology isn't
> >> even always used correctly in the original context of classful
> addressing.
> >>
> >> I have a handful of common misconceptions that I'd put on a top 10
> >> list, but I'd like to solicit from this community what it considers
> >> to be the most annoying and common operational misconceptions future
> >> operators often come at you with.
> >>
> >> I'd prefer replies off-list and can summarize back to the list if
> >> there is interest.
> >>
> >> John
> >>
> >
> >
> >
> >
> >
> >
>
>
>
>
>

From bmanning at vacation.karoshi.com  Thu Feb 16 00:34:21 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 16 Feb 2012 06:34:21 +0000
Subject: SSL Certificates
In-Reply-To: <20120216001700.52490.qmail@joyce.lan>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
Message-ID: <20120216063421.GA2785@vacation.karoshi.com.>

On Thu, Feb 16, 2012 at 12:17:00AM -0000, John Levine wrote:
> >Almost everyone are basically just selling an "activation" with one of the SSL certificate authorities.
> >
> >I usually buy a "RapidSSL" (Verisign) certificate from https://www.sslmatrix.com/ -- they seem to have some of the best
> >prices and the rapidssl enrollment process is very efficient (at least for the cheap automatically "validated"
> >products).
> 
> I get my RapidSSL and Comodo from these guys.  Prices look about the same:
> 
> http://www.cheapssls.com/
> 
> If you order a cert for example.com, Comodo's also work for www.example.com, no
> extra charge.
> 
> R's,
> John
> 

	Comodo ever get "fixed" ??

/bill


From jof at thejof.com  Thu Feb 16 00:42:13 2012
From: jof at thejof.com (Jonathan Lassoff)
Date: Wed, 15 Feb 2012 22:42:13 -0800
Subject: Wireless Recommendations
In-Reply-To: <4F3C88E6.3000208@bogus.com>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
 <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>
 <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C041D7E@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3C7D1D.7070203@snappydsl.net>
 <CAHsqw9vQTw7nZPzrvgtVqqRcc=aOgwsu1cNZLDRV6vP8HyPR=Q@mail.gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C042796@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3C88E6.3000208@bogus.com>
Message-ID: <CAHsqw9vRJwvqStdu8hMMRmZ3e4kcy_H7txShCZ_AXHBUFj4Dxg@mail.gmail.com>

On Wed, Feb 15, 2012 at 8:41 PM, Joel jaeggli <joelja at bogus.com> wrote:
> On 2/15/12 20:14 , Mario Eirea wrote:
>> This is my guess too, i guess there is some bleed over from their antenna arrays.
>
> Even the most directional sector antenna in the world has a back lobe...
> and there there's the clients...

Agreed. There is rarely a thing as a perfectly-directional antenna
(not without a lot of shielding, I would presume).

Since I would presume that all the radios are controlled by the same
host, perhaps it could coordinate the 802.11 DCF and sequence CTS
frames so that the various client and AP radios remain as spectrally
orthogonal as possible. There's not much you can do about the clients
transmitting RTSes, but it can be predicted to a certain extent.

> there's no magic bullet you simply can't do it all in one ap with the
> space available.

Agreed. More, lower-power APs means better spectral efficiency and
overall resilience.


--j


From mysidia at gmail.com  Thu Feb 16 00:57:25 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 16 Feb 2012 00:57:25 -0600
Subject: SSL Certificates
In-Reply-To: <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
Message-ID: <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>

On Wed, Feb 15, 2012 at 6:49 PM, George Herbert
<george.herbert at gmail.com> wrote:
> On Wed, Feb 15, 2012 at 4:17 PM, John Levine <johnl at iecc.com> wrote:
> The problem with anything related to Verisign at the moment is that

> The possibility of their root certs being compromised is nonzero.

The possibility of _ANY_  CA's root certs having been compromised is non-zero.
There's no evidence published to indicate Verisign's CA key has been
compromised,
and it's highly unlikely.

Just as there's no evidence of other CAs'  root certificate keys being
compromised.

> There may be no problem; they also may be completely worthless. ?Until
> there's full disclosure...
[snip]

They are not completely worthless until revoked,  or distrusted by web browsers.

There is a risk that any CA issued SSL certificate signed by _any_ CA
may be worthless some time in the future, if the CA chosen is later
found to have issued  sufficient quantities fraudulent certificates,
and sufficiently failed in their duties.


I suppose if you buy a SSL certificate,  you should be looking for
your CA to have insurance to reimburse the cost of the certificate
should that happen,   and an ironclad   "refund"  clause in the
agreement/contract  under which a SSL cert is issued

E.g.  A guarantee such   that the  CA will refund the complete
certification fee,   or pay for the replacement of the SSL certificate
with a  new  valid certificate   issued by another fully trusted CA,
and  compensate for any tangible loss,    resulting from the   CA's
signing certificate  being marked as untrusted by major browsers,
revoked,  or  removed from major browsers' trust list,   due to any
failure on the CA's part or compromise of their systems, resulting in
loss of trust.


--
-JH


From owen at delong.com  Thu Feb 16 01:34:02 2012
From: owen at delong.com (Owen DeLong)
Date: Wed, 15 Feb 2012 23:34:02 -0800
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <8A3EC4D2-EFAB-41FD-A1C3-E21C1B2EBD52@delong.com>


On Feb 15, 2012, at 12:47 PM, John Kristoff wrote:

> Hi friends,
> 
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
> 
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers.  Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
> 
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
> 
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
> 
> John

I think one of the most damaging fundamental misconceptions which is
not only rampant among students, but, also enterprise IT professionals
is the idea that NAT is a security tool and the inability to conceive of the
separation between NAT (header mutilation) and Stateful Inspection
(policy enforcement).

Owen



From owen at delong.com  Thu Feb 16 01:45:48 2012
From: owen at delong.com (Owen DeLong)
Date: Wed, 15 Feb 2012 23:45:48 -0800
Subject: Common operational misconceptions
In-Reply-To: <4F3C6703.4050607@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
Message-ID: <D2E0BA90-D48E-42FA-9312-9E659694837F@delong.com>


On Feb 15, 2012, at 6:16 PM, Steve Bertrand wrote:

> On 2012.02.15 19:55, Nathan Eisenberg wrote:
>>> IPv6 is operational.
>> 
>> How is this a misconception?  It works fine for me...
> 
> Imagine an operator who is v6 ignorant, with a home provider who implements v6 half-assed, and tries to access a v6 site that has perhaps v6-only accessible nameservers, when their provider who 'offers' v6 has resolvers that operate only over v4.
> 
> *huge* misconception about the operational status of IPv6 (imho).
> 
> Steve

By that definition, IPv4 is non-operational.

You can break anything if you try hard enough.

Owen



From prt at prt.org  Thu Feb 16 02:21:05 2012
From: prt at prt.org (Paul Thornton)
Date: Thu, 16 Feb 2012 08:21:05 +0000
Subject: Common operational misconceptions
In-Reply-To: <D2E0BA90-D48E-42FA-9312-9E659694837F@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
 <D2E0BA90-D48E-42FA-9312-9E659694837F@delong.com>
Message-ID: <4F3CBC71.3010401@prt.org>

On 16/02/2012 07:45, Owen DeLong wrote:
> 
> On Feb 15, 2012, at 6:16 PM, Steve Bertrand wrote:
> 
>> On 2012.02.15 19:55, Nathan Eisenberg wrote:
>>>> IPv6 is operational.
>>>
>>> How is this a misconception?  It works fine for me...
>>
>> Imagine an operator who is v6 ignorant, with a home provider who implements v6 half-assed, and tries to access a v6 site that has perhaps v6-only accessible nameservers, when their provider who 'offers' v6 has resolvers that operate only over v4.
>>
>> *huge* misconception about the operational status of IPv6 (imho).
>>
>> Steve
> 
> By that definition, IPv4 is non-operational.
> 
> You can break anything if you try hard enough.

This being well demonstrated by most of the "Internet" access provided
by hotels, for example.

-- 
Paul


From leigh.porter at ukbroadband.com  Thu Feb 16 02:32:07 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Thu, 16 Feb 2012 08:32:07 +0000
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <804FACA5-E586-4108-AED3-C1E9B2549120@ukbroadband.com>


On 15 Feb 2012, at 20:50, "John Kristoff" <jtk at cymru.com> wrote:

> Hi friends,
> 
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
> 
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers.  Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.

When I took an A level computing course in the 90s the course material still talked about primary stor and backing stor, batch jobs and the like...

Needless to say I quit in disgust but the point is that the people who write these courses are often woefully out of touch.

--
Leigh


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


From jof at thejof.com  Thu Feb 16 02:57:59 2012
From: jof at thejof.com (Jonathan Lassoff)
Date: Thu, 16 Feb 2012 00:57:59 -0800
Subject: 802.11 MAC Point Coordination Function
In-Reply-To: <CAJCOWetn9o5cfm2LWS5z9-pb1SvPTmVm8GqstLt9fNZvzW2yaA@mail.gmail.com>
References: <CAJCOWetn9o5cfm2LWS5z9-pb1SvPTmVm8GqstLt9fNZvzW2yaA@mail.gmail.com>
Message-ID: <CAHsqw9u5nsmXOJ4ZoZ-sGMh8hTHOK5tCayuJF3-E9-coHWoERw@mail.gmail.com>

On Wed, Feb 15, 2012 at 8:13 PM, Jeremy <jbaino at gmail.com> wrote:
> I'm doing some research on 802.11 quality of service, congestion control,
> etc. I'm trying to find some information on the Point Coordination
> Function, a polling based access control method, but I'm having a hard time
> finding much in the way of vendor support. I have access to some cisco
> 1242's, 1140's and 1252's and I've been searching the Cisco's site and
> can't find a real answer on whether or not it's supported let alone how to
> configure it.
>
> Does anyone have any experience with this? Does Cisco have some special
> name for it aside from PCF? Any help would be appreciated!

I know of no such feature in "classic" Aironet APs. Everything I've
run across only does classic 802.11-style DCF along with all the
stations.
You might check out the Aironet 1550, which supports forming dynamic
mesh-like topologies, though I can't speak to it as I've never laid
hands on the hardware or software.

Other vendors and hackers are implementing alternative media-access
control and coordination functions, though.
You might check out Ubiquiti's AirMax-speaking hardware or
ieee80211_tdma in FreeBSD for software MAC-capable drivers.

Cheers,
jof


From tim at pelican.org  Thu Feb 16 03:58:53 2012
From: tim at pelican.org (Tim Franklin)
Date: Thu, 16 Feb 2012 09:58:53 -0000 (GMT)
Subject: Common operational misconceptions
In-Reply-To: <804FACA5-E586-4108-AED3-C1E9B2549120@ukbroadband.com>
Message-ID: <dca78cc7-d063-4c96-b990-a5cfea77c128@mail.pelican.org>

> When I took an A level computing course in the 90s the course material
> still talked about primary stor and backing stor, batch jobs and the
> like...

I was working with a lot of batch jobs in my first development role in 1993, and still supporting overnight scheduling to make best use of the Cray by 1999.  I still leave the occasional big data set crunching overnight now.  I'll grant you it's not exactly mainstream computing, but it's not exactly up there with drum memory either...

The concept that a computer can do things when a person isn't there, or without the need for clicking things, is probably not a bad one to impart.

Regards,
Tim.


From chris at ctcampbell.com  Thu Feb 16 04:26:26 2012
From: chris at ctcampbell.com (Chris Campbell)
Date: Thu, 16 Feb 2012 10:26:26 +0000
Subject: Common operational misconceptions
In-Reply-To: <20120215225244.GA25272@gsp.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215225244.GA25272@gsp.org>
Message-ID: <5BE69C32-0E92-4C7E-B4D2-DAC646D91A0C@ctcampbell.com>

This isn't so much a list of misconceptions that recent students have as a list of misconceptions that security management have?

On 15 Feb 2012, at 22:52, Rich Kulawiec wrote:

> ICMP is evil.
> Firewalls can be configured default-permit.
> Firewalls can be configured unidirectionally.
> Firewalls will solve our security issues.
> Antivirus will solve our security issues.
> IDS/IPS will solve our security issues.
> Audits and checklists will solve our security issues.
> Our network will never emit abuse or attacks.
> Our users can be trained.
> We must do something; this is something; let's do this.
> We can add security later.
> We're not a target.
> We don't need to read our logs.
> What logs?
> 
> (with apologies to Marcus Ranum, from whom I've shamelessly
> cribbed several of these)
> 
> ---rsk
> 



From sthaug at nethelp.no  Thu Feb 16 06:01:43 2012
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Thu, 16 Feb 2012 13:01:43 +0100 (CET)
Subject: Common operational misconceptions
In-Reply-To: <20120216031208.132481D76BD5@drugs.dv.isc.org>
References: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
 <20120216031208.132481D76BD5@drugs.dv.isc.org>
Message-ID: <20120216.130143.74691634.sthaug@nethelp.no>

> If you want to know if your resolver talks IPv6 to the world and
> supports 4096 EDNS UDP messages the following query will tell you.
> 
> 		dig edns-v6-ok.isc.org txt
> 
> Similarly for IPv4.
> 
> 		dig edns-v4-ok.isc.org txt

Both PowerDNS recursor 3.3 and Nominum CNS 3.0.5 have problems
with these queries. They both get the TC answer from 149.20.64.58 /
2001:4f8:0:2::8. Then:

- CNS tries with 4000 EDNS UDP size (4000 is the CNS documented max
UDP size), gets another TC.

- PowerDNS doesn't try to used EDNS at all.

Then they both try TCP and get a RST. And then they return SERVFAIL.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no


From mwlucas at blackhelicopters.org  Thu Feb 16 06:03:24 2012
From: mwlucas at blackhelicopters.org (Michael W. Lucas)
Date: Thu, 16 Feb 2012 07:03:24 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3C8A4B.1090309@gmx.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C8A4B.1090309@gmx.com>
Message-ID: <20120216120324.GA49227@bewilderbeast.blackhelicopters.org>


"You can trust your supplier's marketing literature."

Heck, maybe just "You can trust your supplier."

==ml

> 15.02.2012 22:47, John Kristoff kirjoitti:
> >Hi friends,
> >
> >As some of you may know, I occasionally teach networking to college
> >students and I frequently encounter misconceptions about some aspect
> >of networking that can take a fair amount of effort to correct.
> >
> >For instance, a topic that has come up on this list before is how the
> >inappropriate use of classful terminology is rampant among students,
> >books and often other teachers.  Furthermore, the terminology isn't even
> >always used correctly in the original context of classful addressing.
> >
> >I have a handful of common misconceptions that I'd put on a top 10 list,
> >but I'd like to solicit from this community what it considers to be the
> >most annoying and common operational misconceptions future operators
> >often come at you with.
> >
> >I'd prefer replies off-list and can summarize back to the list if
> >there is interest.
> >
> >John
> >
> 

-- 
Michael W. Lucas 	
http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
Latest book: SSH Mastery http://www.michaelwlucas.com/nonfiction/ssh-mastery
mwlucas at BlackHelicopters.org, Twitter @mwlauthor


From lykinsbd at gmail.com  Thu Feb 16 06:11:42 2012
From: lykinsbd at gmail.com (Brett Lykins)
Date: Thu, 16 Feb 2012 07:11:42 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <-4603831956774401251@unknownmsgid>

The idea that the network will always match the documentation.

I have walked into many projects where this is not the case, but a
Junior Admin working with me can't seem to get around the fact that
the Visio we were handed isn't to be trusted and we've got to
double-check everything.

-Brett Lykins

On Feb 15, 2012, at 3:47 PM, John Kristoff <jtk at cymru.com> wrote:

> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers.  Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
>
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
>
> John


From jared at puck.nether.net  Thu Feb 16 06:31:46 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 16 Feb 2012 07:31:46 -0500
Subject: Common operational misconceptions
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
Message-ID: <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>


On Feb 15, 2012, at 7:55 PM, Nathan Eisenberg wrote:

>> IPv6 is operational.
> 
> How is this a misconception?  It works fine for me...

I think he left off "In Japan".  There's been a lot of local politics as it relates to the broken nature of IPv6 in japan.  When its there, it's not globally accessible in many cases (at the consumer or last-mile level).  Most (all?) major backbones are IPv6 capable these days, but in some cases it's 6PE vs "native".

IPv6 is operational and does work, but like any protocol there are issues.  If you are unaware, take a look at what people are trying to put into IPv4 still at IETF.  The fact that the IPv6 day went so well last year, and the IPv6 launch is coming quickly is a reminder its real.  Me?  I can't wait to have this behind us.  (Oh, and if you're not at least routing your IPv6 space to your lab/NOC LAN, get on it.  Even if you have to poke the 'security' guys who think you need an IPv6 NAT in the eye).

- Jared

From davidianwalker at gmail.com  Thu Feb 16 07:01:50 2012
From: davidianwalker at gmail.com (David Walker)
Date: Thu, 16 Feb 2012 23:31:50 +1030
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <CABE=bROXb90M3Ft7zO8DVW4zxugyEu8pMmd_+oadJHY6WnyKvA@mail.gmail.com>

Teach the TCP/IP model ...

On 16/02/2012, John Kristoff <jtk at cymru.com> wrote:
> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers.  Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
>
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
>
> John
>
>


From hank at efes.iucc.ac.il  Thu Feb 16 07:03:55 2012
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Thu, 16 Feb 2012 15:03:55 +0200
Subject: Hi speed trading - hi speed monitoring
Message-ID: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>

Nanosecond Trading Could Make Markets Go Haywire
http://www.wired.com/wiredscience/2012/02/high-speed-trading/

"Below the 950-millisecond level, where computerized trading occurs so 
quickly that human traders can't even react, no fewer than 18,520 crashes 
and spikes occurred."

Anyone who has managed a network knows that when you look at your 
MRTG/Cacti graphs at 5min, 10min ,15min intervals - all looks well.  Start 
looking at 1sec intervals and you will see spikes that hit 100% of capacity 
- even on networks running at 25% average utilization.

I guess trading and networking do have many unseen similarities.

-Hank



From owen at delong.com  Thu Feb 16 07:03:45 2012
From: owen at delong.com (Owen DeLong)
Date: Thu, 16 Feb 2012 05:03:45 -0800
Subject: Common operational misconceptions
In-Reply-To: <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
Message-ID: <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>


On Feb 16, 2012, at 4:31 AM, Jared Mauch wrote:

> 
> On Feb 15, 2012, at 7:55 PM, Nathan Eisenberg wrote:
> 
>>> IPv6 is operational.
>> 
>> How is this a misconception?  It works fine for me...
> 
> I think he left off "In Japan".  There's been a lot of local politics as it relates to the broken nature of IPv6 in japan.  When its there, it's not globally accessible in many cases (at the consumer or last-mile level).  Most (all?) major backbones are IPv6 capable these days, but in some cases it's 6PE vs "native".
> 
> IPv6 is operational and does work, but like any protocol there are issues.  If you are unaware, take a look at what people are trying to put into IPv4 still at IETF.  The fact that the IPv6 day went so well last year, and the IPv6 launch is coming quickly is a reminder its real.  Me?  I can't wait to have this behind us.  (Oh, and if you're not at least routing your IPv6 space to your lab/NOC LAN, get on it.  Even if you have to poke the 'security' guys who think you need an IPv6 NAT in the eye).
> 
> - Jared

Yes, I'm well aware of the problems being created by the attempts by NTT to force the government to let them be a residential ISP.

Owen



From jtk at cymru.com  Thu Feb 16 07:12:27 2012
From: jtk at cymru.com (John Kristoff)
Date: Thu, 16 Feb 2012 07:12:27 -0600
Subject: Common operational misconceptions
In-Reply-To: <CAOF0KO92Bg3tzFa5PcF4ATka=-AqM8=9QegP6b+4-_3gHdRJaA@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
 <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>
 <CAOF0KO92Bg3tzFa5PcF4ATka=-AqM8=9QegP6b+4-_3gHdRJaA@mail.gmail.com>
Message-ID: <20120216071227.7bf8a61e@w520.localdomain>

On Wed, 15 Feb 2012 22:26:11 -0500
Charles Mills <w3yni1 at gmail.com> wrote:

> Not understanding RFC1918.  Actually got read the riot act by someone
> because I worked for an organization that used 10.0.0.0/8 and that was
> "their" network and "they" owned it.

Once upon a time, a now deservedly defunct organization called
marchFIRST, was brought in to do a security assessment of a university
network I was involved in and one issue I recall them "identifying" was
that the university was not "RFC 1918 compliant". The following
statement was also made:

  As part of the Forum of Incident Response and Security Teams (FIRST)
  Coalition, there is no firewall between the DePaul University data
  network and the Coalition network.

*plonk*

John


From rps at maine.edu  Thu Feb 16 07:17:03 2012
From: rps at maine.edu (Ray Soucy)
Date: Thu, 16 Feb 2012 08:17:03 -0500
Subject: Common operational misconceptions
In-Reply-To: <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
Message-ID: <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>

I help with networking curriculum and labs here at the University of
Maine, especially for network security.

There seems to be (even among faculty) a gross misunderstanding of
Layer-2.  Nearly every textbook starts with IP, and talks about it as
if we were 20 years in the past.

I've found starting off with some history on Ethernet (Maine loves Bob
Metcalfe) becomes a very solid base for understanding; how "Ethernet"
today is very different; starting with hubs, bridges, collisions, and
those problems, then introducing modern switching, VLANs, broadcast
domain's etc.

Then expanding on that by introducing Layer-3 starting with its
relationship to L-2 (ARP, how packets are manipulated when a host
makes the determination if a packet is on link or needs to be routed,
etc).




On Thu, Feb 16, 2012 at 8:03 AM, Owen DeLong <owen at delong.com> wrote:
>
> On Feb 16, 2012, at 4:31 AM, Jared Mauch wrote:
>
>>
>> On Feb 15, 2012, at 7:55 PM, Nathan Eisenberg wrote:
>>
>>>> IPv6 is operational.
>>>
>>> How is this a misconception? ?It works fine for me...
>>
>> I think he left off "In Japan". ?There's been a lot of local politics as it relates to the broken nature of IPv6 in japan. ?When its there, it's not globally accessible in many cases (at the consumer or last-mile level). ?Most (all?) major backbones are IPv6 capable these days, but in some cases it's 6PE vs "native".
>>
>> IPv6 is operational and does work, but like any protocol there are issues. ?If you are unaware, take a look at what people are trying to put into IPv4 still at IETF. ?The fact that the IPv6 day went so well last year, and the IPv6 launch is coming quickly is a reminder its real. ?Me? ?I can't wait to have this behind us. ?(Oh, and if you're not at least routing your IPv6 space to your lab/NOC LAN, get on it. ?Even if you have to poke the 'security' guys who think you need an IPv6 NAT in the eye).
>>
>> - Jared
>
> Yes, I'm well aware of the problems being created by the attempts by NTT to force the government to let them be a residential ISP.
>
> Owen
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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


From jeff-kell at utc.edu  Thu Feb 16 07:27:14 2012
From: jeff-kell at utc.edu (Jeff Kell)
Date: Thu, 16 Feb 2012 08:27:14 -0500
Subject: Common operational misconceptions
In-Reply-To: <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
Message-ID: <4F3D0432.6070201@utc.edu>

On 2/16/2012 8:17 AM, Ray Soucy wrote:
> I've found starting off with some history on Ethernet (Maine loves Bob
> Metcalfe) becomes a very solid base for understanding; how "Ethernet"
> today is very different; starting with hubs, bridges, collisions, and
> those problems, then introducing modern switching, VLANs, broadcast
> domain's etc.

It's a bit dated (1998) but I always thought Rich Siefert covered "the
basics" very well...
http://www.amazon.com/Gigabit-Ethernet-Technology-Applications-High-Speed/dp/0201185539

Jeff


From jared at puck.nether.net  Thu Feb 16 07:25:22 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 16 Feb 2012 08:25:22 -0500
Subject: Common operational misconceptions
In-Reply-To: <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
Message-ID: <46062C99-75D7-4B1D-AE78-A1ECF20785F7@puck.nether.net>

Wouldn't know about that part. You would have to ask an ntt employee. 

Jared Mauch

On Feb 16, 2012, at 8:03 AM, Owen DeLong <owen at delong.com> wrote:

> Yes, I'm well aware of the problems being created by the attempts by NTT to force the government to let them be a residential ISP.


From johnl at iecc.com  Thu Feb 16 07:33:55 2012
From: johnl at iecc.com (John R. Levine)
Date: 16 Feb 2012 08:33:55 -0500
Subject: SSL Certificates
In-Reply-To: <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
 <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1202160820001.4595@joyce.lan>

> I suppose if you buy a SSL certificate,  you should be looking for
> your CA to have insurance to reimburse the cost of the certificate
> should that happen,   and an ironclad   "refund"  clause in the
> agreement/contract  under which a SSL cert is issued

These certs cost $9.00.  You're not going to get much of an insurance 
policy at that price.

R's,
John


From rodrick.brown at gmail.com  Thu Feb 16 07:35:28 2012
From: rodrick.brown at gmail.com (Rodrick Brown)
Date: Thu, 16 Feb 2012 08:35:28 -0500
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
References: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
Message-ID: <87B432B3-94F6-411A-A8CD-B931B6DC74D9@gmail.com>

On Feb 16, 2012, at 8:03 AM, Hank Nussbacher <hank at efes.iucc.ac.il> wrote:

> Nanosecond Trading Could Make Markets Go Haywire
> http://www.wired.com/wiredscience/2012/02/high-speed-trading/
> 
> "Below the 950-millisecond level, where computerized trading occurs so quickly that human traders can't even react, no fewer than 18,520 crashes and spikes occurred."
> 
> Anyone who has managed a network knows that when you look at your MRTG/Cacti graphs at 5min, 10min ,15min intervals - all looks well.  Start looking at 1sec intervals and you will see spikes that hit 100% of capacity - even on networks running at 25% average utilization

I've had great success using appliances from network monitoring vendor  Corvil - http://www.corvil.com/ and TS-A's TipOff - www.ts-a.com/TipOff/tipoff.html 

Both can decode most market data feeds formats and drill down to provide a slew of details when trying to debug jitter and latency on networks where sub-millisecond thresholds are essential for analysis.

Disclaimer: I'm no way affiliated with any of these companies or products.

> 
> I guess trading and networking do have many unseen similarities.
> 
> -Hank
> 
> 


From regnauld at nsrc.org  Thu Feb 16 07:36:59 2012
From: regnauld at nsrc.org (Phil Regnauld)
Date: Thu, 16 Feb 2012 14:36:59 +0100
Subject: Common operational misconceptions
In-Reply-To: <742C02BD-93F9-4EC4-96FE-ADC2BFAE5E30@charterschoolit.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <742C02BD-93F9-4EC4-96FE-ADC2BFAE5E30@charterschoolit.com>
Message-ID: <20120216133659.GA65401@macbook.bluepipe.net>

Mario Eirea (meirea) writes:
> Something that makes me crawl out of my skin is when they refer to an access point as "router". 

	I have colleagues that work with radio and wireless, and they crawl out
	of *their* skin when I call an access point an access point, and they tell
	me it's a station :)



From regnauld at nsrc.org  Thu Feb 16 07:44:37 2012
From: regnauld at nsrc.org (Phil Regnauld)
Date: Thu, 16 Feb 2012 14:44:37 +0100
Subject: Common operational misconceptions
In-Reply-To: <20120216031208.132481D76BD5@drugs.dv.isc.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
 <20120216031208.132481D76BD5@drugs.dv.isc.org>
Message-ID: <20120216134437.GB65401@macbook.bluepipe.net>

Mark Andrews (marka) writes:
> If you want to know if your resolver talks IPv6 to the world and
> supports 4096 EDNS UDP messages the following query will tell you.
> 
> 		dig edns-v6-ok.isc.org txt
> 
> Similarly for IPv4.
> 
> 		dig edns-v4-ok.isc.org txt
> 

	9.8.1P1 on a dual stacked native v6 host: I'm seeing TC on both answers,
	the difference is the TCP answer comes through on v4 but v6 gives SERVFAIL.

	Don't see any v6 fragments (that'd be a problem since PF doesn't handle
	them on this host).

	P.



From jethro.binks at strath.ac.uk  Thu Feb 16 07:49:47 2012
From: jethro.binks at strath.ac.uk (Jethro R Binks)
Date: Thu, 16 Feb 2012 13:49:47 +0000 (GMT)
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
References: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
Message-ID: <alpine.BSF.2.00.1202161348160.68442@qrswnz.pp.fgengu.np.hx>

On Thu, 16 Feb 2012, Hank Nussbacher wrote:

> Nanosecond Trading Could Make Markets Go Haywire
> http://www.wired.com/wiredscience/2012/02/high-speed-trading/
> 
> "Below the 950-millisecond level, where computerized trading occurs so 
> quickly that human traders can't even react, no fewer than 18,520 
> crashes and spikes occurred."
> 
> Anyone who has managed a network knows that when you look at your 
> MRTG/Cacti graphs at 5min, 10min ,15min intervals - all looks well.  
> Start looking at 1sec intervals and you will see spikes that hit 100% of 
> capacity - even on networks running at 25% average utilization.
> 
> I guess trading and networking do have many unseen similarities.

Tieing the two together, this post shows how a lot of 'conventional' 
network thinking needs to be turned on its head when it comes to networks 
for trading floors:

http://www.fragmentationneeded.net/2011/12/pricing-and-trading-networks-down-is-up.html

Jethro.

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.


From marka at isc.org  Thu Feb 16 07:51:26 2012
From: marka at isc.org (Mark Andrews)
Date: Fri, 17 Feb 2012 00:51:26 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Thu, 16 Feb 2012 13:01:43 BST."
 <20120216.130143.74691634.sthaug@nethelp.no>
References: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <20120216.130143.74691634.sthaug@nethelp.no>
Message-ID: <20120216135126.40A051D8B63A@drugs.dv.isc.org>


In message <20120216.130143.74691634.sthaug at nethelp.no>, sthaug at nethelp.no writes:
> > If you want to know if your resolver talks IPv6 to the world and
> > supports 4096 EDNS UDP messages the following query will tell you.
> > 
> > 		dig edns-v6-ok.isc.org txt
> > 
> > Similarly for IPv4.
> > 
> > 		dig edns-v4-ok.isc.org txt
> 
> Both PowerDNS recursor 3.3 and Nominum CNS 3.0.5 have problems
> with these queries. They both get the TC answer from 149.20.64.58 /
> 2001:4f8:0:2::8. Then:

I stated very clearly the conditions under which the queries would
resolve.
 
> - CNS tries with 4000 EDNS UDP size (4000 is the CNS documented max
> UDP size), gets another TC.
> 
> - PowerDNS doesn't try to used EDNS at all.
> 
> Then they both try TCP and get a RST. And then they return SERVFAIL.

Correct. Those servers are deliberately configured to not answer
TCP as they are for testing the EDNS UDP path.  They also put out
a answer that will exactly fill a 4096 byte EDNS UDP message which
is the default and largest EDNS UDP size advertised by named.  This
allows someone running named to test their firewall configuration
to ensure that it will let through any EDNS UDP reply, size wise,
that can occur.  As IPv4 and IPv6 are often configured independently
we provide a way to test each independently.


> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From jeff-kell at utc.edu  Thu Feb 16 07:57:04 2012
From: jeff-kell at utc.edu (Jeff Kell)
Date: Thu, 16 Feb 2012 08:57:04 -0500
Subject: Common operational misconceptions
In-Reply-To: <5BE69C32-0E92-4C7E-B4D2-DAC646D91A0C@ctcampbell.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215225244.GA25272@gsp.org>
 <5BE69C32-0E92-4C7E-B4D2-DAC646D91A0C@ctcampbell.com>
Message-ID: <4F3D0B30.1090504@utc.edu>

Or a security vendor, or a security publication...  the whole "top ten"
delivered as ten individual clicks with pay-per-view banner ads on each
page and a bazillion tracker cookies....  arrrrrrgh.....

Jeff

On 2/16/2012 5:26 AM, Chris Campbell wrote:
> This isn't so much a list of misconceptions that recent students have as a list of misconceptions that security management have?
>
> On 15 Feb 2012, at 22:52, Rich Kulawiec wrote:
>
>> ICMP is evil.
>> Firewalls can be configured default-permit.
>> Firewalls can be configured unidirectionally.
>> Firewalls will solve our security issues.
>> Antivirus will solve our security issues.
>> IDS/IPS will solve our security issues.
>> Audits and checklists will solve our security issues.
>> Our network will never emit abuse or attacks.
>> Our users can be trained.
>> We must do something; this is something; let's do this.
>> We can add security later.
>> We're not a target.
>> We don't need to read our logs.
>> What logs?
>>
>> (with apologies to Marcus Ranum, from whom I've shamelessly
>> cribbed several of these)
>>
>> ---rsk
>>
>



From cra at WPI.EDU  Thu Feb 16 08:01:59 2012
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 16 Feb 2012 09:01:59 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3D0432.6070201@utc.edu>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D0432.6070201@utc.edu>
Message-ID: <20120216140159.GT17691@angus.ind.WPI.EDU>

On Thu, Feb 16, 2012 at 08:27:14AM -0500, Jeff Kell wrote:
> On 2/16/2012 8:17 AM, Ray Soucy wrote:
> > I've found starting off with some history on Ethernet (Maine loves Bob
> > Metcalfe) becomes a very solid base for understanding; how "Ethernet"
> > today is very different; starting with hubs, bridges, collisions, and
> > those problems, then introducing modern switching, VLANs, broadcast
> > domain's etc.
> 
> It's a bit dated (1998) but I always thought Rich Siefert covered "the
> basics" very well...
> http://www.amazon.com/Gigabit-Ethernet-Technology-Applications-High-Speed/dp/0201185539

I like this free Juniper online training to introduce people to Layer 2 and
Layer 3 and how they interact:

https://learningportal.juniper.net/juniper/user_fasttrack_home.aspx

"Networking Fundamentals" eLearning course.


From jeroen at unfix.org  Thu Feb 16 08:01:41 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Thu, 16 Feb 2012 15:01:41 +0100
Subject: Common operational misconceptions
In-Reply-To: <20120216135126.40A051D8B63A@drugs.dv.isc.org>
References: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <20120216.130143.74691634.sthaug@nethelp.no>
 <20120216135126.40A051D8B63A@drugs.dv.isc.org>
Message-ID: <4F3D0C45.9020100@unfix.org>

On 2012-02-16 14:51 , Mark Andrews wrote:
[..]
> that can occur.  As IPv4 and IPv6 are often configured independently
> we provide a way to test each independently.

Could you make that label also for both IPv4/IPv6, that way, one could
figure out if the query ends up being answered over IPv4 or IPv6...
though then maybe the content would need to have a IPv4/IPv6 label in
it. Maybe it is even more useful to show the source of the querier?

Greets,
 Jeroen


From shuque at upenn.edu  Thu Feb 16 08:08:18 2012
From: shuque at upenn.edu (Shumon Huque)
Date: Thu, 16 Feb 2012 09:08:18 -0500
Subject: Common operational misconceptions
In-Reply-To: <00f201ccec70$3a4c8f50$aee5adf0$@chipps.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C8A4B.1090309@gmx.com>
 <00e501ccec68$65aa8650$30ff92f0$@chipps.com>
 <4F3C9ACF.2050108@bogus.com>
 <00f201ccec70$3a4c8f50$aee5adf0$@chipps.com>
Message-ID: <20120216140818.GA15528@isc.upenn.edu>

We run IS-IS at the University of Pennsylvania as the IGP for
IPv6. I know of a few other non-ISPs too but I won't speak for 
them. At the time we initially deployed IPv6, it was pretty
much one of the few safe choices (OSPFv3 implementations were 
very new then).

--Shumon.

On Thu, Feb 16, 2012 at 12:00:04AM -0600, Kenneth M. Chipps Ph.D. wrote:
> "ISIS is used in organizations other than ISPs" Any examples you can share
> of some other than ISPs?
> 
> -----Original Message-----
> From: Joel jaeggli [mailto:joelja at bogus.com] 
> Sent: Wednesday, February 15, 2012 11:58 PM
> To: Kenneth M. Chipps Ph.D.
> Cc: nanog at nanog.org
> Subject: Re: Common operational misconceptions
> 
> On 2/15/12 21:04 , Kenneth M. Chipps Ph.D. wrote:
> > How widespread would you say the use of IS-IS is?
> >
> > Even more as to which routing protocols are used, not just in ISPs, 
> > what percent would you give to the various ones. In other words X 
> > percent of organizations use OSPS, Y percent use EIGRP, and so on.
> 
> Using EIGRP implies your routed IGP dependent infrastructure is a
> monoculture. That's probably infeasible without compromise even if you are
> largely a Cisco shop.
> 
> ISIS is used in organizations other than ISPs.


-- 
Shumon Huque
University of Pennsylvania.


From marka at isc.org  Thu Feb 16 08:28:36 2012
From: marka at isc.org (Mark Andrews)
Date: Fri, 17 Feb 2012 01:28:36 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Thu, 16 Feb 2012 14:44:37 BST."
 <20120216134437.GB65401@macbook.bluepipe.net>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <20120216134437.GB65401@macbook.bluepipe.net>
Message-ID: <20120216142836.CEF371D8BA2D@drugs.dv.isc.org>


In message <20120216134437.GB65401 at macbook.bluepipe.net>, Phil Regnauld writes:
> Mark Andrews (marka) writes:
> > If you want to know if your resolver talks IPv6 to the world and
> > supports 4096 EDNS UDP messages the following query will tell you.
> > 
> > 		dig edns-v6-ok.isc.org txt
> > 
> > Similarly for IPv4.
> > 
> > 		dig edns-v4-ok.isc.org txt
> > 
> 
> 	9.8.1P1 on a dual stacked native v6 host: I'm seeing TC on both answers,
> 	the difference is the TCP answer comes through on v4 but v6 gives SERVFAIL.

You will see TC between dig and the resolver.  If you see TC between the resolver
and the server it will fail as neither server answers over TCP.  If you are seeing
TC between the resolver and the server and the TCP query is being answers then
something in the path is intercepting the DNS queries.

> 	Don't see any v6 fragments (that'd be a problem since PF doesn't handle
> 	them on this host).

You should see something like this on the wire.  The second query is to answer
dig's query over TCP.

01:19:30.421959 IP6 2001:470:1f00:820:6965:eba7:eff6:1242.64345 > 2001:4f8:0:2::8.53: 44698% [1au] TXT? edns-v6-ok.isc.org. (47)
01:19:30.591828 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (0|1232) 53 > 64345: 44698*- 1/0/1 TXT[|domain]
01:19:30.592851 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (1232|1232)
01:19:30.593889 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (2464|1232)
01:19:30.593963 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (3696|408)
01:19:30.596552 IP6 2001:470:1f00:820:6965:eba7:eff6:1242.61500 > 2001:4f8:0:2::8.53: 60740% [1au] TXT? edns-v6-ok.isc.org. (47)
01:19:30.767351 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (0|1232) 53 > 61500: 60740*- 1/0/1 TXT[|domain]
01:19:30.768362 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (1232|1232)
01:19:30.769399 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (2464|1232)
01:19:30.769473 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (3696|408)

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


From marka at isc.org  Thu Feb 16 08:50:22 2012
From: marka at isc.org (Mark Andrews)
Date: Fri, 17 Feb 2012 01:50:22 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Thu, 16 Feb 2012 15:01:41 BST."
 <4F3D0C45.9020100@unfix.org>
References: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <20120216.130143.74691634.sthaug@nethelp.no>
 <20120216135126.40A051D8B63A@drugs.dv.isc.org> <4F3D0C45.9020100@unfix.org>
Message-ID: <20120216145022.E327B1D8C0AF@drugs.dv.isc.org>


In message <4F3D0C45.9020100 at unfix.org>, Jeroen Massar writes:
> On 2012-02-16 14:51 , Mark Andrews wrote:
> [..]
> > that can occur.  As IPv4 and IPv6 are often configured independently
> > we provide a way to test each independently.
> 
> Could you make that label also for both IPv4/IPv6, that way, one could
> figure out if the query ends up being answered over IPv4 or IPv6...
> though then maybe the content would need to have a IPv4/IPv6 label in
> it. Maybe it is even more useful to show the source of the querier?
> 
> Greets,
>  Jeroen

I don't really see much benefit in that other than satisfying
curiosity.

Also this is a stock stand server + firewall to block TCP.  It would
require a custom server to sent back the source address and that
requires getting ops to run it.  That's not to say that it can't
be done but it becomes more than a simple request.

Mark

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


From hank at efes.iucc.ac.il  Thu Feb 16 09:07:48 2012
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Thu, 16 Feb 2012 17:07:48 +0200
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <alpine.BSF.2.00.1202161348160.68442@qrswnz.pp.fgengu.np.hx
 >
References: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
 <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
Message-ID: <5.1.0.14.2.20120216170730.03667380@efes.iucc.ac.il>

At 13:49 16/02/2012 +0000, Jethro R Binks wrote:
>On Thu, 16 Feb 2012, Hank Nussbacher wrote:
>
> > Nanosecond Trading Could Make Markets Go Haywire
> > http://www.wired.com/wiredscience/2012/02/high-speed-trading/
> >
> > "Below the 950-millisecond level, where computerized trading occurs so
> > quickly that human traders can't even react, no fewer than 18,520
> > crashes and spikes occurred."
> >
> > Anyone who has managed a network knows that when you look at your
> > MRTG/Cacti graphs at 5min, 10min ,15min intervals - all looks well.
> > Start looking at 1sec intervals and you will see spikes that hit 100% of
> > capacity - even on networks running at 25% average utilization.
> >
> > I guess trading and networking do have many unseen similarities.
>
>Tieing the two together, this post shows how a lot of 'conventional'
>network thinking needs to be turned on its head when it comes to networks
>for trading floors:
>
>http://www.fragmentationneeded.net/2011/12/pricing-and-trading-networks-down-is-up.html

Great article!

Thanks for sharing,
Hank


>Jethro.
>
>.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
>Jethro R Binks, Network Manager,
>Information Services Directorate, University Of Strathclyde, Glasgow, UK
>
>The University of Strathclyde is a charitable body, registered in
>Scotland, number SC015263.



From ttauber at 1-4-5.net  Thu Feb 16 09:51:19 2012
From: ttauber at 1-4-5.net (Tony Tauber)
Date: Thu, 16 Feb 2012 10:51:19 -0500
Subject: Common operational misconceptions
In-Reply-To: <CAOF0KO92Bg3tzFa5PcF4ATka=-AqM8=9QegP6b+4-_3gHdRJaA@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
 <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>
 <CAOF0KO92Bg3tzFa5PcF4ATka=-AqM8=9QegP6b+4-_3gHdRJaA@mail.gmail.com>
Message-ID: <CAGQUKcerrYz9=b_u5xrbpRzhVfh6bYXCwrzV0zxOAq9FbTV4HQ@mail.gmail.com>

Not understanding RFC1918 also gets my vote.
Don't call them "unroutable", ever.
I like it when I hear people say "if you type a net 10 address into a
router, it will reject it".
What do they think people do with those networks anyway?
Call them "private" or "RFC1918" networks/address spaces/ranges.

I don't know if it's really a common misconception, but worth underlining
to people, especially in these days of IPv4 kinkiness, the expectation of
global address uniqueness in the IP model.  (Yes, NATs are probably here to
stay, but they corrupt the model in a number of ways and hacks result.)

Encourage people to use technically precise language.
When reporting or discussing problems, at the IP layer at least, always get
the answers to these questions:

   - What is the source IP addresses (including external NAT IP if
   applicable)?
   - What is the destination IP address
   - What is the application being used?
   - What is the error message or behavior if any?
   - Did this ever work and, if so, what date and time did it stop working?

Tony

On Wed, Feb 15, 2012 at 10:26 PM, Charles Mills <w3yni1 at gmail.com> wrote:

> Not understanding RFC1918.  Actually got read the riot act by someone
> because I worked for an organization that used 10.0.0.0/8 and that was
> "their" network and "they" owned it.
>
> Chuck
>
>

From morrowc.lists at gmail.com  Thu Feb 16 10:13:07 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 16 Feb 2012 11:13:07 -0500
Subject: SSL Certificates
In-Reply-To: <alpine.BSF.2.00.1202160820001.4595@joyce.lan>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
 <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
 <alpine.BSF.2.00.1202160820001.4595@joyce.lan>
Message-ID: <CAL9jLaZtNv_RqW9zLmu8Cp=6-0CS76zgbSUwxLUB+z2m6-_j=w@mail.gmail.com>

On Thu, Feb 16, 2012 at 8:33 AM, John R. Levine <johnl at iecc.com> wrote:
>> I suppose if you buy a SSL certificate, ?you should be looking for
>> your CA to have insurance to reimburse the cost of the certificate
>> should that happen, ? and an ironclad ? "refund" ?clause in the
>> agreement/contract ?under which a SSL cert is issued
>
>
> These certs cost $9.00. ?You're not going to get much of an insurance policy
> at that price.

again, startssl.com - free. why pay? it's (as you say) not actually
buying you anything except random bits anyway... if you can get them
for free, why would you not do that?


From bicknell at ufp.org  Thu Feb 16 10:21:08 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 16 Feb 2012 08:21:08 -0800
Subject: SSL Certificates
In-Reply-To: <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
 <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
Message-ID: <20120216162108.GA11808@ussenterprise.ufp.org>

In a message written on Thu, Feb 16, 2012 at 12:57:25AM -0600, Jimmy Hess wrote:
> There is a risk that any CA issued SSL certificate signed by _any_ CA
> may be worthless some time in the future, if the CA chosen is later
> found to have issued  sufficient quantities fraudulent certificates,
> and sufficiently failed in their duties.

One thing I'm not clear about is, are there any protocol or
implementation limitations that require only one CA?

I would think I could take my private key and get multiple CA's to
sign it, then present all of those signatures to the client.  Should
one CA be revoked, my certificate would still be signed by one or
more others.

Does this work?  Does anyone do it?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120216/1cc02fef/attachment.bin>

From johnl at iecc.com  Thu Feb 16 10:21:12 2012
From: johnl at iecc.com (John R. Levine)
Date: 16 Feb 2012 11:21:12 -0500
Subject: SSL Certificates
In-Reply-To: <CAL9jLaZtNv_RqW9zLmu8Cp=6-0CS76zgbSUwxLUB+z2m6-_j=w@mail.gmail.com>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
 <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
 <alpine.BSF.2.00.1202160820001.4595@joyce.lan>
 <CAL9jLaZtNv_RqW9zLmu8Cp=6-0CS76zgbSUwxLUB+z2m6-_j=w@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1202161117300.13754@joyce.lan>

>> These certs cost $9.00. ?You're not going to get much of an insurance policy
>> at that price.
>
> again, startssl.com - free. why pay? it's (as you say) not actually
> buying you anything except random bits anyway... if you can get them
> for free, why would you not do that?

The free ones are supposed to be used only for personal sites.

Also, the fact that they tell me to go away and use a different browser 
when I try to sign up using Chrome does not fill me with warm feelings.

Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

From jeroen at unfix.org  Thu Feb 16 10:21:33 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Thu, 16 Feb 2012 17:21:33 +0100
Subject: SSL Certificates
In-Reply-To: <CAL9jLaZtNv_RqW9zLmu8Cp=6-0CS76zgbSUwxLUB+z2m6-_j=w@mail.gmail.com>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
 <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
 <alpine.BSF.2.00.1202160820001.4595@joyce.lan>
 <CAL9jLaZtNv_RqW9zLmu8Cp=6-0CS76zgbSUwxLUB+z2m6-_j=w@mail.gmail.com>
Message-ID: <4F3D2D0D.3040005@unfix.org>

On 2012-02-16 17:13 , Christopher Morrow wrote:
> On Thu, Feb 16, 2012 at 8:33 AM, John R. Levine <johnl at iecc.com> wrote:
>>> I suppose if you buy a SSL certificate,  you should be looking for
>>> your CA to have insurance to reimburse the cost of the certificate
>>> should that happen,   and an ironclad   "refund"  clause in the
>>> agreement/contract  under which a SSL cert is issued
>>
>>
>> These certs cost $9.00.  You're not going to get much of an insurance policy
>> at that price.
> 
> again, startssl.com - free. why pay? it's (as you say) not actually
> buying you anything except random bits anyway... if you can get them
> for free, why would you not do that?

Because they do not have a wildcard one for 'free', which is useful when
one wants to serve eg example.com but als www.example.com from the same
location along with other variants of the hostname. Except for that, it
is a rather great offer. Though one can of course just serve the
example.com one and force people after they accept to the main site.

I tend to stick CAcert ones on hosts and tell people to either just
accept that single cert and store it for future checks or just install
the CAcert root cert, that covers a lot of hosts in one go, given of
course that one trusts what CAcert is doing, but that goes for anything.

The method that Firefox is using with the unchained certificates "save
this unverified cert and as long as it is the same it is great" is in
that respect similar to SSH hostkeys, one can verify those offline and
just keep on using them as as long as that cert is the same you are
likely talking to the same host (ssl etc still don't cover compromised
hosts).

In the end, they are just bits, and this whole verification thing at the
verification of owner adds nothing except for an ease-of-use factor for
the non-techy folks on the Internet.

Greets,
 Jeroen


From johnl at iecc.com  Thu Feb 16 10:29:03 2012
From: johnl at iecc.com (John Levine)
Date: 16 Feb 2012 16:29:03 -0000
Subject: SSL Certificates
In-Reply-To: <20120216162108.GA11808@ussenterprise.ufp.org>
Message-ID: <20120216162903.14199.qmail@joyce.lan>

In article <20120216162108.GA11808 at ussenterprise.ufp.org> you write:
>-=-=-=-=-=-
>
>In a message written on Thu, Feb 16, 2012 at 12:57:25AM -0600, Jimmy Hess wrote:
>> There is a risk that any CA issued SSL certificate signed by _any_ CA
>> may be worthless some time in the future, if the CA chosen is later
>> found to have issued  sufficient quantities fraudulent certificates,
>> and sufficiently failed in their duties.
>
>One thing I'm not clear about is, are there any protocol or
>implementation limitations that require only one CA?

I've had the same cert signed by multiple CAs, although rarely at the
same time.  Never tried to present both versions in the same session,
though.

R's,
John


From regnauld at nsrc.org  Thu Feb 16 10:53:08 2012
From: regnauld at nsrc.org (Phil Regnauld)
Date: Thu, 16 Feb 2012 17:53:08 +0100
Subject: Common operational misconceptions
In-Reply-To: <20120216142836.CEF371D8BA2D@drugs.dv.isc.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
 <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <20120216134437.GB65401@macbook.bluepipe.net>
 <20120216142836.CEF371D8BA2D@drugs.dv.isc.org>
Message-ID: <20120216165308.GE65401@macbook.bluepipe.net>

	Borderline dns-ops, sorry folks! - but this is interesting
	as we've been talking about ipv6 being operational, and this
	is part of it...

Mark Andrews (marka) writes:
> 
> If you are seeing TC between the resolver and the server and the TCP query is being answers then
> something in the path is intercepting the DNS queries.

	TC is on the answer from the remote server to my resolver, so yeah, seems
	like something is messing with the packets.

> > 	Don't see any v6 fragments (that'd be a problem since PF doesn't handle
> > 	them on this host).
> 
> You should see something like this on the wire.  The second query is to answer
> dig's query over TCP.

	I'm not seeing fragments as you are.

	Here's what I see:

14:40:20.955876 IP6 2001:2000:1080:d::2.64561 > 2001:4f8:0:2::8.53: 52841 TXT? edns-v6-ok.isc.org. (36)
14:40:21.141948 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.64561: 52841*-| 0/0/0 (36)
14:40:21.142259 IP6 2001:2000:1080:d::2.53262 > 2001:4f8:0:2::8.53: Flags [S], seq 1112939462, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS val 2571957531 ecr 0], length 0
14:40:21.327895 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.53262: Flags [R.], seq 0, ack 1112939463, win 0, length 0

	Cheers,
	Phil


From jbates at brightok.net  Thu Feb 16 11:08:22 2012
From: jbates at brightok.net (Jack Bates)
Date: Thu, 16 Feb 2012 11:08:22 -0600
Subject: Common operational misconceptions
In-Reply-To: <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
Message-ID: <4F3D3806.4000008@brightok.net>

On 2/16/2012 7:17 AM, Ray Soucy wrote:
> There seems to be (even among faculty) a gross misunderstanding of
> Layer-2.  Nearly every textbook starts with IP, and talks about it as
> if we were 20 years in the past.

Understanding all layers and how they can interact stacked within layers 
is a big issue. Granted, they aren't coming out of school, but I've seen 
old Sonet/TDM guys trying to figure out transport of Ethernet and it has 
been a nightmare on dealing with terminology.

It at first started with trying to explain that vlan based switching is 
not Layer-3. :(

Use your imagination when they finally got into MPLS, which kindly takes 
the OSI model like a flat piece of paper and wads it up.


Jack


From jm-nanog at vj8.net  Thu Feb 16 11:54:39 2012
From: jm-nanog at vj8.net (James Triplett)
Date: Thu, 16 Feb 2012 12:54:39 -0500
Subject: SSL Certificates startssl.com
In-Reply-To: <CAL9jLaZtNv_RqW9zLmu8Cp=6-0CS76zgbSUwxLUB+z2m6-_j=w@mail.gmail.com>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
 <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
 <alpine.BSF.2.00.1202160820001.4595@joyce.lan>
 <CAL9jLaZtNv_RqW9zLmu8Cp=6-0CS76zgbSUwxLUB+z2m6-_j=w@mail.gmail.com>
Message-ID: <20120216175439.GA14119@datamat.net>

On (16/02/12 11:13), Christopher Morrow wrote:
> again, startssl.com - free. why pay? it's (as you say) not actually
> buying you anything except random bits anyway... if you can get them
> for free, why would you not do that?
> 

They may not charge money, but it's not really free.  You have to
provide them so much personal information, it feels like an
invitation to identity theft.  At the least what they collect would
be valuable information to sell to marketeers.

They demand a valid residential address for the free personal-use certificate;
a business address will not do (and they check).  Our mixed-use building did
not qualify.

Next option is one of their cheap business certificates, but then you must
send scanned images of:
	1. The cover of your passport
	2. The first pages of the passport
	3. The picture of you with your personal detail of your passport
		 and
	1. Both sides of your drivers license or identity card or
	2. Photo ID document issued by a local, state or federal authority.

In order to save a couple bucks, I'm gonna scan all this and send it off
to somewhere in Israel???  Geotrust or Comodo don't put you through this.  
For $10, I'll keep my info, thanks.









From michael at rancid.berkeley.edu  Thu Feb 16 13:10:45 2012
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Thu, 16 Feb 2012 11:10:45 -0800
Subject: Common operational misconceptions
In-Reply-To: <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
Message-ID: <4F3D54B5.4000109@rancid.berkeley.edu>

On 02/16/12 05:17, Ray Soucy wrote:
> I've found starting off with some history on Ethernet (Maine loves Bob
> Metcalfe) becomes a very solid base for understanding; how "Ethernet"
> today is very different; starting with hubs, bridges, collisions, and
> those problems, then introducing modern switching, VLANs, broadcast
> domain's etc.

There was an old cruddy 1950s building on the UCB campus called Stanley 
Hall.  (Now there's a new, nice, modern building on the UCB campus 
called Stanley Hall in place of the old one.)  The old building had both 
UCB net and Lawrence Berkeley Lab (LBNL) net running through it.  The 
LBNL net was fed from fiber using a 10base-FL-to-AUI repeater.  The AUI 
connected into the coax spine.

The cool thing is that the coax spine was provisioned exactly as you 
would expect in an old ethernet textbook.  The spine ran through the 
hallway (usually just tied to a pipe, but sometimes with a J-hook) and 
every 1.5 meters, there was a vampire tap and (usually) a transceiver 
with an AUI cable connected to it that went into an office and dropped 
down through the ceiling.

Amazingly, the UCB network was somewhat more modern.  There were DEC 
Delni MPTs (or "AUI hubs") coming off the UCB coax.  There were even 
some 10base-T hubs and concentrators that fed offices that had newer 
cat-3 or even cat-5 wiring.

It was great to take students on tours through this operational museum. 
  (Well, the LBNL net was sort of operational.  It would just stop 
working for minutes on end and then come back mysteriously.)  You could 
basically see the first 10-15 years of the evolution of ethernet, and it 
was installed and working.

The new Stanley is plumbed to the gills with cat-5e, gigabit switches, 
and vlans all over the place.  A modern LAN, yes, but no sense of history.

michael


From cjp at 0x1.net  Thu Feb 16 13:25:32 2012
From: cjp at 0x1.net (Christopher J. Pilkington)
Date: Thu, 16 Feb 2012 14:25:32 -0500
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
References: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
Message-ID: <20120216192532.GA57917@byzantium.local>

On Thu, Feb 16, 2012 at 03:03:55PM +0200, Hank Nussbacher wrote:
> Anyone who has managed a network knows that when you look at your
> MRTG/Cacti graphs at 5min, 10min ,15min intervals - all looks well.
> Start looking at 1sec intervals and you will see spikes that hit
> 100% of capacity - even on networks running at 25% average
> utilization.

As sampling rate approaches zero, so will the "spikyness" of the
graph--ultimately an interface is either sending a frame (100%) or it's
not (0%).

-cjp


From owen at delong.com  Thu Feb 16 13:25:18 2012
From: owen at delong.com (Owen DeLong)
Date: Thu, 16 Feb 2012 11:25:18 -0800
Subject: Common operational misconceptions
In-Reply-To: <20120216140818.GA15528@isc.upenn.edu>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C8A4B.1090309@gmx.com> <00e501ccec68$65aa8650$30ff92f0$@chipps.com>
 <4F3C9ACF.2050108@bogus.com> <00f201ccec70$3a4c8f50$aee5adf0$@chipps.com>
 <20120216140818.GA15528@isc.upenn.edu>
Message-ID: <DC1DF01C-46A1-4FF0-B420-D8AB131CE363@delong.com>

I would say that the average University is more of an unusual ISP than a non-ISP.

Almost every University I know of has a networking group that functions like an ISP for the various departments of the college(s) as well as providing essentially residential ISP services to their
residence halls and in some cases fraternities, faculty housing, etc.

From a networking perspective they tend to operate much more like an ISP than an enterprise.

One of the key defining differences (IMHO) is that an enterprise (mostly) trusts the employees connected to its network whereas an ISP and a University cannot.

Owen

On Feb 16, 2012, at 6:08 AM, Shumon Huque wrote:

> We run IS-IS at the University of Pennsylvania as the IGP for
> IPv6. I know of a few other non-ISPs too but I won't speak for 
> them. At the time we initially deployed IPv6, it was pretty
> much one of the few safe choices (OSPFv3 implementations were 
> very new then).
> 
> --Shumon.
> 
> On Thu, Feb 16, 2012 at 12:00:04AM -0600, Kenneth M. Chipps Ph.D. wrote:
>> "ISIS is used in organizations other than ISPs" Any examples you can share
>> of some other than ISPs?
>> 
>> -----Original Message-----
>> From: Joel jaeggli [mailto:joelja at bogus.com] 
>> Sent: Wednesday, February 15, 2012 11:58 PM
>> To: Kenneth M. Chipps Ph.D.
>> Cc: nanog at nanog.org
>> Subject: Re: Common operational misconceptions
>> 
>> On 2/15/12 21:04 , Kenneth M. Chipps Ph.D. wrote:
>>> How widespread would you say the use of IS-IS is?
>>> 
>>> Even more as to which routing protocols are used, not just in ISPs, 
>>> what percent would you give to the various ones. In other words X 
>>> percent of organizations use OSPS, Y percent use EIGRP, and so on.
>> 
>> Using EIGRP implies your routed IGP dependent infrastructure is a
>> monoculture. That's probably infeasible without compromise even if you are
>> largely a Cisco shop.
>> 
>> ISIS is used in organizations other than ISPs.
> 
> 
> -- 
> Shumon Huque
> University of Pennsylvania.



From dholmes at mwdh2o.com  Thu Feb 16 13:41:17 2012
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Thu, 16 Feb 2012 11:41:17 -0800
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <922ACC42D498884AA02B3565688AF9953403542EB5@USEXMBS01.mwd.h2o>

With telcos increasingly implementing Metro Ethernet Forum (MEF) networks, I have found that telco technicians tasked with maintaining and operating these carrier Ethernet networks appear to disregard common high availability practices. For instance, after diagnosing a routing protocol neighbor flap (consistently 20-30 seconds) and isolating the problem to the carrier MEF network, the carrier technician told me that the problem was a spanning tree convergence that took their primary and back-up links down during convergence, but that "this is no big deal because the network was only down for 20-30 seconds".

-----Original Message-----
From: John Kristoff [mailto:jtk at cymru.com]
Sent: Wednesday, February 15, 2012 12:47 PM
To: nanog at nanog.org
Subject: Common operational misconceptions

Hi friends,

As some of you may know, I occasionally teach networking to college
students and I frequently encounter misconceptions about some aspect
of networking that can take a fair amount of effort to correct.

For instance, a topic that has come up on this list before is how the
inappropriate use of classful terminology is rampant among students,
books and often other teachers.  Furthermore, the terminology isn't even
always used correctly in the original context of classful addressing.

I have a handful of common misconceptions that I'd put on a top 10 list,
but I'd like to solicit from this community what it considers to be the
most annoying and common operational misconceptions future operators
often come at you with.

I'd prefer replies off-list and can summarize back to the list if
there is interest.

John


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


From marka at isc.org  Thu Feb 16 14:22:42 2012
From: marka at isc.org (Mark Andrews)
Date: Fri, 17 Feb 2012 07:22:42 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Thu, 16 Feb 2012 17:53:08 BST."
 <20120216165308.GE65401@macbook.bluepipe.net>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <20120216134437.GB65401@macbook.bluepipe.net>
 <20120216142836.CEF371D8BA2D@drugs.dv.isc.org>
 <20120216165308.GE65401@macbook.bluepipe.net>
Message-ID: <20120216202242.C18381D8C58B@drugs.dv.isc.org>


In message <20120216165308.GE65401 at macbook.bluepipe.net>, Phil Regnauld writes:
> 	Borderline dns-ops, sorry folks! - but this is interesting
> 	as we've been talking about ipv6 being operational, and this
> 	is part of it...
> 
> Mark Andrews (marka) writes:
> > 
> > If you are seeing TC between the resolver and the server and the TCP query is being answers then
> > something in the path is intercepting the DNS queries.
> 
> 	TC is on the answer from the remote server to my resolver, so yeah, seems
> 	like something is messing with the packets.
> 
> > > 	Don't see any v6 fragments (that'd be a problem since PF doesn't handle
> > > 	them on this host).
> > 
> > You should see something like this on the wire.  The second query is to answer
> > dig's query over TCP.
> 
> 	I'm not seeing fragments as you are.
> 
> 	Here's what I see:
> 
> 14:40:20.955876 IP6 2001:2000:1080:d::2.64561 > 2001:4f8:0:2::8.53: 52841 TXT? edns-v6-ok.isc.org. (36)
> 14:40:21.141948 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.64561: 52841*-| 0/0/0 (36)
> 14:40:21.142259 IP6 2001:2000:1080:d::2.53262 > 2001:4f8:0:2::8.53: Flags [S], seq 1112939462, win 65535, optio
> ns [mss 1440,nop,wscale 6,sackOK,TS val 2571957531 ecr 0], length 0
> 14:40:21.327895 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.53262: Flags [R.], seq 0, ack 1112939463, win 0, l
> ength 0

Which means you are seeing named in fallback mode, or have configured named to not take EDNS to
this server.  In anycase your firewall is misconfigured/broken if it is blocking fragments.

> 	Cheers,
> 	Phil
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From andreas at livejournalinc.com  Thu Feb 16 14:27:08 2012
From: andreas at livejournalinc.com (Andreas Echavez)
Date: Thu, 16 Feb 2012 13:27:08 -0700
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>

I'm surprised I haven't seen QoS mentioned! If you're teaching college
students, you might want to go over stuff that directly relates to what
they're doing at home, or misconceptions they might make in a small
WAN/ISP environment.

*Why disabling ICMP doesn't increase security and only hurts the web* *(path
MTU discovery, diagnostics)
*How NAT breaks end-to-end connectivity (fun one..., took me hours to
explain to an old boss why doing NAT at the ISP level was horrendously
wrong)
*Not to be afraid of ACLs on an edge router. Understanding what
does/doesn't affect cpu utilization
*Layer 3 Switch vs Router. Old concepts like switch vs router need to be
clarified...
*When vendors and numbers lie ;) aka *oversubscription*!
*MAC is not security
*Irrelevant security concepts (smurf attacks, ping of death). More focus
should be on real modern day security concerns, like layer 7 exploits,
router software 0days, VLAN hopping, and UDP floods and BGP spoofing. This
might be a good place to explain why downloading IOS firmware from
thepiratebay is a bad idea :)

This is just coming from a sysadmin who likes to play with network gear and
once endured college networking classes.

Thanks!
Andreas


On Wed, Feb 15, 2012 at 1:47 PM, John Kristoff <jtk at cymru.com> wrote:

> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers.  Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
>
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
>
> John
>
>

From web at typo.org  Thu Feb 16 14:35:15 2012
From: web at typo.org (Wayne E Bouchard)
Date: Thu, 16 Feb 2012 13:35:15 -0700
Subject: Common operational misconceptions
In-Reply-To: <CAD8GWssw53E6RqLS7x5YxJzG_+1BAHxarWQCBT6tVADCLvXiHA@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAD8GWssw53E6RqLS7x5YxJzG_+1BAHxarWQCBT6tVADCLvXiHA@mail.gmail.com>
Message-ID: <20120216203515.GA5775@wakko.typo.org>

Or more to the point, it is a misconception that traffic is
symetrical (the path out and the path back are the same) whereas in
the present network, symetrical paths are the exception rather than
the rule, especially as your radius increases.

On Wed, Feb 15, 2012 at 07:17:57PM -0500, Lee wrote:
> traceroute shows _a_ path.  Your packets might have taken a different
> path.  (& the return traffic yet another)


---
Wayne Bouchard
web at typo.org
Network Dude
http://www.typo.org/~web/


From george.herbert at gmail.com  Thu Feb 16 14:41:11 2012
From: george.herbert at gmail.com (George Herbert)
Date: Thu, 16 Feb 2012 12:41:11 -0800
Subject: SSL Certificates
In-Reply-To: <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
 <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
Message-ID: <CAK__Kzth_d3UxDyaGRNpHPkexCQMwU9j8wpnySZXs_Yr9MdXTQ@mail.gmail.com>

On Wed, Feb 15, 2012 at 10:57 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> On Wed, Feb 15, 2012 at 6:49 PM, George Herbert
> <george.herbert at gmail.com> wrote:
>> On Wed, Feb 15, 2012 at 4:17 PM, John Levine <johnl at iecc.com> wrote:
>> The problem with anything related to Verisign at the moment is that
>
>> The possibility of their root certs being compromised is nonzero.
>
> The possibility of _ANY_ ?CA's root certs having been compromised is non-zero.
> There's no evidence published to indicate Verisign's CA key has been
> compromised,
> and it's highly unlikely.
>
> Just as there's no evidence of other CAs' ?root certificate keys being
> compromised.

Please recall that this HAS happened to another CA in the last year.


>> There may be no problem; they also may be completely worthless. ?Until
>> there's full disclosure...
> [snip]
>
> They are not completely worthless until revoked, ?or distrusted by web browsers.
>...

I think that's highly ass-backwards.

If it's been compromised and the compromise is not yet "fully known" -
revoked by the CA or distrusted by browsers - we exist in a nether
region where the customers connecting to "your" servers can be
transparently Man-in-the-Middle attacked.  If someone doing MiiM to
your customers would be a significant problem, then it's incumbent
upon you to not put your head in the sand when there's a
higher-than-normal risk that one CA may have A Problem.

The situation is in fact *worse* than "completely worthless".  In that
situation it has an active negative value.

This is complicated by the fact that you don't even need to be a
customer of that CA for that to be a risk.  If browsers trust that CA,
and that CA's keys are loose, then anyone with those can impersonate
anyone else on the net transparently.  But the fix for that revokes
the root cert and all the signed certs for that CA.  Immediately, if
the browser vendors response to the prior incident carries through to
a new one.  Buying new certs or continuing to use certs that have a
noticable risk of immediate revocation seems ... unwise.


Again - I don't know if it's been compromised.  The vendor is not
being forthcoming at that level of detail yet.  They are evidently
still trying to figure out how bad the penetration was.  That is not a
good sign, but does not automatically mean the worst by any means.


-- 
-george william herbert
george.herbert at gmail.com


From jchambers at ucla.edu  Thu Feb 16 14:59:01 2012
From: jchambers at ucla.edu (Jason Chambers)
Date: Thu, 16 Feb 2012 12:59:01 -0800
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
References: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
Message-ID: <4F3D6E15.7080006@ucla.edu>

On 2/16/12 5:03 AM, Hank Nussbacher wrote:
> Nanosecond Trading Could Make Markets Go Haywire
> http://www.wired.com/wiredscience/2012/02/high-speed-trading/
> 
> "Below the 950-millisecond level, where computerized trading occurs so
> quickly that human traders can't even react, no fewer than 18,520
> crashes and spikes occurred."
> 
> Anyone who has managed a network knows that when you look at your
> MRTG/Cacti graphs at 5min, 10min ,15min intervals - all looks well. 
> Start looking at 1sec intervals and you will see spikes that hit 100% of
> capacity - even on networks running at 25% average utilization.
> 
> I guess trading and networking do have many unseen similarities.
> 

Some complementary information I read a few weeks ago:

http://www.homelandsecuritynewswire.com/critical-cyber-vulnerabilities-found-financial-system

http://www.cpacket.com/latency

http://www.cpacket.com/download/Introduction%20to%20Network%20Latency%20Engineering.pdf



Regards,

--Jason



From streiner at cluebyfour.org  Thu Feb 16 15:02:29 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Thu, 16 Feb 2012 16:02:29 -0500 (EST)
Subject: Common operational misconceptions
In-Reply-To: <20120216203515.GA5775@wakko.typo.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAD8GWssw53E6RqLS7x5YxJzG_+1BAHxarWQCBT6tVADCLvXiHA@mail.gmail.com>
 <20120216203515.GA5775@wakko.typo.org>
Message-ID: <Pine.LNX.4.64.1202161558540.11697@whammy.cluebyfour.org>

On Thu, 16 Feb 2012, Wayne E Bouchard wrote:

> Or more to the point, it is a misconception that traffic is
> symetrical (the path out and the path back are the same) whereas in
> the present network, symetrical paths are the exception rather than
> the rule, especially as your radius increases.

To add to that, I feel pretty sure in stating that many of the people on 
this list, at one point or another, have either had people tell them that 
asymmetric routing is "bad", or have had to explain why asymmetric routing 
across 'the Internet' is not "bad", even if it can make troubleshooting a 
'network problem' somewhat more involved.  The path from A to B is not 
necessarily the same as the path from B to A.

jms


From randy at psg.com  Thu Feb 16 15:08:46 2012
From: randy at psg.com (Randy Bush)
Date: Thu, 16 Feb 2012 13:08:46 -0800
Subject: time sink 42
Message-ID: <m2aa4ih4f5.wl%randy@psg.com>

ok, this is horribly pragmatic, but it's real.  yesterday i was in the
westin playing rack and stack for five hours.  an horrifyingly large
amount of my time was spent trying to peel apart labels made on my
portable brother label tape maker, yes peeling the backing from a little
label so remote hands could easily confirm a server they were going to
attack.

is there a trick?  is there a (not expensive) different labeling machine
or technique i should use?

randy


From blakjak at blakjak.net  Thu Feb 16 15:12:15 2012
From: blakjak at blakjak.net (Mark Foster)
Date: Fri, 17 Feb 2012 10:12:15 +1300
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <4F3D712F.50304@blakjak.net>

On 17/02/12 10:08, Randy Bush wrote:
> ok, this is horribly pragmatic, but it's real.  yesterday i was in the
> westin playing rack and stack for five hours.  an horrifyingly large
> amount of my time was spent trying to peel apart labels made on my
> portable brother label tape maker, yes peeling the backing from a little
> label so remote hands could easily confirm a server they were going to
> attack.
>
> is there a trick?  is there a (not expensive) different labeling machine
> or technique i should use?
>
> randy
>
Many label makers (including Brother) use tapes that have a split up the
middle of the back layer, so you can peel it off half-at-a-time and not
fight with finding edges, etc.

Otherwise I suppose it's just a case of finding the knack.  My label
maker is of the cheaper variety and the tape i've been getting for it
doesn't have the back-split, so I get to fight with it on the occasion
that the knack doesn't seem to work...

Mark.


From george.herbert at gmail.com  Thu Feb 16 15:14:11 2012
From: george.herbert at gmail.com (George Herbert)
Date: Thu, 16 Feb 2012 13:14:11 -0800
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <CAK__KzvaTau-Lrq2Kpyxw6LWfAdjL-mhqHdbg+QrZtL43XadhQ@mail.gmail.com>

Brothers' are fine; buy the tapes that have the split-down-the-middle
backing on them.

It reduces the unpeeling problem from
more-time-than-the-label-took-to-type-in to about 2 seconds.  You just
grab the edges at an end and bend it, so the backing bulges outwards,
and off it starts to come.


-george

On Thu, Feb 16, 2012 at 1:08 PM, Randy Bush <randy at psg.com> wrote:
> ok, this is horribly pragmatic, but it's real. ?yesterday i was in the
> westin playing rack and stack for five hours. ?an horrifyingly large
> amount of my time was spent trying to peel apart labels made on my
> portable brother label tape maker, yes peeling the backing from a little
> label so remote hands could easily confirm a server they were going to
> attack.
>
> is there a trick? ?is there a (not expensive) different labeling machine
> or technique i should use?
>
> randy
>



-- 
-george william herbert
george.herbert at gmail.com


From bicknell at ufp.org  Thu Feb 16 15:15:47 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 16 Feb 2012 13:15:47 -0800
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <20120216211547.GA23755@ussenterprise.ufp.org>

In a message written on Thu, Feb 16, 2012 at 01:08:46PM -0800, Randy Bush wrote:
> ok, this is horribly pragmatic, but it's real.  yesterday i was in the
> westin playing rack and stack for five hours.  an horrifyingly large
> amount of my time was spent trying to peel apart labels made on my
> portable brother label tape maker, yes peeling the backing from a little
> label so remote hands could easily confirm a server they were going to
> attack.

The Brother I have that takes "M" tape has the problem you describe,
it's nearly impossible to get the backing to separate from the label.

I have another Brother that takes "TZ" tape, the backing of the tape of
slit down the middle lengthwise.  Gently curling the tape by squeezing
it causes the middle to pop open, easy to grab.

You can guess which one sits on the shelf, and which one gets used a
lot.

The TZ tape unit I use is a P-Touch 1100QL, I don't think it's made
anymore but there are several similar curent models.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120216/ca930803/attachment.bin>

From mike.lyon at gmail.com  Thu Feb 16 15:18:42 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Thu, 16 Feb 2012 13:18:42 -0800
Subject: time sink 42
In-Reply-To: <20120216211547.GA23755@ussenterprise.ufp.org>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <20120216211547.GA23755@ussenterprise.ufp.org>
Message-ID: <CAFFgAjDmTMnwFDa8SrYQk+hYPMBVY4qZR-UguobjjrmroDjvXg@mail.gmail.com>

If they are Dell servers, you could always name each host in their BIOS so
it shows up on the display of the host.

-Mike


On Thu, Feb 16, 2012 at 1:15 PM, Leo Bicknell <bicknell at ufp.org> wrote:

> In a message written on Thu, Feb 16, 2012 at 01:08:46PM -0800, Randy Bush
> wrote:
> > ok, this is horribly pragmatic, but it's real.  yesterday i was in the
> > westin playing rack and stack for five hours.  an horrifyingly large
> > amount of my time was spent trying to peel apart labels made on my
> > portable brother label tape maker, yes peeling the backing from a little
> > label so remote hands could easily confirm a server they were going to
> > attack.
>
> The Brother I have that takes "M" tape has the problem you describe,
> it's nearly impossible to get the backing to separate from the label.
>
> I have another Brother that takes "TZ" tape, the backing of the tape of
> slit down the middle lengthwise.  Gently curling the tape by squeezing
> it causes the middle to pop open, easy to grab.
>
> You can guess which one sits on the shelf, and which one gets used a
> lot.
>
> The TZ tape unit I use is a P-Touch 1100QL, I don't think it's made
> anymore but there are several similar curent models.
>
> --
>       Leo Bicknell - bicknell at ufp.org - CCIE 3440
>        PGP keys at http://www.ufp.org/~bicknell/
>



-- 
Mike Lyon
408-621-4826
mike.lyon at gmail.com

http://www.linkedin.com/in/mlyon

From keegan.holley at sungard.com  Thu Feb 16 15:18:44 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Thu, 16 Feb 2012 16:18:44 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <CABO8Q6TuX4fuqxh06Jp6t6u5uge66Fd42GOq0KfLJCqN4ThcKw@mail.gmail.com>

Alot of people are unclear on how hard it is for someone to sniff internet
traffic if the aren't physically located at or near one of the endpoints
IE: connected to the  same access point or same switch.

2012/2/15 John Kristoff <jtk at cymru.com>

> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers.  Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
>
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
>
> John
>
>
>

From erik.soosalu at calyxinc.com  Thu Feb 16 15:20:06 2012
From: erik.soosalu at calyxinc.com (Erik Soosalu)
Date: Thu, 16 Feb 2012 16:20:06 -0500
Subject: time sink 42
In-Reply-To: <201202162115