One document matched: draft-ietf-mmusic-latching-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category='info' ipr='trust200902'
docName='draft-ietf-mmusic-latching-03'>
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc strict='yes' ?>
<?rfc compact='yes' ?>
<front>
<title abbrev='Hosted NAT Traversal for Media in RTC'>
Latching: Hosted NAT Traversal (HNT) for Media in Real-Time
Communication
</title>
<author initials='E.' surname='Ivov'
fullname='Emil Ivov'>
<organization abbrev='Jitsi'>Jitsi</organization>
<address>
<postal>
<street></street>
<city>Strasbourg</city>
<code>67000</code>
<country>France</country>
</postal>
<email>emcho@jitsi.org</email>
</address>
</author>
<author initials='H.' surname='Kaplan'
fullname='Hadriel Kaplan'>
<organization>Oracle</organization>
<address>
<postal>
<street>100 Crosby Drive</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>USA</country>
</postal>
<email>hadriel.kaplan@oracle.com</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<date />
<abstract>
<t>
This document describes behavior of signalling intermediaries in
Real-Time Communication (RTC) deployments, sometimes referred to
as Session Border Controllers (SBCs), when performing Hosted NAT
Traversal (HNT). HNT is a set of mechanisms, such as media
relaying and latching, that such intermediaries use to enable
other RTC devices behind NATs to communicate with each other.
This document is non-normative, and is only written to explain
HNT in order to provide a reference to the IETF community, as
well as an informative description to manufacturers, and users.
</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>
Network Address Translators (NATs) are widely used in the
Internet by consumers and organizations. Although specific NAT
behaviors vary, this document uses the term "NAT" for devices
that map any IPv4 or IPv6 address and transport port number to
another IPv4 or IPv6 address and transport port number. This
includes consumer NATs, Firewall-NATs, IPv4-IPv6 NATs,
Carrier-Grade NATs (CGNs) <xref target="RFC6888"/>, etc.
</t>
<t>
Protocols like <xref target="RFC3261">SIP</xref>, and others
that try to use a more direct path for media than with
signalling, are difficult to use across NATs. They use IP
addresses and transport port numbers encoded in bodies such as
<xref target="RFC4566">SDP</xref> as well as, in the case of
SIP, various header fields. Such addresses and ports are
unusable unless all peers in a session are located behind the
same NAT.
</t>
<t>
Mechanisms such as Session Traversal Utilities for NAT (STUN)
<xref target="RFC5389"/>, Traversal Using Relays around NAT
(TURN) <xref target="RFC5766"/>, and Interactive Connectivity
Establishment (ICE) <xref target="RFC5245"/> did not exist when
protocols like SIP began being deployed. Some mechanisms, such
as the early versions of STUN <xref target="RFC3489"/>, had
started appearing but they were unreliable and suffered a number
of issues typical for UNilateral Self-Address Fixing (UNSAF) and
described in <xref target="RFC3424"/>. For these and other
reasons, Session Border Controllers (SBCs) that were already
being used by SIP domains for other SIP and media-related
purposes began to use proprietary mechanisms to enable SIP
devices behind NATs to communicate across the NATs.
</t>
<t>
The term often used for this behavior is Hosted NAT Traversal
(HNT), although some manufacturers sometimes use other names
such as "Far-end NAT Traversal" or "NAT assist" instead. The
systems which perform HNT are frequently SBCs as described in
<xref target="RFC5853"/>, although other systems such as media
gateways and "media proxies" sometimes perform the same role.
For the purposes of this document, all such systems are referred
to as SBCs, and the NAT traversal behavior is called HNT.
</t>
<t>
As of this document's creation time, a vast majority of SIP
domains use HNT to enable SIP devices to communicate across
NATs, despite the publication of ICE. There are many reasons for
this, but those reasons are not relevant to this document's
purpose and will not be discussed. It is however worth pointing
out that the current deployment levels of HNT and NATs
themselves make an exclusive adoption of ICE highly unlikely
in the foreseeable future.
</t>
<t>
The purpose of this document is to describe the mechanisms often
used for HNT at the SDP and media layer, in order to aid
understanding the implications and limitations imposed by it.
Although the mechanisms used in HNT are not novel to experts,
publication in an IETF document is useful as a means of
providing common terminology and a reference for related
documents.
</t>
<t>
In no way does this document try to make a case for HNT or
present it as a solution that is somehow better than
alternatives such as ICE. The mechanisms described here, popular
as they may be, are not considered best practice or recommended
operation and should hence be avoided when possible.
</t>
<t>
It is also worth mentioning that there are purely
signaling-layer components of HNT as well. One such component is
briefly described for SIP in <xref target="RFC5853"/>, but that
is not the focus of this document. The SIP signaling-layer
component of HNT is typically more implementation-specific and
deployment-specific than the SDP and media components. For
the purposes of this document it is hence assumed that
signaling intermediaries handle traffic in way that allows
protocols such as SIP to function correctly across the NATs.
</t>
<t>
The rest of this document is going to focus primarily on use of
HNT for SIP. However, the mechanisms described here are
relatively generic and are often used with other protocols, such
as <xref target="RFC6120">XMPP</xref>, Media Gateway Control
Protocol (MGCP) <xref target="RFC3435"/>, H.248/MEGACO
<xref target="RFC5125"/>, and H.323 <xref target="H.323"/>.
</t>
</section>
<section title='Background'>
<t>
The general problems with NAT traversal for protocols such as
SIP are:
<list style='numbers'>
<t>
The addresses and port numbers encoded in SDP bodies (or
their equivalents) by NATed User Agents (UAs) are not usable
across the Internet, because they represent the private
network addressing information of the UA rather than the
addresses/ports that will be mapped to/from by the NAT.
</t>
<t>
The policies inherent in NATs, and explicit in Firewalls,
are such that packets from outside the NAT cannot reach the
UA until the UA sends packet out first.
</t>
<t>
Some NATs apply endpoint dependent filtering on incoming
packets, as described in <xref target="RFC4787"/> and thus a
UA may only be able to receive packets from the same remote
peer IP:port as it sends packets out to.
</t>
</list>
</t>
<t>
In order to overcome these issues, signaling intermediaries such
as SIP SBCs on the public side of the NATs perform HNT for both
signaling and media. An example deployment model of HNT and SBCs
is shown in <xref target='fig-deployment' />.
</t>
<figure title="Logical Deployment Paths"
anchor="fig-deployment">
<artwork>
<![CDATA[
+-----+ +-----+
| SBC |-------| SBC |
+-----+ +-----+
/ \
/ Public Net \
/ \
+-----+ +-----+
|NAT-A| |NAT-B|
+-----+ +-----+
/ \
/ Private Net Private Net \
/ \
+------+ +------+
| UA-A | | UA-B |
+------+ +------+
]]>
</artwork>
<postamble>
</postamble>
</figure>
</section>
<section title='Impact on Signaling'>
<t>
Along with codec and other media-layer information, session
establishment signaling also conveys, potentially private and
non-globally routable addressing information. Signaling
intermediaries would hence modify such information so that peer
UAs are given the (public) addressing information of a media
relay controlled by the intermediary.
</t>
<t>
Quite often, the IP address of the newly introduced media relay
may be the same as that of the signaling intermediary (e.g. the
SIP SBC) or it may be a completely different one. In almost
all cases however, the new address would belong to the same IP
address family as the one used for signaling, since it is known
to work for that UA.
</t>
<t>
The port numbers introduced in the signaling by the intermediary
are typically allocated dynamically. Allocation strategies are
entirely implementation dependent and they often vary from one
product to the next.
</t>
<t>
The offer/answer media negotiation model
<xref target="RFC3264"/> is such that once an offer is sent, the
generator of the offer needs to be prepared to receive media on
the advertised address/ports. In practice such media may or may
not be received, depending on the implementations participating
in a given session, local policies, and call scenario. For
example if a SIP SDP Offer originally came from a UA behind a
NAT, the SIP SBC cannot send media to it until an SDP Answer is
given to the UA and <xref target="sec-latching">latching</xref>
occurs. Another example is when a SIP SBC sends an SDP Offer in
a SIP INVITE to a residential customer's UA and receives back
SDP in a 18x response, the SBC may decide not to send media to
that customer UA until a SIP 200 response for policy reasons, to
prevent toll-fraud.
</t>
</section>
<section title='Media Behavior, Latching' anchor="sec-latching">
<t>
An UA behind a NAT streams media from a private address:port set
that once packets cross the NAT, will be mapped to a public set.
The UA however is not typically aware of the public mapping and
would often advertise the private address:port couple in
signaling. This way, when the signalling intermediary performing
HNT receives private addressing information from from a NATed UA
it will not know what address/ports to send media to. Therefore
media relays used in HNT would often use a mechanism called
"latching".
</t>
<t>
Historically, "latching" only referred to the process by which
SBCs "latch" onto UDP packets from a given UA for security
purposes, and "symmetric-latching" is when the latched
address:ports are used to send media back to the UA. Today most
people talk about them both as "latching", and thus this
document does as well.
</t>
<t>
The latching mechanism works as follows:
<list style='numbers'>
<t>
After receiving an offer from a NATed UA, a signaling
intermediary located on the public Internet would allocate
a set of IP address:ports on a media relay. The set would
then be advertised to the remote party so that it would use
those media relay address:ports for all media it wished to
send toward the UA.
</t>
<t>
Next, after receiving an answer to its offer, the signaling
server would allocate a second address:port set on the media
relay. It would advertise this second set in the answer to the
UA. The UA will then send to this media relay address:port.
</t>
<t>
The media relay receives the media packets on the allocated
ports, and uses their source address and port as a
destination for all media bound in the opposite direction.
In other words, it "latches" or locks on these source
address:port set.
</t>
<t>
This way all media streamed by the UA would be received
on the second address:port set. The source addresses and
ports of the traffic would belong to the public interface
of the NAT in front of the UA and anything that the relay
sends there would find its way to it.
</t>
<t>
Similarly the source of the stream originating at the remote
party would be latched upon and used for media going in that
direction.
</t>
<t>
Latching is usually done only once per peer and not allowed
to change or cause a re-latching until a new offer and
answer get exchanged (e.g. in a subsequent call or after
a SIP peer has gone on and off hold). The reasons for such
restrictions are mostly related to security: once a session
has started a user agent is not expected to suddenly start
streaming from a different port without sending a new offer
first. A change may indicate an attempt to hijack the
session. In some cases however, a port change may be caused
by a re-mapping in a NAT device standing between the SBC and
the UA. More advanced SBCs may therefore allow some level of
flexibility on the re-latching restrictions while carefully
considering the potential security implications of doing so.
</t>
</list>
</t>
<t>
<xref target="fig-sip-latching"/> describes how latching occurs
for SIP where HNT is provided by an SBC connected to two
networks: 203.0.113/24 facing towards the User Agent Client
(UAC) network and 198.51.100/24 facing towards the User Agent
Server (UAS) network.
</t>
<figure title="Latching by a SIP SBC across two interfaces"
anchor="fig-sip-latching">
<artwork>
<![CDATA[
192.0.2.1 198.51.100.33
Alice NAT 203.0.113.0/24-SBC-198.51.100.0/24 Bob
------- --- --- -------
| | | |
1. |--SIP INVITE+offer c=192.0.2.1--->| |
| | | |
2. | | (SBC allocates 198.51.100.2:22007 |
| | for inbound RTP from UAS) |
| | | |
3. | | |---INVITE+offer---->|
| | |c=198.51.100.2:22007|
| | | |
4. | | |<---180 Ringing-----|
| | | |
| | | |
5. |<------180 Ringing----------------| |
| | | |
6. | | |<---200+answer------|
| | | |
7. | | (SBC allocates 203.0.113.4:36010 |
| | for inbound RTP from UAC) |
| | | |
8. |<-200+answer,c=203.0.113.4:36010--| c=198.51.100.33 |
| | | |
9. |------------ACK------------------>| |
10. | | |-------ACK--------->|
| | | |
11. |=====RTP,dest=203.0.113.4:36010==>| |
| | | |
12. | | (SBC latches to |
| | source IP address and |
| | port seen at (10)) |
| | | |
13. | | |<====== RTP ========|
| | | |
14. |<=====RTP, to latched address=====| |
| | | |
]]>
</artwork>
<postamble>
</postamble>
</figure>
<t>
While XMPP implementations often rely on ICE to handle NAT
traversal, there are some that also support a non-ICE transport
called <xref target="XEP-0177">XMPP Jingle Raw UDP Transport
Method</xref>. <xref target="fig-xmpp-latching"/> describes how
latching occurs for one such XMPP implementation where HNT is
provided by an XMPP server on the public internet.
</t>
<figure title="Latching by a SIP SBC across two interfaces"
anchor="fig-xmpp-latching" align="left">
<artwork>
<![CDATA[
192.0.2.1 192.0.2.9/203.0.113.4 203.0.113.9 198.51.100.8
XMPP Client1 NAT XMPP Server XMPP Client2
----- --- --- -----
| | | |
1. |----session-initiate cand=192.0.2.1--->| |
| | | |
2. |<------------ack-----------------------| |
| | | |
3. | | (Server allocates 203.0.113.9:2200 |
| | for inbound RTP from Client2) |
| | | |
4. | | |--session-initiate->|
| | cand=203.0.113.9:2200|
| | | |
5. | | |<-------ack---------|
| | | |
| | | |
6. | | |<--session-accept---|
| | | cand=198.51.100.8 |
| | | |
7. | | |--------ack-------> |
| | | |
8. | | (Server allocates 203.0.113.9:3300 |
| | for inbound RTP from Client1) |
| | | |
9. |<-session-accept cand=203.0.113.9:3300-| |
| | | |
10. |-----------------ack------------------>| |
| | | |
| | | |
11. |======RTP, dest=203.0.113.9:3300======>| |
| | | |
12. | | (XMPP server latches to |
| | src IP 203.0.113.4 and |
| | src port seen at (10)) |
| | | |
13. | | |<====== RTP ========|
| | | |
14. |<======RTP, to latched address=========| |
| | | |
]]>
</artwork>
<postamble>
</postamble>
</figure>
<t>
The above is a general description, and some details vary
between implementations or configuration settings. For example,
some intermediaries perform additional logic before latching
on received packet source information to prevent malicious
attacks or latching erroneously to previous media senders -
often called "rogue-rtp" in the industry.
</t>
<t>
It is worth pointing out that latching is not an exclusively
"server affair" and some clients may also use it in cases where
they are configured with a public IP address and they are
contacted by a NATed client with no other NAT traversal means.
</t>
<t>
In order for latching to function correctly, the UA behind the
NAT needs to support symmetric RTP. That is, it needs to use the
same ports for sending data as the ones it listens on for
inbound packets. Today this is the case for with, for example,
almost all SIP and XMPP clients. Also UAs need to make sure they
can begin sending media packets independently and without
waiting for packets to arrive first. In theory, it is possible
that some UAs would not send packets out first; for example if a
SIP session begins in 'inactive' or 'recvonly' SDP mode from
the UA behind the NAT. In practice, however, SIP sessions from
regular UAs (the kind that one could find behind a NAT)
virtually never begin an inactive or 'recvonly' mode, for
obvious reasons. The media direction would also be problematic
if the SBC side indicated 'inactive' or 'sendonly' modes when it
sent SDP to the UA. However SBCs providing HNT would always be
configured to avoid this.
</t>
<t>
Given that, in order for latching to work properly, media relays
need to begin receiving media before they start sending, it is
possible for deadlocks to occur. This can happen when the UAC
and the UAS in a session are connected to different signalling
intermediaries that both provide HNT. In this case the media
relays controlled by the signalling servers could end up each
waiting upon the other to initiate the streaming. To prevent
this relays would often attempt to start streaming toward the
address:port sets provided in the offer/answer even before
receiving any inbound traffic. If the entity they are streaming
to is another HNT performing server it would have provided its
relay's public address and ports and the early stream would find
its target.
</t>
<t>
Although many SBCs only support UDP-based media latching, and in
particular RTP/RTCP, many SBCs support TCP-based media latching
as well. TCP-based latching is more complicated, and involves
forcing the UA behind the NAT to be the TCP client and sending
the initial SYN-flagged TCP packet to the SBC (i.e., be the
'active' mode side of a TCP-based media session). If both UAs
of a TCP-based media session are behind NATs, then SBCs
typically force both UAs to be the TCP clients, and the SBC
splices the TCP connections together. TCP splicing is a
well-known technique, and described in [tcp-splicing].
</t>
<t>
HNT and latching in particular are generally found to be working
reliably but they do have obvious caveats. The first one usually
raised by IETF members is that UAs are not aware of it
occurring. This makes it impossible for the mechanism to be
used with protocols such as ICE that try various traversal
techniques in an effort to choose the one the best suits a
particular situation. Overwriting address information in in
offers and answers may actually completely prevent UAs from
using ICE because of the ice-mismatch rules described in
<xref target="RFC5245"/>
</t>
<t>
The second issue raised by IETF members is that it causes media
to go through a relay instead of directly over the IP-routed
path between the two participating UAs. While this adds obvious
drawbacks such as reduced scalability and often increased
latency, it is also considered a benefit by SBC administrators:
if a customer pays for "phone" service, for example, the media
is what is truly being paid for, and the administrators usually
like to be able to detect that media is flowing correctly,
evaluate its quality, know if and why it failed, etc. Also in
some cases routing media through operator controlled relays may
route media over paths explicitly optimized for media and hence
offer better performance than regular Internet routing.
</t>
</section>
<section title='Security Considerations' anchor="security">
<t>
A common concern is that an SBC that implements HNT may latch to
incorrect and possibly malicious sources. A malicious source
could, for example, attempt a resource exhaustion attack by
flooding all possible media-latching UDP ports on the SBC in
order to prevent calls from succeeding. SBCs have various
mechanisms to prevent this from happening, or alert an
administrator when it does. Still, a sufficiently sophisticated
attacker may be able to bypass them for some time. The most
common example is typically referred to as "restricted-latching",
whereby the SBC will not latch to any packets from a source
public IP address other than the one the SIP UA uses for SIP
signaling. This way the SBC simply ignores and does not latch
onto packets coming from the attacker. In some cases the
limitation may be loosened to allow media from a range of IP
addresses belonging to the same network in order to allow for
use cases such as decomposed UAs and various forms of third
party call control. However, since relaxing the restrictions in
such a way may widen the gap for potential attackers, such
configurations are generally performed only on a case-by-case
basis so that the specifics of individual deployments would be
taken into account.
</t>
<t>
In all of the above problems would still arise if the attacker
knows the public source IP of the UA that is actually making the
call. This would allow them to still flood all of the SBC's
public IP addresses and ports with packets spoofing that SIP
UA's public source IP address. However, this would only disturb
media from that IP (or range of IP addresses) rather than all
calls that the SBC is servicing.
</t>
<t>
A malicious source could send media packets to an SBC
media-latching UDP port in the hopes of being latched-to for
the purpose of receiving media for a given SIP session. SBCs
have various mechanisms to prevent this as well. Restricted
latching for example would also help in this case since the
attacker can't make the SBC send media packets back to
themselves since the SBC will not latch onto the attacker's
packets. There could still be an issue if the attacker happens
to be either (1) in the IP routing path and thus can spoof the
same IP as the real UA and get the media coming back, in which
case the attacker hardly needs to attack at all to begin with,
or (2) the attacker is behind the same NAT as the legitimate SIP
UA, in which case the attacker's packets will be latched-to by
the SBC and the SBC will send media back to the attacker. In
this latter case, which may be of particular concern with
Carrier-Grade NATs, the legitimate SIP UA will end the call
anyway, because a human user would not hear anything and will
hang up. In the case of a non-human call participant, such as an
answering machine, this may not happen (although many such
automated UAs would also hang up when they do not receive any
media). The attacker could also redirect all media to the real
SIP UA after receiving it, in which case the attack would likely
remain undetected and succeed. Again, this would be of
particular concern with larger scale NATs serving many different
endpoints such as Carrier-Grade NATs. The larger the number of
devices fronted by a NAT is, the more use cases would vary and
the more the number of possible attack vectors would grow.
</t>
<t>
Naturally, <xref target="RFC3711">SRTP</xref> would help
mitigate such threats and should be used independently of HNT.
For example, in cases where end-to-end encryption is used it
would still be possible for an attacker to hijack a session
despite the use of SRTP and perform a denial of service attack.
However, media integrity would not be compromised. Additionally,
if the SBC that performs the latching is actually participating
in the SRTP key exchange, then it would simply refuse to latch
onto a source unless it can authenticate it. Failing to
implement this would represent а serious threat to users
connecting from behind Carrier-Grade NATs
<xref target="RFC6888"/> and is considered a harmful practice.
</t>
<t>
For SIP clients, HNT is usually transparent in the sense that
the SIP UA does not know it occurs. In certain cases it may be
detectable, such as when ICE is supported by the SIP UA and the
SBC modifies the default connection address and media port
numbers in SDP, thereby disabling ICE due to the mismatch
condition. Even in that case, however, the SIP UA only knows a
middle box is relaying media, but not necessarily that it is
performing latching/HNT.
</t>
<t>
In order to perform HNT, the SBC has to modify SDP to and from
the SIP UA behind a NAT, and thus the SIP UA cannot use
<xref target="RFC5751">S/MIME</xref>, and it cannot sign a
sending request or verify a received request using
<xref target="RFC4474"/> unless the SBC re-signs the request.
However it is sometimes argued that, neither S/MIME nor
<xref target="RFC4474"/> are widely deployed and that this may
not be a real concern.
</t>
<t>
From a privacy perspective, media relaying is sometimes seen as
a way of protecting one's IP address and not revealing it to the
remote party. That kind of IP address masking is often perceived
as important. However, this is no longer an exclusive advantage
of HNT since it can also be accomplished by client-controlled
relaying mechanisms such as <xref target="RFC5766">TURN</xref>,
if the client explicitly wishes to do so.
</t>
</section>
<section title='IANA Considerations'>
<t>
This document has no actions for IANA.
</t>
<t>
Note to the RFC-Editor: please remove this section prior to
publication as an RFC.
</t>
</section>
<section title='Acknowledgements'>
<t>
The authors would like to thank Flemming Andreasen, Miguel A.
Garcia, Ari Keränen and Paul Kyzivat for their reviews and
suggestions on improving this document.
</t>
</section>
</middle>
<back>
<references title='Informative References'>
<?rfc include="reference.RFC.5125"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.RFC.3424"?>
<?rfc include="reference.RFC.3435"?>
<?rfc include="reference.RFC.3489"?>
<?rfc include="reference.RFC.3711"?>
<?rfc include="reference.RFC.4474"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.4787"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.5389"?>
<?rfc include="reference.RFC.5751"?>
<?rfc include="reference.RFC.5766"?>
<?rfc include="reference.RFC.5853"?>
<?rfc include="reference.RFC.6120"?>
<?rfc include="reference.RFC.6888"?>
<reference anchor="H.323">
<front>
<title>Packet Based Multimedia Communication Systems</title>
<author fullname='International Telecommunication Union'>
<organization abbrev='ITU-T'>
International Telecommunication Union
</organization>
</author>
<date month="July" year="2003" />
</front>
<seriesInfo name="Recommendation"
value="H.323"/>
</reference>
<reference anchor="XEP-0177">
<front>
<title>XEP-0177: Jingle Raw UDP Transport Method</title>
<author initials='J.' surname='Beda'
fullname='Joe Beda'>
<organization abbrev='Google'>
Google
</organization>
</author>
<author initials='P.' surname='Saint-Andre'
fullname='Peter Saint-Andre'>
<organization abbrev='Cisco'>
Cisco
</organization>
</author>
<author initials='J.' surname='Hildebrand'
fullname='J. Hildebrand'>
<organization abbrev='Cisco'>
Cisco
</organization>
</author>
<author initials='S.' surname='Egan'
fullname='Sean Egan'>
<organization abbrev='Google'>
Google
</organization>
</author>
<date month="December" year="2009" />
</front>
<seriesInfo name="XEP" value="XEP-0177" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:34:54 |