cable.html

Latest Posts

Details: Written by: khalil shreateh; Category: Vulnerabilities; Hits: 5

cable.html

<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta cable.html

<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>802</title>
<meta name="Microsoft Theme" content="safari 010">
</head>

<body background bgcolor="#000000" text="#CCCCCC" link="#CC9933" vlink="#999966" alink="#FFCC33">


<h1 align="center">802.14
and DOCSIS Standard Information:</h1>

 
General DOCSIS Standard
Historical Related Information:
 
   
DOCSIS 1.0 was proposed in March of 1997 by MCNA. The demonstration of the first
DOCSIS compliant equipment was in December of 1997. In March of 1998 the ITU
(International Telecommunications Union) accepted DOCSIS as a Cable Modem
Standard (J.112). To deliver DOCSIS over CAT (Cable Television Network), one
6MHz RF channel in the  50-750MHz spectrum range is typically allocated for
downstream traffic to homes and another channel in the 5-42MHz band is used to
carry upstream signals. 
 
    A
head-end CMTS (Cable Modem Termination System) communicates through these
channels (6MHz RF in 50-750Mhz spectrum for downstream and another 6MHz channel
in the 5-42MHz band for upstream signals. Cable modems were described as
external devices that connect to a personal computer through a standard 10Base-T
(10Mbps Ethernet over CAT3-5 cabling) Ethernet card or USB interface, although
internal PCI modem cards were being developed. 
    
   
CableLabs manages a certification process to ensure DOCSIS cable modems
manufactured by different vendors comply with the standard and are
interoperable. Those products that pass the tests earn the right to affix a seal
marked "CableLabs Certified" to their DOCSIS cable modem packaging,
informing buyers that the product is guaranteed to interoperate with other
certified products. 
    
    In
April 1999 CableLabs issued a second-generation specification called DOCSIS 1.1
which adds key enhancements to the original standard, such as improved QoS
(Quality of Service) and hardware-based packet-fragmentation capabilities, to
support IP Telephony and other constant-bit-rate services. DOCSIS 1.1 provides
bandwidth and latency guarantees required to offer toll-quality voice, dedicated
business-class data services and multimedia applications across a shared cable
modem access network. The next-generation standard is designed to be backward
compatible, enabling DOCSIS 1.0 and 1.1 modems to operate in the same spectrum
on the same network. 
   
    
In addition to DOCSIS 1.1, CableLabs is eyeing a third-generation DOCSIS
standard which would add an advanced PHY (Physical Layer) to the core
specification to increase the upstream transmission capacity and reliability.
The plan is to use FA-TDMA (Frequency-agile Time Division Multiple Access)
technology advocated by Broadcom and S-CDMA (Synchronous Code Division Multiple
Access). 
 
DOCSIS 1.1 Specification
In-Depth Information:
 
    The
intended service will allow transparent bi-directional transfer of IP (Internet
Protocol) traffic, between the cable system head-end and customer locations,
over an all-coaxial or HFC (hybrid fiber/coax) cable television network. 
 
<img border="0" src="DOCSIS1.gif" width="766" height="200"> 
 
    The
transmission path over the cable system is realized at the head-end by a CMTS
(Cable Modem Termination System), and at each customer location by a CM (Cable
Modem). At the head-end (or hub), the interface to the data-over-cable system is
called the CMTS-NSI (Cable Modem Termination System - Network-Side Interface) At
the customer locations, the interface is called the CMCI (Cable Modem to
customer premise equipment interface) and is specified in MCNS4. The intent is
for the MCNS operators to transparently transfer IP (Internet Protocol) traffic
between these interfaces, including but not limited to datagrams, DHCP, ICMP,
and IP Group Addressing (broadcast and multicast). 
 
<img border="0" src="Service_Distribution.jpg" width="991" height="646">
 
    Since
data privacy is Baseline Privacy's principal service goal, and given neither CM
nor CMTS authentication are prerequisite for providing user data privacy. Baseline
Privacy's key distribution protocol does not authenticate CM and CMTS (IE It
does not employ authentication mechanisms such as passwords or digital
signatures). In the absence of authentication, Baseline Privacy provides basic
protection of service by insuring that a modem, uniquely identified by its
48-bit IEEE MAC Address, can only obtain keying material for services it is
authorized to access. Since it does not authenticate Cable Modems, it cannot
protect against an attacker employing a cloned modem, masquerading as an
authorized modem. 
 
   
Baseline Privacy security services are defined as a set of extended services
within the MCNS MAC (Media Access Control) sublayer. Packet header information
specific to Baseline Privacy is located in a Privacy Extended Header element in
the MAC Extended Header, as defined in MSNS1. Two new MAC management message
types, BPKM-REQ and BPKM-RSP, have been defined to support the Baseline Privacy
Key Management (BPKM) protocol. Baseline Privacy uses the CBC (Cipher Block
Chaining) mode of the DES (US Data Encryption Standard) algorithm to encrypt the
Packet PDU field both upstream and downstream RF MAC Packet Data PDUs. The MCNS
MAC headers of these Packet Data PDUs MUST NOT be encrypted. The Payloads, as
well as headers, of MAC management messages MUST be sent in the clear to
facilitate registration, ranging, and normal operation of the MAC
sublayer. 
    
   
Baseline Privacy extends the definition of the MAC sublayer's SID (Service ID).
The MCNS MCNS1 (Radio Frequency Interface Specification) defines a SID as a
mapping between the Cable Modem and Cable Modem Termination System for the
purposed of upstream bandwidth allocation and class-of-service management. In
this context, the SID only has upstream significance. When Baseline Privacy is
in operation, the SID also identifies a particular security association and,
thus, has both upstream and downstream significance. A Downstream multicast
traffic flow, then, which normally would have no SID associated with it, will
have an associated SID when Baseline Privacy is operational. The Privacy
Extended Header Element includes the SID associated with the MAC Packet Data
PDU; the SID, in combination with other components of the extended header
element, identifies to a modem the keying material required to decrypt the MAC
PDU's Packet Data field.  
 
   
Baseline Privacy's key management protocol runs between the CM (Cable Modem) and
CMTS (Cable Modem Termination System); CM's (Cable Modem's) use the protocol to
obtain authorization and traffic keying material (pertaining to a particular
SID) from the CMTS (Cable Modem Termination System), and to support periodic
reauthorization and key refresh. The key management protocol uses RSA [RSA,
RSA1], a public-key encryption algorithm, and the ECB (electronic Codebook) mode
of DES [FIPS-81] to secure key exchanges between the CM (Cable Modem) and the
CMTS (Cable Modem Termination System). CM's (Cable Modem's) MUST have
factory-installed RSA Private/public key pairs, or provide an internal algorithm
to generate such key pairs dynamically. If a Cable Modem relies on an internal algorithm
to generate its private/public key pair, the Cable Modem MUST generate the key
pair prior to its first Baseline Privacy Establishment. Internal key pair
generation MUST be a one-time-only operation; once a key pair is generated, it
MUST be retained for the operational life of the Cable Modem. 
 
    A
SID's keying material (DES key and CBC Initialization Vector) has a limited
lifetime. When the CMTS (Cable Modem Termination System) delivers SID keying
material to a CM (Cable Modem), it also provides the CM (Cable Modem) with that
material's remaining lifetime. IT is the responsibility of the CM (Cable Modem)
to request new keying material from the CMTS (Cable Modem Termination System)
before the set of keying material the CM (Cable Modem) currently has expired at
the CMTS (Cable modem Termination System. 
 
 
Cable Modem
Initialization Information as described in the DOCSIS 1.1 Standard:
 
   
(1)     Scan for downstream channel and establich
synchronization with the CMTS (Cable Modem Termination System)
   
(2)     Obtain Transmit parameters
   
(3)     Perform Ranging 
   
(4)     Establish IP (Internet Protocol) connectivity
through DHCP (Dynamic Host Configuration Protocol)
   
(5)     Establish Time of Day
   
(6)     Transfer operational parameters (download parameter
file via TFTP)
   
(7)     CMTS (Cable Modem Termination System)
Registration 
 
Baseline Privacy
Establishment follows CMTS (Cable Modem Termination System) Registration:
 
    If a
CM (Cable Modem) is to run Baseline privacy, its parameter file, downloaded
during the transfer of operational parameters, MUST include Baseline Privacy
Configuration Settings. Upon completing the CMTS registration, the CMTS will
have assigned SIDs (Service IDs) to the registering Cable modem that match the
Cable Modem's class-of-service provisioning. If a Cable Modem is configured to
run Baseline Privacy, the CMTS (Cable Modem Termination System) registration is
immediately followed by initialization of the Cable Modem's Baseline Privacy
security functions. 
 
   
Baseline Privacy initialization begins with the Cable modem Sending the CMTS an
authorization request, containing data identifying the Cable Modem (EG MAC
Address), the Cable Modem's RSA Public Key, and a list of zero or more assigned
unicast SIDs that have been configured to run Baseline Privacy. If the CMTS
determines the requesting Cable Modem is authorized for these services, the CMTS
responds with an authorization reply containing a list of SIDs (both unicast and
multicast) that the Cable Modem is permitted to run Baseline Privacy on. The
reply also includes an authorization key from which the Cable Modem and CMTS
derive the keys needed to secure a Cable Modem's subsequent requests for per-SID
traffic encryption keys, and the CMTS's responses to these requests. The authorization
key is encrypted with the receiving cable modem's public key. 
    
    After
successfully completing the authorization with the CMTS, the cable modem sends
key requests to the CMTS, requesting traffic encryption keys to use with each of
its Baseline Privacy SIDs. A Cable modem's traffic key requests are
authenticated using a keyed hash (the HMAC algorithm [RFC2104]); the message
authentication key is derived from the authorization key obtained during the
earlier authorization exchange. The CMTS responds with key replies, containing
the traffic encryption keys; the keys are DES encrypted with a key encryption
key derived from the authorization key. Like the Key Requests, Key Replies are
authenticated with a keyed has, where the message authentication key is derived
from the authorization key. 
 
Cable Modem Key Update
Mechanism:
 
    The
traffic encryption keys which the CMTS provides to client Cable Modem's have
limited lifetime. The CMTS delivers a key's remaining lifetime, along with the
key value, in the key replies it sends to its client Cable Modem's. It is the
responsibility of individual cable modems to insure the keys they are suing
match those the CMTS is using. Cable Modems do this by tracking when a
particular SID's key is scheduled to expire and issuing a new key request for
the latest key prior to that expiration time. In addition, Cable Modems are
required to periodically reauthorized with the CMTS; as is the case with traffic
encryption keys, an authorization key has a finite lifetime which the CMTS
provides the Cable Modem along with the key value. It is the responsibility of
individual cable modems to reauthorize and obtain a new authorization key and a
current list of supported SIDs before the CMTS expires their current
authorization key. Baseline Privacy initialization and key update is implemented
within the Baseline Privacy Key Management  protocol, defined in detail in
Section 4. 
 
 
 
MCNS Variable-length
Packet Data PDU with Privacy Extended Header element and Encrypted Packet PDU
Payload:
 
    The
following picture depicts the format of an MCNS variable-length Packet Data PDU
with a Privacy EH (Extended Header) element and encrypted Packet PDU payload.
The first 12 octets of the Packet PDU, containing the Ethernet/802.3 destination
and source addresses, are not encrypted. Transmitting a frame's destination and
source addressing in the clear provides vendors with greater flexibility in how
they integrate encryption/decryption with MAC functionality; EG vendors have
freedom to choose between filtering on DA/SA or SID first. The Packet PDU's
Ethernet/IEEE 802.3 CRC is encrypted. 
 
<img border="0" src="encrypted.jpg" width="676" height="433">
 
    
 
Links:
List of <a href="http://www.cabledatacomnews.com/cmic/docsiscm.html">DOCSIS
Cable Modem Vendors</a> 
 


</body>

</html>

Social Media Share

Get Rid of Ads!

Latest Posts