1!I!
`
`
`
` 1 | |
`
`DECLARATION OF SANDY GINOZA FORIETF
`RFC 3489: STUN - SIMPLE TRAVERSAL OF USER DATAGRAM PROTOCOL (UDP)
`THROUGH NETWORK ADDRESS TRANSLATORS (NATS)
`
`I, Sandy Ginoza, based on my personal knowledge and information, hereby declare as
`
`follows:
`
`1.
`
`Iam an employee of Association Management Solutions, LLC (AMS), which
`
`acts under contract to the Internet Society (ISOC) as the operator of the RFC Production
`
`Center, The RFC Production Center is part of the "RFC Editor" function, which prepares
`
`documents for publication and placesfiles in an online repository for the authoritative
`
`Request for Comments (RFC) series of documents (RFC Series), and preserves records
`
`relating to these documents. The RFC Series includes, among otherthings, the series of
`
`Internet standards developed by the Internet Engineering Task Force (IETF), an organized
`
`activity of ISOC. I hold the position of Director of the RFC Production Center. I began
`
`employment with AMSin this capacity on 6 January 2010.
`
`2.
`
`Among my responsibilities as Director of the RFC Production Center, I act as
`
`the custodian of recordsrelating to the RFC Series, and I am familiar with the record keeping
`
`practices relating to the RFC Series, including the creation and maintenance of such records.
`
`3.
`
`From June 1999 to 5 January 2010, I was an employeeof the Information
`
`SciencesInstitute at University of Southern California (ISI). I held various position titles with
`
`the RFC Editor project at IST, ending with Senior Editor.
`
`4,
`
`The RFC Editor function was conducted by ISI under contract to the United
`
`States governmentprior to 1998. In 1998, ISOC,in furtherance of its IETF activity, entered into
`
`the first in a series of contracts with ISI providing for ISI's performance of the RFC Editor
`
`function. Beginning in 2010, certain aspects of the RFC Editor function were assumed by the
`
`Apple Inc.
`Ex. 1019 - Page 1
`
`Apple Inc.
`Ex. 1019 - Page 1
`
`

`

`
`
`
`
`
`
`REC Production Center operation of AMS under contract to ISOC (acting through its IETF
`
`function and, in particular, the IETF Administrative Oversight Committee). The business records
`
`of the RFC Editor function as it was conducted by ISI are currently housed on the computer
`
`systems of AMS, as contractor to ISOC,
`
`5.
`
`I makethis declaration based on my personal knowledge and information
`
`contained in the business records of the RFC Editor as they are currently housed at AMS, or
`
`confirmation with other responsible RFC Editor personnel with such knowledge.
`
`6.
`
`Prior to 1998, the RFC Editor's regular practice was to publish RFCs, making
`
`them available from a repository via FTP. When a new RFC waspublished, an announcement
`
`of its publication, with information on how to access the RFC, would be typically sent out
`
`within 24 hours of the publication.
`
`7.
`
`Any RFC published on the RFC Editor website or via FTP was reasonably
`
`accessible to the public and was disseminated or otherwise available to the extent that persons
`
`interested and ordinarily skilled in the subject matter or art exercising reasonable diligence could
`
`have locatedit. In particular, the RFCs were indexed and placed in a public repository.
`
`8.
`
`The RFCsare kept in an online repository in the course of the RFC Editor's
`
`regularly conducted activity and ordinary course of business. The records are made pursuant to
`
`established procedures and are relied upon by the RFC Editor in the performanceofits functions.
`
`9.
`
`10.
`
`It is the regular practice of the RFC Editor to make and keep the RFC records.
`
`Based on those records, I can state that the publication date of RFC 3489 was
`
`March 2003 (date listed on the RFC), at which time it was reasonably accessible to the public
`either on the RFC Editor website or via FTP from a repository. A copy of that RFC is attached
`
`to this declaration as an exhibit.
`
`Apple Inc.
`Ex. 1019 - Page 2
`
`Apple Inc.
`Ex. 1019 - Page 2
`
`

`

`|
`
`i |
`
`
`
`Pursuant to Section 1746 of Title 28 of United States Code, I declare under penalty of
`
`perjury underthe laws of the United States of America that the foregoing is true and correct
`
`and that the foregoing is based upon personal knowledge and information and is believed to be
`
`true.
`
`\
`Date:
`seroeaiz.agys.,
`
`set \>
`ALTACHED CALIF. ACKNOWLEDGMENT
`;
`
`By:
`|
`yp atti
`
`/SpGinoza
`
`Apple Inc.
`Ex. 1019 - Page 3
`
`Apple Inc.
`Ex. 1019 - Page 3
`
`

`

` CALIFORNIA ALL-PURPOSE ACKNOWLEDGMENT CIVIL CODE $11189
`
`
`
`A notary public or other officer completing this certificate verifies only the identity of the individual who signed the
`document to whichthis certificate is attached, and not the truthfulness, accuracy, or validity of that document.
`
`State of California
`
`}
`
`)
`
`
`
`Date
`
`Here insert Name and Title of the Officer
`
`4
`
`.
`|
`County of Le ANGTES .
`CS.degaditto ~ Narary pubic
`On Septenletr UUpens before me,
`personally appeared
`Sandy Gine24
`Se
`Name(ofofSignerfef
`who proved to me on the basis of satisfactory evidence to be the person{é) whose name(ahisvare
`subscribed to the within instrument and acknowledged to me that he/sn¢/they executed the same !n
`his/aerptheirauthorized capacity(ies), and that by Fisther)their signaturefé) onthe instrument the person{s),
`or the entity upon behalf of which the person(g} acted, executed the instrument.
`1 certify under PENALTY OF PERJURY under the laws
`of the State of California that the foregoing paragraph
`is true and correct.
`
`|
`
`$.8.DELGADILO
`
`
`LosAngelesCounty
`Notary Public ~ California
`
`
`-YNN
`
`Commission # 2224720
`My Comm, Expires Cac 9, 2021
`:
`
`
`WITNESS my hand and official seal.
`Signature
`S - S -
`AQ(bo
`Signature of Notary Public
`
`Place Notary Seal Above
`
`OPTIONAL
`Though this section is optional, completing this information can deter alteration of the document or
`fraudulent reattachment ofthis form to an unintended document.
`
`Description of Attached Documen
`
`.
`
`.
`
`=
`
`°
`
`Title orTypeof Document: yclaraoF Sanely Gera for {err LerPied:stun
`
`
`Document Date: Number of Pages:_®iv
`
`
`Signer(s) Other Than Named Above:_NM
`
`Capacity(ies) Claimed by Signer(s)
`
`Signer’s Name:
`Li Corporate Officer — Title(s):
`{| Partner — (C] Limited
`[1 General
`C] Individual
`C1] Attorney in Fact
`CJ Trustee
`=] Guardian or Conservator
`
`LJ Other:
`
`Signer’s Name:
`C1) Corporate Officer — Title(s):
`L1 Partner — LiLimited
`(1 General
`C) individual
`L] Attorney in Fact
`[_] Trustee
`[1] Guardian or Conservator
`L] Other:
`
`
`Signer is Representing:
`SignerIs Representing:
`
` ©2016 Nationalal Notary As‘Association« www.w NationalNotaty,org « (-800-5-US NOTARY (1-800-876-6.6827) item45907
`
`
`
`Apple Inc.
`Ex. 1019 - Page 4
`
`Apple Inc.
`Ex. 1019 - Page 4
`
`

`

`Network Working Group J. Rosenberg
`Request for Comments: 3489 J. Weinberger
`Category: Standards Track dynamicsoft
` C. Huitema
` Microsoft
` R. Mahy
` Cisco
` March 2003
`
` STUN - Simple Traversal of User Datagram Protocol (UDP)
` Through Network Address Translators (NATs)
`Status of this Memo
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`Copyright Notice
` Copyright (C) The Internet Society (2003). All Rights Reserved.
`Abstract
` Simple Traversal of User Datagram Protocol (UDP) Through Network
` Address Translators (NATs) (STUN) is a lightweight protocol that
` allows applications to discover the presence and types of NATs and
` firewalls between them and the public Internet. It also provides the
` ability for applications to determine the public Internet Protocol
` (IP) addresses allocated to them by the NAT. STUN works with many
` existing NATs, and does not require any special behavior from them.
` As a result, it allows a wide variety of applications to work through
` existing NAT infrastructure.
`Table of Contents
` 1. Applicability Statement ................................... 3
` 2. Introduction .............................................. 3
` 3. Terminology ............................................... 4
` 4. Definitions ............................................... 5
` 5. NAT Variations ............................................ 5
` 6. Overview of Operation ..................................... 6
` 7. Message Overview .......................................... 8
` 8. Server Behavior ........................................... 10
` 8.1 Binding Requests .................................... 10
`
`Rosenberg, et al. Standards Track [Page 1]
`RFC 3489 STUN March 2003
`
` 8.2 Shared Secret Requests .............................. 13
` 9. Client Behavior ........................................... 14
` 9.1 Discovery ........................................... 15
` 9.2 Obtaining a Shared Secret ........................... 15
`https://www.rfc-editor.org/rfc/rfc3489.txt
`1
`
`Apple Inc.
`Ex. 1019 - Page 5
`
`

`

` 9.3 Formulating the Binding Request ..................... 17
` 9.4 Processing Binding Responses ........................ 17
` 10. Use Cases ................................................. 19
` 10.1 Discovery Process ................................... 19
` 10.2 Binding Lifetime Discovery .......................... 21
` 10.3 Binding Acquisition ................................. 23
` 11. Protocol Details .......................................... 24
` 11.1 Message Header ...................................... 25
` 11.2 Message Attributes .................................. 26
` 11.2.1 MAPPED-ADDRESS .............................. 27
` 11.2.2 RESPONSE-ADDRESS ............................ 27
` 11.2.3 CHANGED-ADDRESS ............................. 28
` 11.2.4 CHANGE-REQUEST .............................. 28
` 11.2.5 SOURCE-ADDRESS .............................. 28
` 11.2.6 USERNAME .................................... 28
` 11.2.7 PASSWORD .................................... 29
` 11.2.8 MESSAGE-INTEGRITY ........................... 29
` 11.2.9 ERROR-CODE .................................. 29
` 11.2.10 UNKNOWN-ATTRIBUTES .......................... 31
` 11.2.11 REFLECTED-FROM .............................. 31
` 12. Security Considerations ................................... 31
` 12.1 Attacks on STUN ..................................... 31
` 12.1.1 Attack I: DDOS Against a Target ............. 32
` 12.1.2 Attack II: Silencing a Client ............... 32
` 12.1.3 Attack III: Assuming the Identity of a Client 32
` 12.1.4 Attack IV: Eavesdropping .................... 33
` 12.2 Launching the Attacks ............................... 33
` 12.2.1 Approach I: Compromise a Legitimate
` STUN Server ................................. 33
` 12.2.2 Approach II: DNS Attacks .................... 34
` 12.2.3 Approach III: Rogue Router or NAT ........... 34
` 12.2.4 Approach IV: MITM ........................... 35
` 12.2.5 Approach V: Response Injection Plus DoS ..... 35
` 12.2.6 Approach VI: Duplication .................... 35
` 12.3 Countermeasures ..................................... 36
` 12.4 Residual Threats .................................... 37
` 13. IANA Considerations ....................................... 38
` 14. IAB Considerations ........................................ 38
` 14.1 Problem Definition .................................. 38
` 14.2 Exit Strategy ....................................... 39
` 14.3 Brittleness Introduced by STUN ...................... 40
` 14.4 Requirements for a Long Term Solution ............... 42
` 14.5 Issues with Existing NAPT Boxes ..................... 43
` 14.6 In Closing .......................................... 43
`
`Rosenberg, et al. Standards Track [Page 2]
`RFC 3489 STUN March 2003
`
` 15. Acknowledgments ........................................... 44
` 16. Normative References ...................................... 44
` 17. Informative References .................................... 44
` 18. Authors' Addresses ........................................ 46
` 19. Full Copyright Statement................................... 47
`1. Applicability Statement
` This protocol is not a cure-all for the problems associated with NAT.
` It does not enable incoming TCP connections through NAT. It allows
` incoming UDP packets through NAT, but only through a subset of
` existing NAT types. In particular, STUN does not enable incoming UDP
` packets through symmetric NATs (defined below), which are common in
`https://www.rfc-editor.org/rfc/rfc3489.txt
`2
`
`Apple Inc.
`Ex. 1019 - Page 6
`
`

`

` large enterprises. STUN's discovery procedures are based on
` assumptions on NAT treatment of UDP; such assumptions may prove
` invalid down the road as new NAT devices are deployed. STUN does not
` work when it is used to obtain an address to communicate with a peer
` which happens to be behind the same NAT. STUN does not work when the
` STUN server is not in a common shared address realm. For a more
` complete discussion of the limitations of STUN, see Section 14.
`2. Introduction
` Network Address Translators (NATs), while providing many benefits,
` also come with many drawbacks. The most troublesome of those
` drawbacks is the fact that they break many existing IP applications,
` and make it difficult to deploy new ones. Guidelines have been
` developed [8] that describe how to build "NAT friendly" protocols,
` but many protocols simply cannot be constructed according to those
` guidelines. Examples of such protocols include almost all peer-to-
` peer protocols, such as multimedia communications, file sharing and
` games.
` To combat this problem, Application Layer Gateways (ALGs) have been
` embedded in NATs. ALGs perform the application layer functions
` required for a particular protocol to traverse a NAT. Typically,
` this involves rewriting application layer messages to contain
` translated addresses, rather than the ones inserted by the sender of
` the message. ALGs have serious limitations, including scalability,
` reliability, and speed of deploying new applications. To resolve
` these problems, the Middlebox Communications (MIDCOM) protocol is
` being developed [9]. MIDCOM allows an application entity, such as an
` end client or network server of some sort (like a Session Initiation
` Protocol (SIP) proxy [10]) to control a NAT (or firewall), in order
` to obtain NAT bindings and open or close pinholes. In this way, NATs
` and applications can be separated once more, eliminating the need for
` embedding ALGs in NATs, and resolving the limitations imposed by
` current architectures.
`
`Rosenberg, et al. Standards Track [Page 3]
`RFC 3489 STUN March 2003
`
` Unfortunately, MIDCOM requires upgrades to existing NAT and
` firewalls, in addition to application components. Complete upgrades
` of these NAT and firewall products will take a long time, potentially
` years. This is due, in part, to the fact that the deployers of NAT
` and firewalls are not the same people who are deploying and using
` applications. As a result, the incentive to upgrade these devices
` will be low in many cases. Consider, for example, an airport
` Internet lounge that provides access with a NAT. A user connecting
` to the NATed network may wish to use a peer-to-peer service, but
` cannot, because the NAT doesn't support it. Since the administrators
` of the lounge are not the ones providing the service, they are not
` motivated to upgrade their NAT equipment to support it, using either
` an ALG, or MIDCOM.
` Another problem is that the MIDCOM protocol requires that the agent
` controlling the middleboxes know the identity of those middleboxes,
` and have a relationship with them which permits control. In many
` configurations, this will not be possible. For example, many cable
` access providers use NAT in front of their entire access network.
` This NAT could be in addition to a residential NAT purchased and
` operated by the end user. The end user will probably not have a
` control relationship with the NAT in the cable access network, and
`https://www.rfc-editor.org/rfc/rfc3489.txt
`3
`
`Apple Inc.
`Ex. 1019 - Page 7
`
`

`

` may not even know of its existence.
` Many existing proprietary protocols, such as those for online games
` (such as the games described in RFC 3027 [11]) and Voice over IP,
` have developed tricks that allow them to operate through NATs without
` changing those NATs. This document is an attempt to take some of
` those ideas, and codify them into an interoperable protocol that can
` meet the needs of many applications.
` The protocol described here, Simple Traversal of UDP Through NAT
` (STUN), allows entities behind a NAT to first discover the presence
` of a NAT and the type of NAT, and then to learn the addresses
` bindings allocated by the NAT. STUN requires no changes to NATs, and
` works with an arbitrary number of NATs in tandem between the
` application entity and the public Internet.
`3. Terminology
` In this document, the key words "MUST", "MUST NOT", "REQUIRED",
` "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
` and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
` [1] and indicate requirement levels for compliant STUN
` implementations.
`
`Rosenberg, et al. Standards Track [Page 4]
`RFC 3489 STUN March 2003
`
`4. Definitions
` STUN Client: A STUN client (also just referred to as a client)
` is an entity that generates STUN requests. A STUN client can
` execute on an end system, such as a user's PC, or can run in a
` network element, such as a conferencing server.
` STUN Server: A STUN Server (also just referred to as a server)
` is an entity that receives STUN requests, and sends STUN
` responses. STUN servers are generally attached to the public
` Internet.
`5. NAT Variations
` It is assumed that the reader is familiar with NATs. It has been
` observed that NAT treatment of UDP varies among implementations. The
` four treatments observed in implementations are:
` Full Cone: A full cone NAT is one where all requests from the
` same internal IP address and port are mapped to the same external
` IP address and port. Furthermore, any external host can send a
` packet to the internal host, by sending a packet to the mapped
` external address.
` Restricted Cone: A restricted cone NAT is one where all requests
` from the same internal IP address and port are mapped to the same
` external IP address and port. Unlike a full cone NAT, an external
` host (with IP address X) can send a packet to the internal host
` only if the internal host had previously sent a packet to IP
` address X.
`
`https://www.rfc-editor.org/rfc/rfc3489.txt
`
`4
`
`Apple Inc.
`Ex. 1019 - Page 8
`
`

`

` Port Restricted Cone: A port restricted cone NAT is like a
` restricted cone NAT, but the restriction includes port numbers.
` Specifically, an external host can send a packet, with source IP
` address X and source port P, to the internal host only if the
` internal host had previously sent a packet to IP address X and
` port P.
` Symmetric: A symmetric NAT is one where all requests from the
` same internal IP address and port, to a specific destination IP
` address and port, are mapped to the same external IP address and
` port. If the same host sends a packet with the same source
` address and port, but to a different destination, a different
` mapping is used. Furthermore, only the external host that
` receives a packet can send a UDP packet back to the internal host.
`
`Rosenberg, et al. Standards Track [Page 5]
`RFC 3489 STUN March 2003
`
` Determining the type of NAT is important in many cases. Depending on
` what the application wants to do, it may need to take the particular
` behavior into account.
`6. Overview of Operation
` This section is descriptive only. Normative behavior is described in
` Sections 8 and 9.
` /-----\
` // STUN \\
` | Server |
` \\ //
` \-----/
`
` +--------------+ Public Internet
` ................| NAT 2 |.......................
` +--------------+
`
` +--------------+ Private NET 2
` ................| NAT 1 |.......................
` +--------------+
` /-----\
` // STUN \\
` | Client |
` \\ // Private NET 1
` \-----/
` Figure 1: STUN Configuration
` The typical STUN configuration is shown in Figure 1. A STUN client
` is connected to private network 1. This network connects to private
` network 2 through NAT 1. Private network 2 connects to the public
` Internet through NAT 2. The STUN server resides on the public
` Internet.
` STUN is a simple client-server protocol. A client sends a request to
`https://www.rfc-editor.org/rfc/rfc3489.txt
`5
`
`Apple Inc.
`Ex. 1019 - Page 9
`
`

`

` a server, and the server returns a response. There are two types of
` requests - Binding Requests, sent over UDP, and Shared Secret
` Requests, sent over TLS [2] over TCP. Shared Secret Requests ask the
` server to return a temporary username and password. This username
` and password are used in a subsequent Binding Request and Binding
` Response, for the purposes of authentication and message integrity.
`
`Rosenberg, et al. Standards Track [Page 6]
`RFC 3489 STUN March 2003
`
` Binding requests are used to determine the bindings allocated by
` NATs. The client sends a Binding Request to the server, over UDP.
` The server examines the source IP address and port of the request,
` and copies them into a response that is sent back to the client.
` There are some parameters in the request that allow the client to ask
` that the response be sent elsewhere, or that the server send the
` response from a different address and port. There are attributes for
` providing message integrity and authentication.
` The trick is using STUN to discover the presence of NAT, and to learn
` and use the bindings they allocate.
` The STUN client is typically embedded in an application which needs
` to obtain a public IP address and port that can be used to receive
` data. For example, it might need to obtain an IP address and port to
` receive Real Time Transport Protocol (RTP) [12] traffic. When the
` application starts, the STUN client within the application sends a
` STUN Shared Secret Request to its server, obtains a username and
` password, and then sends it a Binding Request. STUN servers can be
` discovered through DNS SRV records [3], and it is generally assumed
` that the client is configured with the domain to use to find the STUN
` server. Generally, this will be the domain of the provider of the
` service the application is using (such a provider is incented to
` deploy STUN servers in order to allow its customers to use its
` application through NAT). Of course, a client can determine the
` address or domain name of a STUN server through other means. A STUN
` server can even be embedded within an end system.
` The STUN Binding Request is used to discover the presence of a NAT,
` and to discover the public IP address and port mappings generated by
` the NAT. Binding Requests are sent to the STUN server using UDP.
` When a Binding Request arrives at the STUN server, it may have passed
` through one or more NATs between the STUN client and the STUN server.
` As a result, the source address of the request received by the server
` will be the mapped address created by the NAT closest to the server.
` The STUN server copies that source IP address and port into a STUN
` Binding Response, and sends it back to the source IP address and port
` of the STUN request. For all of the NAT types above, this response
` will arrive at the STUN client.
` When the STUN client receives the STUN Binding Response, it compares
` the IP address and port in the packet with the local IP address and
` port it bound to when the request was sent. If these do not match,
` the STUN client is behind one or more NATs. In the case of a full-
` cone NAT, the IP address and port in the body of the STUN response
` are public, and can be used by any host on the public Internet to
` send packets to the application that sent the STUN request. An
` application need only listen on the IP address and port from which
`
`https://www.rfc-editor.org/rfc/rfc3489.txt
`
`6
`
`Apple Inc.
`Ex. 1019 - Page 10
`
`

`

`Rosenberg, et al. Standards Track [Page 7]
`RFC 3489 STUN March 2003
`
` the STUN request was sent. Any packets sent by a host on the public
` Internet to the public address and port learned by STUN will be
` received by the application.
` Of course, the host may not be behind a full-cone NAT. Indeed, it
` doesn't yet know what type of NAT it is behind. To determine that,
` the client uses additional STUN Binding Requests. The exact
` procedure is flexible, but would generally work as follows. The
` client would send a second STUN Binding Request, this time to a
` different IP address, but from the same source IP address and port.
` If the IP address and port in the response are different from those
` in the first response, the client knows it is behind a symmetric NAT.
` To determine if it's behind a full-cone NAT, the client can send a
` STUN Binding Request with flags that tell the STUN server to send a
` response from a different IP address and port than the request was
` received on. In other words, if the client sent a Binding Request to
` IP address/port A/B using a source IP address/port of X/Y, the STUN
` server would send the Binding Response to X/Y using source IP
` address/port C/D. If the client receives this response, it knows it
` is behind a full cone NAT.
` STUN also allows the client to ask the server to send the Binding
` Response from the same IP address the request was received on, but
` with a different port. This can be used to detect whether the client
` is behind a port restricted cone NAT or just a restricted cone NAT.
` It should be noted that the configuration in Figure 1 is not the only
` permissible configuration. The STUN server can be located anywhere,
` including within another client. The only requirement is that the
` STUN server is reachable by the client, and if the client is trying
` to obtain a publicly routable address, that the server reside on the
` public Internet.
`7. Message Overview
` STUN messages are TLV (type-length-value) encoded using big endian
` (network ordered) binary. All STUN messages start with a STUN
` header, followed by a STUN payload. The payload is a series of STUN
` attributes, the set of which depends on the message type. The STUN
` header contains a STUN message type, transaction ID, and length. The
` message type can be Binding Request, Binding Response, Binding Error
` Response, Shared Secret Request, Shared Secret Response, or Shared
` Secret Error Response. The transaction ID is used to correlate
` requests and responses. The length indicates the total length of the
` STUN payload, not including the header. This allows STUN to run over
` TCP. Shared Secret Requests are always sent over TCP (indeed, using
` TLS over TCP).
`
`Rosenberg, et al. Standards Track [Page 8]
`RFC 3489 STUN March 2003
`
` Several STUN attributes are defined. The first is a MAPPED-ADDRESS
` attribute, which is an IP address and port. It is always placed in
`https://www.rfc-editor.org/rfc/rfc3489.txt
`7
`
`Apple Inc.
`Ex. 1019 - Page 11
`
`

`

` the Binding Response, and it indicates the source IP address and port
` the server saw in the Binding Request. There is also a RESPONSE-
` ADDRESS attribute, which contains an IP address and port. The
` RESPONSE-ADDRESS attribute can be present in the Binding Request, and
` indicates where the Binding Response is to be sent. It's optional,
` and when not present, the Binding Response is sent to the source IP
` address and port of the Binding Request.
` The third attribute is the CHANGE-REQUEST attribute, and it contains
` two flags to control the IP address and port used to send the
` response. These flags are called "change IP" and "change port"
` flags. The CHANGE-REQUEST attribute is allowed only in the Binding
` Request. The "change IP" and "change port" flags are useful for
` determining whether the client is behind a restricted cone NAT or
` restricted port cone NAT. They instruct the server to send the
` Binding Responses from a different source IP address and port. The
` CHANGE-REQUEST attribute is optional in the Binding Request.
` The fourth attribute is the CHANGED-ADDRESS attribute. It is present
` in Binding Responses. It informs the client of the source IP address
` and port that would be used if the client requested the "change IP"
` and "change port" behavior.
` The fifth attribute is the SOURCE-ADDRESS attribute. It is only
` present in Binding Responses. It indicates the source IP address and
` port where the response was sent from. It is useful for detecting
` twice NAT configurations.
` The sixth attribute is the USERNAME attribute. It is present in a
` Shared Secret Response, which provides the client with a temporary
` username and password (encoded in the PASSWORD attribute). The
` USERNAME is also present in Binding Requests, serving as an index to
` the shared secret used for the integrity protection of the Binding
` Request. The seventh attribute, PASSWORD, is only found in Shared
` Secret Response messages. The eight attribute is the MESSAGE-
` INTEGRITY attribute, which contains a message integrity check over
` the Binding Request or Binding Response.
` The ninth attribute is the ERROR-CODE attribute. This is present in
` the Binding Error Response and Shared Secret Error Response. It
` indicates the error that has occurred. The tenth attribute is the
` UNKNOWN-ATTRIBUTES attribute, which is present in either the Binding
` Error Response or Shared Secret Error Response. It indicates the
` mandatory attributes from the request which were unknown. The
` eleventh attribute is the REFLECTED-FROM attribute, which is present
` in Binding Responses. It indicates the IP address and port of the
`
`Rosenberg, et al. Standards