|
On-The-Fly TFTP Server Specification
A design for building cable modem configuration files dynamically
on demand
By: Bruce Bahlmann - Contributing Author (your
feedback
is important to us!)
Created: December 8, 1997
Note: For help designing your provisioning system or developing tools to help test, automate, and deploy your system contact Birds-Eye.Net.
Abstract:
The use of TFTP with a large number of unique or shared boot files have administrative
limitations. Since a majority of boot file parameters are common among clients on the same
network only a few parameters are actually unique to a client. If these unique parameters
were readily available at the time of the TFTP request, the boot file could be built
on-the-fly (preferably in memory) bypassing problems of scaling local storage, updates,
and redundancy for configuration files needed to support large numbers of subnets (greater
than 50). A modified TFTP server seems to be the logical place to integrate the
functionality of customized boot file creation with file transfer to qualified/authorized
clients and fix the anticipated TFTP scaling problems.
Introduction:
"Classic" BOOTP w/ Unique Configuration Files
The use of TFTP and boot files began with "classic" or traditional BOOTP. In
"classic" BOOTP each client requires both a static IP address and a unique
configuration (boot) file. Classic BOOTP accomplishes this by mapping each client (by mac
address) to an IP address and directs them (through standard BOOTP/DHCP parameters) to a
TFTP server for downloading of their unique configuration file. The mapping of mac
addresses to IP addresses takes place in a standard file called a bootptab and all the
unique configuration files are placed in the directory structure of the TFTP server
(usually TFTP home directory).
Dynamic BOOTP w/ Shared Configuration Files
Dynamic BOOTP differs from "classic" BOOTP in that rather than mapping
specific clients (mac addresses) to a static IP address, each client receives a dynamic IP
address from a pool of available addresses configured on the BOOTP server (based on which
relay agent [gateway] forwarded the request to the BOOTP server). Dynamic addressing is
actually a feature of DHCP servers that is made available to BOOTP clients. There are two
important features in dynamic BOOTP that enable clients to roam the network (move from
network to network) but never consume more that one IP address.
- Auto release old lease
- Separate parameters for home directory and boot file for each subnet (or scope)
The auto-release feature automatically deletes previous lease(s) held by a client when
the client changes its network. This prevents a single client from consuming more than one
IP address and also speeds troubleshooting a client’s IP address. Although dynamic IP
addressing has obvious benefits for clients, it presents some technical challenges for
providing shared (pseudo-dynamic) configuration files. Configuration files contain network
specific information preventing a client’s use of this file on any network other than
which it was created. However, an analysis of the configuration files used in
"classic" BOOTP for a specific network revealed that all clients in the same
service class had identical configuration files. Therefore, clients on the same network
with the same service class could share the same configuration file. Separate BOOTP server
parameters for home directory and boot file combined with a standard naming convention for
configuration files and a directory structure unique for each network would enable
pseudo-dynamic operation for clients requiring both IP and configuration file (see Figure
1.0).
Figure 1.0 Shared TFTP file structure
Since all the client types (MD5 files) are named similarly across networks, a client
can request a particular configuration anywhere on the network and the file it receives
WILL be appropriate for that network. More importantly, network and headend configuration
information do not need to be included in the client definition because they are encoded
into the home directory field configured on the BOOTP server when that network was
initially set up. Associating a client (cable modem mac address) with a client class
enables the name of the bootfile defined for that client class be used for the bootfile
name during all transactions with that client. Since this bootfile name is appended to the
home directory filed (defined in the bootp networks) the BOOTP server will deliver TFTP
directory path to the very file the client should be requesting. Although this process
works very well in production (once a system was created to build and maintain the
directory structure), a problem occurs when a change to existing bootfiles or additional
bootfiles must be created limiting its ability to scale with the business.
Limitations of Shared Configuration Files
Shared configuration files are organized by directories (below TFTP home) and are
associated with each network. Within each directory are a number of configuration files
(one for each type of client or class of service). The unique directory and shared files
are created at the time the network is brought on-line using the boot file creation
capabilities available at that time. Upon closer examination into the scalability of using
shared files for large numbers of networks, the following problems are not addressed with
this implementation:
- Local storage for configuration files
As the number of networks, client types (or service classes), and features desired in
the configuration file increase, the amount of storage required to sustain the shared
configuration file model will increase beyond the capacity of a standard server. For
example the use of unique and shared models for 50 customer networks with 10 client types
consisting of an average of 1Kb configuration files would require the following hard drive
space:
unique model: 50 (nets) x 460 (cust) x 1000 (BOOT) = 23 gig
shared model: 50 (nets) x 10 (types) x 1000 (BOOT) = 500 meg
While the shared model significantly reduces the space needed, any changes to the size
of the boot file or the number of supported client types has a dramatic effect on the
space needed to support these files. Currently the only way to address this problem is to
acquire more hardware (more disk drive space).
- Retooling creation code to take advantage of new features
With each new release of features for clients, comes changes to the configuration file.
The code that creates boot files will need to be retooled to enable these features. This
will become increasingly complex and consume unnecessary resources.
- Interoperation with DOCSIS modems when available
With the DOCSIS modems comes even more requirements on the shared file model. DOCSIS
modems require a somewhat different MD5 file that is not compatible with existing (now
legacy) rev 3 Bay cable modems. Although DOCSIS modems would work on a separate frequency
pair (to enable it to be deployed along-side existing modems) from the legacy cable modems
it would mean that that a additional group of files (one for each service class) would
need to be created to support this new equipment.
- Security of shared file model is suspect, needs to protect against theft of service
Since the shared model uses standard TFTP the file download is not controlled. Anyone
knowing the correct filepath and TFTP server IP address (not that simple but it can be
done) can download a valid file for their network, serve their cable modem this file via
their own BOOTP and TFTP server and effectively steal higher quality service. If security
were beefed-up on the BOOTP response and TFTP request process to impose some privately
held data we could ensure the file requested is actually authorized (linked to the service
level the customer is paying for).
- Employ a some kind of "unique transaction id" to avoid spoofing TFTP server
into handing out configuration files to unauthorized hosts.
- Reacting to changes in the boot creation procedure (i.e. additional functionality)
In the shared configuration file model, with each new update in the creation procedure,
additional service class added, or new filter option implemented the existing
configuration files would have to be updated. This update process would demand an
increasing amount of administrative time before TFTP requests would be able to utilize new
features and functionality.
- Distributing TFTP services
Since the management of unique or shared configuration files is best centralized, this
implementation would not lend it self to distributed architecture (all files are created
at one location). A preferred implementation of TFTP would be to distribute this service
to satellite locations (i.e. headends) and provide backup (redundant) service in the data
center. However, TFTP is currently not highly available and ends up being a single point
of failure. In the event of a catastrophic network/regional power failure a single TFTP
server would serialize the recovery effort. To make TFTP highly available, some mechanism
must be in place to continually direct TFTP requests to a working server with up-to-date
configuration files. A couple ways to do this might be:
- Write a application monitor that polls satellite TFTP servers to see if they are
reachable (TFTP port). If the satellite server is on-line, BOOTP/DHCP responses direct
TFTP requests to the satellite server. In the event the satellite server goes down, the
monitor updates the BOOTP/DHCP networks (scope) that contain this parameter (satellite
server’s address) with another server that is available. Similarly, this same monitor
could be used to redirect the DNS servers a client uses. However, the DHCP server must be
able to update clients constantly (every minute or so) – renewal and release times
could be used to make this possible.
- Investigate if the router could take a rejected TFTP request (host not reachable) and
redirect it to a working IP address. This method would work seamless with TFTP and not
require any modifications to BOOTP/DHCP configurations.
Both ways of making TFTP redundant require synchronization of configuration files (if
using shared or unique model). This synchronization would require that not one but two or
more machines to maintain up-to-date copies of configuration files.
The limitations of using "real" configuration files whether they are unique
or shared presents insurmountable challenges to scaling the use of this implementation
beyond 50 customer networks. The use of some non-file related mechanism (on-the-fly) to
answer TFTP requests is a necessity to scale beyond 50 customer networks.
On-The Fly Creation:
The unique parameters must be readily available at the time of the TFTP request to
build the boot file on-the-fly and respond to the requesting client before it times out.
Performing database lookups triggered by TFTP requests could potentially be fast enough to
obtain the necessary information, build the boot file, and respond before the client timed
out. However, the lookups could be avoided if these same parameters were encoded into the
BOOTP response and presented to the TFTP server when the client requests a file. Utilizing
the filename path in the BOOTP response as a way of encoding unique boot parameters would
make them available at the time of the TFTP request (because they are part of the request
– enabling on-the-fly boot file building) and eliminates the need to organize and
store boot files
A feature common in BOOTP/DHCP servers enables filenames and path names to be defined
independently. The path name in the BOOTP/DHCP response would be determined by the network
(scope) associated with a particular relay agent (gateway) and the filename is determined
by either client (mac address) association or by a default parameter (to be used for
self-activation).
Since networks contain groups of like clients that have similar characteristics
(network, gateway, subnet mask, etc.) these parameters could be encoded into the path name
used in the BOOTP/DHCP response to provide TFTP with network specific information about
the requesting client. These parameters, combined with the boot file name would provide
all the necessary information to build a customized boot file for each client.
Note the need for customized configuration files falls into one of three categories
(shared, unique, unrelated). Shared represents an configuration that can represent a group
of similar clients signed up for the same service class. This would normally represent
about 80% of our customers since our service is residentially focused and most of these
customers only have a single computer. Unique represents those customers that do not fall
into one of the MSO’s neat shared service classes. They would need to contain
something that is unique among all other cable modem configuration files (perhaps packed
mac addresses). This category accounts for most of the remaining 20% (perhaps 15 –
18%) leaving the last for the unrelated configuration file needs. Unrelated requirements
may range from other cable modem vendor’s dependencies to non-cable modem needs (like
router TFTP files).
Structure of BOOTP Response (TFTP Request)
Since many types of devices use TFTP in conjunction with either BOOTP or DHCP the form
of the response should account for different vendor needs for creating different boot
files while not taking away from conventional use of TFTP services. The other approach may
be to not support conventional TFTP services and only support on-the-fly TFTP based on
security problems with conventional TFTP. Regardless of the support for conventional TFTP,
on-the-fly functionality should contain the following parameters:
Path = /special char/ <passed network specific parameters >
- special charAn unique character that triggers on-the-fly feature (else use normal TFTP).
- parametersSpecifies the network/scope based parameters passed to a client ("/"
delimited)
Filename = /vendor id/device type/file type/<passed client specific parameters>
- vendor id Specifies the vender whos product is intended for this file
- device typeSpecifies the type of device requesting a file
- bootfile typeSpecifies the type of boot file to be created (txt, md5)
- parametersSpecifies service used by customer ("/" delimited)
Any service description that requires more than 255 characters to explain must utilize
an LDAP query to obtain the needed information for the TFTP server to create the requested
boot file. The service class "ldap" tells the TFTP server when to retrieve the
needed information externally. The absence of the ldap service class tells the TFTP server
that it has all the parameters it needs to build the boot file. An example of how these
parameters would be defined for use with a cable modem and a router is as follows:
Cable Modem: (using BayNetworks LCp)
path = /%/gw=24.128.24.1/sm=23/rx=26.75/tx=541/ld=512
where % instructs TFTP to build the file on-the-fly
24.128.24.1 is a gateway
23 is the subnet mask of the network (in bits)
26.75 is the transmit frequency of the modem
541 is the receive frequency of the modem
512 is the loop delay of the modem
filename = /ven=bayn/dt=cm/et=md5/sc=res01/fo=secure/nc=2
where bayn specifies where in the tftp.conf file represents this manufacturer
(BayNetworks)
cm represents which bay networks product is requesting
md5 represents the type of output file requested
res01 represents the a customer’s class of service
secure is the filtering option selected by the customer
2 represents the number of connections desired at the customer site
BOOTP Router: (using Cisco 2500 series)
path = /%/gw=24.128.24.1/sm=23/rx=26.75/tx=541/512
where % instructs TFTP to build the file on-the-fly
23 is the subnet mask of the network (in bits)
filename = /ven=cisc/ct=rr/et=txt/ho=co.xyz/cnw=24.128.7.65/csm=28
where cisc specifies where in the tftp.conf file represents this manufacturer (Cisco)
rr represents the type of client this is (residential router)
txt represents the type of output file requested
co.xyz represents the router’s hostname
24.128.7.65 is the network address of the customer side subnet
28 is the subnet mask of the customer side subnet
Future LDAP Requirements
Limiting customers access based on the sheer number of connections they require fails
in a small business or power user environment. These users have a number of network
devices (computers, printers, etc) of which they want pay for only a subset of them to
access Internet service through the cable modem. The only way to prevent unwanted devices
from accessing the network or being accidentally learned by the cable modem’s
bridging table (when the modem periodically recycles) is to prestuff or preload these
device’s mac addresses into the configuration file of the modem. Since a cable modem
has the capacity to stuff the mac addresses of up to 16 devices into its configuration
file this amount of information cannot be encoded into the TFTP request (because
16x12=192+ characters for these mac addresses along with the path and file name would
exceed the 255 character limit of the TFTP request).
To provide a working product suitable for this business need first an LDAP schema would
need to be designed to accommodate this data. While the structure of such a schema is left
undeveloped the suggested fields required to support this functionality include:
| Field |
Example Data |
| customer id |
xxxxxxxxxx |
| vendor type |
bayn |
| device type |
cm |
| format |
md5 |
| service class |
res01 |
| filtering setting |
secure |
| use LDAP |
y |
| number of nodes |
2 |
| device mac addresses |
xxxxxxxxxx, xxxxxxxxxx |
When this information is entered (during sign-up or customer modification) this
information would need to be communicated to the provisioning server to update the cable
modem’s service class information (associate the cable modem with a new/different
service class). This information would enable a new or re-booted modem to obtain a
configuration file that corresponds to the above parameters. There may also be a need to
update a working cable modem’s configuration (without forcing the cable modem to
reset/re-boot) using SNMP set commands.
Structure of On-The-Fly TFTP configuration file
Along with the structure of the TFTP responses described above a configuration file
(tftp.conf) is needed to define names used in the path and filename parameters, define the
order (placement) of parameters in the BOOTP/DHCP response, define the any default values
used in the boot file, and define the order (or process) of assembling the elements of the
boot file.
The configuration file represents all the vendors that support the build on-the-fly
model and is divided into sections by vendor. Since this file is user configurable, the
syntax is pretty critical.
File tftp.conf:
# On the fly TFTP config file
# define path variable as it relates to TFTP requests
#Note that <client_ip>, <nsubnet_mask>, and <csubnet_mask> represents
variables used in the config file that
#are calculated externally.
#Path name has the structure of: /special char/ <passed network specific parameters
>
define ldap
#variable value
ldap_server_ip x.x.x.x
ldap_port x
base_dn c=US, o=MSO
bind_user jondoe
bind_pw passwd
define path
#variable position
spec_char 1
client_gateway 2
nsubnet_bits 3
xmit_freq 4
xrcv_freq 5
loop_delay 6
#define filename
#file name has the structure of: /vendor id/device type/bootfile type/<passed client
specific parameters>
define filename
vendor_id 1
device_type 2
bootfile_type 3
#define client types
# BAY NETWORKS
client bayn
device_type cm
service_class 4 # position in filename of service class setting
filtering_level 5 # position in filename of filtering selected for customer
max_nodes 6 # position in filename of a number indicating the how many customer devices
to allow
define defaultkey
md5_key 123456789012345678911234567892…
decipher service_class
#service variables……
#name dbw ubw ap bt hn
res01 1500 300 3 1 No
res02 1500 1500 3 2 No
hn 10000 10000 1 4 Yes
ldap - - - - -
decipher filtering_level (similar to the above – need more details)
#additional default configuration file parameters defined
join_network Yes
SNMP_RO No
Max_CDMs 512
Min_conten 15
Read_comm MSO
Write_comm Express
Manager_IP (0.0.0.0 x5) or none
Manager_eth (00:00:00:00:00:00 x5)or none
Client_eth (00:00:00:00:00:00 x16)or none
Client_IP (0.0.0.0 x16) or none
Encryption Off
Off_Net_gw No
Key_server 0.0.0.0
Encry_nets (0.0.0.0 x10) or none
sw_revision 0
TFTP_IP 0.0.0.0
define buildorder
xmit_freq, xrcv_freq, … (etc.) …
# CISCO SYSTEMS
client cisc
device_type rr
hostname 4
client_gw 5
csubnet_bits 6
#Define contents of bootfile
!
version 11.1
service password-encryption
service udp-small-servers
service tcp-small-servers
!
hostname <hostname>
enable secret 5 $#@%
enable password 7 0201001
!
!
interface Ethernet0
ip address <client_ip> <nsubnet_mask>
ip rip send version 2
!
interface Ethernet1
ip address <client_gw> <csubnet_mask>
!
interface Serial0
no ip address
shutdown
!
interface Serial1
no ip address
shutdown
!
router rip
version 2
network 24.0.0.0
no auto-summary
!
ip classless
ip route 0.0.0.0 0.0.0.0 Ethernet0
!
snmp-server community xxxx R0
!
line con 0
line aux 0
line vty 0 4
password 7 0438290
login
!
Sequence of Events Using On-The-Fly TFTP Server
The following sequence of events describe how the various components of the
provisioning system might be joined with the using of an On-The-Fly TFTP server.
Preliminary steps (before using application)
1. BOOTP server networks (scopes) are modified such that the RF/network parameters
are encoded into each network’s path information. These parameters position (in terms
of their order in the path variable must be consistent and noted for editing the TFTP
server’s configuration file).
- path = /%/24.128.24.1/23/26.75/541/512
2. BOOTP server client classes are created based on a list of products developed by
marketing. The actual configuration meanings of these products is noted for later use in
the TFTP server’s configuration file.
- client-class name = res01
- filename = /bayn/cm/md5/res01/secure/2
3. TFTP server’s configuration file is modified by its customer (MSO, @Home, etc.)
- Order and names of path variables
- Order and names of filename variables
- Table of client class names
- Table of filtering options
- If file type is "md5" will need to inform TFTP server the order in which the
variables are inserted into the file and the default_key used to create the message
digest.
Example ‘new’ cable modem transaction
- Cable modem is first connected to the RF plant and is allowed to boot
- Since the cm is NOT registered with the provisioning server or customer care the request
from that device is assigned to a default service class by the server. This service class
has a filename defined for these cm and is appended to the path name (which is assigned by
which gateway the modem request came from). The combined filename, IP address of the
closest TFTP server, and the IP address assigned to the cm is sent in the bootp response.
- The bootp response is received by the cm, it assumes that IP address and follows the
instructions in the bootp response to obtain the boot file from the nearest TFTP server
specified in the bootp response.
- The TFTP server receives this request but notices that the request begins with a special
character (telling it to build the file on-the-fly. The TFTP server parses the boot file
parameters encoded in the TFTP request as instructed by the TFTP.conf file. Taking the
instructions from the TFTP.conf file along with all the available parameters the new TFTP
server builds the boot file in memory and sends it back to the device (cm) that requested
it.
- This default boot file received by the cm and loaded. Since the cm is NOT registered the
boot file is limited in its capabilities (restricts the cm to only access a handful of IP
addresses – special dns server [limited], dhcp server, bootp server, and a
registration web server, ftp server).
- Cable modem allows network interface card to connect to the dhcp server and retrieve
limited lease. Since the nic is also not registered the lease is part of a internally used
network – perhaps net10 with limited dns.
- The customer computer either uses its own browser or one downloaded from the ftp server
and connects to the registration web site.
- The registration web site authenticates the user using their email name and password
which are available to the customer and the installer. If the customer is doing their own
install a different type of authentication would need to be available – perhaps look
up a credit card number, username and billing address. If the self install authentication
was successful the customer would fill out similar data of that obtained over the phone
for regular scheduled installs and proceeds to the next step.
- Once authenticated, the installer/customer can register their nic and modem with the
customer’s account to allow the cable modem to obtain a working boot file as opposed
to the initial protected currently in use. Through this web page the parameters can either
be forced (via SNMP) or jump-started (using either a software reset of the cm or a power
cycle).
- When the cable modem obtains its new operational parameters the restrictive access is
lifted and the customer assumes normal operation. After this the customer’s PC(s)
will also need to be either re-booted or release and renew their leases to obtain a
working 24net address.
- The customer can return to the registration web site at any time to change nic/cm mac
addresses, type of service, hostname, request a vanity hostname, obtain additional email
addresses, look up account information, cancel service (if they own their own cable modem)
or request a scheduled disconnect, even refer potential customers for a finder fee if that
person subscribes.
Can Birds-Eye.Net help you or your Company?
Receive your Birds-Eye.Net articles and white
papers hot off
the presses by adding our RSS feed to your reader.
|