One document matched: draft-fu-ipfix-network-security-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-fu-ipfix-network-security-00"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="IPFIX IEs for network security">IPFIX Information Elements
for inspecting network security issues</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Tianfu Fu" initials="T." surname="Fu">
<organization>Huawei</organization>
<address>
<postal>
<street>Q11, Huanbao Yuan, 156 Beiqing Road, Haidian
District</street>
<!-- Reorder these if your country does things differently -->
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>futianfu@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Dacheng Zhang" initials="D." surname="Zhang">
<organization>Huawei</organization>
<address>
<postal>
<street>Q14, Huanbao Yuan, 156 Beiqing Road, Haidian
District</street>
<!-- Reorder these if your country does things differently -->
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>zhangdacheng@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Danping He" initials="D." surname="He">
<organization>Huawei</organization>
<address>
<postal>
<street>Q14, Huanbao Yuan, 156 Beiqing Road, Haidian
District</street>
<!-- Reorder these if your country does things differently -->
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>ana.hedanping@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="25" month="October" year="2014"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>IPFIX Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>IPFIX protocol has been used to carry Information Elements, which are
defined to measure the traffic information and information related to
the traffic observation point, traffic metering process and the
exporting process. Network or device status are checked through
analysing neccessary observed information. Although most of the existing
Information Elements are useful for network security inspection, they
are still not sufficient to determine the reasons behind observed events
such as for DDOS attack, ICMP attack, and fragment attack. To allow
administrators making effective and quick response to the attacks, this
document extends the standard Information Elements and describes the
formats for inspecting network security.</t>
</abstract>
</front>
<middle>
<section title="Terminology">
<t>IPFIX-specific terminology (Information Element, Template, Template
Record, Options Template Record, Template Set, Collector, Exporter, Data
Record, etc.) used in this document is defined in Section 2 of
[RFC7011]. As in [RFC7011], these IPFIX-specific terms have the first
letter of a word capitalized.</t>
<t>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 <xref
target="RFC2119"/>.</t>
</section>
<section title="Introduction">
<t>As network security issues arising dramatically nowadays, network
administrators are eager to detect and identify attacks as early as
possible, generate countermeasurements with high agility. Due to the
enormous amount of network attack types, metrics useful for attack
detection are as diverse as attack patterns themselves. Moreover,
attacking methods are evolved rapidly, which brings challenges to
designing detect mechanism.</t>
<t>The IPFIX requirement [RFC3917] points out that one of the target
applications of IPFIX is atack and intrusion detection. The IPFIX
Protocol [RFC7011] defines a generic exchange mechanism for flow
information and events. It supports source-triggered exporting of
information due to the push model approach other than exporting upon
flow-end or fixed time intervals.The IPFIX Information Model [RFC5102]
defines a list of standard Information Elements (IEs) which can be
carried by the IPFIX protocol. Eventhough the existing standard IEs are
useful to check the status/events of the traffic, they are not
sufficient to help network administrators identify categories of the
attacks. The scanty information will result in an inaccurate analysis
and slowing down the effective response towards network attacks.</t>
<t>For instance, CC (Challenge Collapsar) attack is a typical
application layer DDoS attack, which mainly attacks the dynamic pages of
web server. It makes the web server's resources exhausted and paralyzed,
so the server will be denial of service. Because CC attacker imitates
normal users' behavior pretty well by using different real IP addresses
with relatively completive access process (even with low speed), it
makes the attack concealed well compared with traditional network layer
DDoS (e.g. SYN-Flood, etc). In addition, the attacker often manipulates
the attack behind the scenes by non-direct communicate with target
server, so the attack is not easy to be tracked and discovered. It would
be useful to collect application status information for application
layer attacks. In this case, CC attack is likely to happen if a large
number of non 2XX HTTP status code replied from the server are
observed.</t>
<t>Fragment attack employs unexpected formats of fragmentation, which
will result in errors such as fragmentation buffer full, fragment
overlapped, fragment incomplete. Existing IPFIX fragmentation metrics
includes fragmentOffset, fragmentIdentification, fragmentFlags, which
only indicate the attributes of a single fragment, and are not suitable
for attack detection. Integrated measurements are needed to provide an
holistic review of the session. Furthermore ICMP flow model has features
such as the ICMP Echo/Echo Reply dominate the whole traffic flow, ICMP
packet interval is usually not too short (normally 1 pkt/s). The current
ICMP information elements of IPFIX contains the ICMP type and code for
both IPv4 and IPv6, however they are for a single ICMP packet rather
than statistical property of the ICMP session. Further metrics like the
cumulated sum of various counters should be calculated based on sampling
method defined by the Packet SAMPling (PSAMP) protocol [RFC 5477].
Similar problems occur in TCP, UDP, SNMP and DNS attack, it would be
useful to derive the number of the upstream and downstream packets
separately and over time in order to detect the anomalies of the
network.</t>
<t>Upon the above discussions and per IPFIX applicability [RFC 5472],
derived metrics are useful to provide sufficient evidence about security
incident. A wisely chosen sets of derived metrics will allow direct
exporting with minimal resource consumption. This document extends the
IPFIX Information model and defines Information Elements (IEs) that
SHOULD be used to identify different attack categories, the
standardization of those IEs will improve the network security and will
support the offline analysis of data from different operators in the
future.</t>
</section>
<section title="Information Elements and use cases">
<t>This section presents the information elements that are useful for
attack detection, the IPFIX templates could contain a subset of the
Information Elements(IEs) shown in Table 1 depending upon the attack
under concern of the network administrator. For example a session
creation template contains</t>
<t>{sourceIPv4Address, destinationIpv4Address, sourceTransportPort,
destinationTransportPort, protocolIdentifier, pktUpstreamCount,
pktDownstreamCount, selectorAlgorithm, samplingPacketInterval,
samplingPacketSpace}</t>
<t>An example of the actual event data record is shown below in a
readable form</t>
<t>{192.168.0.201, 192.168.0.1, 51132, 80, 7, 67, 87, 3, 100,1000}</t>
<section title="Information Elements">
<t>The following is the table of all the IEs that a device would need
to export for attack statistic analysis. The formats of the IEs and
the IPFIX IDs are listed below. Most of the IEs are defined in
[IPFIX-IANA], while some of the IPFIX IE's ID are not assigned yet,
and hence the detailed explanation of these fields are presented in
the following sections. The recommended registrations to IANA is
described the IANA considerations section.</t>
<texttable anchor="InformationElementtable"
title="Information Element table">
<ttcol align="left" width="43%">Field Name</ttcol>
<ttcol align="left" width="9%">Size (bits)</ttcol>
<ttcol align="left" width="9%">IANA IPFIX ID</ttcol>
<ttcol align="left" width="10%">Description</ttcol>
<c>sourceIPv4Address</c>
<c>32</c>
<c>8</c>
<c>Source IPv4 Address</c>
<c>destinationIPv4Address</c>
<c>32</c>
<c>12</c>
<c>Destination IPv4 Address</c>
<c>sourceTransportPort</c>
<c>16</c>
<c>7</c>
<c>Source Port</c>
<c>destinationTransportPort</c>
<c>16</c>
<c>11</c>
<c>Destination port</c>
<c>protocolIdentifier</c>
<c>8</c>
<c>4</c>
<c>Transport protocol</c>
<c>packetDeltaCount</c>
<c>64</c>
<c>2</c>
<c>The number of incoming packets since the previous report (if any)
for this Flow at the Observation Point</c>
<c>pktUpstreamCount</c>
<c>32</c>
<c>TBD</c>
<c>Upstream packet counter</c>
<c>pktDownstreamCount</c>
<c>32</c>
<c>TBD</c>
<c>Downstream packet counter</c>
<c>octetUpstreamCount</c>
<c>32</c>
<c>TBD</c>
<c>Upstream octet counter</c>
<c>octetDownstreamCount</c>
<c>32</c>
<c>TBD</c>
<c>Downstream octet counter</c>
<c>tcpSynTotalCount</c>
<c>64</c>
<c>218</c>
<c>The total number of packets of this Flow with TCP "Synchronize
sequence numbers" (SYN) flag set</c>
<c>tcpFinTotalCount</c>
<c>64</c>
<c>219</c>
<c>The total number of packets of this Flow with TCP "No more data
from sender" (FIN) flag set</c>
<c>tcpRstTotalCount</c>
<c>64</c>
<c>220</c>
<c>The total number of packets of this Flow with TCP "Reset the
connection" (RST) flag set.</c>
<c>tcpPshTotalCount</c>
<c>64</c>
<c>221</c>
<c>The total number of packets of this Flow with TCP "Push Function"
(PSH) flag set.</c>
<c>tcpAckTotalCount</c>
<c>64</c>
<c>222</c>
<c>The total number of packets of this Flow with TCP "Acknowledgment
field significant" (ACK) flag set.</c>
<c>tcpUrgTotalCount</c>
<c>64</c>
<c>223</c>
<c>The total number of packets of this Flow with TCP "Urgent Pointer
field significant" (URG) flag set.</c>
<c>tcpControlBits</c>
<c>8</c>
<c>6</c>
<c>TCP control bits observed for packets of this Flow</c>
<c>flowEndReason</c>
<c>8</c>
<c>136</c>
<c>The reason for Flow termination</c>
<c>minimumIpTotalLength</c>
<c>64</c>
<c>25</c>
<c>Length of the smallest packet observed for this Flow</c>
<c>maximumIpTotalLength</c>
<c>64</c>
<c>26</c>
<c>Length of the largest packet observed for this Flow</c>
<c>flowStartSeconds</c>
<c>32</c>
<c>150</c>
<c>The absolute timestamp of the first packet of this Flow</c>
<c>flowEndSeconds</c>
<c>32</c>
<c>151</c>
<c>The absolute timestamp of the last packet of this Flow</c>
<c>flowStartMilliseconds</c>
<c>32</c>
<c>152</c>
<c>The absolute timestamp of the first packet of this Flow</c>
<c>flowEndMilliseconds</c>
<c>32</c>
<c>153</c>
<c>The absolute timestamp of the last packet of this Flow</c>
<c>flowStartMicroseconds</c>
<c>32</c>
<c>154</c>
<c>The absolute timestamp of the first packet of this Flow</c>
<c>flowEndMicroseconds</c>
<c>32</c>
<c>155</c>
<c>The absolute timestamp of the last packet of this Flow</c>
<c>applicationErrorCode</c>
<c>32</c>
<c>TBD</c>
<c>Application error</c>
<c>fragmentFlags</c>
<c>8</c>
<c>197</c>
<c>Fragmentation properties indicated by flags in the IPv4 packet
header or the IPv6 Fragment header, respectively</c>
<c>fragmentIncomplete</c>
<c>32</c>
<c>TBD</c>
<c>Fragment incomplete flag</c>
<c>fragmentFirstTooShort</c>
<c>32</c>
<c>TBD</c>
<c>First fragment too short flag</c>
<c>fragmentOffestError</c>
<c>32</c>
<c>TBD</c>
<c>Fragment offset error flag</c>
<c>fragmentFlagError</c>
<c>32</c>
<c>TBD</c>
<c>fragment flag error flag</c>
<c>icmpTypeIPv4</c>
<c>8</c>
<c>176</c>
<c>Type of the IPv4 ICMP message</c>
<c>icmpCodeIPv4</c>
<c>8</c>
<c>177</c>
<c>Code of the IPv4 ICMP message</c>
<c>icmpTypeIPv6</c>
<c>8</c>
<c>178</c>
<c>Type of the IPv6 ICMP message</c>
<c>icmpCodeIPv6</c>
<c>8</c>
<c>179</c>
<c>Code of the IPv6 ICMP message</c>
<c>icmpEchoCount</c>
<c>32</c>
<c>TBD</c>
<c>The number fo ICMP echo.</c>
<c>icmpEchoReplyCount</c>
<c>32</c>
<c>TBD</c>
<c>The number of ICMP echo reply.</c>
<c>selectorAlgorithm</c>
<c>16</c>
<c>304</c>
<c>This Information Element identifies the packet selection methods
(e.g., Filtering, Sampling) that are applied by the Selection
Process.</c>
<c>samplingPacketInterval</c>
<c>32</c>
<c>305</c>
<c>The number of packets that are consecutively sampled</c>
<c>samplingPacketSpace</c>
<c>32</c>
<c>306</c>
<c>The number of packets between two "samplingPacketInterval"s.</c>
</texttable>
</section>
<!-- End of section IEs above -->
<section title="Packet upstream/downstream counters">
<t>A sudden increase of Flow from different sources to one destination
may be caused by an attack on a specific host or network node using
spoofed addresses. However it may be cased by legitimate users who
seek access to a recently published web content. Only reporting the
total packet number is not sufficient to indicate whether attacks
occur, as it lacks details to separate good packets from abnormoal
packets. as a result, upstream and downstream packets should be
monitored seperately so that upstream to downstream packet number
ratio can be use to detect successful connections. pktUpstreamCount
and pktDownstreamCount are added to IPFIX to represent the cumulated
upstream and downstream packet number respectively.</t>
</section>
<section title="ICMP echo/echo reply counters">
<t>An unusual ratio of ICMP echo to ICMP echo reply packets can refer
to ICMP attack. However the existing set of IPFIX IEs provides the
type and code of ICMP packet, countinuously export the information
will result in serious resource consumption at the exporter, the
collector and the bandwith. The number of echo and echo reply packets
in a Flow can be derived for the Observation Domain in a specific time
interval or once the ratio exceeds threshold. The basic metrics
icmpEchoCount and icmpEchoReplyCount are defined as new IPFIX
Information Elements.</t>
</section>
<section title="Fragment statistic">
<t>Typical fragment attack includes fragmentation buffer full,
fragment overlapped, fragment incomplete. Existing IPFIX fragmentation
metrics includes fragmentIdentification,fragmentOffset, fragmentFlags,
which are not sufficient to identify errors, and are not suitable for
early attack detection. Integrated measurements are needed to provide
an holistic review of the flow. fragmentIncomplete checks the
integrity of the fragmentation ,fragmentFirstTooShort verifies the
format of the first fragment, fragmentOffestError checks the offset
error based on previous and current observation, and fragmentFlagError
detect early whether the fragmentation is caused by a malicious
attack.</t>
</section>
<section title="Application error code">
<t>The application layer attack requires IPFIX protocol capture packet
payload. An initial consideration of the application error code comes
from the HTTP status code except 2XX successful code. Other
application layer protocol error code are also supported. The error
code list can be expanded in the future as necessary. The data record
will have the corresponding error code value to identify the error
that is being logged.</t>
</section>
<section title="Extended value of FlowEndReason">
<t>There are 5 defined reasons for Flow termination, with values
ranging from 0x01 to 0x05:</t>
<t>0x01: idle timeout</t>
<t>0x02: active timeout</t>
<t>0x03: end of Flow detected</t>
<t>0x04: forced end</t>
<t>0x05: lack of resources</t>
<t>There is an additional reason caused by state machine anomaly. When
FIN/SYN is sent, but no ACK is replied after a waiting timeout, the
existing five reasons do not match this case.Therefore, a new value is
proposed to extend the FlowEndReason, which is 0x06: protocol
exception timeout.</t>
<t/>
</section>
<!--May consider to add template example for different attack observations named as Template for...-->
<!---->
<!-- End of section templates above -->
</section>
<!-- End of section Event based logging above -->
<section anchor="Encoding" title="Encoding">
<section title="IPFIX">
<t>This document uses IPFIX as the encoding mechanism to monitor
security events. However, the information that is logged SHOULD be the
same irrespective of what kind of encoding scheme is used. IPFIX is
chosen, because it is an IETF standard that meets all the needs for a
reliable logging mechanism and one of its targets are for security
applications. IPFIX provides the flexibility to the logging device to
define the data sets that it is logging. The IEs specified for logging
MUST be the same irrespective of the encoding mechanism used.</t>
</section>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>The following information elements are requested from IANA IPFIX
registry.</t>
<t>Name : pktUpstreamCount</t>
<t>Description: The number of the upstream packets for this Flow at the
Observation Point since the Metering Process (re-)initialization for
this Observation Point.</t>
<t>Abstract Data Type: unsigned32</t>
<t>Data Type Semantics: TBD</t>
<t>Name: pktDownstreamCount</t>
<t>Description: The number of the downstream packets for this Flow at
the Observation Point since the Metering Process (re-)initialization for
this Observation Point.</t>
<t>Abstract Data Type: unsigned32</t>
<t>Data Type Semantics: TBD</t>
<t>Name: octetUpstreamCount</t>
<t>Description: The total number of octets in upstream packets for this
Flow at the Observation Point since the Metering Process
(re-)initialization for this Observation Point. The number of octets
includes IP header(s) and IP payload.</t>
<t>Abstract Data Type: unsigned32</t>
<t>Data Type Semantics: TBD</t>
<t>Name : octetDownstreamCount</t>
<t>Description: The total number of octets in downstream packets for
this Flow at the Observation Point since the Metering Process
(re-)initialization for this Observation Point. The number of octets
includes IP header(s) and IP payload.</t>
<t>Abstract Data Type: unsigned32</t>
<t>Data Type Semantics: TBD</t>
<t>Name: applicationErrorCode</t>
<t>Description: This Information Element identifies the application
layer error code.</t>
<t>Abstract Data Type: unsigned32</t>
<t>Data Type Semantics: TBD</t>
<t>Name: fragmentIncomplete</t>
<t>Description: This Information Element specifies whether fragments of
the same flow is incomplete.</t>
<t>Abstract Data Type: unsigned32</t>
<t>Data Type Semantics: TBD</t>
<t>Name: fragmentFirstTooShort</t>
<t>Description: This Information Element indicates the first fragment of
a flow is too short.</t>
<t>Abstract Data Type: unsigned32</t>
<t>Data Type Semantics: TBD</t>
<t>Name: fragmentOffestError</t>
<t>Description: This Information Element specifies fragment offset error
(eg. overlapping or exceeds the maimum length).</t>
<t>Abstract Data Type: unsigned32</t>
<t>Data Type Semantics: TBD</t>
<t>Name: fragmentFlagError</t>
<t>Description: This Information Element specifies the error of fragment
flag.When the DF bit and MF bit of the fragment flag are set in the same
fragment, the fragmentFlagError is 1.</t>
<t>Abstract Data Type: unsigned32</t>
<t>Data Type Semantics: TBD</t>
<t>Name: icmpEchoCount</t>
<t>Description: This Information Element specifies he number of ICMP
echo.</t>
<t>Abstract Data Type: unsigned32</t>
<t>Data Type Semantics: TBD</t>
<t>Name: icmpEchoReplyCount</t>
<t>Description: This Information Element specifies the number of ICMP
echo reply.</t>
<t>Abstract Data Type: unsigned32</t>
<t>Data Type Semantics: TBD</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>No additional security considerations are introduced in this
document. The same security considerations as for the IPFIX protocol
[RFC7011] apply.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.3971.xml"?>
<?rfc include="reference.RFC.5102.xml"?>
<?rfc include="reference.RFC.5472.xml"?>
<?rfc include="reference.RFC.5477.xml"?>
<?rfc include="reference.RFC.7011.xml"?>
</references>
<references title="Informative References">
<reference anchor="IPFIX-IANA"
target="http://www.iana.org/assignments/ipfix">
<front>
<title>IPFIX Information Elements registry</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<!--
Here we use entities that we defined at the beginningI. -->
</references>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:46:41 |