RE: Interesting Point of view - Russian police and RIPE accused of aiding RBN

[Martin, Paul]

So considering they're widely regarded as a criminal network hosting the
more dodgy/dangerous stuff on the net, surely we could 'protect' our
customers by blocking the 91.202.60.0/22 range?

Consider that can of worms opened :o)

Paul

-Original Message-
From: Jeffrey Lyon [mailto:jeffrey.l...@blacklotus.net] 
Sent: 24 October 2009 08:18
To: Suresh Ramasubramanian
Cc: nanog@nanog.org
Subject: Re: Interesting Point of view - Russian police and RIPE accused
of aiding RBN

Since we're on the subject, here is where RBN went:


inetnum: 91.202.60.0 - 91.202.63.255
netname: AKRINO-NET
descr:   Akrino Inc
country: VG
org: ORG-AI38-RIPE
admin-c: IVM27-RIPE
tech-c:  IVM27-RIPE
status:  ASSIGNED PI
mnt-by:  RIPE-NCC-HM-PI-MNT
mnt-by:  MNT-AKRINO
mnt-lower:   RIPE-NCC-HM-PI-MNT
mnt-routes:  MNT-AKRINO
mnt-domains: MNT-AKRINO
source:  RIPE # Filtered
organisation:ORG-AI38-RIPE
org-name:Akrino Inc
org-type:OTHER
address: Akrino Inc.
address: P.O.Box 146 Trident Chambers
address: Road Town, Tortola
address: BVI
e-mail:  noc.akr...@gmail.com
mnt-ref: MNT-AKRINO
mnt-by:  MNT-AKRINO
source:  RIPE # Filtered
person:  Igoren V Murzak
address: Akrino Inc
address: P.O.Box 146 Trident Chambers
address: Road Town, Tortola
address: BVI
phone:   +1 914 5952753
e-mail:  noc.akr...@gmail.com
nic-hdl: IVM27-RIPE
mnt-by:  MNT-AKRINO
source:  RIPE # Filtered
% Information related to '91.202.60.0/22AS44571'
route:   91.202.60.0/22
descr:   AKRINO BLOCK
origin:  AS44571
mnt-by:  MNT-AKRINO
source:  RIPE # Filtered


On Sat, Oct 24, 2009 at 3:00 AM, Suresh Ramasubramanian
 wrote:
>
http://www.eweekeurope.co.uk/news/russian-police-and-internet-registry-a
ccused-of-aiding-cybercrime-2165
>
> Some quotes from the article -
>
> Internet registry RIPE NCC turned a blind eye to cybercrime, and
Russian police
> corruption helped the perpetrators get away with it, according to the
UK
> Serious Organised Crime Agency
>
> [...]
>
> "RIPE was being paid by RBN for that service, for its IP allocation,"
he said.
> "Essentially what you have - and I make no apologies for saying this
is - if
> you were going to interpret this very harshly RIPE as the IP
allocation body
> was receiving criminal funds and therefore RIPE was involved in money
> laundering offences," said Auld.
>
> [...]
>
> "All we could get there was a disruption, we weren't able to get a
prosecution
> in Russia," admitted Auld. "Our biggest concern is where did RBN go?
Our
> information suggests that RBN is back in business but now pursuing a
slightly
> different business model which is bad news."
>
> [...]
>
> "Where you have got LIRs (Local Internet Registries) set up to run a
criminal
> business- that is criminal actvity being taken by the regional
internet
> registries themselves. "So what we are trying to do is work with them
to make
> internet governance a somewhat less permissive environment for
criminals and
> make it more about protecting consumers and individuals," added Auld.
> RBN looked legitimate, says RIPE NCC
>
> In response to the comments that it could be accused of being involved
in
> criminal activity, Paul Rendek, head of external relations and
communications
> at RIPE NCC said that the organisation has very strict guidelines for
dealing
> with LIRs.
>
> "The RBN was accepted as an LIR based on our checklists," he said."
Our
> checklists include the provision of proof that a prospective LIR has
the
> necessary legal documentation, which proves that a business is bona
fide."
>
> etc
>
>



-- 
Jeffrey Lyon, Leadership Team
jeffrey.l...@blacklotus.net | http://www.blacklotus.net
Black Lotus Communications of The IRC Company, Inc.

Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 -
21 to find out how to "protect your booty."



For more information about the Viatel Group, please visit www.viatel.com

VTL (UK) Limited Registered in England and Wales
Registered Address: Inbucon House, Wick Road, Egham, Surrey TW20 0HR  
Company Registration No: 04287100 VAT Registration Number: 781 4991 88

THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INTENDED RECIPIENT TO WHICH IT 
IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND 
EXEMPT FROM DISCLOSURE.  If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering the message to 
the intended recipient, you are notified that any dissemination, distribution 
or copying of this e-mail is prohibited, and you should delete this e-mail from 
your system.

This message has been scanned for viruses and spam by Viatel MailControl - 
www.viatel.com

RE: qos 3560

[Martin, Paul]

Following on, the best way is to 'trust' on all uplinks between devices
and filter at the edge. So you have a customer who shouldn't be sending
tagged traffic, set the port to not trusted (should be the default
state) and any customer using QoS should have "mls qos trust dscp" on
the demark port.

If you don't have a trusted core, then all it takes is a simple switch
in the path traffic takes and you'll find yourself scratching your head
as to why the DSCP tags are disappearing all of a sudden!


Paul



-Original Message-
From: Scott Morris [mailto:s...@emanon.com] 
Sent: 12 November 2009 14:41
To: Bogdan
Cc: nanog@nanog.org
Subject: Re: qos 3560

Look at "show mls qos map" to see the defaults that may be rewriting
your information depending on trust (or non-trust) mechanisms you have
configured.

If you trust CoS, a frame received with cos5 and dscp46 will get
rewritten to dscp 40 with default maps...

"show mls qos interface (intf)" is also good to see status.

Scott



Bogdan wrote:
> hello
>
> indeed, a fellow nanoger gave me this hint.
>
> 1. i had to enable mls qos globally in "network" switches
> 2. set the mls qos trust dscp on the uplinks (ingress port)
>
>
> thanks
>
> ps thanks to andrey.gordon too :)
>
>
>
>
>
> On 11/12/2009 03:21 PM, Brian Feeny wrote:
>   
>> You should make sure that any links that go between devices have
trust
>> set.  In your case if your doing DSCP,
>> then make sure each link that goes between devices which must carry
>> tagged packets have trust dscp set.
>>
>> Brian
>>
>> On Nov 12, 2009, at 5:11 AM, Bogdan wrote:
>>
>> 
>>> hello
>>>
>>> i am playing with qos on some devices
>>> - cisco 3560
>>> - cisco 7609
>>> and i have some things that i don't seem to understand.
>>>
>>> 1. in 3560, i enable mls qos, on the ingress port applyed policy
map,
>>> classify the packets with acl, mark, all good. on the egress ports i
use
>>> srr-queue with shape/share, everything is fine, it is working.
>>>
>>>
http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/relea
se/12.2_20_se/configuration/guide/swqos.html#wp1028614
>>>
>>>
>>>
>>> 2. reset to defaults the 3560
>>> in 7606 i pick up a vlan, and apply a policy-map and set dscp 40 on
>>> egress of that vlan
>>> 3560 in uplinked in 7609
>>> in 3560 i can see the "marked" packets, and i have matches on the
dscp
>>> set earlier (sh mls qos int xx stat).
>>> the problem is: when i apply the srr-queue in 3560 on egress
(towards
>>> the test port), it does not work.
>>> if i enable mls qos on 3560, i cannot match anymore the dscp 40 from
the
>>> 7609
>>>
>>> is it normal? do i have to apply the qos stuff (point1) on all
switches
>>> i want qos on? i mean, i cannot set dscp in one "core" device and
use
>>> that in the whole network ?
>>>
>>>
>>> thanks
>>>
>>>
>>>   
>> 
>
>
>
>
>   



For more information about the Viatel Group, please visit www.viatel.com

VTL (UK) Limited Registered in England and Wales
Registered Address: Inbucon House, Wick Road, Egham, Surrey TW20 0HR  
Company Registration No: 04287100 VAT Registration Number: 781 4991 88

THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INTENDED RECIPIENT TO WHICH IT 
IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND 
EXEMPT FROM DISCLOSURE.  If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering the message to 
the intended recipient, you are notified that any dissemination, distribution 
or copying of this e-mail is prohibited, and you should delete this e-mail from 
your system.

This message has been scanned for viruses and spam by Viatel MailControl - 
www.viatel.com

RE: dark fiber and sfp distance limitations

[Martin, Paul]

If you only want 1gig, then if the SP provides it, won't it be cheaper
to simply get a 1gig circuit from them that hands off to you on a GigE
port rather than pay for all the various higher spec equipment that
you'd otherwise require?

Paul.



-Original Message-
From: Kevin Hodle [mailto:kevin.ho...@gmail.com] 
Sent: 02 January 2010 23:36
To: Mike
Cc: nanog@nanog.org
Subject: Re: dark fiber and sfp distance limitations

On Fri, Jan 1, 2010 at 4:52 PM, Mike 
wrote:
> I am looking at the possibility of leasing a ~70 mile run of fiber. I
don't
> have access to any mid point section for regeneration purposes, and so
I am
> wondering what the chances that a 120km rated SFP would be able to
light the
> path and provide stable connectivity. There are a lot of unknowns
including
> # of splices, condition of the cable, or the actual dispersion index
or
> other properties (until we actually get closer to leasing it). Its
spare
> telco fibers in the same cable binder they are using interoffice
transport,
> but there are regen huts along the way so it works for them but may
not for
> us, and 'finding out' is potentially expensive. How would someone
> experienced go about determining the feasibillity of this concept and
what
> options might there be? Replies online or off would be appreciated.

I second the recommendation that you request OTDR traces from whomever
you are leasing the glass from, and further request traces for each
strand in *both* directions (a end to z end, z end to a end) at
multiple wavelengths, say 1530nm-1640nm at a maximum of 200GHz
wavelength spacing  to properly identify potential problem locations
in the future when you want to build out a  10GE metro DWDM solution
(You really do want to know about that old mechanical splice 20km into
your run, etc). An OTDR will provide you with granular loss/gain event
details for your entire span, while a power meter/light source will
only tell you your overall span loss.  While your fiber provider may
not pony up OTDR results until after you've executed the contract,
they should be able to give you a rough estimate of the total loss (in
dB for a 1550nm signal) for the span you are looking at leasing, and
you can build provisions into your contract that enforce an absolute
maximum loss on the span, in which case the provider will be forced to
take necessary actions to replace old poorly executed splices with
fusion splices, isolate and correct bends, etc. As most have pointed
out - EDFA should not be required for a 1GE single channel solution,
and probably would not be required for a simple 1GE CWDM setup either.
Once you graduate to an active 10GE DWDM solution EDFA's will be more
of a necessity (possibly with dispersion compensation, depending on
your vendor this may be an entirely separate shelf module or may be
build into the amp card). The addition of EDFA's in a multi-channel
solution also adds complexity (if you want to build a scalable/cost
effective solution). Most EDFA's have a maximum and minimum
per-channel input power, and ideally you would want to have each
channel near the same power level before hitting the EDFA. Depending
on your gear, topological complexity, etc this may require the use of
an optical spectrum analyzer to verify individual channel power levels
so the correct amount of attenuation can be added to each channel
before it hits the EDFA, however for a single point to point span this
will probably not be a concern.


-- 
Cheers,
Kevin

 Kevin Hodle | http://www.linkedin.com/in/kevinhodle

 PGP Key ID  | fingerprint
 0x803F24BE  | 1094 FB06 837F 2FAB C86B E4BE 4680 3679 803F 24BE

"Elegance is not a dispensable luxury but a factor that decides
between success and failure. "
-Edsgar Dijkstra




For more information about the Viatel Group, please visit www.viatel.com

VTL (UK) Limited Registered in England and Wales
Registered Address: Inbucon House, Wick Road, Egham, Surrey TW20 0HR  
Company Registration No: 04287100 VAT Registration Number: 781 4991 88

THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INTENDED RECIPIENT TO WHICH IT 
IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND 
EXEMPT FROM DISCLOSURE.  If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering the message to 
the intended recipient, you are notified that any dissemination, distribution 
or copying of this e-mail is prohibited, and you should delete this e-mail from 
your system.

This message has been scanned for viruses and spam by Viatel MailControl - 
www.viatel.com

RE: Comcast IPv6 Trials Update

[Martin, Paul]

I've just bought "IPv6 Essentials", however it turned out to be the 1st
edition, hopefully there won't be too many differences.

I'm also going to go through this PDF on the Cisco website that should
put a practical face on the book, which seems very theoretical on a
quick flick through ...

http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/12_4/ipv6_1
2_4_book.pdf



-Original Message-
From: Brzozowski, John [mailto:john_brzozow...@cable.comcast.com] 
Sent: 01 March 2010 14:37
To: bdflem...@kanren.net; cmaur...@xyonet.com
Cc: nanog@nanog.org
Subject: Re: Comcast IPv6 Trials Update

Did you check out IPv6 Essentials, 2nd edition by Siliva Hagen?


John
609-377-6594


- Original Message -
From: Brad Fleming 
To: Curtis Maurand 
Cc: nanog@nanog.org 
Sent: Mon Mar 01 09:27:48 2010
Subject: Re: Comcast IPv6 Trials Update

I found "Migrating to IPv6: A practical guide to implementing IPv6 in  
mobile and fixed networks" by Marc Blanchet very well written and  
"worth the price of admission".

ISBN: 978-0471-49892-6
--
Brad Fleming

On Mar 1, 2010, at 8:21 AM, Curtis Maurand wrote:

>
> Can anyone recommend a decent book on IPV6?  Most of what I find on  
> the net don't explain things very well.
>
> thanks,
> Curtis
>
> On 2/28/2010 2:08 PM, John Jason Brzozowski wrote:
>> Mike,
>>
>> Are you looking for something specific on www.comcast6.net?  We  
>> will likely
>> be making some content updates in the not too distant future and  
>> over time
>> as the trials progress and evolve.  If there is something specific  
>> you would
>> like to see send me your suggestions.
>>
>> Thanks,
>>
>> John
>>
>>
>> On 2/26/10 1:15 PM, "Michael Greb"  wrote:
>>
>>
>>> Received this message today.  They haven't updated the
>>>   site yet.
>>>
>>> Mike
>>>
>>> Begin forwarded message:
>>>
>>>
 An Important Message From Comcast

 Dear Comcast Customer,

 Thank you for volunteering to participate in Comcast's IPv6  
 trials! I wanted
 to provide you with a quick update on what our next steps are and  
 when you
 can expect to hear from us again.

 As you know, we have four trials described at
http://www.comcast6.net 
 . We're
 in detailed planning on the first three: 6RD, plus native dual- 
 stack for
 residential and for commercial customers. We expect each of these  
 to start
 sometime within the next 90 days or so.

 6RD Trial:
 We anticipate having customers from around our network, not  
 limited to any
 specific areas, participate. We will start the trial on a very  
 small scale
 and then progressively increase the number of participants. We  
 plan to ship a
 new home gateway device to each trial participant.

 Residential Native Dual-Stack Trial:
 This trial will be limited to a few areas in our network. We are  
 in the midst
 of determining precisely what those areas will be, based on where  
 we have
 volunteers and where the infrastructure will be ready. If trial  
 participants
 do not have an IPv6-capable home gateway and cable modem, one  
 will be
 provided.

 Commercial Native Dual-Stack Trial:
 This trial will be limited to a few areas in our network. We have  
 tentatively
 identified these trial areas and will soon be in touch with  
 potential trial
 users.

 Within approximately the next 30 days we will begin to contact  
 some of our
 volunteers regarding each of these trials, so expect to hear from  
 us soon.

 Thanks again for your interest!

 Regards
 Jason Livingood
 Internet Systems Engineering
 Comcast

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




For more information about the Viatel Group, please visit www.viatel.com

VTL (UK) Limited Registered in England and Wales
Registered Address: Inbucon House, Wick Road, Egham, Surrey TW20 0HR  
Company Registration No: 04287100 VAT Registration Number: 781 4991 88

THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INTENDED RECIPIENT TO WHICH IT 
IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND 
EXEMPT FROM DISCLOSURE.  If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering the message to 
the intended recipient, you are notified that any dissemination, distribution 
or copying of this e-mail is prohibited, and you should delete this e-mail from 
your system.

This message has been scanned for viruses and spam by Viatel MailControl - 
www.viatel.com