One document matched: draft-jennings-behave-rtcweb-firewall-01.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.26 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-jennings-behave-rtcweb-firewall-01" category="info">

  <front>
    <title abbrev="WebRTC Firewall">Firewall Traversal for WebRTC</title>

    <author initials="P." surname="Patel" fullname="Pradeep Patel">
      <organization>Cisco</organization>
      <address>
        <email>pradpate@cisco.com</email>
      </address>
    </author>
    <author initials="C." surname="Jennings" fullname="Cullen Jennings">
      <organization>Cisco</organization>
      <address>
        <email>fluffy@iii.ca</email>
      </address>
    </author>
    <author initials="S." surname="Nandakumar" fullname="Suhas Nandakumar">
      <organization>Cisco</organization>
      <address>
        <email>snandaku@cisco.com</email>
      </address>
    </author>
    <author initials="J." surname="Rosenberg" fullname="Jonathan Rosenberg">
      <organization>Cisco</organization>
      <address>
        <email>jdrosen@cisco.com</email>
      </address>
    </author>
    <author initials="D." surname="Wing" fullname="Dan Wing">
      <organization>Cisco</organization>
      <address>
        <email>dwing@cisco.com</email>
      </address>
    </author>

    <date year="2015" month="July" day="20"/>

    <area>Art</area>
    <workgroup>rtcweb</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>Traversal of RTP through corporate firewalls has traditionally been
complex, requiring the deployment of Session Border Controllers (SBCs)
or wide open pinholes. This draft proposes a simple technique that
allows WebRTC based RTP traffic to traverse firewalls without complex
firewall configuration and without deployment of SBCs or other
middleboxes.</t>



    </abstract>


  </front>

  <middle>


<section anchor="problem-statement" title="Problem Statement">

<t>WebRTC <xref target="I-D.ietf-rtcweb-overview"/> based voice and video
communications systems are becoming far more common inside
enterprises, which often need voice and video media to traverse the
enterprise firewall. This can happen when a device inside the firewall
such as a web browser or phone is exchanging media with a conference
bridge or gateway outside the firewall, or it can happen when a device
inside the firewall is talking to a device in another enterprise or
behind a different firewall.</t>

<t>This problem is not unique to WebRTC media of course. It is common
practice for enterprise administrators to block outbound UDP through
the corporate firewall. This is done for several reasons:</t>

<t><list style="numbers">
  <t>The lack of any kind of return messages means that there is no way
to know that the recipient of the UDP traffic really wants
it. Infected computers within the enterprise could utilize UDP as the
source of a DDoS attack. If the firewall permitted such outbound
traffic, the enterprise could in effect be a contributing source to
such an attack. By blocking UDP, the enterprise IT admin ensures that
this cannot happen - at least not to external targets.</t>
  <t>There have been prior attacks that have utilized UDP as a command
and control channel for orchestrating DDoS attacks. At the time, UDP
had little usage within enterprises (most VoIP was internal to the
enterprise when it existed at all). Consequently, infosec departments
have deemed it safer to block UDP outright in order to prevent such
further incidents.</t>
  <t>Many IT administrators enable various packet inspection operations
on traffic flowing through the firewall. High volume UDP traffic -
such as voice or video - can be costly to inspect. As such, in cases
where there is a need for traversal of such traffic, IT has preferred
to deploy an SBC that, in essence, verifies that the traffic is VoIP
and authorizes its egress. The IT administrator then enables traffic
to/from the SBC through the firewall. In other words, VoIP
authorization is delegated to an outsourced SBC.</t>
</list></t>

<t>As more and more IP communications services move to the cloud, there
is an increased need for VoIP traffic to traverse the enterprise
firewall. At the same time, the entire point of a cloud service is
that it does not require the deployment of on premises infrastructure,
making SBC-based solutions less desirable. An alternative solution
that has been historically used is to enable outbound UDP in the
firewall to specific IP addresses, corresponding to the external
service (TURN servers or conference servers) that the enterprise
wishes to authorize. With more applications running on virtual
machines within cloud compute platforms like Amazon EC2, IP addresses
are decreasingly usable as identifiers for a service. VMs running TURN
servers or conferencing servers may be established and torn down by
the day, hour or even minute, with continuously changing IP
addresses. Given the multitenant nature of such providers, IT
departments are unwilling to whitelist the IP addresses for the entire
block used by such providers.</t>

<t>Consequently, there is a growing need for solutions that allow VoIP
traversal through the corporate firewall that alleviate the concerns
above. This issue is further exacerbated by the growing adoption of
WebRTC by enterprise applications, which provide a ready source of RTP
traffic which often needs to traverse the firewall.</t>

</section>
<section anchor="solution-requirements" title="Solution Requirements">

<t>We believe the solution must meet the following requirements:</t>

<t>REQ-1: The solution must enable traversal of real-time media without
requiring deployment of additional media intermediaries on premise
(e.g., no SBC required)</t>

<t>REQ-2: The solution must not require the whitelisting of specific
external IP addresses</t>

<t>REQ-3: The solution must enable the enterprise to be sure that the
receiving party of the traffic desires the traffic</t>

<t>REQ-4: The solution must work with P2P calls between users in
different enterprises without requiring a TURN server</t>

<t>REQ-5: The solution must work with cloud services external to the
enterprise which terminate media on servers, such as conference
servers, voicemail servers, and so on.</t>

<t>REQ-6: The solution must not require decryption of either signaling
or media traffic at the firewall or at any other intermediary</t>

<t>REQ-7: The solution must allow the IT department to easily make policy
decisions about which applications are allowed, or not allowed, to
traverse the firewall</t>

<t>REQ-8: The solution must not require inspection of every single UDP packet
that traverses the firewall</t>

<t>REQ-9: The solution must provide a minimum level of proof that the
traffic is WebRTC media or data and not something else</t>

<t>REQ-10: The solution must work with WebRTC traffic. Note that solving
this for non-WebRTC is a non-requirement.</t>

</section>
<section anchor="solution-overview" title="Solution Overview">

<t>Many of the reasons for blocking UDP at the corporate firewall have
their origins in the lack of a three-way handshake for UDP
traffic. TCP’s three-way handshake ensures that the receiving party of
the connection desires the traffic. Similarly, HTTP traffic easily
traverses the firewall since it provides application identification
information in the URL.</t>

<t>Consequently, the solution proposed here relies on the ICE
connectivity checks, which provide a similar handshake and ensure
consent of the remote party.</t>

<t>The firewall looks for an outbound ICE connectivity check and allows inbound ICE
connectivity checks that are going to the same location that cared the outbound
and that have the correct random ufrag value that was created by the client
inside the firewall.  After a successful ICE connectivity check, the firewall
allows other media to flow on the same 5 tuple that had the successful ICE
connectivity check.  Timers are used to removed the various pinholes created.</t>

<t>In addition, the initial outbound STUN packets can contain the STUN ORIGIN
field which the firewall can use to make an authorization decision on
the application.</t>

<t>The end result is a system where:</t>

<t><list style="symbols">
  <t>STUN packets are only allowed “in” if they know the 
crypto random username generated by a client inside the firewall</t>
  <t>Non STUN packets are only allowed “in” if they match a 5 tuple that a client
inside the firewall sent a packet too</t>
  <t>Non STUN packets are only allowed “out” if the destination they are sending to
did a stun consent handshake</t>
</list></t>

</section>
<section anchor="firewall-processing" title="Firewall Processing">

<t>The firewall processing is broken into three stages: recognizing STUN
packets, making a policy decision as to whether each STUN packet should
trigger a pinhole to be created, and managing the lifetime of any
pinholes that are created.</t>

<t>The term 3-tuple is used to refer to IP address, protocol (which is always
UPD), and port that the firewall sees as the address of the client inside the
firewall.</t>

<t>The term 4-tuple is used to refer to 3-tuple plus the ice ufrag that was send in
the STUN request message for the client inside the firewall.</t>

<t>The term 5-tuple is used to refer to the 3-tuple plus the  IP address and port
of the device outside the firewall.</t>

<t>When matching a ufrag, if it is a STUN request that came from outside the
firewall, the two halves of the username  on either side of the “:” need to be
swapped before matching.</t>

<section anchor="recognizing-stun-packets" title="Recognizing STUN packets">

<t>STUN messages all have a magic cookie value of 0x2112A442 in the 4th
to 8th byte. This can be used to quickly filter nearly all UDP packets
that are not STUN packets. Many firewalls are capable of doing this
in hardware. STUN supports an optional FINGERPRINT attribute that provides
a 32 bit CRC over the message.</t>

<t>Option A: Firewalls SHOULD look at outbound UDP packets and if they have the
correct magic cookie they can classify them as STUN packets.</t>

<t>Option B: The firewall looks for any outgoing STUN requests to the STUN port
(3478). When it finds one, it stores the 3 tuple of the source address port and
protocol=UDP and for the next 30 seconds checks any packets from this 3 tuple to
see if they are ICE connectivity checks. </t>

<t>Open Issue:
* decide between option A and B. A requires looking at all UDP packets but will
likely work better than B. Most firewalls look at all TCP packets so probably
bot a big deal.</t>

<t>Firewalls that desire fewer false positives MAY also check that the FINGERPRINT
attribute is correct. Open Issue: MAY, MUST, MUST NOT - what do we want here. If
we put MAY or MUST, then browsers MUST include this. If browsers are not
required to provide this then I think we are more in the MUST not category.</t>

</section>
<section anchor="policy-decision" title="Policy decision">

<t>Once the firewall has received a STUN packet from inside the firewall,
it needs to decide if the packet is acceptable. For most situations
the firewall SHOULD accept all outbound STUN packets. This is similar
to allowing all outbound TCP flows. Some firewalls may choose to look
at other factors including the outside UDP port and the ORIGIN
attribute in the STUN packet.</t>

<t>In general WebRTC media can be sent on a wide range of UDP ports but
the two ports that are commonly used are the the RTP port (5004) and
TURN port (3478). Some firewalls MAY choose to only allow flows where
the destination port on the outside of the firewall is one of these.</t>

<t>The STUN ORIGIN attribute <xref target="I-D.ietf-tram-stun-origin"/> carries the
origin of the web page that caused the various STUN requests. So for
example, if a browser was on a page such as example.com and that page
used the WebRTC calls to set up a connection, the STUN request’s
ORIGIN attribute would include example.com. This allows the firewall
to see the web application (in this case, example.com) that is
requesting the pinhole be opened. The firewall MAY have a white list
or black list for domains in STUN ORIGIN.</t>

</section>
<section anchor="creating-the-pinhole-rules" title="Creating the pinhole rules">

<t>Once a STUN packet is accepted, the firewall MUST create a temporary rule that
causes the firewall to allow any inbound or outbound ICE messages on this
4-tuple. This pinhole MUST to be valid for at least 5 seconds from the time of
creation.</t>

<t>The firewall keeps track of the STUN transaction ID for all STUN requests
messages that traverse the 4 tuple along with the 5 tuple they were sent on and
direction (inbound or outbound). If the firewall sees a STUN Success binding
responses, with the same transaction ID, and on the same 5 tuple but in the
opposite direction as the STUN request, then a valid ICE connectivity check has
happened and the firewall MUST create a pinhole for this 5 tuple that allows any
UDP traffic to flow across that 5 tuple. This pinhole MUST to be valid for at
least 30 seconds from the time of creation.</t>

<t>The firewall continues watching ICE connectivity checks across this 5-tuple as
described in the previous paragraph and anytime the a valid ICE connectivity
check happens, this effectively extends the lifetime of the pinhole by 30
seconds. The procedures in <xref target="I-D.ietf-rtcweb-stun-consent-freshness"/> will
ensure that an ICE connectivity check is done more often than every 30 seconds.</t>

</section>
<section anchor="tracking-media-vs-data" title="Tracking media vs data">

<t>WebRTC can send audio and video as well as carry a data
channel. Confidential data could leave an enterprise by a video camera
being pointed at a document, but IT departments are often more
concerned about the data channel. It is easy for the firewall to
separately track the amount of RTP media and non-media data for each
WebRTC flow. If the first byte of the UDP message is 23, it is
non-media data; if it is in the range 127 to 192 it is audio or video
data. More information about this can be found in
<xref target="I-D.ietf-avtcore-rfc5764-mux-fixes"/>. Network management systems on
the firewall can track these two separately which can help identify
unusual usage.</t>

</section>
</section>
<section anchor="webrtc-browsers" title="WebRTC Browsers">

<t>Open Issue: how much randomness for ICE ufrag</t>

<t><list style="symbols">
  <t>ICE mandates at least 24 bits of randomness but we could require the browsers
produce 64 bits of randomness</t>
</list></t>

<t>This specification would require browsers to include the FINGERPRINT
and ORIGIN attributes in STUN for this to work correctly.</t>

<t>Open Issue: Does adding the ORIGIN reduce user privacy?</t>

<t><list style="symbols">
  <t>Consider the following case. The user goes to https://facebook.com and
initiates a call with another Facebook user. The domain facebook.com will appear
(unencrypted) in the STUN packets sent from the browser to Facebook’s TURN
server. Anyone along the network path could tell that the user is using
Facebook’s TURN server. However, when the original TLS connection for the HTTP
was made, the Server Name Indication (SNI) in the TLS of the HTTPS connection
also revealed facebook.com, largely for the same reasons - so that the firewall
would be able to see which applications are using the network.</t>
</list></t>

</section>
<section anchor="blocking-media-hiding-in-http" title="Blocking Media Hiding in HTTP">

<t>The IETF is designing systems to send interactive audio and video such
that it looks like HTTPS and HTTP to the proxies and firewalls.  The
reasons for doing this is that sometimes the proxies and firewalls
allow this to work when the mechanisms and channels designed for
sending audio and video data have been explicitly disabled by the
firewall administrators. Many firewall administrators feel this
circumvents the policy they are trying to enforce and desire a way to
prevent this. Any scheme for preventing this has some risk of
impacting normal HTTP traffic, so there is a desire to provide
guidance around ways to do that in this draft.</t>

<t>Any HTTP or HTTPS connection that sends more than 10 requests per
second for longer than 10 seconds should be paused for 1 second, and
any HTTP/S requests from that client’s IP address in the 1 second
pause time should be buffered or simply dropped. This strategy ensures
there is no impact to clients other than the one exceeding the rate
limit and minimizes the impact to other applications on the device
while still reducing the incentive to try and run calls this way.</t>

</section>
<section anchor="deployment-advice" title="Deployment Advice">

<section anchor="webrtc-servers" title="WebRTC Servers">

<t>WebRTC media servers and TURN servers with public IP address(es) that
can receive incoming packets from anywhere on the Internet are
suggested to listen for UDP on ports 53 (DNS), 123 (NTP), and 5004 for
RTP media servers and 3478 for TURN servers. UDP destined for port 53
or 123 if often allowed by firewalls that otherwise block UDP.</t>

</section>
<section anchor="firewall-admins" title="Firewall Admins">

<t>Often the approach has been to lock down everything, so that all UDP
is blocked. This simply causes applications to do things like embed
the data in normal looking HTTP or HTTPS requests. Malware and viruses
use similar approaches. Just turning off all UDP results in a poor
user experience some of the time, which results in users moving to
applications and devices outside the firewall. The IT department loses
the visibility into what is going on and can no longer protect its
users when their computers become compromised. Allowing things that
users want to use to work and monitoring them to detect when things
have gone wrong is very valuable.</t>

</section>
</section>
<section anchor="design-consideration" title="Design Consideration">

<section anchor="why-not-just-use-tcp" title="Why not just use TCP?">

<t>TODO</t>

</section>
</section>
<section anchor="security-concerns" title="Security Concerns">

<t>Enterprises have a range of concerns around WebRTC traffic traversal
of the firewall. The major concerns that are raised include:</t>

<t><list style="numbers">
  <t>Unlike TCP, UDP does not have a connection where a device inside
the firewall has confirmed that it wants to talk to the thing
outside.</t>
  <t>Incoming UDP pinholes allow out of band packets to be spoofed into
  connecting as there is no equivalent of a TCP sequence number to
check.</t>
  <t>UDP has been used by malware command and control protocols so we
block it.</t>
  <t>We do not want enable ways for data to be exfiltrated outside the
firewall with no monitoring.</t>
  <t>An encrypted data channel in WebRTC can be used to bring malware
into the company.</t>
  <t>An encrypted media or data channel in WebRTC can be used as a
command and control channel for malware inside the firewall.</t>
  <t>An encrypted data channel in WebRTC can be used by an outside
attacker to exfiltrate private files from inside the firewall.</t>
</list></t>

</section>
<section anchor="alternate-approaches" title="Alternate Approaches">

<section anchor="firewall-auth-tokens" title="Firewall Auth Tokens">

<t><xref target="I-D.reddy-rtcweb-stun-auth-fw-traversal"/> attempts to solve a
similar problem by proposing a new comprehension-optional FW-FLOWDATA
STUN attribute as part of ICE Connectivity checks enabling the
firewall to permit outgoing UDP flows across the firewall. FW-FLOWDATA
STUN provides necessary information, such as lifetime, and candidate
information, enabling a firewall to apply the required policy
rules. However, <xref target="I-D.reddy-rtcweb-stun-auth-fw-traversal"/> requires
establishing shared keys across the firewall(s) and the WebRTC server
for successfully verifying the authenticity of the FW-FLOWDATA
information.  In summary, we believe
<xref target="I-D.reddy-rtcweb-stun-auth-fw-traversal"/> to have following
short-comings</t>

<t><list style="numbers">
  <t>Requiring a tight coupling between the application server (WebRTC
server) and firewall(s)</t>
  <t>Requiring additional efforts for Firewall Admins within an
enterprise to distribute and maintain the shared authentication keys
needed to generate authentication tags for the FW-FLOWDATA attribute.</t>
  <t><xref target="I-D.reddy-rtcweb-stun-auth-fw-traversal"/> doesn’t apply for
distributing keys across firewalls in different administrative
domains.</t>
</list></t>

</section>
<section anchor="any-cast-whitelist" title="Any Cast Whitelist">

<t>Deploying media or TURN servers on a single any-cast IP address also
makes it easier for firewall administrators to whitelist the
address. Concerns have been raised that two packets sent from the same
host to a given any-cast address may get delivered to different
servers.  This is certainly possible in theory but in practice it does
not seem be happen in limited experiments done so far.</t>

</section>
</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>Many thanks to Shaun Cooley and Alissa Cooper.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='I-D.ietf-tram-stun-origin'>
<front>
<title>An Origin Attribute for the STUN Protocol</title>

<author initials='A' surname='Johnston' fullname='Alan Johnston'>
    <organization />
</author>

<author initials='J' surname='Uberti' fullname='Justin Uberti'>
    <organization />
</author>

<author initials='J' surname='Yoakum' fullname='John Yoakum'>
    <organization />
</author>

<author initials='K' surname='Singh' fullname='Kundan Singh'>
    <organization />
</author>

<date month='February' day='19' year='2015' />

<abstract><t>STUN, or Session Traversal Utilities for NAT, is a protocol used to assist other protocols traverse Network Address Translators or NATs. This specification defines an ORIGIN attribute for STUN that can be used in similar ways to the HTTP header field of the same name. WebRTC browsers utilizing STUN and TURN would include this attribute which would provide servers with additional information about the STUN and TURN requests they receive.  This specification defines the usage of the STUN ORIGIN attribute for web, SIP, and XMPP contexts.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tram-stun-origin-05' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tram-stun-origin-05.txt' />
</reference>



<reference anchor='I-D.ietf-avtcore-rfc5764-mux-fixes'>
<front>
<title>Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)</title>

<author initials='M' surname='Petit-Huguenin' fullname='Marc Petit-Huguenin'>
    <organization />
</author>

<author initials='G' surname='Salgueiro' fullname='Gonzalo Salgueiro'>
    <organization />
</author>

<date month='March' day='24' year='2015' />

<abstract><t>This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), Real-time Transport Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), and Traversal Using Relays around NAT (TURN) packets are multiplexed on a single receiving socket.  It overrides the guidance from SRTP Extension for DTLS [RFC5764], which suffered from three issues described and fixed in this document.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-avtcore-rfc5764-mux-fixes-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-avtcore-rfc5764-mux-fixes-02.txt' />
</reference>




    </references>

    <references title='Informative References'>





<reference anchor='I-D.ietf-rtcweb-overview'>
<front>
<title>Overview: Real Time Protocols for Browser-based Applications</title>

<author initials='H' surname='Alvestrand' fullname='Harald Alvestrand'>
    <organization />
</author>

<date month='June' day='16' year='2015' />

<abstract><t>This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web".  It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track.  This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications WebRTC compliant implementations are supposed to follow.  This document is a work item of the RTCWEB working group.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-overview-14' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-overview-14.txt' />
</reference>



<reference anchor='I-D.ietf-rtcweb-stun-consent-freshness'>
<front>
<title>STUN Usage for Consent Freshness</title>

<author initials='M' surname='Perumal' fullname='Muthu Perumal'>
    <organization />
</author>

<author initials='D' surname='Wing' fullname='Dan Wing'>
    <organization />
</author>

<author initials='R' surname='R' fullname='Ram R'>
    <organization />
</author>

<author initials='T' surname='Reddy' fullname='Tirumaleswar Reddy'>
    <organization />
</author>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<date month='June' day='22' year='2015' />

<abstract><t>To prevent WebRTC applications, such as browsers, from launching attacks by sending media to unwilling victims, periodic consent to send needs to be obtained from remote endpoints.  This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-stun-consent-freshness-15' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-stun-consent-freshness-15.txt' />
</reference>



<reference anchor='I-D.reddy-rtcweb-stun-auth-fw-traversal'>
<front>
<title>STUN Extensions for Authenticated Firewall Traversal</title>

<author initials='T' surname='Reddy' fullname='Tirumaleswar Reddy'>
    <organization />
</author>

<author initials='M' surname='Perumal' fullname='Muthu Perumal'>
    <organization />
</author>

<author initials='D' surname='Wing' fullname='Dan Wing'>
    <organization />
</author>

<date month='July' day='8' year='2012' />

<abstract><t>Some networks deploy firewalls configured to block UDP traffic.  When SIP user agents or WebRTC endpoints are deployed behind such firewalls, media cannot be sent over UDP across the firewall, but must be sent using TCP (which causes a different user experience) or through a session border controller.  This draft describes an alternate model wherein extensions to ICE connectivity checks can be examined by the firewall to permit outgoing UDP flows across the firewall.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-reddy-rtcweb-stun-auth-fw-traversal-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-reddy-rtcweb-stun-auth-fw-traversal-00.txt' />
</reference>




    </references>



  </back>
</rfc>