Saturday, December 30, 2017

📞 1899 :: Dec. 30 :: American Bell becomes AT&T

American Bell (MA) becomes AT&T (NY). Massachusetts' law restricted the financial structuring of American Bell; New York law was more progressive. In order to allow Bell to continue to grow, AT&T "acquired the assets of American Bell, and became the parent company of the Bell System," moving from Boston to NYC. AT&T had capitalization of $70m. See Cybertelecom.

Sunday, December 24, 2017

Holiday Greetings from Mark Twain

It is my heart-warm and world-embracing Christmas hope and aspiration that all of us, the high, the low, the rich, the poor, the admired, the despised, the loved, the hated, the civilized, the savage (every man and brother of us all throughout the whole earth), may eventually be gathered together in a heaven of everlasting rest and peace and bliss, except the inventor of the telephone. - Mark Twain (Twainquotes citing Caroline Harnsberger's Mark Twain at Your Fingertips ) 

Thursday, December 21, 2017

A Peering Policy Survey

In 2009, William Norton, a.k.a. Dr. Peering, conducted a survey of 28 peering policies. A peering policy is a statement by one network of "inclination" to enter into a peering arrangement with other networks. Norton is one of many evangelists of Internet peering. His objective was to identify clauses that were commonly found in peering policies that could be used as models for prospective peers.

Traditionally, a settlement free peering arrangement was entered into between "peers," in other words, equal networks. Peering policies articulated the benchmarks used for determining if networks were "peers," that "peers" were roughly equal in size and exchanged roughly balanced traffic and therefore the increased value from interconnection would be mutually beneficial. In the nascent commercial Internet ecosystem of the 1990s, there were Tier 1 backbone networks, Tier 2 regional networks, Tier 3 access networks, end users, and edge providers. The network was hierarchical. Each participant in the ecosystem had a relatively discreet business plan. Thus "peers" were (somewhat) easy to identify.

The Internet ecosystem evolved tremendously in the last three decades. It is much more difficult to identify a "peer." The network is no longer hierarchical. Providers' business plans have expanded, offering access, regional, and backbone service. A provider may be a mix of hosting, cloud, CDN, and network services. Large access networks no longer are reliant upon third party backbone service and no longer pay for transit service; they charge content networks to access the access network's subscribers. Content networks are also no longer as reliant on third party backbone services, instead using CDN's to move content as close to end-users as possible. Instead of content moving up the Internet hierarchy until it reaches Tier 1 and an interconnection point, it is moved to the gateway of the access network where the CDN attempts to negotiate interconnection with the access network. This evolution has changed the inclination of networks to enter into settlement free peering arrangements.

This paper seeks to resurvey peering policies in light of the evolution of the Internet ecosystem. What has this evolution meant for the inclination of network providers to peer? Is this evolution reflected in peering policies? Is there a difference in peering policies between backbone service providers, large access providers, and content networks? Are there clauses that remain common across all policies? Can there be "peering" if there are no longer "peers"?

Methodology

The scope of the survey is peering policies for networks providing service in the domestic United States market. Peering policies were found using Google, reviewing CAIDA and DYN's list of top transit providers, and reviewing PeeringDB.

Peering policies were broken down into common clauses. The breakdown of those clauses sometimes did and sometimes did not track the breakdown used by the providers.

Providers could have multiple peering policies.  Some providers have distinct business units that have distinct inclinations.  For example, Verizon's CDN Edgecast has a different peering policy than Verizon broadband Internet.  Other companies have multiple policies due to mergers and acquisitions.  For example, Charter Communications acquired Time Warner Cable; both networks continue to have posted peering policies.  Verizon also has distinct posted peering policies for its acquired assets AOL, Yahoo!, and XO. Legacy peering policies of acquired networks were reviewed if available online even though it cannot be determined whether they remain in effect.

In total, 60 networks were surveyed. While the sample size of networks surveyed is relatively small, this sample represents the top backbone providers, BIAS providers, CDNs, and edge providers, representing a strong majority of network traffic. This methodology, however, biased the results towards the behavior of the largest providers versus small providers; markets have a long tail of hundreds of small providers who may produce different results.[1]

Providers were classified according to primary Internet business: edge provider, broadband Internet access service, content delivery network (both private and commercial grouped together), educational, and infrastructure (i.e., ARIN, ICANN, ISC). This proved difficult.  One of the premises of this survey is that providers no longer fit within discrete business plans where peers are easily discerned.  Providers have diversified their business plans, with incentives to move towards more profitable services.  Therefore, providers were classified according to their dominant characteristic at the point of interconnection.  For instance, Netflix is a video delivery service.  At the point of interconnection, Netflix could be appropriately characterized as a private CDN.  Many of the edge providers and content providers have constructed their own private CDNs and at the point of interconnection are attempting to deliver data to end users. It is a subjective classification but probably sufficient to observe market dynamics. 

Findings

Peering Policies

Sixty five percent of surveyed networks had posted peering policies. One hundred percent had PeeringDB entries (in other words, all networks without posted peering policies nonetheless had PeeringDB entries). [2] Two networks had no peering policy or PeeringDB peering information (they had PeeringDB entries but the peering fields were blank). It appears that for many networks PeeringDB has taken on the role of peering policies as a means of expressing peering inclination and establishing arrangements.

Fifty eight percent of backbone providers have peering policies compared to 79% of BIAS providers, 66% of CDNs, and 83% of edge providers. Sorting the survey for the largest backbone transit providers as identified on Dyn's Baker's Dozen 2016 produced a consistent result of 55% of backbone providers with posted peering policies. These numbers are a little muddled because a number of the BIAS providers are also backbone networks and reportedly charge paid peering, such as AT&T, Centurylink, Time Warner Cable (Charter), Comcast and Verizon; these networks were classified as BIAS providers and all of them had published peering policies.

These findings reflect that all participants in the Internet network ecosystem, not just backbones, are actively seeking peering arrangements. Curiously, backbone networks had the lowest percentage of posted peering policies and yet backbone interconnection conflicts were the original impetus for the calls for published peering policies. Then again, as peering policies are statements of inclination to peer, and backbone networks are inclined to sell transit, not peer, the lack of posted peering policy could be consistent with their lower interest in peering. [3] A backbone network does not enter an IXP with the anticipation of peering with the other firms at the IXP; the backbone enters the IXP to sell transit.
Peering Inclination

Generally, networks inclination to peer is divided into four: open, selective, restrictive, and no peering. "Open" is the most liberal inclination where a network is generally willing to peer with anyone who can meet basic requirements (such as meeting the network at an interconnection point). "Selective" is the similar to open, but the selective networks is looking for some basic requirements before they enter into such relationships (for example, minimum traffic utilization). "Restrictive" is the more traditional inclination where a provider is only willing to entering into peering with "peers," networks that meet a relatively high bar of criteria. These inclinations can be regionally specific. A network may have an open policy in one geographic regional and a selective policy in another.

According to PeeringDB,[4] 35% of networks surveyed had open peering policies, 43% had selective, and 18% has restrictive.[5] Combining "open" and "selective," 78% of networks are interested and inclined to enter into a peering arrangement. This is consistent with what one might anticipate that peering is a beneficial arrangement, but the largest group of networks has at least some criteria for when the expense and logistics justifies the arrangement.
Having a posted peering policy is associated with being more inclined to peer. The survey reveals that those with posted peering policies are 18 percentage points more inclined to peer that those without.
If we break the networks out by business plan, we see differences in inclinations. Sixty seven percent of backbone networks had restrictive peering policies (as noted above, backbones also had the lowest percentage of posted peering policies and have a business plan of selling transit, not peering).[6] The only other networks with restrictive peering policies were large BIAS providers who reportedly charge paid peering. No CDNs or edge providers had restrictive peering policies.

CDN's surveyed had 50% open policies and 50% selective policies. CDNs are in the business of delivering data; they get paid by edge providers for that service. Interconnecting with backbone and access networks facilitates the delivery of traffic and thus furthers their business model.

BIAS providers had 14% open policies, 64% selective, and 14% restrictive. BIAS providers are a mixed bag. BIAS providers that do not have significant backbones and are reliant on transit service to bring the full Internet to their customers have an incentive to avoid transit costs by entering into peering arrangements. Historically, access providers would have welcomed offers of settlement free peering as a means of defraying transit costs. However, large BIAS providers that charge access paid peering to CDNs have no incentive to agree to settlement free peering, increasing the settlement free capacity into their networks that edge providers could use instead of paid peering routes. AT&T, Centurylink, and Comcast have selective peering policies where Time Warner Cable (now Charter) and Verizon have restrictive peering policies.

A provider can have different peering policies based on the service it is providing. Verizon's general peering policy is restrictive whereas Verizon CDN Edgecast's peering policy is open.

Not surprising, educational and infrastructure networks generally have open peering policies. They are not in the business of selling network services; the goal is connectivity.

Words Per Policy

On average peering policies contained 679 words and 8 provisions. As would be expected, the open policies were shorter than the restrictive policies. Open policies had 451 words on average and 5 provisions; selective policies had 665 words and 9 provisions; and restrictive policies had 1183 words and 11 provisions. The shortest peering policy was Limelight's selective policy with 87 words. The longest policy was Time Warner Cable's (Charter) restrictive policy with 1701 words. The third longest peering policy was Charter's at 1404 words, even though it is a selective policy.

Green = Open. Yellow = Selective. Red = Restrictive.
Common Clauses

The most common peering policy clause was the requirement for a 24/7 Network Operations Center. Eighty two percent of surveyed peering policies required this. It appears to be the highest priority in interconnection relationship that partners are able to promptly respond to and resolve networking issues. The next highest clause was the "no abuse" provision (no gateway of last resort, no default routes, no transit traffic in a peering relationship, no static routes),[7] which, likewise, is an assurance that the partner will behave in terms of routing.

Clause All Policies BIAS Backbone CDN All Policies
Norton 2010
Percent Change 2017
versus Norton
24/7 NOC 82% 100% 86% 63% 89% -7%
No Abuse 74% 91% 43% 63% 64% +10%
Minimum Required
interconnection points
67% 91% 71% 63% 46% +21%
Consistent Routing
Announcements
64% 82% 86% 50% 75% -11%
Minimum Traffic 54% 91% 57% 38% 71% -17%
Geographically Diverse
Network
41% 73% 43% 38% 46% -5%
Filter Routes 36% 73% 14% 0% 29% +7%
Customers are not
eligible to become peers
36% 45% 43% 0% 71% -35%
Potato Routing 33% 45% 29% 38% 29% +4%
PeeringDB 31% 9% 0% 63% 7% +24%
Traffic Ratio 28% 64% 57% 0% 32% -4%

Minimum Interconnection Points

Twenty-six policies had minimum required points of interconnection. Three of the highest minimums were for peering on a global basis and included international POPs. The average for the rest was a minimum of three points of interconnection. Some networks were willing to peer even if the networks meet at only one point of interconnection. Of the domestic networks, Charter had the highest minimum required points of interconnection with nine for content providers.

There were a number of networks that required that a potential partner interconnect at "all" points of interconnection where both networks are present.  These networks may be willing to interconnect with only a few POPs, but they want redundancy and Cold Potato delivery and thus want to interconnect anywhere where they both co-exist.  While one might expect this to be a clause of CDNs, it was found in one backbone's policy and three edge providers' policies.


Traffic Ratios

Twenty eight percent of peering policies contained balanced traffic ratio requirements.  These clauses were found in backbone and BIAS network policies.  All of the BIAS providers that are known to charge paid peering had balanced traffic ratios as a condition for interconnection. No CDN, edge provider, infrastructure network, or educational network included a traffic ratio clause.  The average requirement was 2:1 and the range was from 1.5:1 to 3:1.  Three networks simply indicated that a balance traffic ratio was required without specifying a number.
Interconnection Contract Required

In 2012, the OECD published a report that found that 99.5% of peering arrangements were without written contracts. This finding was on a global basis and was based on a per network measurement, not based on the amount of traffic carried by networks (in other words, the hypothesis is that larger networks, networks that carry more traffic, are more likely to require contracts, and represent a larger share of exchanged traffic).

According to PeeringDB, 26% of networks require contracts. None of the networks with open peering policies required contracts; 23% of selective networks require contracts; and 82% of restrictive networks require contracts. Consistently, none of the CDNs or edge providers require contracts where 75% of backbones require contracts. Of the top transit providers listed in Dyn's Baker's Dozen for 2016, every provider except Hurricane Electric requires a contract. Four of the BIAS providers known to charge access paid peering require a contract (TWC, acquired by Charter, indicates that a contract is not necessary).

Hot or Cold Potato Routing

Hot Potato routing is a traditional arrangement where traffic from the sending network is handed off to the receiving network at the closest interconnection point to the origin of the traffic. Hot Potato routing was common between peering Tier 1 backbones.

Cold Potato is the opposite, where the originating network carries the traffic as far as possible and hands it off as close to the receiving end user as possible. The sending network is responsible for long haul transport while the receiving network is responsible for local access transport. CDNs delivering traffic to access networks employ Cold Potato routing.

Thirty three percent of peering policies surveyed contained a Potato clause. Sixty nine percent called for Hot Potato routing; 31% called for Cold Potato routing. The Potato clauses did not fall out as one might expect; one might expect that BIAS providers want CDNs and backbones to carry heavy traffic as far as possible and deliver it as close to end users as possible in order to avoid network costs and improve end user experience. Yet sixty percent of BIAS providers that contained this clause called for Hot Potato routing; this reflects in part BIAS providers that own their own backbone networks. Charter, which owns the TWC backbone, called for Cold Potato routing in both of its peering policies. In the CDN group, Highwinds called for Hot Potato routing; the other two CDNs that had a Potato clause called for Cold Potato routing; most CDNs did not have a Potato clause (CDNs are in the business of quality delivery of content; one might expect them to have an incentive of avoiding congested backbones and improving performance by locating CDN servers as close to end users as possible). Only the backbone providers fell out as expected, with all networks that had this clause calling for Hot Potato routing.

Congestion

The recent interconnection disputes have left their mark on peering policies. Historically, peering disputes were between backbones (generally as backbones grew and tried to join the Tier 1 club) and lasted a few days (the value of network effect and providing service to customers exceeded the value of the dispute, creating an incentive for rapid resolution and getting back to business before customers switch to a backbone service that isn’t affected). Recent interconnection disputes have been between content networks and access networks and have been protracted.

Several peering policies indicate that partners must agree to avoid congestion (Fastly: "Maintain congestion free interconnection"; Yahoo!: "Maintain congestion free interconnection"; Blizzard: "maintain sufficient capacity to exchange traffic without congestion"; Microsoft: "sufficient capacity to exchange traffic without congestion", Frontier: "Peers must agree to resolve congestion issues"). Other networks include in the policy that capacity will be augmented at a specific benchmark. An industry norm is that capacity is augmented when utilization reaches 70%. Google and Microsoft include a clause that capacity will be augmented when utilization reaches 50%. Finally, Comcast includes a clause that partners will participate in capacity planning "and work towards timely augments as identified." Twenty three percent of networks surveyed that had peering policies included some clause to address congestion.

Divergence from Norton 2010 Survey

PeeringDB

A requirement that a potential interconnection partner use PeeringDB is the most significant increase from the Norton 2010 survey. Norton found that only 7% of policies required the use of PeeringDB. Norton observed "nLayer does not even suggest using it - surprising, since Richard Steenbergen from nLayer leads the peeringDB project." This survey found that 31% of peering policies require the use of PeeringDB (and 100% of surveyed networks have PeeringDB entries). The type of network requiring a PeeringDB entry showed interesting variation. Only 1 BIAS provider included this clause and no backbone providers. Conversely, 63% of CDNs and 60% of edge providers included this clause.

No Customers

The clause that had the most significant decrease and largest divergence from the Norton Survey was "no transit customers may become peers." Norton found that 71% of peering policies contained this clause while this survey found only 36%. It seems like this clause would only be of concern to those networks in the business of selling transit. This would be less of an issue for those providers with incentives to avoid transit costs or improve connectivity.

Observations: Peering Policies Dont Measure "Peers" Anymore

A "peering policy" is no longer a measuring stick by which "peers" are determined. By definition, "peering" is an interconnection arrangement between partners who exchange traffic from their own networks. Historically, "peering" was an arrangement between "peers" (equals). A "peer" was a network of roughly equal size that exchanged roughly balanced traffic. A "peering policy" articulated how a "peer" would be measured and determined.

There are no more peers.[8] Providers have diversified their business plans vertically and horizontally, and have merged and consolidated businesses. At the time of the Commercial Internet eXchange, Verizon, Comcast, AT&T, Charter (Time Warner Cable), and Centurylink did not have Internet backbones; now they are the top Internet network providers. Almost none of the original members of the Commercial Internet eXchange exist in their 1992 form. The big question of peering has evolved from an interconnection arrangement in the core between backbones to an interconnection arrangement on the edge between access networks and CDNs.

Since there are no longer "peers," a "peering policy" is no longer a mechanism for measuring "peers." Since there are not networks of "roughly equal size," the first of two necessary benchmarks, then the second benchmark "balanced traffic ratio" likewise no longer helps to measures equals. Instead, what was once a benchmark has become an interconnection condition. "Balanced traffic ratio" is now a condition that limits the amount of traffic that can be exchanged (in order for traffic exchange to be balanced, one network can send the other network no more traffic than it receives).

Peering continues to be an attractive interconnection arrangement. Smaller access networks that are reliant on transit have an incentive to avoid transit costs by entering into peering arrangements with each other, content providers, and edge providers. Content and edge providers have an incentive to directly interconnect with access networks, bypassing congested third-party transit providers. Large networks have an incentive to peer with other large networks, avoiding transit costs and providing quality routes for traffic. Direct interconnection through peering can result in efficiencies, quality delivery of traffic, and better management of traffic flows.

Peering policies reflect the evolution of the Internet ecosystem. Formerly a statement of peering inclination by backbone providers, now peering policies are posted by access networks, CDNs, and edge providers. The more peering furthers a business plan, the more inclined a network will be to enter into a peering arrangement. An access provider indicates that it will enter into a peering arrangement but only on the condition of cold potato routing and that traffic is delivered to specified interconnection points; a CDN indicates that, in order to further its business plan of high quality traffic delivery, it is willing to carry traffic as close end users as possible and openly enter into interconnection arrangements. Peering Policies have become statements of how providers will establish interconnection arrangements with non-equal providers.



Endnotes

[1] Contrast Aemen Lodhi, Natalie Larson, Amogh Dhamdhere, Constantine Dovrolis, kc claffy, Using PeeringDB to Understand the Peering Ecosystem, ACM SIGCOMM Computer Communication Review, 44(2), 20-27 (2014) (reviewing peering characteristics based on the full PeeringDB database.  When Lodhi et al.'s results were sorted for the largest providers, their results were consistent with the findings of this survey.).

[2] Compare Lodhi at 22 ("We find that 93% of the top-100, 80% of the top-200 and 74% of the top-300 ASes from [CAIDA's] AS-rank were present in the [August 2013 PeeringDB] dataset, including all known Tier-1 and major Tier-2 ASes").

[3] See Jayne Miller, IP Transit vs. Peering: How a Network of Networks is Built, Telegeography Blog (Sept. 20, 2016) ("Large networks that are the major providers of IP transit have no incentive to peer with potential customers.").

[4] I did not contrast self reported peering inclinations in PeeringDB with inclinations articulated in posted peering policies in order to confirm consistency.  However, the Using PeeringDB study did. Aemen Lodhi, Natalie Larson, Amogh Dhamdhere, Constantine Dovrolis, kc claffy, Using PeeringDB to Understand the Peering Ecosystem, ACM SIGCOMM Computer Communication Review, 44(2), 20-27, 23 (2014), http://www.sigcomm.org/sites/default/files/ccr/papers/2014/April/0000000-0000002.pdf ("we obtained the peering policy URLs of 50 networks in PeeringDB, and compared the policy seen on their URL with the policy mentioned in the PeeringDB record. In each case, the peering policy listed on PeeringDB (Open, Selective or Restrictive) matched the peering policy at that network’s policy URL.").

[5] Compare Aemen Lodhi, Natalie Larson, Amogh Dhamdhere, Constantine Dovrolis, kc claffy, Using PeeringDB to Understand the Peering Ecosystem, ACM SIGCOMM Computer Communication Review, 44(2), 20-27, 23 (2014), http://www.sigcomm.org/sites/default/files/ccr/papers/2014/April/0000000-0000002.pdf ("Of the 3392 ASes in the [August 2013 PeeringDB] dataset, 76% use Open peering, 21% use Selective, and 3% use Restrictive."). The Using PeeringDB study found that inclination to peer was inversely correlated to network size; larger networks were more likely to have restrictive peering policies.  Id. at 25.  This survey focused on the largest backbones, content providers, CDNs and BIAS providers and therefore the results reflect that methodology.

[6] Compare Aemen Lodhi, Natalie Larson, Amogh Dhamdhere, Constantine Dovrolis, kc claffy, Using PeeringDB to Understand the Peering Ecosystem, ACM SIGCOMM Computer Communication Review, 44(2), 20-27, 21 (2014), http://www.sigcomm.org/sites/default/files/ccr/papers/2014/April/0000000-0000002.pdf ("we find widespread adoption of Open peering among transit providers, which is counterintuitive given that transit providers prefer other ASes as their customers instead of peers. ").

[7] [William Norton, Don’t Abuse Peering, DrPeering] [Understanding Default Routes, IS-IS Feature Guide, Juniper Networks (May 20, 2010), ("A default route is the route that takes effect when no other route is available for an IP destination address.")] [Configuring Static Routes, CISCO Nexus 7000 Series NX-OS Unicast Routing Configuration Guide (June 14, 2017)] [Luc De Ghein, Specify a Next Hop Address for Static Routes, CISCO Technical Support, Sept. 2, 2014] [Configuring a Gateway of Last Resort Using IP Commands, CISCO Technical Support, Aug. 10, 2005 ("Default routes are used to direct packets addressed to networks not explicitly listed in the routing table. Default routes are invaluable in topologies where learning all the more specific networks is not desirable, as in case of stub networks, or not feasible due to limited system resources such as memory and processing power.")]

[8] There are Peering Fundamentalists who adhere to the tenant that "peering" is an arrangement between "peers."  An interconnection arrangement that is not between peers, therefore, cannot be "peering," regardless of the routes exchanged.  To them, the term "paid peering" amounts to heresy as it is implicitly a relationship between non-equals.  As a member of the Reformed Peering Denomination, I view such talk as semantics.  There is no platonic form to the word "peering."  It means just what we chose it to mean – neither more nor less.  It could be called "On-Net traffic exchange."  It could be called "Pineapples."  As long as we adhere to a term and a common understanding, we are good.


Tuesday, December 19, 2017

1913 :: Dec. 19 :: AT&T's Kingsbury Commitment and the end of telephone competition

At the turn of the 20th Century, Alexander Graham Bell's telephone patents had expired and competition had entered the market place.  Independent telephone companies raced to establish themselves in markets as of yet unserved by AT&T  Other markets saw the advent of  "dual service," with multiple, but incompatible, telephone services. Businesses might have multiple phones on their desks in order to reach different customers on different networks. 

AT&T faced competition. And to AT&T, competition was inefficient.  AT&T President Theodore Vail proclaimed that there should be "One policy, one service: Universal Service." Vail could solve the problem of a telephone market where different phones could not talk to each other by establishing AT&T as the government sanctioned monopoly. 

In order to solve the problem of the independents, AT&T leveraged an asset that the independents lacked: it's long distance network linking together the local Bell Operating Companies.  AT&T benefited from Network Effect.  Subscribers to the Bell networks could reach all the other subscribers to the Bell networks over the AT&T interconnected long distance network.  The subscribers to the independent telephone networks could not. 


The independent networks asked to interconnect with the AT&T network.  AT&T refused. AT&T also, through its affiliation with J.P. Morgan, squeezed the Independents' access to financial capital. And also refused to sell superior Western Electric (which AT&T owned) equipment to its rivals.

The position of the independent networks became untenable. The independent telephone companies would crumble, either going out of business or selling out to AT&T.

Progressive era regulators grew wary of AT&T's anticompetitive strategy and filed suit in 1912. Rumors were also brewing in Congress about the possibility of nationalizing AT&T (something that would happen several years later during World War I).

In 1913, AT&T settled the antitrust actions with the Kingsbury Commitment in which AT&T agreed to interconnect its long distance network (not its local Bell Operating Companies) with independent telephone companies, stop acquiring independent telephone companies, and divest itself of Western Union.

At this point the damage to the competitive market had already been done and many crumbling independent telephone companies would have prefered it if AT&T had been permitted to buy them out.  AT&T's strategy of establishing itself as the monopoly telephone network was well under way.   By 1921, AT&T had achieved its strategy and competitive independent telephone providers dissolved from the market.


Monday, December 18, 2017

RFC NIST Trustworthy Email

SP 800-177 Rev. 1 (DRAFT)

Trustworthy Email (2nd Draft)

  

    Documentation     Topics

Date Published: December 2017
Comments Due: January 31, 2018
Email Comments to: sp800-177@nist.gov

Author(s)

Scott Rose (NIST), Stephen Nightingale (NIST), Simson Garfinkel (U.S. Census Bureau), Ramaswamy Chandramouli (NIST)

Announcement

Draft NIST Special Publication 800-177 Revision 1, Trustworthy Email, covers and gives recommendations for state of the art email security technologies to detect and prevent phishing and other malicious email messages. The guide was written for email administrators and for those developing security policies for an enterprise email infrastructure.

This second comment period for Revision 1 is to allow for comments on a newly included security recommendation dealing with mail confidentiality. This revision also includes more text on new email security protocols currently undergoing specification and finalization as IETF Draft Standards. Reviewers should pay particular attention to Sections 5.2 and 7.3, which has newly added material.

Abstract

This document gives recommendations and guidelines for enhancing trust in email. The primary audience includes enterprise email administrators, information security specialists and network managers. This guideline applies to federal IT systems and will also be useful for small or medium sized organi... See full abstract

Keywords

Email; Simple Mail Transfer Protocol (SMTP); Transport Layer Security (TLS); Sender Policy Framework (SPF); Domain Keys Identified Mail (DKIM); Domain based Message Authentication, Reporting and Conformance (DMARC); Domain Name System (DNS) Authentication of Named Entities (DANE); S/MIME;
Control Families

None selected

DOCUMENTATION

Publication:
 Draft (2nd) SP 800-177 Rev. 1

Supplemental Material:
 Comment template (xls)

Related NIST Publications:
SP 800-45 Version 2

Tuesday, December 12, 2017

Peering Policies

A "Peering Policy" is "[t]he decision criteria that a provider applies in deciding with whom they will peer. " [NRIC Sec. 1.2.2] In the words of Bill Norton, a "Peering Policy" is "an articulation of peering inclination." [Norton, A Guide to Peering Contracts] [Norton Open Peering Policy] Originally, it was an articulation by a backbone network (the networks in the 1990s that peered) of whom it would perceive to be a "peer" or equal. It is like an amusement park sign that says, "you must be this tall to ride." Generally, to be a "peer," a network had to satisfy the settlement free peering proxy and be roughly equal in size and exchange roughly balanced traffic. A peering policy delineated how that would be measured.[Golding][BEREC p. 21 Dec. 6, 2012][NRIC FG 4]

A peering policy is not a peering contract; peering contracts are far more elaborate. It is not a legal "offer;" networks reserve the right to negotiate and to enter into a peering arrangement or not. [NRIC Sec. 1.2.2] [Norton, Peering Policies]

In the 1990s, as the nascent commercial Internet matured, Tier 1 backbones looked at smaller networks, concluded that they were not "peers," and migrated smaller networks to transit customer arrangements. [1997 Depeering] Smaller networks that found themselves with large transit bills complained. [Digital Handshake 2000] [First 706 Report, para. 105 (at the time, commenters unanimously opposed FCC intervention into peering and interconnection disputes with one exception; Bell Atlantic, now Verizon, recommended possible action by the FCC to lower barriers of entry to new entrants).] If they were not large enough to qualify for peering, then they wanted to know how large they had to be. They wanted to know what benchmarks they had to meet to avoid transit fees.

In 2001, the FCC's Network Reliability and Interoperability Council (NRIC, predecessor of CSRIC), led by Jim Crowe of Level 3, recommended that networks post peering policies on their websites. [NRIC Sec. 4.1] [NRIC Internet Peering Statement ("NRIC V encourages other Internet providers, and especially the large "backbone" Internet providers that comprise the core of the modern Internet, to consider, consistent with their business practices, publication of their criteria for peering.") Available on the Web Archive.] [GAO ("We were also told that peering policies should be made public.")] [FCC NRIC Encourages Publication of Peering Criteria to Promote Transparency (Oct. 30, 2001).] In the 2005 mergers (Verizon/WCOM, AT&T/SBC) and the 2007 merger (AT&T/Bell South), the parties agreed to post peering policies as a merger condition. [SBC / AT&T ¶ 133] [Verizon / MCI ¶ 134] [AT&T / Bell South, Appendix F]

Peering policies consist of two different types of clauses.[Compare Norton Survey (dividing the clauses into three groups: (1) operations-related Internet peering policy clauses; (2) Technical / Routing / Interconnection clauses; and (3) General Clauses).] First, provisions that determine whether a potential partner is a "peer" (roughly equal size with roughly balanced traffic), and, second, operational conditions regarding what is necessary to successfully interconnect. These provisions fall out as follows: 

Peer Criteria (roughly equal size / traffic) 
Operational Conditions 
  • Geographic reach
  • Redundant network
  • Presence at specified IXPs
  • Minimum number of points of interconnection
  • Minimum traffic capacity / utilization
  • Balanced traffic ratio
  • No customers as peers
  • 24/7 NOC
  • No Abuse
  • Consistent Routing Announcements
  • Filter routes
  • Hot or Cold Potato Routing
  • Resolving congestion / augmentation
  • Use of IRR, PeeringDB

[NortonStudy of 28 Peering Policies] [Golding] [BEREC p. 21 2012] [NRIC Sec. 4.3 (examples include geographic coverage, proximity to exchange points, minimum capacity, symmetry of traffic exchange, minimum traffic loads, reliable network support, and reasonable address aggregation)] [Verizon (“The key common feature, however, is that these voluntary arrangements involve a mutual exchange of value of one form or another.”)] [Aemen Lodhi, Natalie Larson, Amogh Dhamdhere, Constantine Dovrolis, kc claffy, Using PeeringDB to Understand the Peering Ecosystem, ACM SIGCOMM Computer Communication Review, 44(2), 20-27, 21 (2014), ("Finally, we explore what historical snapshots of the PeeringDB database can tell us about the evolution of the Internet peering ecosystem.")]

In 2004PeeringDB came on the scene. PeeringDB is a database created "by and for peering coordinators" that provides 
  • a link to peering policy,
  • peering inclination,
  • whether interconnection at multiple locations is required,
  • whether there is a balanced ratio requirement,
  • whether a contract is required,
  • peering contact information, and
  • the peering facilities where the network is available for interconnection.
According to PeeringDB, "The purpose of this project is to facilitate the exchange of information related to peering. Specifically, what networks are peering, where they are peering, and if they are likely to peer with you." [Martin Levy, PeeringDB and why everyone should use it, presentation at African Peering and Interconnection Forum 2011, slide 7] In 2016, PeeringDB 2.0 was launched and PeeringDB was established as a non-profit organization. By the end of 2016, it listed 8194 peering networks, 2302 interconnection facilities, and 566 IXPs.  [Arnold Nipper, PeeringDB, presentation at CEE Peering Days 2017] [Terry Rodery, PeeringDB, presentation at NANOG 40 (2007)] [Aemen Lodhi, Natalie Larson, Amogh Dhamdhere, Constantine Dovrolis, kc claffy, Using PeeringDB to Understand the Peering Ecosystem, ACM SIGCOMM Computer Communication Review, 44(2), 20-27 (2014)]

FTC FCC NN MOU :: BEREC on NN :: Carpenter v USA :: RIF For Whom?

FTC, FCC Outline Agreement to Coordinate Online Consumer Protection Efforts Following Adoption of The Restoring Internet Freedom Order https://www.ftc.gov/news-events/press-releases/2017/12/ftc-fcc-outline-agreement-coordinate-online-consumer-protection

Chairman Smith letter to DHS requesting information regarding Kaspersky lab


BEREC to discuss Net Neutrality issues in light of the report presenting one year of implementation of Open internet Regulation and related BEREC Guidelines http://berec.europa.eu//eng/news_and_publications/whats_new/4702-berec-to-discuss-net-neutrality-issues-in-light-of-the-report-presenting-one-year-of-implementation-of-open-internet-regulation-and-related-berec-guidelines


Changing Privacy Laws in the Digital Age: Carpenter v. United States Col. S. Tech. L. R. http://stlr.org/2017/11/28/changing-privacy-laws-in-the-digital-age-carpenter-v-united-states/

Carpenter v. United States – What future for digital privacy? WJLTA https://wjlta.com/2017/11/17/carpenter-v-united-states-what-future-for-digital-privacy/

Michael Geist, Why Abandoning Net Neutrality in the U.S. Matters in Canada http://www.michaelgeist.ca/2017/11/abandoning-net-neutrality-u-s-matters-canada/


Friday, November 03, 2017

Sen. Comm. Comm. Hrg. Nov 7 :: Advancing IoT in Rural America

U.S. Sen. Roger Wicker (R-Miss.), chairman of the Subcommittee on Communications, Technology, Innovation, and the Internet, will convene a hearing titled "Advancing the Internet of Things in Rural America," at 10:00 a.m. on Tuesday, November 7, 2017. The hearing will examine the use and benefits of the Internet of Things (IoT) in rural communities, and the infrastructure needs necessary to advance the IoT market to ensure rural America has access to products and devices that are driving the digital economy.

Witnesses:

  • Mr. Michael Adcock, Executive Director, Telehealth Center University of Mississippi Medical Center, Jackson, Miss.
  • Mr. David Armitage, Founder and CEO of Cartasite, Denver, Colo.
  • Mr. Timothy Hassinger, President and CEO, Lindsay Corporation, Omaha, Neb.
  • Mr. Michael Terzich, Chief Administrative Officer, Zebra Technologies, Lincolnshire, Ill.

Hearing Details:

Tuesday, November 7, 2017
10:00 a.m.
Subcommittee on Communications, Technology, Innovation, and the Internet

 

This hearing will take place in Russell Senate Office Building, Room 253. Witness testimony, opening statements, and a live video of the hearing will be available on www.commerce.senate.gov.

Thursday, November 02, 2017

1988, Nov. 2 :: 25th Anniversary of the Morris Worm

"In the fall of 1988, Morris was a first-year graduate student in Cornell University's computer science Ph.D. program. Through undergraduate work at Harvard and in various jobs he had acquired significant computer experience and expertise. When Morris entered Cornell, he was given an account on the computer at the Computer Science Division. This account gave him explicit authorization to use computers at Cornell. Morris engaged in various discussions with fellow graduate students about the security of computer networks and his ability to penetrate it.

Disc containing Morris Code
at Museum of Science
"In October 1988, Morris began work on a computer program, later known as the Internet "worm" or "virus." The goal of this program was to demonstrate the inadequacies of current security measures on computer networks by exploiting the security defects that Morris had discovered. The tactic he selected was release of a worm into network computers. Morris designed the program to spread across a national network of computers after being inserted at one computer location connected to the network. Morris released the worm into Internet, which is a group of national networks that connect university, governmental, and military computers around the country. The network permits communication and transfer of information between computers on the network.

"Morris sought to program the Internet worm to spread widely without drawing attention to itself. The worm was supposed to occupy little computer operation time, and thus not interfere with normal use of the computers. Morris programmed the worm to make it difficult to detect and read, so that other programmers would not be able to "kill" the worm easily. Morris also wanted to ensure that the worm did not copy itself onto a computer that already had a copy. Multiple copies of the worm on a computer would make the worm easier to detect and would bog down the system and ultimately cause the computer to crash. Therefore, Morris designed the worm to "ask" each computer whether it already had a copy of the worm. If it responded "no," then the worm would copy onto the computer; if it responded "yes," the worm would not duplicate. However, Morris was concerned that other programmers could kill the worm by programming their own computers to falsely respond "yes" to the question. To circumvent this protection, Morris programmed the worm to duplicate itself every seventh time it received a "yes" response. As it turned out, Morris underestimated the number of times a computer would be asked the question, and his one-out-of-seven ratio resulted in far more copying than he had anticipated. The worm was also designed so that it would be killed when a computer was shut down, an event that typically occurs once every week or two. This would have prevented the worm from accumulating on one computer, had Morris correctly estimated the likely rate of reinfection.

"Morris identified four ways in which the worm could break into computers on the network: (1) through a "hole" or "bug" (an error) in SEND MAIL, a computer program that transfers and receives electronic mail on a computer; (2) through a bug in the "finger demon" program, a program that permits a person to obtain limited information about the users of another computer; (3) through the "trusted hosts" feature, which permits a user with certain privileges on one computer to have equivalent privileges on another computer without using a password; and (4) through a program of password guessing, whereby various combinations of letters are tried out in rapid sequence in the hope that one will be an authorized user's password, which is entered to permit whatever level of activity that user is authorized to perform.

"On November 2, 1988, Morris released the worm from a computer at the Massachusetts Institute of Technology. MIT was selected to disguise the fact that the worm came from Morris at Cornell. Morris soon discovered that the worm was replicating and reinfecting machines at a much faster rate than he had anticipated. Ultimately, many machines at locations around the country either crashed or became "catatonic." When Morris realized what was happening, he contacted a friend at Harvard to discuss a solution. Eventually, they sent an anonymous message from Harvard over the network, instructing programmers how to kill the worm and prevent reinfection. However, because the network route was clogged, this message did not get through until it was too late. Computers were affected at numerous installations, including leading universities, military sites, and medical research facilities. The estimated cost of dealing with the worm at each installation ranged from $200 to more than $53,000.

"Morris was found guilty, following a jury trial, of violating 18 U.S.C. Section 1030(a)(5)(A). He was sentenced to three years of probation, 400 hours of community service, a fine of $10,050, and the costs of his supervision."

- U.S. v. Morris, 928 F.2d 504 (2nd Cir. 1991)

Postlude 

The Morris Worm also resulted in the creation of multiple new federal projects such as CERT with the mission of researching, thwarting, and alerting the network to new possible threats.  

Robert Morris is reportedly a professor at MIT.