RE: RIP Justification

[Jonathon Exley]

It also scales better from the SP point of view. If you have 1000 L3VPN 
services on your PE node using OSPF to the customer that would require a lot of 
memory for the multiple LSDBs and a lot of CPU for the SPF calculations.
BGP is nicer but the reality is that many enterprises don't have the know-how. 

Jonathon 

-Original Message-
From: Heath Jones [mailto:hj1...@gmail.com] 
Sent: Saturday, 2 October 2010 12:39 a.m.
To: Tim Franklin
Cc: nanog@nanog.org
Subject: Re: RIP Justification

On 1 October 2010 12:19, Tim Franklin  wrote:
> Or BGP.  Why not?

Of course, technically you could use almost any routing protocol.
OSPF and IS-IS would require more configuration and maintenance, BGP even more 
still.

I think this is a pretty good example though of how RIPv2 is probably the most 
appropriate for the job. It doesnt require further configuration from the 
provider side as new sites are added and is very simple to set up and maintain.

This email and attachments: are confidential; may be protected by
privilege and copyright; if received in error may not be used,copied,
or kept; are not guaranteed to be virus-free; may not express the
views of Kordia(R); do not designate an information system; and do not
give rise to any liability for Kordia(R).

Re: Request for participation - Arbor 2010 Worldwide Infrastructure Security Report.

[Dobbins, Roland]

On Oct 5, 2010, at 1:27 AM, Scott Weeks wrote:

> Why are we required to register to look at the survey?


That's how it's set up by the biz folks who provide the funding and resources 
which allow us to conduct the survey, analyze the responses, and then write and 
publish the report free of charge each year as a public service to the 
operational community. 

If registering to download the report is unduly burdensome, feel free to email 
me 1:1 and I can provide a copy for you, thanks!

---
Roland Dobbins  // 

   Sell your computer and buy a guitar.

Re: [Nanog-futures] Memberships, Bylaws and other election matters

[Randy Bush]

> Short term cash supply is important; we have a decent lag between now
> and NANOG 52 where there will be a significant outflow of cash for
> salaries, hotel contracts, etc. without any meeting revenue.

yes, the published data do show that plan.  and i guess it is not
outrageous.  a choice between borrowing from other organizations or
borrowing from members.  

unless, of course, one can get gifts.  but that's not something on which
i would play bet the company.

randy

Re: [Nanog-futures] Memberships, Bylaws and other election matters

[Randy Bush]

>> personally, i am not strongly against it, but am sceptical.  it may get
>> a cash infusion now, but what will it do to income down the road when
>> folk don't need to renew? [0]
> 
> Furthermore, your opposition will surely depress demand even more,
> because now folks are saying "why would I pay for a life membership
> that Randy, for reasons that are largely inexplicable, would attempt
> to revoke, leaving me with no recourse"*

first, i find your characterizing my being sceptical as opposition to be
almost offensive.  i dared to question your oh so wise authority.  given
the ad hominem defense, i now am far more sceptical and suspicious.

second, i have never said i would attempt to revoke it.   again you
grossly and unjustifiably wildly distort my statement.  what i said was
i recommended against passing it, and asked steve if he would include it
in the "we won't do until consensus is reached" list.  i said that very
clearly because i thought it unwindable, quite the opposite of what you
are attempting to put in my mouth.

i used to think you credible.  i no longer do.  but my opinions and 15
cents will get you on the subway.  well, you may also need a time
machine.

> I get the fellow thing, even if I think its silly. The opposition to
> student membership - I even understand that, although I respectfully
> disagree.

just charge 'em a different fee.

> your opposition to life memberships is starting to sound like
> reflexive opposition because you feel like being ornery.

then try q-tips.

>> does newnog actually need the infusion up front?  are there other ways
>> to deal with the financial problem that the attempt to create of this
>> class of membership implies?
> Yes, we do. I have done a complete analysis, which I offered to share with
> everyone at the community meeting.

some of us asked for the pro forma financials to be published many
months ago.  and now i missed my opportunity by going to kyoto for icnp
instead of going to atlanta.  damn!

and no, the 'budget' on the web site is far from sufficient.

> * Of course there IS a recourse if life membership is canceled. Its
> called "refund the unused portion of the life membership on a
> pro-rated basis".

not really good.  you made a contract.  stick to it.  we're not a credit
card company or google's so called privacy policy.

randy

Re: do you use SPF TXT RRs? (RFC4408)

[Kevin Stange]

On 10/04/2010 11:47 AM, Greg Whynott wrote:
> 
> A partner had a security audit done on their site.  The report said they were 
> at risk of a DoS due to the fact they didn't have a SPF record.   

We publish a ~all record for our domain.  I think it's bad practice to
publish any other result because you're making assertions which are
almost definitely untrue.  +all implies that anywhere on the internet is
a valid origination, and -all implies you are certain nothing else could
ever send an email on behalf of your domain.

The most common situation where another host sends on your domain's
behalf is a forwarding MTA, such as NANOG's mailing list.  A lot of MTAs
will only trust that the final MTA handling the message is a source
host.  In the case of a mailing list, that's NANOG's server.  All
previous headers are untrustworthy and could easily be forged.  I'd bet
few, if any, people have NANOG's servers listed in their SPF, and
delivering a -all result in your SPF could easily cause blocked mail for
anyone that drops hard failing messages.

If you're going to filter using SPFs, I believe best practice is to
consider all mail from a +all or neutral record the same as mail that
soft or hard fails a ~all or -all record.  By filtering, I mean I would
simply subject those messages to additional testing, but never block
exclusively based upon an SPF result.  I would just ignore SPF and
that's what I do on MTAs I configure.

All you'll really be preventing with SPF is some backscatter and
messages which forge the source information for domains that have even
bothered to publish accurate records.  A huge amount of the spam you get
will pass SPF (or return neutral) and possibly pass DKIM as well because
the big spam operations register new domains and set up SPF before they
start spamming.

-- 
Kevin Stange
Chief Technology Officer
Steadfast Networks
http://steadfast.net
Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867



signature.asc
Description: OpenPGP digital signature

Re: A New TransAtlantic Cable System

[Randy Bush]

> With regards to the Wired Article, I still have my copy of that issue
> and would consider that article perhaps my favorite magazine article
> of all time.

i too thought that a great article and often point folk to it.  sadly,
the copy on the wired web site does not have the figures :(

randy

Re: do you use SPF TXT RRs? (RFC4408)

[Michael Loftis]

--On Monday, October 04, 2010 9:54 AM -0700 John Adams  
wrote:



Without proper SPF records your mail stands little chance of making it
through some of the larger providers, like gmail, if you are sending
in any high volume. You should be using SPF, DK, and DKIM signing.

I don't really understand how your security company related SPF to DoS
though. They're unrelated, with the exception of backscatter.


FUD most likely, that's the stock in trade for almost all "security audit" 
firms.




-j

Re: A New TransAtlantic Cable System

[Dorn Hetzel]

With regards to the Wired Article, I still have my copy of that issue and
would consider that article perhaps my favorite magazine article of all
time.

On Mon, Oct 4, 2010 at 1:41 PM, Patrick Giagnocavo  wrote:

> On 10/4/2010 1:24 PM, Heath Jones wrote:
> >> By the way, my recollection is the undersea regenerators do purely
> optical regeneration.
> >> There is no O-E conversions undersea, only at the landing stations and
> terrestrial components.
> >
> > I'm not clever enough to know of some way that you could do optical
> > regeneration without converting the signal to electrical and
> > retransmitting back as optical.. How is that done?
> >
> >
>
> A halfway-decent description of the physics of how this is done, is
> covered in Neal Stephenson's excellent article on Wired:
>
> http://www.wired.com/wired/archive/4.12/ffglass.html
>
> The specific page covering optical regeneration:
>
> http://www.wired.com/wired/archive/4.12/ffglass.html?pg=6&topic=
>
> quote:
>
> 
> These signals begin to fade after they have traveled a certain distance,
> so it's necessary to build amplifiers into the cable every so often. In
> the case of FLAG, the spacing of these amplifiers ranges from 45 to 85
> kilometers. They work on a strikingly simple and elegant principle. Each
> amplifier contains an approximately 10-meter-long piece of special fiber
> that has been doped with erbium ions, making it capable of functioning
> as a laser medium. A separate semiconductor laser built into the
> amplifier generates powerful light at 1,480 nm - close to the same
> frequency as the signal beam, but not close enough to interfere with it.
> This light, directed into the doped fiber, pumps the electrons orbiting
> around those erbium ions up to a higher energy level.
>
> The signal coming down the FLAG cable passes through the doped fiber and
> causes it to lase, i.e., the excited electrons drop back down to a lower
> energy level, emitting light that is coherent with the incoming signal -
> which is to say that it is an exact copy of the incoming signal, except
> more powerful.
>
> 
>
> Cordially
>
> Patrick Giagnocavo
> patr...@zill.net
>
>

Re: A New TransAtlantic Cable System

[Heath Jones]

What's that quote again...?
Oh, that's it: "The more you know, the more you know you don't."
It feels very appropriate now :)

Cheers Patrick for that great info & to everyone who contacted me off-list also!


> A halfway-decent description of the physics of how this is done, is
> covered in Neal Stephenson's excellent article on Wired:
> http://www.wired.com/wired/archive/4.12/ffglass.html

[NANOG-announce] Election reminder

[Steve Feldman]

Everyone who registered for a NANOG meeting in 2009 or 2010 is eligible to vote 
in this year's combined NANOG/NewNOG election.

If you are eligible and have not already done so, please go to
  http://www.nanog.org/governance/elections/2010elections/
to review the election materials and vote.

Note that there are two ballots, one for the NANOG Steering Committee and 
charter amendment, and one for the NewNOG Bylaws ratification.  Please follow 
both links to vote.

Thanks,
Steve Feldman, SC Chair


___
NANOG-announce mailing list
nanog-annou...@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

2010.10.04 NANOG50 Monday afternoon notes

[Matthew Petach]

Here's my notes from the Monday afternoon presentations.
Apologies for the gaps where I nodded off in post-lunch
food coma, as well as for the typos and misspellings
that snuck in.
Notes are posted at
http://kestrel3.netflight.com/2010.10.04-NANOG50-afternoon-notes.txt

Off to Bear and Gear now.  ^_^

Matt

Re: Whois lookups (was: 2010.10.04 NANOG50 day 1 morning notes posted)

[Mark Kosters]

On 10/4/10 4:58 PM, "David Conrad"  wrote:

> On Oct 4, 2010, at 9:58 AM, John Curran wrote:
>> On Oct 4, 2010, at 1:25 PM, Seth Mattinen wrote:
>>> Or the new whois doesn't scale as well as the old one.
>>  New WHOIS scales much better than the old one; it would have
>>  extremely challenging to assemble enough equipment to handle
>>  the current query rate.  Look at the NANOG presentation slide
>>  for the exact query rate graph, but we're handling orders of
>>  magnitude more queries at present.
> 
> Looking at the graph on your 3 slide, it looks like ARIN is getting around
> 3200 whois queries per second.  How much of that query load is a result of
> non-port 43 queries (that is, making use of the REST features in the new
> server)?  It looks like the exponentiation in query load started around the
> same time the Whois-RWS was deployed...

Traffic increases a lot over the course of a day and follows a diurnal
pattern. Right now we are seeing close to 7,000 queries per second during
the height of the day. The original Whois cluster that Whois-RWS replaced
could not serve more than 800 queries per second.

There were two spikes. The first was right after we deployed Whois-RWS. For
two months, we saw a consistent load maxing at 2400 queries per second. The
second spike happened on Sept 6. At that point, traffic jumped almost 3x to
the current max of 7,000 queries per second and has been pretty consistent
over the past month.

The patterns that we see are interesting. Most interesting is the spike
asking for ip addresses login servers for the likes of Facebook, AOL, and
Yahoo. This pattern emerged on Sept 6.  Various people have been looking at
this but no good explanation has yet been found. Your guess is good as mine
what the cause of this query growth.

Regards,
Mark
 

Re: do you use SPF TXT RRs? (RFC4408)

[Valdis . Kletnieks]

On Mon, 04 Oct 2010 17:05:12 EDT, Suresh Ramasubramanian said:
> dig throwaway1.com NS
> dig throwaway2.com NS
> 
> etc etc ... and then check_sender_ns_access in postfix, for example.

Yes, that *is* better than whack-a-mole on the same DNS server, but...

The NANOG lurker in the next cubicle used to do that.  Turned out the
bang-for-buck wasn't as good as we hoped - it doesn't take too many
false-positive errors blocking 20,000 domains hosted on the same DNS server as
one spammer before the collateral damage becomes too painful. Our cost of
dealing with a false positive is a lot higher than a false negative, especially
once you factor in goodwill - people don't like spam, but a false positive on
something they consider important causes more ire than 10x as many false
negatives.

That, and when our block list hit 150K entries or so, its size caused *other*
issues with various things that were never designed for block lists quite that
big...



pgps1GM8R5Gr5.pgp
Description: PGP signature

Re: [ncc-services-wg] RPKI Resource Certification: building features

[Randy Bush]

> 1) We have not implemented support for this yet. We plan to go live
> with the fully hosted version first and extend it with support for
> non-hosted systems around Q2/Q3 2011.

this is a significant slip from the 1q11 we were told in prague.  care
to explain.

> Randy Bush who is cc-ed may be able to provide some more insight in
> the features offered by the ISC rpkid. I don't know whether the
> features mentioned by Alex in his first message will be supported by
> this system.

calling it isc's is a bit incorrect, but no difference.

it is an open source, bsd license, i.e. free as in free, implementation
of all of the rpki protocols, provisioning, up/down, publication, relying
party, proto-gui to manage your resources, ...  the full monty.  it has
been operational in a testbed with isp players from asia, the states,
europe, ... for some time.

randy

Re: do you use SPF TXT RRs? (RFC4408)

[Suresh Ramasubramanian]

dig throwaway1.com NS
dig throwaway2.com NS

etc etc ... and then check_sender_ns_access in postfix, for example.

Scales much better than whackamoling one domain after the other on the same NS

On Mon, Oct 4, 2010 at 4:59 PM,   wrote:
>
> 140 million .coms. Throw-away domains. I do believe that Marcus Ranum had
> "trying to enumerate badness" on his list of "Six stupidest security ideas".
> This won't scale as long as you have more spammers adding new domains faster
> than your NOC staff can add them to the blacklist.
>
> (And even centralized blacklists run by dedicated organizations haven't solved
> the problem yet, so I'm not holding my breath waiting for that to work out...)



-- 
Suresh Ramasubramanian (ops.li...@gmail.com)

Re: do you use SPF TXT RRs? (RFC4408)

[Valdis . Kletnieks]

On Mon, 04 Oct 2010 13:30:55 PDT, Owen DeLong said:

> Removing a few points probably isn't a bad idea so long as you have a list of
> domains for which points should be added.

140 million .coms. Throw-away domains. I do believe that Marcus Ranum had
"trying to enumerate badness" on his list of "Six stupidest security ideas".
This won't scale as long as you have more spammers adding new domains faster
than your NOC staff can add them to the blacklist.

(And even centralized blacklists run by dedicated organizations haven't solved
the problem yet, so I'm not holding my breath waiting for that to work out...)

Re: Whois lookups (was: 2010.10.04 NANOG50 day 1 morning notes posted)

[David Conrad]

On Oct 4, 2010, at 9:58 AM, John Curran wrote:
> On Oct 4, 2010, at 1:25 PM, Seth Mattinen wrote:
>> Or the new whois doesn't scale as well as the old one.
>  New WHOIS scales much better than the old one; it would have 
>  extremely challenging to assemble enough equipment to handle 
>  the current query rate.  Look at the NANOG presentation slide
>  for the exact query rate graph, but we're handling orders of 
>  magnitude more queries at present.

Looking at the graph on your 3 slide, it looks like ARIN is getting around 3200 
whois queries per second.  How much of that query load is a result of non-port 
43 queries (that is, making use of the REST features in the new server)?  It 
looks like the exponentiation in query load started around the same time the 
Whois-RWS was deployed... 

Regards,
-drc

Re: do you use SPF TXT RRs? (RFC4408)

[Owen DeLong]

On Oct 4, 2010, at 10:16 AM, Michael Thomas wrote:

> On 10/04/2010 10:05 AM, John Adams wrote:
>> We've seen percentage gains when signing with DK, and we carefully
>> monitor our mail acceptance percentages with ReturnPath. It's around
>> 4-6%. I'd like to stop using it, but some people still check DK.
> 
> Sigh. I was hoping not to hear that. It's been about 5 years since
> the issue of rfc4871. It might be helpful to name and shame.
> 
> Mike
> 
At least in that case, the spammer has to have control of the sending domain.
SPF is not intended to protect from that case. It is intended to protect from 
the
case where spammers Joe-job domains they can't control.

Removing a few points probably isn't a bad idea so long as you have a list of
domains for which points should be added.

Owen

>> 
>> -j
>> 
>> 
>> On Mon, Oct 4, 2010 at 10:02 AM, Michael Thomas  wrote:
>>> On 10/04/2010 09:54 AM, John Adams wrote:
 
 Without proper SPF records your mail stands little chance of making it
 through some of the larger providers, like gmail, if you are sending
 in any high volume. You should be using SPF, DK, and DKIM signing.
>>> 
>>> There should really be no reason to sign with DK too. It's historic.
>>> 
 I don't really understand how your security company related SPF to DoS
 though. They're unrelated, with the exception of backscatter.
>>> 
>>> Me either.
>>> 
>>> Mike
>>> 
 
 -j
 
 
 On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott
  wrote:
> 
> A partner had a security audit done on their site.  The report said they
> were at risk of a DoS due to the fact they didn't have a SPF record.
> 
> I commented to his team that the SPF idea has yet to see anything near
> mass deployment and of the millions of emails leaving our environment
> yearly,  I doubt any of them have ever been dropped due to us not having 
> an
> SPF record in our DNS.  When a client's email doesn't arrive somewhere,  
> we
> will hear about it quickly,  and its investigated/reported upon.  I'm
> not opposed to putting one in our DNS,  and probably will now - for
> completeness/best practice sake..
> 
> 
> how many of you are using SPF records?  Do you have an opinion on their
> use/non use of?
> 
> take care,
> greg
> 
> 
> 
> 
> 
> 
> 
>>> 
>>> 
> 

NANOG50 VCR (Vendor Collaboration Room)

[John Jason Brzozowski]

Hopefully you are all aware of the NANOG50 VCR, please visit the following
page for additional information:

http://www.nanog.org/meetings/nanog50/vcr.php

We wanted to send you a quick email and provide some additional information
about the VCR.  When in or near the VCR feel free to connect any of the
wireless networks.  Each is native dual stack enabled.  Most are powered by
residential home networking equipment.

Thanks again and please let us know if you have any questions.

Regards,

John
=
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozow...@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=

re: Akamai Traffic Spikes

[Nick Olsen]

Didn't see any spikes here, But from the looks of that graph something sure 
happened. It was huge, And only for a short period, Strange.

Nick Olsen
Network Operations
(877) 804-3001  x106



From: "Scott, Robert D." 
Sent: Monday, October 04, 2010 3:51 PM
To: "nanog@nanog.org" 
Subject: Akamai Traffic Spikes

We were trying to diagnose an issue we had around 1 PM EDST, and were 
looking at net flow data. The data indicated a significant change in our 
traffic patterns, all coming from Akamai address space. The Akamai 
utilization graphs show a near doubling of retail traffic in the same time 
period that we had traffic spikes. Does anybody have any idea what caused 
such a major surge in traffic? 

http://www.akamai.com/html/technology/nui/retail/charts.html

Robert D. Scott   rob...@ufl.edu
Senior Network Engineer   352-273-0113 Phone
CNS - Network Services352-392-2061 CNS Phone Tree
University of Florida 352-392-9440 FAX
Florida Lambda Rail   352-294-3571 FLR NOC
Gainesville, FL  32611321-663-0421 Cell
3216630...@messaging.sprintpcs.com

Re: Akamai Traffic Spikes

[Patrick W. Gilmore]

On Oct 4, 2010, at 3:50 PM, Scott, Robert D. wrote:

> We were trying to diagnose an issue we had around 1 PM EDST, and were looking 
> at net flow data. The data indicated a significant change in our traffic 
> patterns, all coming from Akamai address space. The Akamai utilization graphs 
> show a near doubling of retail traffic in the same time period that we had 
> traffic spikes. Does anybody have any idea what caused such a major surge in 
> traffic? 
> 
> http://www.akamai.com/html/technology/nui/retail/charts.html

Akamai is happy to discuss traffic to individual ASes with those ASes.  Please 
be sure to send e-mail from a verifiable address in that AS if you want 
information about that AS.

If you are a peer, the standard peer...@akamai.com address works.

If you have Akamai boxes on your network, you can open a ticket with the 
Network Support group at netsupport-...@akamai.com.

Our 24/7 NOC, n...@akamai.com, can help with emergency problems, such as a 
congested link.  However, you will have to reach one of the other groups for 
in-depth, historical traffic investigation.

Or you can find one of the Akamai people at NANOG. :)


As for this specific problem, I haven't an idea what happened.  I can tell you 
Akamai's global traffic at 1300 EDT / 1700 UTC today was actually lower than 
yesterday's traffic at the same time.  Not sure if that means anything, though.

-- 
TTFN,
patrick

Re: Whois lookups (was: 2010.10.04 NANOG50 day 1 morning notes posted)

[John Curran]

On Oct 4, 2010, at 1:25 PM, Seth Mattinen wrote:
> 
> 
> Or the new whois doesn't scale as well as the old one.

Seth - 
 
  New WHOIS scales much better than the old one; it would have 
  extremely challenging to assemble enough equipment to handle 
  the current query rate.  Look at the NANOG presentation slide
  for the exact query rate graph, but we're handling orders of 
  magnitude more queries at present.

/John

Re: Request for participation - Arbor 2010 Worldwide Infrastructure Security Report.

[Scott Weeks]

--- rdobb...@arbor.net wrote:
From: "Dobbins, Roland" 

The 2009 edition of the survey is available here (registration required):



Why are we required to register to look at the survey?

scott

Akamai Traffic Spikes

[Scott, Robert D.]

We were trying to diagnose an issue we had around 1 PM EDST, and were looking 
at net flow data. The data indicated a significant change in our traffic 
patterns, all coming from Akamai address space. The Akamai utilization graphs 
show a near doubling of retail traffic in the same time period that we had 
traffic spikes. Does anybody have any idea what caused such a major surge in 
traffic? 

http://www.akamai.com/html/technology/nui/retail/charts.html

Robert D. Scott   rob...@ufl.edu
Senior Network Engineer   352-273-0113 Phone
CNS - Network Services352-392-2061 CNS Phone Tree
University of Florida 352-392-9440 FAX
Florida Lambda Rail   352-294-3571 FLR NOC
Gainesville, FL  32611321-663-0421 Cell
  3216630...@messaging.sprintpcs.com

Re: do you use SPF TXT RRs? (RFC4408)

[Tony Finch]

On Mon, 4 Oct 2010, Greg Whynott wrote:
>
> A partner had a security audit done on their site.  The report said they
> were at risk of a DoS due to the fact they didn't have a SPF record.

Bullshit.

> I commented to his team that the SPF idea has yet to see anything near
> mass deployment and of the millions of emails leaving our environment
> yearly, I doubt any of them have ever been dropped due to us not having
> an SPF record in our DNS.

In my experience the presence of SPF records causes more problems than the
absence, because it is incompatible with forwarded mail. If you are forced
to use it, don't use -all unless that's the entirety of the record.

> Do you have an opinion on their use/non use of?

It's easiest to just ignore them. The whole idea was wrong-headed from the
start. Use DKIM instead.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

Re: do you use SPF TXT RRs? (RFC4408)

[Greg Whynott]

i think it was an observation they made,  and suggestions to make things 
better.   I don't think the message was "fix this or you'll be off the air one 
day.".   

  if they have a 56k port speed(stuck in the 80's),  there is potential there 
for a DoS from a large volume of spam back splatter..  8)  

  over all,  I'm inclined to accept your assumptions.   

-g


On Oct 4, 2010, at 2:38 PM, Suresh Ramasubramanian wrote:

> On Mon, Oct 4, 2010 at 12:47 PM, Greg Whynott  wrote:
>> 
>> A partner had a security audit done on their site.  The report said they 
>> were at risk of a DoS due to the fact they didn't have a SPF record.
> 
> This is pure unadulterated BS from someone who doesnt understand
> either DDOS mitigation, or SPF .. or more likely both.
> 
> -- 
> Suresh Ramasubramanian (ops.li...@gmail.com)

Re: do you use SPF TXT RRs? (RFC4408)

[William Herrin]

On Mon, Oct 4, 2010 at 12:47 PM, Greg Whynott  wrote:
> A partner had a security audit done on their site.
>The report said they were at risk of a DoS due to
>the fact they didn't have a SPF record.
>
> how many of you are using SPF records?  Do you
> have an opinion on their use/non use of?


I use your SPF records (if you offer any) to prevent my servers from
slamming your servers with backscatter from someone forging your
address and sending me undeliverable email. Without SPF records,
you'll receive an undeliverable report for messages "from" you that I
can't deliver -- just like the RFC says I "must."

Regards,
Bill Herrin




-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: do you use SPF TXT RRs? (RFC4408)

[Suresh Ramasubramanian]

On Mon, Oct 4, 2010 at 12:47 PM, Greg Whynott  wrote:
>
> A partner had a security audit done on their site.  The report said they were 
> at risk of a DoS due to the fact they didn't have a SPF record.

This is pure unadulterated BS from someone who doesnt understand
either DDOS mitigation, or SPF .. or more likely both.

-- 
Suresh Ramasubramanian (ops.li...@gmail.com)

RE: A New TransAtlantic Cable System

[Rod Beck]

> By the way, my recollection is the undersea regenerators do purely optical 
> regeneration.
> There is no O-E conversions undersea, only at the landing stations and 
> terrestrial components.

I'm not clever enough to know of some way that you could do optical
regeneration without converting the signal to electrical and
retransmitting back as optical.. How is that done?

Erbium doped fibers. 

Re: RIP Justification

[Jeff Aitken]

On Fri, Oct 01, 2010 at 04:28:30PM +, Tim Franklin wrote:
> Leaf-node BGP config is utterly trivial [...]
> 
> The Enterprise guys really need to get out of the blanket "BGP is scary" 
> mindset

It's not just "enterprise" mindset.  Over the years I've seen a lot of
deployed gear that either didn't support BGP at all or for which it was a
significant extra cost.  At least in the past this applied to many
firewalls and load-balancers, and until recently, even one of the major
CMTS vendors didn't support BGP.

I agree that edge-node BGP is simple, but finding gear that supports it
isn't necessarily so.


--Jeff

Re: do you use SPF TXT RRs? (RFC4408)

[Douglas Otis]

 On 10/4/10 12:47 PM, Greg Whynott wrote:

A partner had a security audit done on their site.  The report said they were 
at risk of a DoS due to the fact they didn't have a SPF record.

I commented to his team that the SPF idea has yet to see anything near mass 
deployment and of the millions of emails leaving our environment yearly,  I 
doubt any of them have ever been dropped due to us not having an SPF record in 
our DNS.  When a client's email doesn't arrive somewhere,  we will hear about 
it quickly,  and its investigated/reported upon.  I'm not opposed to 
putting one in our DNS,  and probably will now - for completeness/best practice 
sake..


how many of you are using SPF records?  Do you have an opinion on their use/non 
use of?
It is ironic to see recommendations requiring use of SPF due to DoS 
concerns.  SPF is a macro language expanded by recipients that may 
combine cached DNS information with MailFrom local-parts to synthesize 
>100 DNS transactions targeting any arbitrary domain unrelated to those 
seen within any email message.  A free >300x DDoS attack while spamming.


SPF permits the use of 10 mechanisms that then require targets to be 
resolved which introduces a 10x multiplier.  The record could end with 
"+all", where in the end, any message would pass.  Since SPF based 
attacks are unlikely to target email providers, it seems few 
recommending SPF consider that resolving these records containing active 
content might also be a problem.


-Doug

Re: do you use SPF TXT RRs? (RFC4408)

[Rich Kulawiec]

On Mon, Oct 04, 2010 at 12:47:52PM -0400, Greg Whynott wrote:
> how many of you are using SPF records?  Do you have an opinion on their 
> use/non use of?

1. Not using them, and don't have any (observed) problems despite years
of closely monitoring mail logs looking for just such issues.

2. Note that they don't stop spam, don't stop forgery, and don't prevent
backscatter (aka outscatter).  [Similar/related technologies have
similar/related problems, so these points aren't really SPF-specific.]

3. As others have pointed out, you can just easily be DoS'd when using
them as you could be without.

---Rsk

Re: A New TransAtlantic Cable System

[Patrick Giagnocavo]

On 10/4/2010 1:24 PM, Heath Jones wrote:
>> By the way, my recollection is the undersea regenerators do purely optical 
>> regeneration.
>> There is no O-E conversions undersea, only at the landing stations and 
>> terrestrial components.
> 
> I'm not clever enough to know of some way that you could do optical
> regeneration without converting the signal to electrical and
> retransmitting back as optical.. How is that done?
> 
> 

A halfway-decent description of the physics of how this is done, is
covered in Neal Stephenson's excellent article on Wired:

http://www.wired.com/wired/archive/4.12/ffglass.html

The specific page covering optical regeneration:

http://www.wired.com/wired/archive/4.12/ffglass.html?pg=6&topic=

quote:


These signals begin to fade after they have traveled a certain distance,
so it's necessary to build amplifiers into the cable every so often. In
the case of FLAG, the spacing of these amplifiers ranges from 45 to 85
kilometers. They work on a strikingly simple and elegant principle. Each
amplifier contains an approximately 10-meter-long piece of special fiber
that has been doped with erbium ions, making it capable of functioning
as a laser medium. A separate semiconductor laser built into the
amplifier generates powerful light at 1,480 nm - close to the same
frequency as the signal beam, but not close enough to interfere with it.
This light, directed into the doped fiber, pumps the electrons orbiting
around those erbium ions up to a higher energy level.

The signal coming down the FLAG cable passes through the doped fiber and
causes it to lase, i.e., the excited electrons drop back down to a lower
energy level, emitting light that is coherent with the incoming signal -
which is to say that it is an exact copy of the incoming signal, except
more powerful.



Cordially

Patrick Giagnocavo
patr...@zill.net

Re: A New TransAtlantic Cable System

[nick hatch]

On Mon, Oct 4, 2010 at 10:24 AM, Heath Jones  wrote:

>
> I'm not clever enough to know of some way that you could do optical
> regeneration without converting the signal to electrical and
> retransmitting back as optical.. How is that done?
>
> I'm not sure how it's done in practice, but check out doped fiber
amplifiers for one possibility.

One has to grok laser fundamentals to get what's going on, but it's not an
especially complex topic.

-Nick

Re: do you use SPF TXT RRs? (RFC4408)

[Jared Mauch]

I've found lots of domains with +all which really should be -all since they 
were all spam. 

Jared Mauch

On Oct 4, 2010, at 1:08 PM, Nathan Eisenberg  wrote:

>> If it passes SPF we remove a few points of the spam weight.
> 
> I would rethink this practice.  Many spammers publish SPF valid records these 
> days precisely because of this.
> 
> Nathan 
> 
> 

Re: A New TransAtlantic Cable System

[Heath Jones]

> By the way, my recollection is the undersea regenerators do purely optical 
> regeneration.
> There is no O-E conversions undersea, only at the landing stations and 
> terrestrial components.

I'm not clever enough to know of some way that you could do optical
regeneration without converting the signal to electrical and
retransmitting back as optical.. How is that done?

Re: Whois lookups (was: 2010.10.04 NANOG50 day 1 morning notes posted)

[Seth Mattinen]

On 10/4/2010 10:05, Nathan Eisenberg wrote:
> http://kestrel3.netflight.com/2010.10.04-NANOG50-morning-notes.txt
> 
> "
> Whois traffic has been going through the roof; they
> added more proxies in front to support it.
> Apparently, there's IP management packages that do
> whois queries.  It would be good to find out who is
> doing it, and talk to ARIN engineering, to find a better
> way of handling it.
> We can't keep up if so many machines on the internet
> keep doing it like this.
> Source addresses are all over, they're all over, not
> sign of bots; could be a DLL or mac system startup
> that's doing it.
> Please, don't embed whois lookups in everyone's computers
> like this!!
> "
> 
> The only thing I know of is that packages like fail2ban that perform WHOIS 
> lookups when blocking IPs to generate abuse POC notification emails.  So more 
> SSH bruteforce attacks = more whois lookups.
> 


Or the new whois doesn't scale as well as the old one.

~Seth

Re: do you use SPF TXT RRs? (RFC4408)

[Michael Thomas]

On 10/04/2010 10:05 AM, John Adams wrote:

We've seen percentage gains when signing with DK, and we carefully
monitor our mail acceptance percentages with ReturnPath. It's around
4-6%. I'd like to stop using it, but some people still check DK.


Sigh. I was hoping not to hear that. It's been about 5 years since
the issue of rfc4871. It might be helpful to name and shame.

Mike



-j


On Mon, Oct 4, 2010 at 10:02 AM, Michael Thomas  wrote:

On 10/04/2010 09:54 AM, John Adams wrote:


Without proper SPF records your mail stands little chance of making it
through some of the larger providers, like gmail, if you are sending
in any high volume. You should be using SPF, DK, and DKIM signing.


There should really be no reason to sign with DK too. It's historic.


I don't really understand how your security company related SPF to DoS
though. They're unrelated, with the exception of backscatter.


Me either.

Mike



-j


On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott
  wrote:


A partner had a security audit done on their site.  The report said they
were at risk of a DoS due to the fact they didn't have a SPF record.

I commented to his team that the SPF idea has yet to see anything near
mass deployment and of the millions of emails leaving our environment
yearly,  I doubt any of them have ever been dropped due to us not having an
SPF record in our DNS.  When a client's email doesn't arrive somewhere,  we
will hear about it quickly,  and its investigated/reported upon.  I'm
not opposed to putting one in our DNS,  and probably will now - for
completeness/best practice sake..


how many of you are using SPF records?  Do you have an opinion on their
use/non use of?

take care,
greg

RE: do you use SPF TXT RRs? (RFC4408)

[Nathan Eisenberg]

> If it passes SPF we remove a few points of the spam weight.

I would rethink this practice.  Many spammers publish SPF valid records these 
days precisely because of this.

Nathan 

RE: A New TransAtlantic Cable System

[Rod Beck]

Hi Frank, 

Yes it does include all the O-E conversions. By the way, my recollection is the 
undersea regenerators do purely optical regeneration. There is no O-E 
conversions undersea, only at the landing stations and terrestrial components. 

Since the system is just in the planning stage, the latency estimate is 
conversative. It is better to surprise than disappoint ...



   Hi All.
   It appears we're discussing theoretical limits of silica-based glass
   here. The Press Release assertion talks about what a trader might
   experience. Hm. I would ask Rob Beck to clarify this point and inform
   whether the stated objective in the release accounts for the many o-e
   and e-o conversions on the overland part of the end-to-end trader
   connection, including the handoffs that occur in the NY and London
   metros.  I  know that terrestrially, i.e., here in the US, some
   brokerage firms and large banks (is there any longer a distinction
   between those two today?:) have used their clout to secure links that
   are virtually entirely optical in nature on routes that are under a
   thousand miles, but this is not an option on a submarine system
   that's intrinsically populated with electronics, never mind the tail
   sections that assume multiple service providers getting into the act.
   Rob? Anyone?
   FAC
   --- valdis.kletni...@vt.edu wrote:
   From: valdis.kletni...@vt.edu
   To: Heath Jones 
   Cc: nanog@nanog.org
   Subject: Re: A New TransAtlantic Cable System
   Date: Fri, 01 Oct 2010 10:08:50 -0400
   On Fri, 01 Oct 2010 15:01:25 BST, Heath Jones said:
   > >
   http://finance.yahoo.com/news/Hibernia-Atlantic-to-bw-3184701710.html
   ?x=0&.v=1
   > Sales spam - but still - very close to minimum possible latency!
   >  3471 miles @ 186,282 miles/s * 1.5 in glass * 2 round trip =
   55.9ms.
   My first thought is that they've found a way to cheat on the 1.5. If
   you can
   make it work at 1.4, you get down to 52.2ms - but get it *too* low
   and all
   your photons leak out the sides.  Hmm.. Unless you have a magic core
   that
   runs at 1.1 and a *cladding* that's up around 2.0?

Re: do you use SPF TXT RRs? (RFC4408)

[Greg Whynott]

it was the backskatter they were referring to,  where spamers forge your domain 
as the source of the email.   


Thanks John for your comments,

-g


On Oct 4, 2010, at 12:54 PM, John Adams wrote:

> Without proper SPF records your mail stands little chance of making it
> through some of the larger providers, like gmail, if you are sending
> in any high volume. You should be using SPF, DK, and DKIM signing.
> 
> I don't really understand how your security company related SPF to DoS
> though. They're unrelated, with the exception of backscatter.
> 
> -j
> 
> 
> On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott  wrote:
>> 
>> A partner had a security audit done on their site.  The report said they 
>> were at risk of a DoS due to the fact they didn't have a SPF record.
>> 
>> I commented to his team that the SPF idea has yet to see anything near mass 
>> deployment and of the millions of emails leaving our environment yearly,  I 
>> doubt any of them have ever been dropped due to us not having an SPF record 
>> in our DNS.  When a client's email doesn't arrive somewhere,  we will hear 
>> about it quickly,  and its investigated/reported upon.  I'm not opposed 
>> to putting one in our DNS,  and probably will now - for completeness/best 
>> practice sake..
>> 
>> 
>> how many of you are using SPF records?  Do you have an opinion on their 
>> use/non use of?
>> 
>> take care,
>> greg
>> 
>> 
>> 
>> 
>> 
>> 
>> 

Whois lookups (was: 2010.10.04 NANOG50 day 1 morning notes posted)

[Nathan Eisenberg]

http://kestrel3.netflight.com/2010.10.04-NANOG50-morning-notes.txt

"
Whois traffic has been going through the roof; they
added more proxies in front to support it.
Apparently, there's IP management packages that do
whois queries.  It would be good to find out who is
doing it, and talk to ARIN engineering, to find a better
way of handling it.
We can't keep up if so many machines on the internet
keep doing it like this.
Source addresses are all over, they're all over, not
sign of bots; could be a DLL or mac system startup
that's doing it.
Please, don't embed whois lookups in everyone's computers
like this!!
"

The only thing I know of is that packages like fail2ban that perform WHOIS 
lookups when blocking IPs to generate abuse POC notification emails.  So more 
SSH bruteforce attacks = more whois lookups.

Nathan
 

> For those who might care, I've put version 1.0 of my notes from the morning
> session up at 
> http://kestrel3.netflight.com/2010.10.04-NANOG50-morning-notes.txt

Re: do you use SPF TXT RRs? (RFC4408)

[John Adams]

We've seen percentage gains when signing with DK, and we carefully
monitor our mail acceptance percentages with ReturnPath. It's around
4-6%. I'd like to stop using it, but some people still check DK.

-j


On Mon, Oct 4, 2010 at 10:02 AM, Michael Thomas  wrote:
> On 10/04/2010 09:54 AM, John Adams wrote:
>>
>> Without proper SPF records your mail stands little chance of making it
>> through some of the larger providers, like gmail, if you are sending
>> in any high volume. You should be using SPF, DK, and DKIM signing.
>
> There should really be no reason to sign with DK too. It's historic.
>
>> I don't really understand how your security company related SPF to DoS
>> though. They're unrelated, with the exception of backscatter.
>
> Me either.
>
> Mike
>
>>
>> -j
>>
>>
>> On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott
>>  wrote:
>>>
>>> A partner had a security audit done on their site.  The report said they
>>> were at risk of a DoS due to the fact they didn't have a SPF record.
>>>
>>> I commented to his team that the SPF idea has yet to see anything near
>>> mass deployment and of the millions of emails leaving our environment
>>> yearly,  I doubt any of them have ever been dropped due to us not having an
>>> SPF record in our DNS.  When a client's email doesn't arrive somewhere,  we
>>> will hear about it quickly,  and its investigated/reported upon.      I'm
>>> not opposed to putting one in our DNS,  and probably will now - for
>>> completeness/best practice sake..
>>>
>>>
>>> how many of you are using SPF records?  Do you have an opinion on their
>>> use/non use of?
>>>
>>> take care,
>>> greg
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>

Re: do you use SPF TXT RRs? (RFC4408)

[bmanning]

On Mon, Oct 04, 2010 at 12:47:52PM -0400, Greg Whynott wrote:
> 
> A partner had a security audit done on their site.  The report said they were 
> at risk of a DoS due to the fact they didn't have a SPF record.   

that does not follow at all.

> 
> I commented to his team that the SPF idea has yet to see anything near mass 
> deployment and of the millions of emails leaving our environment yearly,  I 
> doubt any of them have ever been dropped due to us not having an SPF record 
> in our DNS.  When a client's email doesn't arrive somewhere,  we will hear 
> about it quickly,  and its investigated/reported upon.  I'm not opposed 
> to putting one in our DNS,  and probably will now - for completeness/best 
> practice sake..  
> 
> 
> how many of you are using SPF records?  Do you have an opinion on their 
> use/non use of?


I don't use them.

--bill

> 
> take care,
> greg
> 
> 
> 
> 
> 
> 

Geoff Huston's study on IPv6 Background Radiation - now on RIPE Labs

[Mirjam Kuehne]

Hi,

Earlier today, Geoff Huston presented the following at NANOG 50 in 
Atlanta: Background Radiation in IPv6.


You can read the full story now on RIPE Labs:

https://labs.ripe.net/Members/mirjam/background-radiation-in-ipv6

Kind Regards,
Mirjam Kuehne
RIPE NCC

Re: do you use SPF TXT RRs? (RFC4408)

[Michael Thomas]

On 10/04/2010 09:54 AM, John Adams wrote:

Without proper SPF records your mail stands little chance of making it
through some of the larger providers, like gmail, if you are sending
in any high volume. You should be using SPF, DK, and DKIM signing.


There should really be no reason to sign with DK too. It's historic.


I don't really understand how your security company related SPF to DoS
though. They're unrelated, with the exception of backscatter.


Me either.

Mike



-j


On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott  wrote:


A partner had a security audit done on their site.  The report said they were 
at risk of a DoS due to the fact they didn't have a SPF record.

I commented to his team that the SPF idea has yet to see anything near mass 
deployment and of the millions of emails leaving our environment yearly,  I 
doubt any of them have ever been dropped due to us not having an SPF record in 
our DNS.  When a client's email doesn't arrive somewhere,  we will hear about 
it quickly,  and its investigated/reported upon.  I'm not opposed to 
putting one in our DNS,  and probably will now - for completeness/best practice 
sake..


how many of you are using SPF records?  Do you have an opinion on their use/non 
use of?

take care,
greg

re: do you use SPF TXT RRs? (RFC4408)

[Nick Olsen]

We use SPF. Lots of the bigger guys require it. Along with DK/DKIM 
signing.
In our spam weight based filtering, if it hardfails it drops it, 
softfail(no spf record) we don't add or remove points at all. If it passes 
SPF we remove a few points of the spam weight.

Nick Olsen
Network Operations
(877) 804-3001  x106



From: "Greg Whynott" 
Sent: Monday, October 04, 2010 12:48 PM
To: "nanog@nanog.org list" 
Subject: do you use SPF TXT RRs?  (RFC4408)

A partner had a security audit done on their site.  The report said they 
were at risk of a DoS due to the fact they didn't have a SPF record.   

I commented to his team that the SPF idea has yet to see anything near mass 
deployment and of the millions of emails leaving our environment yearly,  I 
doubt any of them have ever been dropped due to us not having an SPF record 
in our DNS.  When a client's email doesn't arrive somewhere,  we will hear 
about it quickly,  and its investigated/reported upon.  I'm not opposed 
to putting one in our DNS,  and probably will now - for completeness/best 
practice sake..  

how many of you are using SPF records?  Do you have an opinion on their 
use/non use of?

take care,
greg

2010.10.04 NANOG50 day 1 morning notes posted

[Matthew Petach]

For those who might care, I've put version 1.0 of
my notes from the morning session up at
http://kestrel3.netflight.com/2010.10.04-NANOG50-morning-notes.txt

and I bounced apache on the box, since it seemed to have gotten
hung--sorry about that, for those who were puzzled at the timing
out URL from earlier.  ^_^;;

Matt

Re: do you use SPF TXT RRs? (RFC4408)

[John Adams]

Without proper SPF records your mail stands little chance of making it
through some of the larger providers, like gmail, if you are sending
in any high volume. You should be using SPF, DK, and DKIM signing.

I don't really understand how your security company related SPF to DoS
though. They're unrelated, with the exception of backscatter.

-j


On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott  wrote:
>
> A partner had a security audit done on their site.  The report said they were 
> at risk of a DoS due to the fact they didn't have a SPF record.
>
> I commented to his team that the SPF idea has yet to see anything near mass 
> deployment and of the millions of emails leaving our environment yearly,  I 
> doubt any of them have ever been dropped due to us not having an SPF record 
> in our DNS.  When a client's email doesn't arrive somewhere,  we will hear 
> about it quickly,  and its investigated/reported upon.      I'm not opposed 
> to putting one in our DNS,  and probably will now - for completeness/best 
> practice sake..
>
>
> how many of you are using SPF records?  Do you have an opinion on their 
> use/non use of?
>
> take care,
> greg
>
>
>
>
>
>
>

RE: do you use SPF TXT RRs? (RFC4408)

[Nathan Eisenberg]

> how many of you are using SPF records?  Do you have an opinion on their
> use/non use of?
 
We use SPF on most client domains.  On inbound filtering, we add no score for a 
lack of SPF record, and we reject mail if the SPF record hardfails.  We've seen 
it reduce domain-imposter spam.  It's not the ultimate spam fighting tool, but 
it does give you some control over your own domain for whoever will listen to 
it, which is handy.  The only 'DoS Mitigation'  I can think of is that the 
presence of a hardfail record would help keep your domain off the various DBLs. 
 You could call "getting a domain blacklisted" a denial of service, I suppose.

Nathan

do you use SPF TXT RRs? (RFC4408)

[Greg Whynott]

A partner had a security audit done on their site.  The report said they were 
at risk of a DoS due to the fact they didn't have a SPF record.   

I commented to his team that the SPF idea has yet to see anything near mass 
deployment and of the millions of emails leaving our environment yearly,  I 
doubt any of them have ever been dropped due to us not having an SPF record in 
our DNS.  When a client's email doesn't arrive somewhere,  we will hear about 
it quickly,  and its investigated/reported upon.  I'm not opposed to 
putting one in our DNS,  and probably will now - for completeness/best practice 
sake..  


how many of you are using SPF records?  Do you have an opinion on their use/non 
use of?

take care,
greg

2010.10.03 NANOG50 NANOG Community meeting nots

[Matthew Petach]

Here's my notes from the community meeting from last night;
sorry about being a bit late with them, the meeting ran long,
and we dashed straight out from it to the social, which had
already started by the time we wrapped up.  ^_^;;
Apologies for any typos still in the notes, I did a quick
proofread this morning while jotting down this morning's
notes, so it wasn't terribly thorough.

Bcc'ing to nanog-futures@ as well, as it is germaine
to both lists.

Notes are also available online at
http://kestrel3.netflight.com/2010.10.03-NANOG50-community-meeting.txt

Matt



NANOG50
2010.10.03 community meeting notes

AGENDA:
Steering committee report -- steve feldman
Progream committee report dave meyer
Communicatons commitee report

This is a dialog, not a lecture; come to the mic
with questions, comments, etc.

steering committee report -- steve feldman
blue badges are steering committee

highlights since nanog49:
day-to-day nanog stuff has Just Been Working
 thanks to hosts and merit for that!
prep for 2010 election
Postel network operator's scholarship
preoparation for this and future meetings, through 2011
 and the transition


After NANOG50
 select new PC members
 select new CC members (nominations still open)
 start on planning for 2012 meetings
  and the transition


Mailing lists...look at website for list.

Dave Meyers, Program Committee Report
PC has yellow badges; if you like things on program,
come let yellow badge people know.
PC members really pull the conference together.

PC committee member list

Communications Committee Report, Mike Smith
Red target badges!
List of CC members is shown.

They try to take a light hand when running the list;
nanog-futures is a great forum, please do speak up.
They are very much in need of more people, so make
sure to nominate your friends (or enemies!)!


Marketing Working Group -- Cat Hoffman
members listed..
Full sponsorship attendance at NANOG49
 sponsorship appreciation lunch and pre-promotion for NANOG50
 Atlanta NANOG50
 full sponsorship promotion attendance
 pre-promotion of NANOG51
Vendor Collaboration
 check it out in Chastain Room (may be called NOG room)


Merit Report  --  Andy R.
Thanks to meeting host, TelX
network connectivity, engineering
power in general session
onsite meeting staffing
2 socials!

Other contributors for logistics
Break sponsors, breakfasts, etc.

Beer and Gear is Monday evening, they double as
breakfast sponsors as well.

Vendor collaboration is Comcast, Arris, A10, [and one more I missed]

Merit Network Team
Larry Blunk, David Bilbertson , DSue Joiner ,Dawn Khan, Rob Levitt,
Carl Wadsworth.
Pete Hoffswell


NANOG 49, SF
Attendance
607 total (record!)
505 PAID
102 WAIVED
199 newcomers (32.7%)
9 students
26 countries
31 US states plus DC

NANOG49
revenue 409,061
expense, 423,340
balance -14,279

hosting was 184,221; SF was about 80,000 more than
previous meetings; expense place to host, about 34%
more than other locations.

2 big staff transitions at the beginning of the year,
from Merit, put against the revenue from meetings,
cost of about 40,000.

2 meetings upcoming
NANOG51 Jan30-Feb2, Miami FL, Terremark
NANOG52, June 12-15, 2011 Denver, CO, Alcatel, Lucent


NANOG Election
election process
SC candidates
NANOG charter amendment
NewNOG charter

Election slide, giving eligibility
instructions should be on NANOG page; you can vote any
time up to Weds morning.
Announced Weds at lunch.

Please, if you have opinion, please vote!

SC candidates, 5 for 3 positions
Thanks to Joe Provo who is aging out after 4 years.

Rob Seastrom
Richarch Steenbergen
John Osmon
Michael K Smith
Patrick Gilmore

Order is random, don't read anything into it.

Rob Seastrom starts off with his statement, listing his
experiences and background; his position statement is on
the web, you can read it there.  He'd like to help make
Nanog stand on its own, and has some 501(3c) experience.

Richard Steenbergen is up next; he's been on PC for 4
years, he's termed out there, so now he's running for
SC.  He thinks NANOG's been doing good job on the reform
process that last 4 years; he'd like to help make the
transition go smoothly, keep mailing list on topic,
make it a good place for engineers to get information.
And if you vote for him, you get custom-printed M&Ms.  :)

Michael K. Smith--chair of communications committee;
been on SC as non-voting member for past year, working
to make newNOG a success.  Has been working on doing
business modelling for the organization, and wants to
keep doing it!

Patrick Gilmore--he helped start newNOG, and wants to see
it through; there's five really good candidates, so whomever
you pick, newNOG will be in good hands.   If you like what
he's done, vote him back; otherwise, vote him off and signal
a desire for change.

SC members will become newNOG board members, btw.


New Charter Amendment on Ballot
Lets Merit wind down, and newNOG wind up; it's an
endorsement for newNOG organization.  If you're in
favour of it, vote for it.  :)

Ther

Re: router lifetime

[Jon Lewis]

On Mon, 4 Oct 2010, Curtis Maurand wrote:


On 10/2/2010 7:23 PM, Franck Martin wrote:

How long do you keep a router in production?

What is your cycle for replacement of equipment?

For a PC, you usually depreciate it over 3 years, and can make it last 5 
years, but then you are stretching the functionality, especially if you 
upgrade the OS, tho it is not uncommon to see companies still on XP and 
IE6.

Hell, we still have Windows 2000 and IE6.


People tend to want/expect faster graphics performance, faster CPUs, more 
RAM for bigger (or more bloated) applications.


A router handling T1 aggregation (i.e. cisco 7206, PA-MC-T3, M13 mux) 10 
years ago will still handle T1 aggregation today (assuming you still have 
T1 customers).  Over that time period, the only major change is that with 
routing table growth, routers that were able to handle full routes no 
longer can...so you either have to upgrade the NPE board to one that can 
hold 512MB or more or give up full routes.  And with the widebank28 muxes, 
you just have to replace the mux controller cards every few years as they 
tend to burn out.


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

Re: [ncc-services-wg] RPKI Resource Certification: building features

[Owen DeLong]

>> 
>> No... I'm saying that if ISPs aren't the only entities that hold their
>> private keys, then they aren't the only entities that can sign their
>> resources.
> 
> The hosted system that we created uses Hardware Signing Modules (HSM)
> for generating keys and signing operations. By design it is impossible
> to retrieve the private keys. Any process or feature that would involve
> the transferral of keys cannot be implemented.
> 
In other words, not only do you hold the resource holders private key, but,
they do not. This means that the ability to sign their resources is 100% under
your control and 0% under their control except to the extent that you allow
it.

While I'm not accusing RIPE of nefarious conduct and do not believe that
there is any malicious intent in the system, I do believe that it is a security
model that any rational provider would likely consider untenable.

The fact that you cannot retrieve the key is of little relevance, since you
have full use of the key without retrieving it.

> Access to the *use* of the keys is a different thing though. This is
> controlled by the software. Although we cannot extract the keys, we can
> instruct the HSM to create a new key, or use an existing key to sign
> something.
> 
Exactly...

> Our hosted software controls all (activated) hosted member certificate
> authorities. The process has potential access to the *use* of *all* keys
> in the system. However, other security layers are implemented to ensure
> that for a given LIR only those users that have the 'certification'
> group enabled are *authorised* to use the hosted system -- and thereby
> the applicable keys.
> 
But by the very nature, the administrators of the system have the ability
to make themselves members of the certification group.

While I'm not saying that I think RIPE would do such a thing, the reality
is that using this hosted solution is placing a tremendous amount of
trust in the system and the administrators of the system. I have no
problem with LIRs that choose to do this, so long as they are making
an informed decision and understand the risks.

I think the risks have been substantially down-played.

>> 
>> If you choose to delegate the CA role for signing your resources
>> to someone else, then, obviously, you have to give them a valid
>> private key with which to sign those resources.
>> 
> 
> 
> Given this setup a member can authorise any person to use the system by
> creating an LIR Portal account for them and enabling the certification
> group. Only the LIR's admin user can do this.
> 
Really? There's no way for any member of RIPE staff to make corrections
to an LIR's admin account such that it would be possible to bypass this?
I tend to doubt that any sustainable system could be built in such a manner.

Again, I am not accusing RIPE of doing so, but, pointing out that for such
a hosted solution to remain functional over time, there must be certain
compromises in the trust model. These compromises should at least
give one pause and be carefully considered prior to handing over that
level of trust.

>> However, in doing that, you've created a situation where your 
>> signature is now much easier to forge. Kind of like automatic
>> signing machines for checks. Benefit: The accounting department
>> can sign thousands of checks and the CFO doesn't have to.
>> Draw-back... The accounting department can sign thousands of
>> checks without the CFO knowing they did so.
>> 
> 
> The current system has an audit history page that shows all the commands
> executed by users. It includes details like the name of the user, the
> time of the change and further details: e.g. in case of the modification
> of a ROA specification the complete new specification is visible in the
> history.
> 
So at least if someone does something horrible, assuming the system
integrity is not compromised in the process, we can tell what happened
and either who did it, or, at least who they chose to impersonate. That's
good, but, by itself it is not enough.

> There is currently no additional notification mechanism implemented but
> that would be fairly trivial to add if there is a demand.
> 
That would be a good additional safety feature.

> 
> Non-hosted:
> =
> 
> Of course we put a lot of effort into maintaining security and quality
> of the implementation we built. But we can well imagine that for some
> people it is a matter of principle that they want full local access to
> their own private keys and important configuration objects such as ROAs
> -- and don't want to be hosted on a shared system outside of their
> control. Other members may not mind so much about this and choose to
> trust and use the hosted services.
> 
Exactly my point... Such a choice should be an informed decision and if
it is not a matter of choice made by the organization holding the resource
(as is currently the case), then, there are issues.

> There is standard that is close to completion in the SIDR WG in the IETF
> that de

Re: [ncc-services-wg] RPKI Resource Certification: building features

[Owen DeLong]

> 
>> I'll go a step further and say that the resource holder should be
>> the ONLY holder of the private key for their resources.
>> 
>> Owen
> 
> If you're saying that ISPs can only participate in an RPKI scheme if they
> run their own Certificate Authority, then I think that would practically
> ruin the chances of Certification actually ever taking off on a large
> scale.
> 
> -Alex

No... I'm saying that if ISPs aren't the only entities that hold their
private keys, then they aren't the only entities that can sign their
resources.

If you choose to delegate the CA role for signing your resources
to someone else, then, obviously, you have to give them a valid
private key with which to sign those resources.

However, in doing that, you've created a situation where your 
signature is now much easier to forge. Kind of like automatic
signing machines for checks. Benefit: The accounting department
can sign thousands of checks and the CFO doesn't have to.
Draw-back... The accounting department can sign thousands of
checks without the CFO knowing they did so.

Owen

Re: RPKI Resource Certification: building features

[Alex Band]

The thread got a bit torn apart due to some cross posting, so here are  
Randy and Owen's replies to keep it all together:


On Oct 3, 2010, at 7:26 PM, Randy Bush wrote:

Do you think there is value in creating a system like this?


yes. though, given issues of errors and deliberate falsifications, i  
am not entirely comfortable with the whois/bgp combo being  
considered formally authoritative. but we have to do something.

Are there any glaring holes that I missed


yes. the operator should be able to hold the private key to their  
certificate(s) or the meaning of 'private key' and the security  
structure of the [ripe part of the] rpki is a broken.

randy
I'll go a step further and say that the resource holder should be the  
ONLY holder of the private key for their resources.

Owen

On 3 Oct 2010, at 19:06, Alex Band wrote:

Most of the discussions around RPKI Resource Certification that have  
been held up to now have largely revolved around infrastructure and  
policy topics. I would like to move away from that here and discuss  
what kind of value and which features can be offered with  
Certification for network administrators around the world. Because  
in the end, the goal is to make Internet routing more robust and  
create a more reliable method for network operators to make routing  
decisions.


We all know about the shortcomings of the IRR system and that just  
half of all prefixes on the Internet have a route object associated  
with them (http://bgpmon.net/blog/?p=140). However, it does mean  
that there is ton of valuable information in the IRRs, whereas the  
Certification system needs to start from scratch. Based on many  
discussion I've had with members and the Community, here is my idea  
for a Route Origin Authorisation** (ROA) wizard that retrieves IRR  
information, compares it to real world routing and uses that for the  
creation of ROA Specifications. This has a number of benefits:


- Network operators don't have to create their routing policy in the  
Certification system from scratch
- Because a comparison between is done the IRR and RIS (http://ripe.net/ris/ 
), only accurate up-to-date information is added to the  
Certification system
- The accuracy of the IRR is increased as a bonus, and is achieved  
without leaving the wizard


Ideally, a network operator should be able to manage and publish  
their routing policy – both for the IRR and Certification – from one  
single interface.


Here are the basic steps for the wizard after a certificate is  
generated:


1. Start ROA Wizard

2. Detect IRR information using the AS numbers in the Certificate,  
like for example:

http://www.db.ripe.net/whois?searchtext=AS286&inverse_attributes=origin&form_type=simple

3: Compare results with RIS using RRCC/Netsense, like for example:
http://www.ris.ripe.net/cgi-bin/rrccng/query.cgi?target=AS286

4: Allow user to flag which ROA specifications they would actually  
like to create, based on the IRR and RRCC/Netsense results.


5: Allow user to create additional ROA Specifications

6: Detect which maintainer is used for the route objects in the IRR

7: Allow user to specify maintainer password/pgp key, so all route  
objects are updated/removed/added based on the ROAs that were  
created. This makes sure the data in the IRR and the Certification  
system is consistent.


8: Save and publish ROAs and route objects

Do you think there is value in creating a system like this? Are  
there any glaring holes that I missed, or something that could be  
added? I'm looking forward to your feedback.


Alex Band
RIPE NCC
http://ripe.net/certification


** The certification system largely revolves around three main  
elements: (1) the Certificate, that offers validated proof of  
holdership of an Internet Resource, (2) the Route Orgin  
Authorisation Object (ROA), a standardised document that states that  
the holder of a certain prefix authorises a particular AS to  
announce that prefix and (3) the Validator, which relying parties,  
i.e. your peers, can use to validate certificates and ROAs.

Re: router lifetime

[Curtis Maurand]

 On 10/2/2010 7:23 PM, Franck Martin wrote:

How long do you keep a router in production?

What is your cycle for replacement of equipment?

For a PC, you usually depreciate it over 3 years, and can make it last 5 years, 
but then you are stretching the functionality, especially if you upgrade the 
OS, tho it is not uncommon to see companies still on XP and IE6.

Hell, we still have Windows 2000 and IE6.

--Curtis

Re: [ncc-services-wg] RPKI Resource Certification: building features

[Alex Band]

On Mon, October 4, 2010 04:38, Owen DeLong wrote:
>
> On Oct 3, 2010, at 7:26 PM, Randy Bush wrote:
>
>>> Do you think there is value in creating a system like this?
>>
>> yes.  though, given issues of errors and deliberate falsifications, i am
>> not entirely comfortable with the whois/bgp combo being considered
>> formally authoritative.  but we have to do something.

But blindly considering whois/BGP authoritative is not what I am
proposing. I want to confront the network operator with what is registered
in the IRR and what is seen in BGP, and let the human element make
decisions and corrections, improving data quality in the process.

>>> Are there any glaring holes that I missed
>>
>> yes.  the operator should be able to hold the private key to their
>> certificate(s) or the meaning of 'private key' and the security
>> structure of the [ripe part of the] rpki is a broken.
>>
>> randy

In the hosted implementation the RIPE NCC currently has, only a registered
contact for an LIR with whom we have a business relationship has access to
the secured LIR Portal in which the Certification system is embedded.

The reason to offer a hosted system initially, is to take away the burden
from an LIR of having to run their own Certificate Authority. We offer a
service that makes the entry barrier for Certification as low as possible.
Properly running your own CA, with all the crypto aspects, is no small
feat for a lot of LIRs (technically, but perhaps more psychologically).
You may argue that it's easy and cheap to do yourself, but just look at
adoption rates and levels of IPv6 and DNSSEC *at an LIR level* to see what
reality is like.

After the production launch on 1 January 2011, the next step we will take
is to implement the up/down protocol, allowing people to run their own
Certificate Authority if they choose to do so. We plan to roll this out in
the first half of 2011. We'll go one step further by having our software
certified by an external independent company, and releasing it as open
source to the Community, so they can be sure they adopt a robust system if
they choose our package.

So in the end our implementation is not 'broken' as you say, it is in he
middle of a planned, phased approach. Not everything is possible yet and
that is a deliberate decision.

> I'll go a step further and say that the resource holder should be
> the ONLY holder of the private key for their resources.
>
> Owen

If you're saying that ISPs can only participate in an RPKI scheme if they
run their own Certificate Authority, then I think that would practically
ruin the chances of Certification actually ever taking off on a large
scale.

-Alex

Re: [ncc-services-wg] RPKI Resource Certification: building features

[mkarir]

Hi Alex,

We are trying to tackle a similar problem with the RADB.  The approach  
we have
taken is to build into the object management web portal an alerting  
system that
provides alerts to a user when there is a mismatch between what is in  
the IRR
and what is observed in BGP.  Right next to the alert will be a button  
that
they can click on to "fix" their own IRR information or to flag an  
object
as "conflict - needs review" to allow Merit to manually review and  
resolve
conflicting IRR information.  If it indeed is a hijack then they can  
take other

steps.

A second piece of this is a historical origin database we have built  
where we
attempt to learn from history what a valid origin might be for a given  
prefix.
Lots of complications here with moas and newly announced prefixes but  
some
heuristics can help here.  Once again this db becomes a source of  
validation

information like the IRR database.  Not for use in rejecting/accepting
routes but for generating alerts that allow a user to fix/monitor their
routing assets.

So in both these cases we take what is reported in BGP and compare it  
with
sources of possible validation and generates alerts for users on  
mismatches.


The final piece of the puzzle which is a link with roa is something that
we are still working on integrating into the RADB.  The piece that is
currently in place add roa-uri tag to irrd which allows a user to
specify in the IRR a URI pointer to a roa for that prefix.  Currently
we dont use it in any validation.  However we have a modified
rpki-whois that at the end of the whois query will perform roa  
validation

and tell the user whether the roa was valid or in in addition to the
usual whois reponse.

-manish


On Oct 4, 2010, at 6:00 AM, routing-wg-requ...@ripe.net wrote:



Message: 1
From: Alex Band 
Date: Sun, 3 Oct 2010 19:08:33 +0200
To: ncc-services...@ripe.net,
routing...@ripe.net
Subject: [routing-wg] RPKI Resource Certification: building features

Most of the discussions around RPKI Resource Certification that have =
been held up to now have largely revolved around infrastructure and =
policy topics. I would like to move away from that here and discuss  
what =
kind of value and which features can be offered with Certification  
for =
network administrators around the world. Because in the end, the  
goal is =
to make Internet routing more robust and create a more reliable  
method =

for network operators to make routing decisions.

We all know about the shortcomings of the IRR system and that just  
half =
of all prefixes on the Internet have a route object associated with  
them =
(http://bgpmon.net/blog/?p=3D140). However, it does mean that there  
is =

ton of valuable information in the IRRs, whereas the Certification =
system needs to start from scratch. Based on many discussion I've  
had =

with members and the Community, here is my idea for a Route Origin =
Authorisation** (ROA) wizard that retrieves IRR information,  
compares it =

to real world routing and uses that for the creation of ROA =
Specifications. This has a number of benefits:

- Network operators don't have to create their routing policy in the =
Certification system from scratch
- Because a comparison between is done the IRR and RIS =
(http://ripe.net/ris/), only accurate up-to-date information is  
added to =

the Certification system
- The accuracy of the IRR is increased as a bonus, and is achieved =
without leaving the wizard

Ideally, a network operator should be able to manage and publish  
their =

routing policy =96 both for the IRR and Certification =96 from one =
single interface.=20

Here are the basic steps for the wizard after a certificate is =
generated:

1. Start ROA Wizard

2. Detect IRR information using the AS numbers in the Certificate,  
like =

for example:
=
http://www.db.ripe.net/whois?searchtext=3DAS286&inverse_attributes=3Dorigi=
n&form_type=3Dsimple

3: Compare results with RIS using RRCC/Netsense, like for example:
http://www.ris.ripe.net/cgi-bin/rrccng/query.cgi?target=3DAS286

4: Allow user to flag which ROA specifications they would actually  
like =

to create, based on the IRR and RRCC/Netsense results.

5: Allow user to create additional ROA Specifications

6: Detect which maintainer is used for the route objects in the IRR

7: Allow user to specify maintainer password/pgp key, so all route =
objects are updated/removed/added based on the ROAs that were  
created. =

This makes sure the data in the IRR and the Certification system is =
consistent.=20

8: Save and publish ROAs and route objects

Do you think there is value in creating a system like this? Are  
there =
any glaring holes that I missed, or something that could be added?  
I'm =

looking forward to your feedback.

Alex Band
RIPE NCC
http://ripe.net/certification


** The certification system largely revolves around three main  
elements: =

(1) the Certificate, that offers validated proof of holdership of an =
Internet Resource, (2) t

Re: RPKI Resource Certification: building features

[Alex Band]

And here is my reply to them...

On Mon, October 4, 2010 04:38, Owen DeLong wrote:


On Oct 3, 2010, at 7:26 PM, Randy Bush wrote:


Do you think there is value in creating a system like this?


yes.  though, given issues of errors and deliberate falsifications,  
i am

not entirely comfortable with the whois/bgp combo being considered
formally authoritative.  but we have to do something.


But blindly considering whois/BGP authoritative is not what I am
proposing. I want to confront the network operator with what is  
registered

in the IRR and what is seen in BGP, and let the human element make
decisions and corrections, improving data quality in the process.


Are there any glaring holes that I missed


yes.  the operator should be able to hold the private key to their
certificate(s) or the meaning of 'private key' and the security
structure of the [ripe part of the] rpki is a broken.

randy


In the hosted implementation the RIPE NCC currently has, only a  
registered
contact for an LIR with whom we have a business relationship has  
access to

the secured LIR Portal in which the Certification system is embedded.

The reason to offer a hosted system initially, is to take away the  
burden

from an LIR of having to run their own Certificate Authority. We offer a
service that makes the entry barrier for Certification as low as  
possible.

Properly running your own CA, with all the crypto aspects, is no small
feat for a lot of LIRs (technically, but perhaps more psychologically).
You may argue that it's easy and cheap to do yourself, but just look at
adoption rates and levels of IPv6 and DNSSEC *at an LIR level* to see  
what

reality is like.

After the production launch on 1 January 2011, the next step we will  
take

is to implement the up/down protocol, allowing people to run their own
Certificate Authority if they choose to do so. We plan to roll this  
out in

the first half of 2011. We'll go one step further by having our software
certified by an external independent company, and releasing it as open
source to the Community, so they can be sure they adopt a robust  
system if

they choose our package.

So in the end our implementation is not 'broken' as you say, it is in he
middle of a planned, phased approach. Not everything is possible yet and
that is a deliberate decision.


I'll go a step further and say that the resource holder should be
the ONLY holder of the private key for their resources.

Owen


If you're saying that ISPs can only participate in an RPKI scheme if  
they

run their own Certificate Authority, then I think that would practically
ruin the chances of Certification actually ever taking off on a large
scale.

-Alex


On 4 Oct 2010, at 10:54, Alex Band wrote:

The thread got a bit torn apart due to some cross posting, so here  
are Randy and Owen's replies to keep it all together:


On Oct 3, 2010, at 7:26 PM, Randy Bush wrote:

Do you think there is value in creating a system like this?


yes. though, given issues of errors and deliberate falsifications,  
i am not entirely comfortable with the whois/bgp combo being  
considered formally authoritative. but we have to do something.

Are there any glaring holes that I missed


yes. the operator should be able to hold the private key to their  
certificate(s) or the meaning of 'private key' and the security  
structure of the [ripe part of the] rpki is a broken.

randy
I'll go a step further and say that the resource holder should be  
the ONLY holder of the private key for their resources.

Owen

On 3 Oct 2010, at 19:06, Alex Band wrote:

Most of the discussions around RPKI Resource Certification that  
have been held up to now have largely revolved around  
infrastructure and policy topics. I would like to move away from  
that here and discuss what kind of value and which features can be  
offered with Certification for network administrators around the  
world. Because in the end, the goal is to make Internet routing  
more robust and create a more reliable method for network operators  
to make routing decisions.


We all know about the shortcomings of the IRR system and that just  
half of all prefixes on the Internet have a route object associated  
with them (http://bgpmon.net/blog/?p=140). However, it does mean  
that there is ton of valuable information in the IRRs, whereas the  
Certification system needs to start from scratch. Based on many  
discussion I've had with members and the Community, here is my idea  
for a Route Origin Authorisation** (ROA) wizard that retrieves IRR  
information, compares it to real world routing and uses that for  
the creation of ROA Specifications. This has a number of benefits:


- Network operators don't have to create their routing policy in  
the Certification system from scratch
- Because a comparison between is done the IRR and RIS (http://ripe.net/ris/ 
), only accurate up-to-date information is added to the  
Certification system
- The accuracy of the IRR is increased as a bonus