Hi, folks, I have some questions/comments on RFC 5572 on which I'd be glad if you could shed some light:
Section 2.1 states: > TSP is also used to discover if a NAT is in the path. In this > discovery mode, the client sends a TSP message over UDP, containing > its tunnel request information (such as its source IPv4 address) to > the TSP server. This seems to imply that even if TCP is being used as the transport protocol for TSP, the "nat discovery" is performed with UDP. However, after reading the whole doc, I don't think this is the case. -- Am I missing something? Section 2.1 states: > If an IPv4 NAT is discovered, then IPv6 over UDP-IPv4 tunnel > encapsulation is selected. Once the TSP signaling is done, the > tunnel is established over the same UDP channel used for TSP, so the > same NAT address-port mapping is used for both the TSP session and > the IPv6 traffic. If no IPv4 NAT is detected in the path by the TSP > server, then IPv6 over IPv4 encapsulation is used. This seems to imply that the NAT is of type "cone". However, you don't specify any mechanism to discover this (the NAT might be of some other type!). -- Am I missing something? Section 4.4.1 states: > TSP signaling over UDP/v4 MUST be used if a v6 over UDP over IPv4 > (v6udpv4) tunnel is to be requested (e.g., for NAT traversal). I don't follow. Why is this a MUST? -- after all, TSP is the control channel for the tunnel, but not the tunnel itself... Section 4.4.1.2 states: > While TCP provides the connection-oriented and reliable data delivery > features required during the TSP signaling session, UDP does not > offer any reliability. This reliability is added inside the TSP > session as an extra header at the beginning of the UDP payload. > [....] > > The algorithm used to add reliability to TSP packets sent over UDP is > described in Section 22.5 of [UNP]. If you want reliability, congestion control, etc., why not just use TCP, rather than reinvent the wheel in the app over UDP? In Section 4.4.3 the document states: > The example in Figure 13 shows a client requesting an anonymous > v6udpv4 tunnel, indicating that a keep-alive packet will be sent > every 30 seconds. The tunnel broker responds with the tunnel > parameters and indicates its acceptance of the keep-alive period > (Section 4.6). Finally, the client sends an accept message to the > server. What's the point of the server "accepting" the keep-alive period? What if the client doesn't care about the server response? Is the server expected to rate-limit the responses to ICMP echoes to at most 1 per keep-alive period? Section 4.6 states: > The IPv6 destination address of the echo message MUST > be the address from the 'keepalive' element sent in the tunnel > response during the TSP signaling (Section 4.4.3). I think this requirement is rather dangerous. Why would the client send keep-alives to other address than that of the remote tunnel endpoint? Section 4.6 states: > The broker can send a different keep-alive interval from the value > specified in the client request. The client MUST conform to the > broker-specified keep-alive interval. Ditto. The client should at least sanitize the value proposed by the server, and impose a lower limit. Section 4.7.2: > The 'client' element contains 3 sub-elements: 'address', 'router', > and 'keepalive'. These elements are used to describe the client > request and will be used by the server to create the appropriate > tunnel. The client element is the only element sent by a client. > > The 'address' element is used to identify the client IP endpoint of > the tunnel. When tunneling over IPv4, the client MUST send only its > IPv4 address to the server. When tunneling over IPv6, the client > MUST only send its IPv6 address to the server. Why not use the address of the incoming packet? If the server blindly trusts the 'address' sub-element, an attacker could cause the tunnel-broker to create a tunnel with a victim (third-party) system. Thanks! Kind regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
