[AusNOG] RFC3514 The Security Flag in the IPv4 Header

[David Hughes]

On 07/04/2010, at 5:39 PM, Narelle wrote:

> I think my all time favourite RFC has to be RFC 1925 The Twelve
> Networking Truths.


I still like the one below but clearly I am biased :)  It was knocked back as the joke RFC in 98 (I think) when we wrote it.  Much of the content was developed over beers around the roof-top pool at Apricot 98 in Manila.  Paul Ferguson couldn't help much as he was communicating by holding up signs as he'd lost his voice yelling in a pub the night before.  Oh, those were the days  (now I really sound old :)


David
...

								Patrik Faltstrom
								Tele2
								Paul Ferguson
								Cisco
								Steve Coya
								IETF Secretariat
								David Hughes
								Hughes Technologies


                Regional Beering Policy Internet-Draught

                      Beering Control Policy (BCP)


Introduction

Because of the increased interest in beering, there is a need of 
controlling the beering itself by internationally agreed rules. These 
rules are to make it easier for those truly implementing beering to get 
the throughput requested.

This paper defines a beering control policy (BCP) which is documenting 
the best current practice used at beering points when controlling 
throughput to receivers, as well as controlling the receiver's access 
to beering points in the first place.

Internationally, there might be some slight differences in policy used. 
For example, in some geographical areas, it is known that one request 
of packages means "bring one package and keep 'em coming", while in 
other areas the receiver have to request each package individually. The 
intention is that this policy will cover most of these localization 
issues. More details can be found in the section on 
internationalization.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119.

Beering Points

At the beering point the consumers requests beer. For this to happen, 
the consumer MUST have access to the same beering point as his beering 
partners. The beering point itself SHOULD use a policy for taking care 
of beering requests from consumers. The policy MUST be published using 
the http (Hop Transfer Transaction Protocol). To be able to fulfil 
requests from beering partners, the beering point MUST be a registrar 
for certain content types.

At a beering point, one can find various beering alliances. Parties at 
a beering point are NOT REQUIRED to beer with each other.

One can find the same content types at different beering points. This 
helps interoperability when the same beering partner start beering at 
more than one beering point as not all beering partners do accept all 
content types.


Settlements

The default settlement at a beering point MUST be free beering. That 
implies that each beering partner is carrying its own cost at the 
beering point, and they do not exchange payments between themselves. A 
beering partner MAY carry the cost for other partners - which because 
of that get free beering. This SHOULD be the case when partners have 
good cooperation regarding carrying the packages (including transit, 
see below).


Access to a beering point

A beering partner SHOULD be connected to a beering point at all times. 
To get effective beering, two or more partners MUST coexist at the same 
beering point at the same time. Access to a beering point is provided 
by transit of third parties. One such party is a Cab (Collaborative 
Access method for Beering points).

A beering point MUST provide beering for companies of a single partner. 
It is though not as interesting for the partner itself as beering 
between two or more parties. The beering point is though not the party 
to set such policies.

A beering point can be public or private. A public beering point is 
called a PUB (Public Unit for Beering).


Caching

If access to a beering point is troublesome, a partner MAY hold a local 
cache of packages at the home location. Such a cache is called a 
fridge. The packages SHOULD be preloaded into the cache in the case 
that such a media type is needed at a later stage. The cache can not be 
loaded on demand, but rather according to calculated needs. The 
packages are transported to the local cache in bursts of 1, 6, 8 or 24. 
Each such burst MAY be fragmented before the content of the package is 
inspected.


Packet size

To get efficient beering, mtu discovery SHOULD be used on the full path 
from one beering partner to another. Some beering partners does not 
handle the large 1024 ml packages, but only 576-ml packages. At some 
more strange beering points, packages with the size of 48 ml is in use 
-- which is extremely inefficient because of overhead in management not 
only between the beering partners, but also the beering point itself. 
To conclude, one can say that 48 ml is a bad, small size, 576 ml is 
better, and 1024 ml what one wants to use.


Frag^H^H^H^Hfermentation

The packages MAY be frag^H^H^H^Hfermented, fermentation is allowed, and 
each media type MAY have their own set of fermentation rules. What 
fermentation rule that has been used can be detected when inspecting 
the actual content of the packages.

While fermentation is allowed, fragmentation is considered harmful and 
MUST NOT be used, except when fragmenting a burst of more than one 
package. See above the section on caching.

There is a minimum mtu of 1 receptacle. An attempt to further fragment 
the packet below a unit of one minimum unit SHALL result is destructive 
fragmentation and a retransmission of the unit MUST occur before the 
expiration of a round. The party fragmenting MUST request 
retransmission of the round.


Streaming

At some beering points, the content of the packages get delivered using 
extremely large mtus (also called kegs). To fragment those large mtus 
into a container size that the peering partner can handle, a streaming 
protocol is used. The beering point MUST change delivery method from 
streaming to packagebased at a tap.


Throughput

The maximum throughput at a beering point can differ significantly 
between beering points. It also differs between beering partners -- but 
is upper bound by the administrative mechanisms at the beering point 
itself. The number of transactions that the beering point can handle 
limits the bandwidth.


Quality of the packet content

Different media types have different amount of hops. It is considered 
that the higher number of hops, the better. I.e. a large hop-count, the 
better

Each beering point is has it's own rules for MPDU (minimum/maximum 
packaging draught unit). The MPDU MAY be standardized in a geographical 
region. In the UK for example, the rules for MPDUs are stricter than in 
other countries.

Packet filtering MAY occur, but it is generally considered that 
filtering does not improve the quality of the packet content. Different 
media types require different methods, and amount of filtering. A 
beering partner MUST take into account when beering that filtering has 
occurred.

Some packet generators are known to produce SPAM - Socially Pervasive 
Anti Tasteful Media. Such media types are less frequent present at 
beering points, but more often at places from which the local cache is 
loaded. A partner SHOULD implement methods that filter out SPAM, or he 
may be the target for a denial of service attack, making him 
uninterested of high quality beering in the future.

The amount of head MAY vary between media types. It is also considered 
tradition for some media types at high quality beering points to have a 
firm, compact head. Such a head is achieved by using header 
compression. The goal is to be able to extract the content of the 
package without damaging the head.


Policy for a beering point

A beering point MUST give the ability for the beering partners to 
recycle the packet content, as a beering partner can not compress 
package content to an infinite amount. Some compression does happen -- 
when the partner has more ingress than egress.

Tunneling MAY be the only way to access resources at the tap when the 
beering point gets requests simultaneously. Tunneling is implemented by 
having one beering partner sending one request to the tap for all 
partners, instead of having all partners sending one request each. 
Tunneling of packages minimize the number of administrative 
transactions at the beering point, which according to discussion above 
increase the maximum amount of throughput. A beering point MUST allow 
tunneling (local transit) of packages.

The beering point MUST handle packet drop. When the buffers are close 
to full, the beering point SHOULD refuse to send more packages to avoid 
packet drop. The beering point MUST implement the random early drop 
method (RED), but other methods MAY be implemented.

The beering point MUST address collision avoidance when passing 
packages between beering partners. Collision leads to packet drop.

Beering stability/instability occurs when one disorderly beering 
partner can wreak havoc at either a public or private beering point. 
The beering point MUST use selective packet discard to ensure that 
control beers are not dropped, but that other beers may be dropped 
instead.


CIDR (Conservation of Inebriating Draft Receptacles)

There is currently an explosion of the number of small receptacles for 
holding draft beer. This is clearly a danger for public beering points 
(Pubs) that must contain all receptacles due to the fact that all 
receptacles use the same amount of shelf space. Obviously, a receptacle 
registrar MAY be implemented so it limits the allocation of these tiny 
receptacles, even at the expense of those partners who can only hold 
the small receptacles. If they can't hold a reasonable size receptacle, 
they shouldn't be at the pub in the first place. Consolidation of the 
beer space by large receptacle handlers as a natural consequence of 
this market. Renumbering into smaller receptacles is considered 
harmful, and SHOULD be avoided.

With respect to the establishment of receptacle registrars at the 
beering point, the use of a membership system would be the most 
effective. In order to obtain a receptacle, the beering point MUST both 
pay a yearly fee as well as document their need for packages in terms 
of engineering (how the package will be transferred into the 
receptacle) as well as deployment (how the package content will be 
taken care of). Simply wanting packages is insufficient -- if the 
registrars were to allocate receptacles to everyone who wanted them, 
there would clearly be insufficient receptacles for those who truly 
justify them.

The registries are aware of certain unfair situations with respect to 
historically allocated large receptacles.  However, recovery of used 
beer tends to be somewhat problematic -- very few individuals wish to 
make use of the recovered beer. Such efforts to reuse recovered beer 
SHALL be considered deviant. Even the use of filters will not be 
considered acceptable practice in such situations. Allocation of NEW 
beer is the only acceptable mode of operation.


Internationalization issues

Because no central registry exists for media types, the beering partner 
MUST be able to both identify and request the correct packet type at a 
beering point. This is increasingly harder when partners transit with 
global transit companies (airlines) to beering points not in the same 
cultural region as the partner normally act within. There is no 
standard on labeling of the packages to make it easier to exchange 
packages at a beering point, even though the beering point SHOULD have 
some common media types available to be able to fulfil foreign beering 
partners requests. At some beering points the packages are tagged with 
specific labels which makes exchange/switching of packages very 
efficient. A beering point SHOULD accept a partner leaving a credit 
card close to the tap. The card holds information the amount of 
packages the partner can receive.

Cultural differences not only make it hard to understand the labels of 
the packages, but also the communication at the beering point is 
difficult. A beering point SHOULD have adequate information for foreign 
partners, and MAY even be able to handle generic payments (greenbacks) 
for packages received.


Operational considerations

A beering partner MAY drop packages when the input buffers are full. 
Other partners at the same beering point can at that moment start 
hostile denial of service attacks to the poor partner, especially by 
the use of Socially Pervasive Anti Tasteful Media (SPAM). The service 
provider at the beering point SHOULD in those cases help the beering 
party to get in contact with a transit company (CAB) to be able to go 
back to its home.

A beering point MUST keep track of the amount of uncleared transactions 
with each beering partner -- as the beering partner might request more 
packages than he can pay for according to the settlement agreement 
between the beering partners and the service provider at the beering 
point.


Security Considerations

qANQR1DBwE4DUBKHZ1nrCuUQA/9ygLThUenLxqU+hLgfpJ2CkhJCk2pdX5c9WxzI
iyKNwJOdbSnk2tqHul1D+xFn9aFRdnVr68htkdepXlHWanFSVzdViDBDae4i8PEW
0b9zCcAq/P2WNvvToixnYLtOFjC/I0HIsewr9EWsJncd7zZUidrc2RS7CDxrmX31
dnQhQAP7BPz3YFbQ+bRJJG3Y8DzzJOZT4iKYU0TRcoKodbPyih+LTMX4PJ1IoQlE
V9NLqouazCrT4lW2q8NSWZFsuaZigPrBksObUqmhk1s3ED9sbHdd9Tgq46XtQAEh
ZPPH9gmb5On6teAuiKQ/nBeZLIEMrDM2x86RGYE/AyMqQB98wL7JwNyek1+G8a6a
ooNgzD3oWlYpo+w4E9uM6CMKgWrQzaVWiSSUBa1BfgfbUowlRDPpKvuEh6IICcUi
En313Cf1WZmzJ9jN+X97GBVXzluao10z9bCQNjv3ucD7/rMTvvU/BAQS/N0WnAdG
mh/WkRkDW0YER1+dgKPFBwNuLiHGTDOPLsgupRKDCgSJUhwt/2vBg+Uhfcnj0If9
oXK+QF5AGx/QT/rAQGBrbL8M3LxmS0MEPxjeoiOb8zhwH6gA4hX7kEw64gP1tbMe
bBQQBJSZ4Q/7scofxGaJEzq0nRaHxjMqBZXNvEZSqiSMAuWjx8ybKBczjS4W4Sam
NR21zftf8gwRdb5N1czAnEfcWryk5RuqPMUy8G+wXLRiDEQfgn6pkE9XtdnP1Fju
wcL5I00rQs7Yqmckv7KB50/BKwi6XxEsoG96BIx1nRAu7vPT45oXpHN0YqEEkmf2
fGPZlXfPJfSt8zLMPn366E7j5c0vZExgHt/XwIZjZoJ4OzaENiKdF0J2S3FKjXli
O2MVYxsX1XeZjpuiB9rfJ3ds9Rei
=eFHS


Acknowledgements:

The editors thank Samuel Adams, Bud Weiser, Hein E. Ken, C. O. Rona, 
Vic Bitter, Ann Hizer-Bush and Gordon Birch for valuable input during 
the developmen of this draught.


Authors Addresses

    Patrik Faltstrom
    Tele2
    Email: paf at swip.net

    Paul Ferguson
    Cisco
    Email: paul at cisco.com

    Steve Coya
    IETF Secretariat
    Email: scoya at ietf.org

    David Hughes
    Hughes Technologies
    Email: bambi at hughes.com.au


Appendix A -- Common used protocols in a PUB

BGP -- Beering Gathering Protocol -- The protocol used to exchange 
information at a beering point between beering parties according to 
earlier settlements.

LDAP: Light Draught Access Protocol used to lookup structured metadata 
about the various package types available in the world. It has nothing 
to do with beering points directly, but can be used by a beering point 
to give information to potential beering partners. One problem for 
global deployment of LDAP is though that we have no global naming 
schemes for packet types. Information on what distinguished names exist 
of packet types is exchanged between beering parties at a beering point.

SNMP: Shout and Nod Message Passing is used to monitor the amount of 
hops in each tap, and can also be used by the service provider at the 
beering point to check the available space in the buffers, to avoid 
buffer overflow and packet drop.

HTTP: Hop Transfer Transaction Protocol, is used by beering parties to 
check at the beering point information of the various taps available, 
i.e. also called the menu

DHCP: Dynamic Hangout Callee Protocol, used when communicating with 
companies handling transit to beering points -- CAB (a Collaborative 
Access method to Beering points). Normally a native language is used in 
this protocol, which means that local variants of DHCP do exist, which 
unfortunately makes it difficult in some places to come to the beering 
point you want.

OSPF: Open Shortest Path First: Locate closest watering hole for 
initial ingestion.

DNS: Draught Name Selection: Is used to select media type at the 
beering point. Specification of point of origination should use 
ISO-3166 country codes.

TIP: Preallocation of TIP may guarantee higher QOS (Quality Of Service).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20100407/00d4fce6/attachment.html>