[AusNOG] RFC3514 The Security Flag in the IPv4 Header
James Spenceley
james at vocus.com.au
Wed Apr 7 20:41:01 EST 2010
It's not an April fool but i dug it out, i was bored that week (c.1999) ....
<to the tune, of Money for Nothing>
(... I want my ...)
(... I want my ...)
(... I want my BGP ... )
Now look at them packets, thats the way you do it.
You route your packets on the M A E.
That ain't working, private connects the way you do it.
Bandwidth for nothin' and your traffic error free.
Now that ain't working, you gotta pay dem RADB fee.
Lemm tell ya them guys ain't dumb.
Maybe get a blister on your typing fingure,
Maybe get dampened on your B G P.
We gotta install microwave uplinks.
Custom queue deliveries
We gotta config these new PVCs.
We gotta prepend our /23s.
See that little faggot with enable and the markup.
Yeah buddy thats his OC3.
That little faggot got his own IPO.
That little faggot's a paper millionarie.
We gotta install DSL circuits
Custom PVC deliveries
We got upgrade these DS3s
We got upgrade those IXPs
I shoulda learned to play with IP.
I shoulda learned more Layer 3.
Look at that MED, he got it down the wrong T3.
Man he can't ACK any TCP.
And he's up there, whats that, spoofed IPs ?
Bangin those circuits as hard as can be.
That ain't working, thats the way you do it.
Get you traffic for nothing via smart BGP.
We gotta install GigE cores
Custom WDM deliveries
We gotta move these T C Ps
We gotta move these U D Ps
Now look at them MAEs, thats the way to do it,
You rate-limit your ICMP.
That ain't working, thats the way we route it
Moving IP, gets you chicks you see.
CEO
Vocus Group Limited
Level 1, Vocus House
189 Miller Street
North Sydney, NSW 2060
(m) +61 407 496 866
(w) +61 2 8999 8999
On 07/04/2010, at 6:19 PM, David Hughes wrote:
>
> 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).
>
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20100407/5f15c868/attachment.html>
More information about the AusNOG
mailing list