One Unified Global Perspective
Communications with a Global Perspective
Home
Intro
Contact Us
Voice over IP
PBX Solutions
Services
Support
Glossary
Open Source
Blog
Forum

WebMail





2009 Jun 27 - Sat

Network Broadcast Addresses

A customer was performing penetration testing on their network. Once the test results were in, among other things, they had a couple questions about responses to certain addresses on their external subnet range.

As a background, every subnet with a network mask of /30 or shorter has three address groups:

  • first address: the zeros address aka network address
  • middle addresses: usuable addresses
  • last address: the ones address aka broadcast address

For explanation purposes, imagine a router with two interfaces:

  • interface 1, the ingress interface, with address range of 10.0.0.0/30 and interface address of 10.0.0.1.
  • interface 2, the egress interface, with address range of 10.0.0.4/30 and interface address of 10.0.0.5.

For some network devices, for a packet arriving on the ingress interface destined for the broadcast address of the egress interface (10.0.0.7), the network device will forward the packet, effectively broadcasting to all devices located in the subnet of the egress interfaces. When many packets arrive in this manner, this is known as a Smurf Attack.

Current Cisco devices, by default, no longer forward packets to broadcast addresses, but may respond to these packets. The following command is applied by default to prevent forwarding of packets to broadcast addresses:

no ip directed-broadcast

At the other end of the subnet, for the network address, I originally thought this was a quiescent address. However, I did find that the an ICMP echo request arriving on the ingress interface destined to the network address (10.0.0.4) of the egress interface will generate an echo-reply with the ingress ip address (10.0.0.1) as the source address.

It appears that in days gone past, that for BSD Unix boxes and various other equipment, the network address was *the* broadcast address. This is why some configurations allow one to configure the address of the broadcast address setting, whether it be the high end or low end of a subnet. (thanx to Steinar Haug for this info).

rfc 1122 formalizes this broadcast address configuration (thanx to an inciteful responder named Lee):

   3.3.6  Broadcasts

         There is a class of hosts* that use non-standard broadcast
         address forms, substituting 0 for -1.  All hosts SHOULD
         recognize and accept any of these non-standard broadcast
         addresses as the destination address of an incoming datagram.
         A host MAY optionally have a configuration option to choose the
         0 or the -1 form of broadcast address, for each physical
         interface, but this option SHOULD default to the standard (-1)
         form.

The host will respond with the echo-reply because of rfc 791:

   3.2.1.3  Addressing: RFC-791 Section 3.2

             ...   An incoming datagram is destined
            for the host if the datagram's destination address field is:

            (1)  (one of) the host's IP address(es); or

            (2)  an IP broadcast address valid for the connected
                 network; or

From a Cisco router perspective, the default use of the command 'no ip directed-broadcast', allows one to use a /31 subnet (two ip addresses) for point to point links instead of the usual /30 subnet (four ip addresses). One can effectively address twice as many links with the same number of addresses. This feature is mentioned in Cisco's Feature Guide: Using 31-Bit Prefixes on IPv4 Point-to-Point Links.

Coincidently, while I was writing this article, I received a note that there are a couple of TCP Security Assessment documents available:

These documents go into the details of the bits and bytes making up the TCP protocol, analyzing the reasons for the bits, how they can be misused, and suggesting counter-measures when used illegally. Theres is a detailed bibilography with active links to related papers and documents.

An idea of the scope of the document can be seen through its first level table of content:

  • The Transmission Control Protocol
  • TCP Header Fields
  • Common TCP Options
  • Connection-Establishment Mechanism
  • Connection-Termination Mechanism
  • Buffer Management
  • TCP Segment Reassembly Algorithm
  • TCP Congestion Control
  • TCP API
  • Blind In-Window Attacks
  • Information Leaking
  • Covert Channels
  • TCP Port Scanning
  • Processing of ICMP Error Messages by TCP
  • TCP Interaction with the Internet Protocol (IP>
  • References



Blog Content ©2009
Ray Burkholder
All Rights Reserved
ray@oneunified.net
(441) 505 7293
Available for Contract Work
Resume

RSS: Click to see the XML version of this web page.

twitter
View Ray 
Burkholder's profile on LinkedIn
technorati
Add to Technorati Favorites



June
Su Mo Tu We Th Fr Sa
 
27
       


Main Links:
Monitoring Server
SSH Tools
QuantDeveloper Code

Special Links:
Frink

Blog Links:
Sergey Solyanik
Marc Andreessen
HotGigs
Micro Persuasion
... Reasonable ...
Chris Donnan
BeyondVC
lifehacker
Trader Mike
Ticker Sense
HeadRush
TraderFeed
Stock Bandit
The Daily WTF
Guy Kawaski
J. Brant Arseneau
Steve Pavlina
Matt Cutts
Kevin Scaldeferri
Joel On Software
Quant Recruiter
Blosxom User Group
Wesner Moise
Julian Dunn
Steve Yegge
Max Dama

2009
Months
Jun




Mason HQ

Disclaimer: This site may include market analysis. All ideas, opinions, and/or forecasts, expressed or implied herein, are for informational purposes only and should not be construed as a recommendation to invest, trade, and/or speculate in the markets. Any investments, trades, and/or speculations made in light of the ideas, opinions, and/or forecasts, expressed or implied herein, are committed at your own risk, financial or otherwise.