asciidoctor-rfc 0.9.0 → 0.9.1

data/spec/examples/rfc1149.md.2.xml.txt

@@ -0,0 +1,168 @@
+
+
+
+
+Network Working Group                                        D. Waitzman
+Internet-Draft                                                   BBN STC
+Intended status: Informational                             April 1, 1990
+Expires: October 3, 1990
+
+
+   A Standard for the Transmission of IP Datagrams on Avian Carriers
+                                rfc-1149
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on October 3, 1990.
+
+Copyright Notice
+
+   Copyright (c) 1990 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+Waitzman                 Expires October 3, 1990                [Page 1]
+
+Internet-Draft       IP Datagrams on Avian Carriers           April 1990
+
+
+Table of Contents
+
+   1.  Overview and Rational . . . . . . . . . . . . . . . . . . . .   2
+   2.  Frame Format  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   2
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   3
+
+1.  Overview and Rational
+
+   Avian carriers can provide high delay, low throughput, and low
+   altitude service.  The connection topology is limited to a single
+   point-to-point path for each carrier, used with standard carriers,
+   but many carriers can be used without significant interference with
+   each other, outside of early spring.  This is because of the 3D ether
+   space available to the carriers, in contrast to the 1D ether used by
+   IEEE802.3.  The carriers have an intrinsic collision avoidance
+   system, which increases availability.  Unlike some network
+   technologies, such as packet radio, communication is not limited to
+   line-of-sight distance.  Connection oriented service is available in
+   some cities, usually based upon a central hub topology.
+
+2.  Frame Format
+
+   The IP datagram is printed, on a small scroll of paper, in
+   hexadecimal, with each octet separated by whitestuff and blackstuff.
+   The scroll of paper is wrapped around one leg of the avian carrier.
+   A band of duct tape is used to secure the datagram's edges.  The
+   bandwidth is limited to the leg length.  The MTU is variable, and
+   paradoxically, generally increases with increased carrier age.  A
+   typical MTU is 256 milligrams.  Some datagram padding may be needed.
+
+   Upon receipt, the duct tape is removed and the paper copy of the
+   datagram is optically scanned into a electronically transmittable
+   form.
+
+3.  Discussion
+
+   Multiple types of service can be provided with a prioritized pecking
+   order.  An additional property is built-in worm detection and
+   eradication.  Because IP only guarantees best effort delivery, loss
+   of a carrier can be tolerated.  With time, the carriers are self-
+   regenerating.  While broadcasting is not specified, storms can cause
+   data loss.  There is persistent delivery retry, until the carrier
+   drops.  Audit trails are automatically generated, and can often be
+   found on logs and cable trays.
+
+
+
+
+
+Waitzman                 Expires October 3, 1990                [Page 2]
+
+Internet-Draft       IP Datagrams on Avian Carriers           April 1990
+
+
+4.  Security Considerations
+
+   Security is not generally a problem in normal operation, but special
+   measures must be taken (such as data encryption) when avian carriers
+   are used in a tactical environment.
+
+Author's Address
+
+   David Waitzman
+   BBN STC
+   10 Moulton Street
+   Cambridge  MA 02238
+
+   Phone: (617) 873-4323
+   Email: dwaitzman@BBN.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Waitzman                 Expires October 3, 1990                [Page 3]

data/spec/examples/rfc2100.md.2.xml.txt

@@ -0,0 +1,168 @@
+
+
+
+
+Network Working Group                                        J. Ashworth
+Internet-Draft                                     Ashworth & Associates
+Intended status: Informational                             April 1, 1997
+Expires: October 3, 1997
+
+
+                          The Naming of Hosts
+                                rfc-2100
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on October 3, 1997.
+
+Copyright Notice
+
+   Copyright (c) 1997 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+1.  Introduction
+
+   This RFC is a commentary on the difficulty of deciding upon an
+   acceptably distinctive hostname for one's computer, a problem which
+   grows in direct proportion to the logarithmically increasing size of
+   the Internet.
+
+
+
+
+Ashworth                 Expires October 3, 1997                [Page 1]
+
+Internet-Draft             The Naming of Hosts                April 1997
+
+
+   Distribution of this memo is unlimited.
+
+   Except to TS Eliot.
+
+   And, for that matter, to David Addison, who hates iambic pentameter.
+
+2.  Poetry
+
+   The Naming of Hosts is a difficult matter,
+       It isn't just one of your holiday games;
+   You may think at first I'm as mad as a hatter
+       When I tell you, a host must have THREE DIFFERENT NAMES.
+
+   First of all, there's the name that the users use daily,
+       Such as venus, athena, and cisco, and ames,
+   Such as titan or sirius, hobbes or europa--
+       All of them sensible everyday names.
+
+   There are fancier names if you think they sound sweeter,
+       Some for the web pages, some for the flames:
+   Such as mercury, phoenix, orion, and charon--
+       But all of them sensible everyday names.
+
+   But I tell you, a host needs a name that's particular,
+       A name that's peculiar, and more dignified,
+   Else how can it keep its home page perpendicular,
+       And spread out its data, send pages world wide?
+
+   Of names of this kind, I can give you a quorum,
+       Like lothlorien, pothole, or kobyashi-maru,
+   Such as pearly-gates.vatican, or else diplomatic-
+       Names that never belong to more than one host.
+
+   But above and beyond there's still one name left over,
+       And that is the name that you never will guess;
+   The name that no human research can discover--
+       But THE NAMESERVER KNOWS, and will us'ually confess.
+
+   When you notice a client in rapt meditation,
+       The reason, I tell you, is always the same:
+   The code is engaged in a deep consultation
+       On the address, the address, the address of its name:
+
+
+
+
+
+
+
+
+
+Ashworth                 Expires October 3, 1997                [Page 2]
+
+Internet-Draft             The Naming of Hosts                April 1997
+
+
+               It's ineffable,
+               effable,
+               Effanineffable,
+               Deep and inscrutable,
+               singular
+               Name.
+
+3.  Credits
+
+   Thanks to Don Libes, Mark Lottor, and a host of twisted
+   individuals^W^Wcreative sysadmins for providing source material for
+   this memo, to Andrew Lloyd-Webber, Cameron Mackintosh, and a cast of
+   thousands (particularly including Terrance Mann) who drew my
+   attention to the necessity, and of course, to Thomas Stearns Eliot,
+   for making this all necessary.
+
+4.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+   Particularly the cardiac security of certain famous poets.
+
+5.  Informative References
+
+   [1]        Libes, D., "Choosing a Name for Your Computer",
+              Communications of the ACM Vol. 32, No. 11, Pg. 1289,
+              November 1989.
+
+   [2]        Lottor, M., "Domain Name Survey", January 1997,
+              <namedroppers@internic.net>.
+
+   [3]        Stearns, TS., "Old Possum's Book of Practical Cats".
+
+   [4]        Wong, M., "Cool Hostnames",
+              <http://www.seas.upenn.edu/~mengwong/coolhosts.html>.
+
+Author's Address
+
+   Jay R. Ashworth
+   Advanced Technology Consulting
+   St. Petersburg  FL 33709-4819
+
+   Phone: +1 813 790 7592
+   Email: jra@scfn.thpl.lib.fl.us
+
+
+
+
+
+
+
+Ashworth                 Expires October 3, 1997                [Page 3]

data/spec/examples/rfc3514.md.2.xml.txt

@@ -0,0 +1,336 @@
+
+
+
+
+Network Working Group                                        S. Bellovin
+Internet-Draft                                        AT&T Labs Research
+Intended status: Informational                             April 1, 2003
+Expires: October 3, 2003
+
+
+                  The Security Flag in the IPv4 Header
+                                rfc-3514
+
+Abstract
+
+   Firewalls, packet filters, intrusion detection systems, and the like
+   often have difficulty distinguishing between packets that have
+   malicious intent and those that are merely unusual.  We define a
+   security flag in the IPv4 header as a means of distinguishing the two
+   cases.
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on October 3, 2003.
+
+Copyright Notice
+
+   Copyright (c) 2003 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Bellovin                 Expires October 3, 2003                [Page 1]
+
+Internet-Draft    The Security Flag in the IPv4 Header        April 2003
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
+   3.  Setting the Evil Bit  . . . . . . . . . . . . . . . . . . . .   3
+   4.  Processing of the Evil Bit  . . . . . . . . . . . . . . . . .   4
+   5.  Related Work  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
+   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6
+
+1.  Introduction
+
+   Firewalls [CBR03], packet filters, intrusion detection systems, and
+   the like often have difficulty distinguishing between packets that
+   have malicious intent and those that are merely unusual.  The problem
+   is that making such determinations is hard.  To solve this problem,
+   we define a security flag, known as the "evil" bit, in the IPv4
+   [RFC0791] header.  Benign packets have this bit set to 0; those that
+   are used for an attack will have the bit set to 1.
+
+1.1.  Terminology
+
+   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
+   document, are to be interpreted as described in [RFC2119].
+
+2.  Syntax
+
+   The high-order bit of the IP fragment offset field is the only unused
+   bit in the IP header.  Accordingly, the selection of the bit position
+   is not left to IANA.
+
+   The bit field is laid out as follows:
+
+        0
+       +-+
+       |E|
+       +-+
+
+   Currently-assigned values are defined as follows:
+
+   0x0:
+      If the bit is set to 0, the packet has no evil intent.  Hosts,
+      network elements, etc., SHOULD assume that the packet is harmless,
+      and SHOULD NOT take any defensive measures.  (We note that this
+
+
+
+Bellovin                 Expires October 3, 2003                [Page 2]
+
+Internet-Draft    The Security Flag in the IPv4 Header        April 2003
+
+
+      part of the spec is already implemented by many common desktop
+      operating systems.)
+
+   0x1:
+      If the bit is set to 1, the packet has evil intent.  Secure
+      systems SHOULD try to defend themselves against such packets.
+      Insecure systems MAY chose to crash, be penetrated, etc.
+
+3.  Setting the Evil Bit
+
+   There are a number of ways in which the evil bit may be set.  Attack
+   applications may use a suitable API to request that it be set.
+   Systems that do not have other mechanisms MUST provide such an API;
+   attack programs MUST use it.
+
+   Multi-level insecure operating systems may have special levels for
+   attack programs; the evil bit MUST be set by default on packets
+   emanating from programs running at such levels.  However, the system
+   _MAY_ provide an API to allow it to be cleared for non-malicious
+   activity by users who normally engage in attack behavior.
+
+   Fragments that by themselves are dangerous MUST have the evil bit
+   set.  If a packet with the evil bit set is fragmented by an
+   intermediate router and the fragments themselves are not dangerous,
+   the evil bit MUST be cleared in the fragments, and MUST be turned
+   back on in the reassembled packet.
+
+   Intermediate systems are sometimes used to launder attack
+   connections.  Packets to such systems that are intended to be relayed
+   to a target SHOULD have the evil bit set.
+
+   Some applications hand-craft their own packets.  If these packets are
+   part of an attack, the application MUST set the evil bit by itself.
+
+   In networks protected by firewalls, it is axiomatic that all
+   attackers are on the outside of the firewall.  Therefore, hosts
+   inside the firewall MUST NOT set the evil bit on any packets.
+
+   Because NAT [RFC3022] boxes modify packets, they SHOULD set the evil
+   bit on such packets.  "Transparent" http and email proxies SHOULD set
+   the evil bit on their reply packets to the innocent client host.
+
+   Some hosts scan other hosts in a fashion that can alert intrusion
+   detection systems.  If the scanning is part of a benign research
+   project, the evil bit MUST NOT be set.  If the scanning per se is
+   innocent, but the ultimate intent is evil and the destination site
+   has such an intrusion detection system, the evil bit SHOULD be set.
+
+
+
+
+Bellovin                 Expires October 3, 2003                [Page 3]
+
+Internet-Draft    The Security Flag in the IPv4 Header        April 2003
+
+
+4.  Processing of the Evil Bit
+
+   Devices such as firewalls MUST drop all inbound packets that have the
+   evil bit set.  Packets with the evil bit off MUST NOT be dropped.
+   Dropped packets SHOULD be noted in the appropriate MIB variable.
+
+   Intrusion detection systems (IDSs) have a harder problem.  Because of
+   their known propensity for false negatives and false positives, IDSs
+   MUST apply a probabilistic correction factor when evaluating the evil
+   bit.  If the evil bit is set, a suitable random number generator
+   [RFC1750] must be consulted to determine if the attempt should be
+   logged.  Similarly, if the bit is off, another random number
+   generator must be consulted to determine if it should be logged
+   despite the setting.
+
+   The default probabilities for these tests depends on the type of IDS.
+   Thus, a signature-based IDS would have a low false positive value but
+   a high false negative value.  A suitable administrative interface
+   MUST be provided to permit operators to reset these values.
+
+   Routers that are not intended as as security devices SHOULD NOT
+   examine this bit.  This will allow them to pass packets at higher
+   speeds.
+
+   As outlined earlier, host processing of evil packets is operating-
+   system dependent; however, all hosts MUST react appropriately
+   according to their nature.
+
+5.  Related Work
+
+   Although this document only defines the IPv4 evil bit, there are
+   complementary mechanisms for other forms of evil.  We sketch some of
+   those here.
+
+   For IPv6 [RFC2460], evilness is conveyed by two options.  The first,
+   a hop-by-hop option, is used for packets that damage the network,
+   such as DDoS packets.  The second, an end-to-end option, is for
+   packets intended to damage destination hosts.  In either case, the
+   option contains a 128-bit strength indicator, which says how evil the
+   packet is, and a 128-bit type code that describes the particular type
+   of attack intended.
+
+   Some link layers, notably those based on optical switching, may
+   bypass routers (and hence firewalls) entirely.  Accordingly, some
+   link-layer scheme MUST be used to denote evil.  This may involve evil
+   lambdas, evil polarizations, etc.
+
+   DDoS attack packets are denoted by a special diffserv code point.
+
+
+
+Bellovin                 Expires October 3, 2003                [Page 4]
+
+Internet-Draft    The Security Flag in the IPv4 Header        April 2003
+
+
+   An application/evil MIME type is defined for Web- or email-carried
+   mischief.  Other MIME types can be embedded inside of evil sections;
+   this permit easy encoding of word processing documents with macro
+   viruses, etc.
+
+6.  IANA Considerations
+
+   This document defines the behavior of security elements for the 0x0
+   and 0x1 values of this bit.  Behavior for other values of the bit may
+   be defined only by IETF consensus [RFC2434].
+
+7.  Security Considerations
+
+   Correct functioning of security mechanisms depend critically on the
+   evil bit being set properly.  If faulty components do not set the
+   evil bit to 1 when appropriate, firewalls will not be able to do
+   their jobs properly.  Similarly, if the bit is set to 1 when it
+   shouldn't be, a denial of service condition may occur.
+
+8.  Normative References
+
+   [CBR03]    Cheswick, W., Bellovin, S., and A. Rubin, "Firewalls and
+              Internet Security: Repelling the Wily Hacker, Second
+              Edition", Addison-Wesley , 2003.
+
+   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
+              DOI 10.17487/RFC0791, September 1981,
+              <https://www.rfc-editor.org/info/rfc791>.
+
+   [RFC1750]  Eastlake 3rd, D., Crocker, S., and J. Schiller,
+              "Randomness Recommendations for Security", RFC 1750,
+              DOI 10.17487/RFC1750, December 1994,
+              <https://www.rfc-editor.org/info/rfc1750>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", RFC 2434,
+              DOI 10.17487/RFC2434, October 1998,
+              <https://www.rfc-editor.org/info/rfc2434>.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
+              December 1998, <https://www.rfc-editor.org/info/rfc2460>.
+
+
+
+
+Bellovin                 Expires October 3, 2003                [Page 5]
+
+Internet-Draft    The Security Flag in the IPv4 Header        April 2003
+
+
+   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
+              Address Translator (Traditional NAT)", RFC 3022,
+              DOI 10.17487/RFC3022, January 2001,
+              <https://www.rfc-editor.org/info/rfc3022>.
+
+Author's Address
+
+   Steven M. Bellovin
+   AT&T Labs Research
+   180 Park Avenue
+   Florham Park  NJ 07932
+
+   Phone: +1 973-360-8656
+   Email: bellovin@acm.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellovin                 Expires October 3, 2003                [Page 6]