TR-111 Applying TR-069 to Remote Managment of Home Networking Devices.

[TR-111 문서 원본]

[기본 동작 절차]

  1. The ACS enables the use of STUN in the CPE and designates the STUN server for the CPE to use.
  2. The CPE uses STUN to determine whether or not the CPE is behind a NAT Gateway.
  3. If the CPE is behind a NAT Gateway, the CPE must discover the NAT binding timeout(binding lifetime).
  4. The CPE sends periodic STUN Binding Requests at a sufficient frequency to keep alive the NAT binding on which it listens for UDP Connection Requests.
  5. When the CPE determines the public IP an port for the NAT binding, and whenever it subsequently changes, the CPE communicates this information(binding change) to the ACS. Following two approaches are provided by this document.
    • STUN-based Approach
    • Notification-based Approach
  6. Whenever the ACS wishes to establish a connection to the CPE, it may send a UDP ConnectionRequest to the CPE.

[CPE Requirements] : ManagementServer.STUNEnable=true

  • Determine the public IP and port for the NAT binding.
  • Discover the NAT binding timeout and send periodic STUN Binding Request at a rate necessary to keep alive this binding.
  • If the binding changes, the CPE must communicate this information to the STUN server with STUN optional attributes and update the UDPConnectionRequestAddress parameter.
    • STUN Optional attributes
      • CONNECTION_REQUEST_BINDING
      • BINDING-CHANGE
  • Listen for UDP Connection Request messages.

<Binding Discovery>

  • Regarding basic Binding discovery, refer to RFC-3489 STUN
  • If no STUNServerAddress is given, the address of the ACS determined from the host portion of the ACS URL must be used as the STUN server address.
  • If the CPE has been provisioned with a STUNUsername and STUNPassword in the ManagementServer object, then if the CPE receives a Binding Error Response with a fault code of 401(Unauthorized), then the CPE MUST resend the Binding Request with the USERNAME and MESSAGE-INTEGRITY attributes.
  • If the local IP of CPE changes, the CPE MUST re-discover the binding.
  • The STUN client in the CPE need not support the CHANGE-REQUEST attribute fo STUN Binding Requests, nor need it understand the CHANGED-ADDRESS, SOURCE-ADDRESS, and REFLECTED-FROM attributes present in a Binding Response.
    • So, STUN Server may need not support secondary IP.
  • The STUN client in the CPE need not support the STUN message for exchanging a Shared Secret.

<Maintaining the Binding>

  • To keep alive the NAT binding, the CPE MUST periodically retransmit Binding Request messages from the source address and port on which the CPE will be listening for UDP Connection Requests.
  • The CPE MUST NOT send theses Binding Requests more frequently than the STUNMinimemKeepAlivePeriod.
  • The CPE MUST send these Binding Requests at least as frequently as is specified by the STUNMaximumKeepAlivePeriod.
  • To learn the binding timeout, the CPE MUST be able to test whether the binding has timed out by sending Binding Request from a secondary source port distinct from the primary source port, and use the RESPONSE-ADDRESS attribute in the Binding Request.
  • The procedure of the binding timeout consists of two phases: a discovery phase, and a monitoring phase.

<Communication of the Binding Information to the ACS>

  • The CPE MUST support both methods.
    • The first method involves the use of optional STUN attributes(CONNECTION-REQUEST-BINDING, BINDING-CHANGE) sent in the Binding Request.
      • => tighter coupling between the ACS and STUN server.
    • The second method involves the CPE updating the value of the UDPConnectionRequestAddress parameter as the binding information changes.
      • => greater communication overhead.
  • Optional STUN attributes used in Binding Request messages
  • CPE MUST include the CONNECTION-REQUEST-BINDING attribute in every Binding Request message whose source address and port are the address and port on which it is listening for UDP Connection Request_ message.
  • In every Binding Request message sent in which the CPE includes the CONNECTION-REQUEST-BINDING attribute, if the value of the STUNUsername parameter in the ManagementServer object is non-empty, the CPE MUST include the USERNAME attribute.
  • Whenever the CPE detects a change to the NAT binding, it MUST immediately send a Binding Request message from the primary source port that includes the BINDING-CHANGE attribute.
  • In all other Binding Request message, the CPE MUST NOT include the BINDING-CHANGE attribute.
  • If the ACS has set the Notification attribute on the UDPConnectionRequestAddress parameter to Active Notification, then whenever the binding information has changed, the CPE MUST establish a connection to the ACS and include the UDPConnectionRequestAddress in the Inform message.

<UDP Connection Requests>

  • A CPE MUST listen for UDP Connection Request message. The following requirements are met.
    • HTTP 1.1
    • HTTP Get Method
    • Following HTTP query arguments are used
      • ts(TimeStamp)
      • id(messageID)
      • un(UserName)
      • sig(SIGnature)
  • Because STUN responses and UDP Connection Requests will be received on the same UDP port, the CPE MUST distinguish STUN message from UDP Connection Requests.
    • STUN message : 0 or 1 value is leading.
    • UDP Connection Request: A alphabetic letter is leading.

[ACS Requirements]

<STUN Server Requirements>

  • The STUN server need not support the Shared Secret exchange mechanism.
  • The STUN server need not support a secondary source IP address or port for sending Binding Response.
  • The STUN server may require message integrity for any received Binding Requirement( 401 fault code is used).

<Determination of the Binding Information>

  • The ACS may choose either of the two defined mechanism to determine the current binding information from a CPE.

STUN-based Approach

  • The ACS SHOULD set a non-empty STUNUsername and STUNPassword in the ManagementServer object.
  • The STUNUsername and STUNPassword must be unique among all CPE to ensure that the CPE can be distinguished.
  • Whenever the STUN server receives a Binding Request that includes both the BINDING-CHANGE and CONNECTION-REQUEST-BINDING attributes:
    • The STUN server SHOULD respond with a Binding Error Response with fault code 401 in order to force the CPE to retransmit the Binding Request with message integrity.
    • When the STUN server receives the retransmitted request with message integrity, it SHOULD authenticate the requester.
      • => This can involve communication between the STUN server and ACS.
    • The STUN server SHOULD extract the source IP and port from the Binding Request message, and record these as the new IP and port to be used for UDP Connection Requests.
    • The STUN server may inform the ACS of the IP address and port along with the corresponding STUNUsername.
    • The STUN server should perform the above only once for a given TransationID in the Binding Request.
  • This approach is tighter coupling between the STUN server and the ACS than the notification-based approach.

Notification-based Approach

  • If the ACS chooses to use Active Notification on the UDPConnectionRequestAddress parameter, it SHOULD do the following:
    • Record changes to the UDPConnectionRequestAddress parameter whenever this parameter is included in the INFORM message.
    • If the port is not given in the UDPConnectionRequestAddress parameter, port 80 MUST be used as the default value.
    • Observe the value of the NATDetected parameter.
      • => If the NATDetected is false, the ACS MAY use TCP-based Connection Request.
  • The ACS MAY choose not to require message integrity or authenticate any STUN Binding Requests. Therefore, the ACS need not set a STUNUsername or STUNPassword in the CPE.

<UDP Connection Requests sent by ACS>

  • The ACS SHOULD send multiple copies of the same UDP Connection Request message because of UDP packet loss.
  • The format of the UDP Connection Request message MUST conform to the following requirements:
    • It MUST be a valid HTTP 1.1 Get message.
    • It MUST contain no Message Body.
      • => If a Content-Length header is present, Its value MUST be zero.
    • URI format:
      • "http" or "HTTP"
      • The Path portion of URI MUST be empty.
      • Query string arguments : ts, id, un, sig, cn(Cnonce).
  • example)
    • http://10.1.1.1:8080?ts=1120673700&id=1234&un=CPE57689&cn=XTGRWIPC6D3IPXS3&sig=3545F7B5820D76A3DF45A3A509DA8D8C38F13512

[Message Flows]

  • Binding discovery/maintenance from the primary source port
    • CPE가 A1, P1 을 사용하여 STUN Server(A3, P3)에게 UDP 패킷을 전송하면 NAT에 external IP/Port A1', P1' 가 뚫림.
    • CPE가 A1, P1 을 사용하여 주기적으로 전송해야 NAT의 A1', P1' binding 정보가 유지됨.
  • Binding Request from secondary source port for binding timeout discovery

    • A1', P1' binding 된 후에 T1시간 후에 CPE가 A1, P2 을 사용하고 RESPONSE-ADDRESS에 NAT binding정보 A1', P1' 정보를 사용하여 Binding Request를 보낸다.
    • STUN Server가 RESPONSE-ADDRESS(A1', P1')으로 Binding Response 보내는데 CPE가 이 Response를 수신하면 NAT binding이 유지되고 있는 상태인 것이다. Response를 수신했다면 CPE는 T1시간을 늘려서 Response를 못 받을 때까지 반복한다.
    • T1 시간을 늘리고 줄이는 방법은 binary search 알고리즘을 사용한다.
  • Binding change notification authenticated by ACS

    • STUN-based approach 설명하는 그림임.
    • NAT binding 정보가 변경되어서 Binding Request보낼때 CONNECTION-REQUEST-BINDING, BINDING-CHANGE, USERNAME attribute를 포함하여 보낸다(Notification-based approach에서도 동일함).
    • CPE가 STUN server로부터 401(Unauthorized) fault code 수신하면, 위 메시지를 재전송하는데 MESSAGE-INTEGRITY 를 포함하여 보낸다.
    • STUN Server가 재전송한 Binding Request를 수신하면 ACS와 communication하면서 Username 과 Password 및 MESSAGE-INTEGRITY 정보등을 사용하여 CPE를 인증하게 된다.
    • 인증이 성공했다면 ACS가 관리하는 Username에 해당하는 UDP ConnectionRequestAddress 정보에 전달받은 A1', P1' 정보로 셋한다.
    • 이 이후 ACS는 UDP Connection Request를 전송할 수 있게 된다.
  • Binding change notification not authenticated by ACS
    • Notification-based approach 임.
    • STUN Server로부터 401 fault code 받지 않고 성공하는 Response를 수신하는 경우임.
    • STUN Server와 ACS간의 communication 하는 것 없음. 따라서 Username 은 사용되지 않음.
    • 이 경우는 CPE가 NAT binding 정보 변경을 감지했을 때, 위 Binding Request 전송과 함께 ACS에게 Inform 메시지로 UDPConnectionRequestAddress 정보가 변경되었다고 알려줘야 한다.
  • UDP Connection Request

    • UDP Connection Request 메시지는 UDP를 사용하기 때문에 packet loss를 감안하여 여러번 전송한다.
    • 이때 CPE는 중복 전송된 UDP Connection Request 메시지를 받을 수 있는데 이때 UDP Connection Request message 안에 ts, id, sig 정보등을 참고하여 이미 처리완료한 request message이면 무시하도록 해야 한다.

댓글

댓글 쓰기