Subject: (NAT) RSIP: comments on latest draft versions

From: "Iyer, Prakash" <[email-masked]>
Date: Tue, 29 Feb 2000 14:03:50 -0800

> rsip-framework-03 draft:
> * In the introduction section, text says
> While NAT does not require a host to be aware of its presence, it requires
> the presence of a proxy module, the application layer gateway (ALG),
> within the NAT router for each application that embeds addressing
> information, IP address or port content, within the packet payload (e.g.,
> FTP). RSIP (Realm Specific IP) provides an alternative to remedy these
> limitations.
> 
> What's needed is an example to show how proxies are completely eliminated
> with RSIP. Applications that use the local IP address in application PDUs
> may have to use the private realm IP address for communication in the
> private realm and the public IP address for communication with a node in
> the public realm. An example on how this can be done should be included in
> the framework draft. Consider active mode FTP and H.323 apps (e.g.
> NetMeeting) as examples on the client side. On the gateway side, an H.323
> proxy in a NAT environment is an example: if an H.323 application tries to
> register with a Gatekeeper, the proxy translates the source IP address to
> the external (WAN) IP address before forwarding the registration packet to
> an external Gatekeeper. If the proxy is eliminated, how will this continue
> to work?
> 
> * Comment on the following text,
> When using RSAP-IP, an RSIP server maintains a pool of IP addresses as
> well as pools of port numbers per address. RSIP clients lease an IP
> address and one or more ports to use with it.  Once an address / port
> tuple has been allocated to a particular client, only that  client may use
> the tuple until it is returned to the pool(s.
> In the trivial case of a pool of 1 IP address, does this imply that only 1
> client can be supported in the private realm. That is clearly not the
> case. The server can allocate the same IP address to multiple clients in
> the private realm and allocate a different, non-overlapping range of ports
> (or other de-MUXing parameters) to each client.
> 
> * The draft recommends an MTU size of 512 bytes for UDP datagrams to avoid
> fragmentation. How will this accommodate video applications that can
> generate datagrams larger than 512 bytes.
> 
> rsip-protocol-05 draft:
> * OK and DEALLOCATE messages have been dropped but not mentioned in
> revision history. And is this an issue if UDP ise used as transport for
> the control channel.
> 
> * Need a section discussing how RSIP works in an environment with N hosts
> in private realm and M IP addresses, where N >= M and M > 1.
> 
> * Can an RSIP client using RSAP-IP use its own (a different set of) ports
> after it requests and is allocated ports by the RSIP server. It seems like
> this should be possible for communication on the local LAN but to keep the
> protocol simple, this may be explicitly disallowed. For communication with
> external (public) hosts, the RSIP client MUST use ports from an RSIP
> server allocated range. Section 7.1 should be clear on this  issue.
> 
> * An RSIP gateway should not allocate more than one 1 IP address to an
> RSIP client simultaneously.
> 
> * Text is inconsistent in specifying handling of "Don't Care" values. 
> For example,  section 8.1 states
> a "don't care" value for an address is signified by a setting the length
> field to 1 and omitting the value field.
> 
> But in section 9.8.3,
> An RSIP client may indicate that it has no preference for local address or
> ports, the RSIP client may place a "don't care" value of zeros in the
> respective address or ports parameters
> 
> * QUERY_REQUEST specifies a network tuple which has a network and a
> netmask field. What's the format of the network field - an example will
> help.
> 
> * Handling of port requests should be documented clearly. For example, if
> a client requests 4 ports from an RSIP server, the server MAY respond with
> the same or a smaller number of ports. Some or all of the ports requested
> the client may be included in a response from the RSIP server.
> 
> Also need an example of a case where a client may specify a don't care
> value for a port.
> 
> rsip-ipsec-02 draft:
> * The following text is confusing:
> If the RSIP client wishes to use IPsec to protect a TCP or UDP
> application, it MUST use the port range parameter (see Appendix A).
> Otherwise, it MUST set the port parameters to the "don't need" value.
> This is accomplished by setting the      length field to 0, and by
> omitting both the number field and the port field.  
> 
> Looks like the first instance of MUST should be a SHOULD (the Appendix
> describes the consequence if a client does not require ports).
> 
> The second part states that fields can be omitted to specify don't need
> values but the semantics are not consistent with any text in the protocol
> draft.
> 
> * ASSIGN_REQUEST_RSIPSEC is missing the Overall Length parameter.
> 
> * The draft does not recommend the use of port mapping in IPsec transport
> mode. For example, is it OK to port map for transport mode IPsec but to
> not modify ports for tunnel mode IPsec.
> 
-Prakash Iyer
Intel Arch Labs

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.