Re: FCC on wifi at hotel

[Brandon Galbraith]

On 2/28/07, Brian <[EMAIL PROTECTED]> wrote:


Brandon Galbraith wrote:
> On 2/28/07, *Steve Meuse* <[EMAIL PROTECTED] >
> wrote:
>
>
>
> On 2/28/07, *Jared Mauch* < [EMAIL PROTECTED]
> > wrote:
>
>
>
http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-06-157A1.pdf
> <
http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-06-157A1.pdf>
>
> I do suggest reading this.  They can not legally bar
> you from
> using the devices.  They can charge you outrageous fees to get
> to/from
> the MMR or telco demarc and make it prohibitively expensive.
>
>
> Right, a wifi that goes nowhere isn't terribly useful :)
>
>
> You could always get to upstream via wireless.
>
> -brandon
>
a small number of wifi users with a card in a laptop to get to cellular
broadband, itd be pretty easy..



Or directional wifi uplink to a building nearby, preferably G vs B (for
54Mbps).

Re: FCC on wifi at hotel

[Brian]

Brandon Galbraith wrote:
On 2/28/07, *Steve Meuse* <[EMAIL PROTECTED] > 
wrote:




On 2/28/07, *Jared Mauch* < [EMAIL PROTECTED]
> wrote:



http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-06-157A1.pdf


I do suggest reading this.  They can not legally bar
you from
using the devices.  They can charge you outrageous fees to get
to/from
the MMR or telco demarc and make it prohibitively expensive.


Right, a wifi that goes nowhere isn't terribly useful :) 



You could always get to upstream via wireless.

-brandon

a small number of wifi users with a card in a laptop to get to cellular 
broadband, itd be pretty easy..


Brian

Re: FCC on wifi at hotel

[Brandon Galbraith]

On 2/28/07, Steve Meuse <[EMAIL PROTECTED]> wrote:




On 2/28/07, Jared Mauch <[EMAIL PROTECTED]> wrote:
>
>
>
> http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-06-157A1.pdf
>
> I do suggest reading this.  They can not legally bar you from
> using the devices.  They can charge you outrageous fees to get to/from
> the MMR or telco demarc and make it prohibitively expensive.
>

Right, a wifi that goes nowhere isn't terribly useful :)



You could always get to upstream via wireless.

-brandon

Re: FCC on wifi at hotel

[Steve Meuse]

On 2/28/07, Jared Mauch <[EMAIL PROTECTED]> wrote:



http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-06-157A1.pdf

I do suggest reading this.  They can not legally bar you from
using the devices.  They can charge you outrageous fees to get to/from
the MMR or telco demarc and make it prohibitively expensive.




Right, a wifi that goes nowhere isn't terribly useful :)


-Steve

Re: FCC on wifi at hotel

[Robert Bonomi]

> Date: Wed, 28 Feb 2007 17:38:10 -0500
> From: Jared Mauch <[EMAIL PROTECTED]>
> Subject: Re: FCC on wifi at hotel
>
[[.. munch ..]]
>   http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-06-157A1.pdf
>
>   I do suggest reading this.  They can not legally bar you from
> using the devices.  They can charge you outrageous fees to get to/from
> the MMR or telco demarc and make it prohibitively expensive.
>
>   It may also be problematic to be held hostage showing up
> and them saying that no, you can not install your equipment while you
> hire a lawyer to explain to them that you are violating FCC fules
> for the "OTARD rules".
>
>   - Jared

Note well that the 'OTARD rules' do *NOT* apply to an organization holding
a meeting at a hotel, or other meeting/convention facility.

I quote:
   For the OTARD rules to apply, the antenna must be installed "on property 
   within the exclusive use or control of an antenna user where the user 
   has a direct or indirect ownership or leasehold interest in the property" 
   upon which the antenna is located.

An orgaization contractig for the short-term use of a meeting facility has
_no_ such 'ownership or leashold' interest in the property.

Re: FCC on wifi at hotel

[Jared Mauch]

On Wed, Feb 28, 2007 at 05:18:24PM -0500, Marshall Eubanks wrote:
> On Feb 28, 2007, at 5:01 PM, Steve Meuse wrote:
> >It's about revenue recovery. If you provide your own free wifi,  
> >they are losing potential business. It's usually part of the  
> >negotiation with the Hotel.
> >
> 
> Yes, some Hotels will indeed want "revenue recovery" for this - they  
> will typically start at the
> rental rate per person x the number of attendees x number of days,  
> which could be $ 10K USD per day or more for a 1000 person meeting.  
> You may or may not be able to negotiate it down; I think that in the  
> IETF experience the
> "negotiate it down" factor has ranged from not at all to 100%.
> 
> But, since it is part of the contract, they can certainly enforce  
> whatever is agreed to.

http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-06-157A1.pdf

I do suggest reading this.  They can not legally bar you from
using the devices.  They can charge you outrageous fees to get to/from
the MMR or telco demarc and make it prohibitively expensive.

It may also be problematic to be held hostage showing up
and them saying that no, you can not install your equipment while you
hire a lawyer to explain to them that you are violating FCC fules
for the "OTARD rules".

- Jared

-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: FCC on wifi at hotel

[Marshall Eubanks]

On Feb 28, 2007, at 5:01 PM, Steve Meuse wrote:



It's about revenue recovery. If you provide your own free wifi,  
they are losing potential business. It's usually part of the  
negotiation with the Hotel.




Yes, some Hotels will indeed want "revenue recovery" for this - they  
will typically start at the
rental rate per person x the number of attendees x number of days,  
which could be $ 10K USD per day or more for a 1000 person meeting.  
You may or may not be able to negotiate it down; I think that in the  
IETF experience the

"negotiate it down" factor has ranged from not at all to 100%.

But, since it is part of the contract, they can certainly enforce  
whatever is agreed to.


Regards
Marshall



-Steve


On 2/28/07, Carl Karsten <[EMAIL PROTECTED]> wrote:
me again.

So wifi at pycon 07 was 'better than 06' witch I hear was a  
complete disaster.

More on 07's coming soon.

Now we are talking about wifi at pycon 08, which will be at a  
different hotel
(Crown Plaza in Rosemont, IL) and the question came up: Can the  
hotel actively

prevent us from using our own wifi?

_maney: although - wasn't the hotel stuck on "our wifi or no wifi"  
at last report?


CarlFK: only the FCC can restrict radio

tpollari: it's their network and their power the FCC has no legal  
right to that.
and no, you show me where they do.  I'm not wasting my day with  
that tripe --
the caselaw you're likely thinking of has to do with an airline and  
an airport
and the airline's lounge, in which case they're paying for the  
power and paying

for their bandwidth from a provider that's not the airport. We're not.

I know that there are all sorts of factors, and just cuz the FCC  
says boo isn't
the end of the story, but i don't even know what the FCC's position  
on this is.
  google gave me many hits, and after looking at 10 or so I decided  
to look

elsewhere.

Carl K



--

-Steve

Re: FCC on wifi at hotel

[Jared Mauch]

On Wed, Feb 28, 2007 at 03:28:11PM -0600, Frank Bulk wrote:
> 
> While the hotel cannot prevent you from using Wi-Fi, but they could:
> a) restrict you from attaching equipment to their internet connection
> (unless you contracted for that and the contract didn't restrict
> attachments) or electrical outlets
> b) ask you to leave and charge you for trespassing if you didn't
> 
> Its highly unlikely those renting facilities from the hotel would agree to
> such onerous restrictions and a hotel renting you the facilities is unlikely
> going to boot you out.
> 
> See:
> http://www.wifinetnews.com/archives/007102.html
> for some good coverage on the Massport incident.

IANAL, but I just (re-)read the FCC order on the massport
"incident" (ugh, silly massport, i have avoided logan for years now
because of them..) and would like to offer my own comments on
the above.

Assuming you're there staying in a hotel room, it is likely to
be considered a nightly lease of some sort, which protects your rights
to use a "Part 15" unlicensed band device within your room.  This
would also extend to your lease of any meeting rooms where you
have some level of "exclusive" access to them.  (The continental case
actually is quite close to a conference where you may have paid 
attendees).  As long as you've contracted power for your devices or the
solar/battery array you're using to power the device meets the fire code,
it doesn't appear they can restrict your usage of any of these devices,
even if it's specifically prohibited in the lease/contract you have
signed.  In any common spaces (bathrooms, bar?, hallways, etc..) they
may be able to prohibit your placement of equipment, but not necessarily
the reception of the signal.

- Jared


-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: FCC on wifi at hotel

[Steve Meuse]

It's about revenue recovery. If you provide your own free wifi, they are
losing potential business. It's usually part of the negotiation with the
Hotel.

-Steve


On 2/28/07, Carl Karsten <[EMAIL PROTECTED]> wrote:



me again.

So wifi at pycon 07 was 'better than 06' witch I hear was a complete
disaster.
More on 07's coming soon.

Now we are talking about wifi at pycon 08, which will be at a different
hotel
(Crown Plaza in Rosemont, IL) and the question came up: Can the hotel
actively
prevent us from using our own wifi?

_maney: although - wasn't the hotel stuck on "our wifi or no wifi" at last
report?

CarlFK: only the FCC can restrict radio

tpollari: it's their network and their power the FCC has no legal right to
that.
and no, you show me where they do.  I'm not wasting my day with that tripe
--
the caselaw you're likely thinking of has to do with an airline and an
airport
and the airline's lounge, in which case they're paying for the power and
paying
for their bandwidth from a provider that's not the airport. We're not.

I know that there are all sorts of factors, and just cuz the FCC says boo
isn't
the end of the story, but i don't even know what the FCC's position on
this is.
  google gave me many hits, and after looking at 10 or so I decided to
look
elsewhere.

Carl K





--

-Steve

RE: 96.2.0.0/16 Bogons

[Eric Ortega]

I'd like to thank the group for the responses and help with this issue. I
find it ironic that Randy's study actually uses 96 space. 

Thanks again!

Eric

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric
Ortega
Sent: Monday, February 26, 2007 12:17 PM
To: nanog@merit.edu
Cc: 'James Blessing'
Subject: RE: 96.2.0.0/16 Bogons



After I sent that mail I realized that I didn't give enough information.
96.2.0.1 is pingable from the net.

Thank you all for your quick response!

-Original Message-
From: James Blessing [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 26, 2007 11:28 AM
To: Eric Ortega
Cc: nanog@merit.edu
Subject: Re: 96.2.0.0/16 Bogons


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eric Ortega wrote:

> I am a network engineer for Midcontinent Communications We are an ISP
> in the American Midwest. Recently, we were allocated a new network
> assignment: 96.2.0.0/16. We've been having major issues with sites 
> still blocking this network. I normally wouldn't blanket post to the 
> group, but I'm looking to hit as many direct network 
> engineers/operators as possible.  Would it be possible to have people 
> do a quick check on their inbound filters?

Pingable IP address in that network please :)

- --
COO
Entanet International
T: 0870 770 9580
http://www.enta.net/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF4xiRR+KszLBLUT8RAnR/AJ43MzH5PUaTflUsPU95MUp4iuZolQCfcJAZ
Y6j4ipQBBseS/VhdvT8ry6c=
=t+y8
-END PGP SIGNATURE-

RE: FCC on wifi at hotel

[Frank Bulk]

While the hotel cannot prevent you from using Wi-Fi, but they could:
a) restrict you from attaching equipment to their internet connection
(unless you contracted for that and the contract didn't restrict
attachments) or electrical outlets
b) ask you to leave and charge you for trespassing if you didn't

Its highly unlikely those renting facilities from the hotel would agree to
such onerous restrictions and a hotel renting you the facilities is unlikely
going to boot you out.

See:
http://www.wifinetnews.com/archives/007102.html
for some good coverage on the Massport incident.

Frank

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carl
Karsten
Sent: Wednesday, February 28, 2007 2:36 PM
To: nanog@merit.edu
Subject: FCC on wifi at hotel

me again.

So wifi at pycon 07 was 'better than 06' witch I hear was a complete
disaster. 
More on 07's coming soon.

Now we are talking about wifi at pycon 08, which will be at a different
hotel 
(Crown Plaza in Rosemont, IL) and the question came up: Can the hotel
actively 
prevent us from using our own wifi?

_maney: although - wasn't the hotel stuck on "our wifi or no wifi" at last
report?

CarlFK: only the FCC can restrict radio

tpollari: it's their network and their power the FCC has no legal right to
that. 
and no, you show me where they do.  I'm not wasting my day with that tripe
-- 
the caselaw you're likely thinking of has to do with an airline and an
airport 
and the airline's lounge, in which case they're paying for the power and
paying 
for their bandwidth from a provider that's not the airport. We're not.

I know that there are all sorts of factors, and just cuz the FCC says boo
isn't 
the end of the story, but i don't even know what the FCC's position on this
is. 
  google gave me many hits, and after looking at 10 or so I decided to look 
elsewhere.

Carl K

Is there a Hotmail contact around?

[William Schultz]

Could you please contact me off list?

Sorry for the clutter...

-Wil

Re: FCC on wifi at hotel

[Jared Mauch]

On Wed, Feb 28, 2007 at 02:35:43PM -0600, Carl Karsten wrote:
> 
> me again.
> 
> So wifi at pycon 07 was 'better than 06' witch I hear was a complete 
> disaster. More on 07's coming soon.
> 
> Now we are talking about wifi at pycon 08, which will be at a different 
> hotel (Crown Plaza in Rosemont, IL) and the question came up: Can the hotel 
> actively prevent us from using our own wifi?
> 
> _maney: although - wasn't the hotel stuck on "our wifi or no wifi" at last 
> report?
> 
> CarlFK: only the FCC can restrict radio
> 
> tpollari: it's their network and their power the FCC has no legal right to 
> that. and no, you show me where they do.  I'm not wasting my day with that 
> tripe -- the caselaw you're likely thinking of has to do with an airline 
> and an airport and the airline's lounge, in which case they're paying for 
> the power and paying for their bandwidth from a provider that's not the 
> airport. We're not.
> 
> I know that there are all sorts of factors, and just cuz the FCC says boo 
> isn't the end of the story, but i don't even know what the FCC's position 
> on this is. google gave me many hits, and after looking at 10 or so I 
>  decided to look elsewhere.

I suggest you google for massport fcc and continental.

- jared


-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

FCC on wifi at hotel

[Carl Karsten]

me again.

So wifi at pycon 07 was 'better than 06' witch I hear was a complete disaster. 
More on 07's coming soon.


Now we are talking about wifi at pycon 08, which will be at a different hotel 
(Crown Plaza in Rosemont, IL) and the question came up: Can the hotel actively 
prevent us from using our own wifi?


_maney: although - wasn't the hotel stuck on "our wifi or no wifi" at last 
report?

CarlFK: only the FCC can restrict radio

tpollari: it's their network and their power the FCC has no legal right to that. 
and no, you show me where they do.  I'm not wasting my day with that tripe -- 
the caselaw you're likely thinking of has to do with an airline and an airport 
and the airline's lounge, in which case they're paying for the power and paying 
for their bandwidth from a provider that's not the airport. We're not.


I know that there are all sorts of factors, and just cuz the FCC says boo isn't 
the end of the story, but i don't even know what the FCC's position on this is. 
 google gave me many hits, and after looking at 10 or so I decided to look 
elsewhere.


Carl K

Cisco Security Advisory: Cisco Catalyst 6000, 6500 Series and Cisco 7600 Series NAM (Network Analysis Module) Vulnerability

[Cisco Systems Product Security Incident Response Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cisco Security Advisory: Cisco Catalyst 6000, 6500 Series and Cisco
7600 Series NAM (Network Analysis Module) Vulnerability

Advisory ID: cisco-sa-20070228-nam

Revision 1.0

For Public Release 2007 February 28 

- -

Summary
===

Cisco Catalyst 6000, 6500 series and Cisco 7600 series that have a
Network Analysis Module installed are vulnerable to an attack, which
could allow an attacker to gain complete control of the system. Only
Cisco Catalyst systems that have a NAM on them are affected. This
vulnerability affects systems that run Internetwork Operating System
(IOS) or Catalyst Operating System (CatOS).

Cisco has made free software available to address this vulnerability
for affected customers.

This advisory is posted at 
http://www.cisco.com/warp/public/707/cisco-sa-20070228-nam.shtml

Affected Products
=

Vulnerable Products
+--

Catalyst 6000, 6500 series and Cisco 7600 series that have a NAM
installed in them are affected. A system that has a NAM can be
identified by the show module command. A NAM will be seen as
WS-SVC-NAM-1, WS-SVC-NAM-2 or WS-X6380-NAM in this output.

This vulnerability affects systems that run IOS or CatOS.

A sample output for a system that has a NAM-2 on it is provided
below:

Cat6k#show module
Mod Ports Card Type  Model  Serial No.
- --- - -- -- 
---
  12  Catalyst 6000 supervisor 2 (Active)WS-X6K-SUP2-2GESAL06417E23
  3   48  48 port 10/100 mb RJ-45 ethernet   WS-X6248-RJ-45 SAD050108R4
  58  8 port 1000mb ethernet WS-X6408-GBIC  SAD041300CL
  68  Network Analysis ModuleWS-SVC-NAM-2   SAD093002AM


Products Confirmed Not Vulnerable
+

  * Catalyst 6000, 6500 and Cisco 7600 series that do not have a NAM
are not affected.
  * Network Analysis Modules for Cisco Branch Routers (NM-NAM) are
not affected.

No other Cisco products are known to be affected by this
vulnerability.

Details
===

NAMs are deployed in Catalyst 6000, 6500 series and Cisco 7600 series
to monitor and analyze network traffic by using Remote Monitoring
(RMON), RMON2, and other MIBs. More information about NAMs can be
found at the following URL:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_module_configuration_guide_chapter09186a0080394e09.html

NAMs communicate with the Catalyst system by using the Simple Network
Management Protocol (SNMP). By spoofing the SNMP communication
between the Catalyst system and the NAM an attacker may obtain
complete control of the Catalyst system.

Devices running both Cisco IOS and Cisco CatOS are affected by this
vulnerability. This vulnerability is introduced in CatOS at 7.6(15)
and 8.5(1). Older CatOS images are not vulnerable.

This issue is documented in bug IDs CSCsd75273 ( registered customers
only) , CSCse52951 ( registered customers only) for IOS and
CSCse39848 ( registered customers only) for CatOS.

Vulnerability Scoring Details
+

Cisco is providing scores for the vulnerabilities in this advisory
based on the Common Vulnerability Scoring System (CVSS). Cisco will
provide a base and temporal score. Customers can then compute
environmental scores to assist in determining the impact of the
vulnerability in individual networks.

Cisco PSIRT will set the bias in all cases to normal. Customers are
encouraged to apply the bias parameter when determining the
environmental impact of a particular vulnerability.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at 
http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html.

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at 
http://intellishield.cisco.com/security/alertmanager/cvss

CSCsd75273 - Cat6k NAM vulnerability

CVSS Base Score: 10
- - Access Vector: Remote
- - Access Complexity: Low
- - Authentication: Not Required
- - Confidentiality Impact: Complete
- - Integrity Impact: Complete
- - Availability Impact: Complete
- - Impact Bias: Normal

CVSS Temporal Score: 8.3
- - Exploitability: Functional
- - Remediation Level: Official Fix
- - Report Confidence: Confirmed


CSCse52951 - Catk NAM vulnerability, additional protection

CVSS Base Score: 10
- - Access Vector: Remote
- - Access Complexity: Low
- - Authentication: Not Required
- - Confidentiality Impact: Complete
- - Integrity Impact: Complete
- - Availability Impact: Complete
- - Impact Bias: Normal

CVSS Temporal Score: 8.3
- - Exploitability: Functional
- - Remediation Level: Official Fix
- - Report Confidence: Confirmed

Cisco Security Advisory: Cisco Catalyst 6000, 6500 and Cisco 7600 Series MPLS Packet Vulnerability

[Cisco Systems Product Security Incident Response Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cisco Security Advisory: Cisco Catalyst 6000, 6500 and Cisco 7600
Series MPLS Packet Vulnerability

Advisory ID: cisco-sa-20070228-mpls

Revision 1.0

For Public Release 2007 February 28 

- -

Summary
===

Cisco Catalyst 6500 series systems that are running certain versions
of Cisco Internetwork Operating System (IOS) are vulnerable to an
attack from a Multi Protocol Label Switching (MPLS) packet. Only the
systems that are running in Hybrid Mode (Catalyst OS (CatOS) software
on the Supervisor Engine and IOS Software on the Multilayer Switch
Feature Card (MSFC)) or running with Cisco IOS Software Modularity
are affected.

MPLS packets can only be sent from the local network segment.

This advisory is posted at 
http://www.cisco.com/warp/public/707/cisco-sa-20070228-mpls.shtml

Affected Products
=

Vulnerable Products
+--

The following products are affected by this vulnerability:

  * Cisco Catalyst 6500 systems that run 12.2(18)SXF4 with Cisco IOS
Software Modularity are affected.

Images that support Cisco IOS Software Modularity have a "-vz"
suffix in their image name.

The following is a conclusive list of all image names that are
running with Cisco IOS Software Modularity and are affected by
this vulnerability.

  + s72033-adventerprisek9_wan-vz.122-18.SXF4.bin
  + s72033-advipservicesk9_wan-vz.122-18.SXF4.bin
  + s72033-entservicesk9_wan-vz.122-18.SXF4.bin
  + s72033-ipservices_wan-vz.122-18.SXF4.bin
  + s72033-ipservicesk9_wan-vz.122-18.SXF4.bin
  + s72033-ipservicesk9-vz.122-18.SXF4.bin

  * Cisco Catalyst 6000, 6500 and Cisco 7600 series systems with an
MSFC2 or MSFC3 that run in Hybrid Mode are affected.

In Hybrid Mode, Catalyst OS (CatOS) software runs on the
Supervisor Engine and IOS runs on the MSFC. It is different from
the Native Mode in which IOS runs both on the Supervisor Engine
and MSFC.

This vulnerability affects MSFC2, MSFC2a and MSFC3 that run
certain images in Hybrid mode.

In Hybrid Mode, IOS images that run on MSFC start with "c6msfc2",
"c6msfc2a" or "c6msfc3". Several image names that run on MSFC in
hybrid mode are provided below for reference:

  + c6msfc2a-adventerprisek9_wan-mz.122-18.SXF
  + c6msfc3-jsv-mz.122-14.SX2

Products Confirmed Not Vulnerable
+

  * Systems that are running in Native Mode without Cisco IOS
Software Modularity are not affected.
  * Systems without an MSFC2, MSFC2a or MSFC3 are not affected.

No other Cisco products are known to be affected by this
vulnerability.

Details
===

Cisco IOS Software Modularity combines subsystems into individual
processes and enhances the Cisco IOS Software memory architecture to
provide process-level fault isolation and subsystem "In Service
Software Upgrade" (ISSU) capability. These enhancements are delivered
in Cisco IOS Software for the Catalyst 6500 Series Supervisor Engine
720 and Supervisor Engine 32. Cisco IOS Software Modularity was first
delivered as an option in a Cisco IOS Software Release 12.2(18)SXF4.
More information on Modular IOS can be found at the following URL:

http://www.cisco.com/en/US/products/hw/switches/ps708/prod_bulletin0900aecd80313e15.html

Not all 12.2(18)SXF4 images support Modular IOS. Only the images with
a "-vz" in the image name support Modular IOS and are affected by
this vulnerability. A conclusive list of all affected image names
that support Cisco IOS Software Modularity is provided in the
Affected Products section.

In Hybrid Mode, a CatOS image is used as the system software to run
the Supervisor Engine on the Catalyst systems. If an MSFC is
installed, a separate IOS Software image is used in order to run the
MSFC. CatOS provides the Layer 2 (L2) switching functionality. The
Cisco IOS on the MSFC provides the Layer 3 (L3) routing
functionality. It differs from the Native Mode, in which a single
Cisco IOS Software image is used as the system software to run both
the Supervisor Engine and MSFC on the Catalyst systems. IOS software
that runs on MSFC in Hybrid Mode is also affected by this
vulnerability. More information about the differences between Hybrid
and Native Modes can be found at the following URL:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c8441.shtml

MPLS packets received by a Route Processor (MSFC) Layer 3 interface
can potentially trigger this vulnerability. The system in question
does not need to be configured for MPLS to be vulnerable. MPLS
packets can only be sent from the local network segment, limiting the
scope of the exploitation.

This issue is documented in bug IDs CSCsd37415 ( registered customers
only) and CSCef90002 ( registered customers only) .

Vulnerability Scoring Deta

Re: 165 Halsey Newark 3rd Floor *explosion* ?

[chip]

On 2/28/07, jim bartus <[EMAIL PROTECTED]> wrote:


I had a sonet link through there drop from 7:56 to 8:07 this morning.
Haven't gotten ahold of my SE yet to hear the story.

-jim

On 2/28/07, Eric Kagan <[EMAIL PROTECTED]> wrote:
>
>  We lost a bunch of MCI circuits at 8am EST this morning and the colo
> provider informed us there was some kind of explosion on the 3rd floor.
> Anyone have additional info or details ?  Not sure how serious - our power
> is still on and our XO and ATT circuits are still up as well as bandwidth.
>
> Thanks
> Eric
>
> Eric Kagan
>
>
>




Word is there was a battery leaking acid, fire dept was called, and building
was evacuated.  From what I hear no loss of service however.  I'm not
on-site but this is what I'm hearing.

--chip

--
Just my $.02, your mileage may vary,  batteries not included, etc

Re: 165 Halsey Newark 3rd Floor *explosion* ?

[jim bartus]

I had a sonet link through there drop from 7:56 to 8:07 this morning.
Haven't gotten ahold of my SE yet to hear the story.

-jim

On 2/28/07, Eric Kagan <[EMAIL PROTECTED]> wrote:


 We lost a bunch of MCI circuits at 8am EST this morning and the colo
provider informed us there was some kind of explosion on the 3rd floor.
Anyone have additional info or details ?  Not sure how serious - our power
is still on and our XO and ATT circuits are still up as well as bandwidth.

Thanks
Eric

Eric Kagan

165 Halsey Newark 3rd Floor *explosion* ?

[Eric Kagan]

We lost a bunch of MCI circuits at 8am EST this morning and the colo
provider informed us there was some kind of explosion on the 3rd floor.
Anyone have additional info or details ?  Not sure how serious - our power
is still on and our XO and ATT circuits are still up as well as bandwidth.  
 
Thanks
Eric
 
Eric Kagan
 
 

Re: Counting tells you if you are making progress

[Rich Kulawiec]

On Wed, Feb 21, 2007 at 12:31:30AM -0500, Sean Donelan wrote:
> Counting IP addresses tends to greatly overestimate and underestimate
> the problem of compromised machines.
> 
> It tends to overestimate the problem in networks with large dynamic
> pools of IP addresses as a few compromised machines re-appear across
> multiple IP addresses.  It tends to underestimate the problem in
> networks with small NAT pools with multiple machines sharing a few IP
> addresses. Differences between networks may reflect different address
> pool management algorithms rather than different infection rates.

Yes, but (I think) we already knew that.  If the goal is to provide
a minimum estimate, then we can ignore everything that might cause
an underestimate (such as NAT).  In order to avoid an overestimate,
multiple techniques can be used.  For example, observation from multiple
points over a period of time much shorter than the average IP address
lease time for dynamic pools, use of rDNS to identify static pools,
use of rDNS to identify separate dynamic pools (e.g., a system which
appears today inside hsd1.oh.comcast.net is highly unlike to show up
tomorrow inside hsd1.nj.comcast.net), classification by OS type (which,
BTW, is one way to detect multiple systems behind NAT), and so on.

I think Gadi makes a good point: in one sense, the number doesn't really
matter, because sufficiently clueful attackers can already lay their
hands on enough to mount attacks worth paying attention to.

On the other hand, I still think that it might be worth knowing, because
I think "the fix" (or probably more accurately "fixes") (and this is
optimistically assuming such exist) may well be very different if we
have 50M than if we have 300M on our hands.

---Rsk