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

From: "Mike Borella" <[email-masked]>
Date: Thu, 9 Mar 2000 14:12:55 -0600

Iyer and all,

I apologize for not responding in detail to these comments.  I will very
soon.  I'd also like to let everyone know that if there are any more comments
on either the framework or protocol drafts, please send them over asap (like
today).  I'm shooting for a minor rev of each before tomorrow's cutoff.

-Mike

"Iyer, Prakash" <[email-masked]> on 02/29/2000 04:03:50 PM

Please respond to "Iyer, Prakash" <[email-masked]>

Sent by:  "Iyer, Prakash" <[email-masked]>

To:   [email-masked]
cc:    (Mike Borella/MW/US/3Com)
Subject:  (NAT) RSIP: comments on latest draft versions

> 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.

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

---

From: "Mike Borella" <[email-masked]>
Date: Fri, 10 Mar 2000 07:12:10 -0600

Oops, this should have gone to the list...

---------------------- Forwarded by Mike Borella/MW/US/3Com on 03/10/2000 07:08
AM ---------------------------

Mike Borella/MW/US/3Com
03/09/2000 04:36 PM

Sent by:  Mike Borella   -   AT&SE, Carrier R&D

To:   "Iyer, Prakash" <[email-masked]>
cc:
Subject:  Re: (NAT) RSIP: comments on latest draft versions  (Document link:
      Database 'Mike Borella', View '($Sent)')

Prakash,

Thanks for your comments.  I've addressed them below.

To:   [email-masked]

> an external Gatekeeper. If the proxy is eliminated, how will this continue

This is a much bigger problem than RSIP.  In order for a SIP or 323 proxy/GK
to operate with either NAT or RSIP, the proxy/GK may have to be able to dump
state down to the NAT/RSIP gateway.  Both boxes will probably have to live
on the "edge" in the sense that they both have public and private IPs.
Not at all clean.  For your particular scenario, I don't understand what the
problem is.  The client uses a public IP.  The GK doesn't necessarily
know the difference.

> (or other de-MUXing parameters) to each client.

We're not talking about addresses, we're talking about address/port pairs.
Read the paragraph again with that in mind and it should be clear that we
never imply that a single IP can't be shared.

> generate datagrams larger than 512 bytes.

Good point.  I'll have to think about this one further.

> revision history. And is this an issue if UDP ise used as transport for

How so?  DEALLOCATE is definitely not necessary.  I don't think OK is either.

> in private realm and M IP addresses, where N >= M and M > 1.

The whole draft is about this situation.  What in particular needs to be
explained?

> server allocated range. Section 7.1 should be clear on this  issue.

If you mean that an RSIP client that is allocated port X to use with public
address A also wants to use port X with local address B, then yes, that's
perfectly fine.  "RSIP ports" are different from tcp or udp ports.

> RSIP client simultaneously.

Why? I belive that this is a useful feature for policy routing support,
and I can't imagine what any drawbacks might be.

> respective address or ports parameters

Yes, this is cruft left over from the change in how don't care is
represented.  Thanks for pointing it out.  Will fix.

> netmask field. What's the format of the network field - an example will

An IP address parameter.  I think this is clear in sec. 9.14.2, but let me know
if it isn't and feel free to suggest an improvement.

> the client may be included in a response from the RSIP server.

My intention has been that if a client request cannot be granted as is, then
an error should be returned, telling the client what was wrong, and then the
client will determine what to do next.  For example, if a client asks for 3
ports
but the server only grants 2, this is ok if the client only needs 1 or 2.  But
if the client actually needs all 3 ports, then it will not be able to do
whatever
it was trying to do.  Of course it may then request another port in a separate
binding, but this can be problematic if the server revokes one binding and not
the other.  One point of bindings is to logically group the resources that
a client needs for certain tasks.  In any case, I'll add some words to address
this and we can debate in Adelaide.

> Also need an example of a case where a client may specify a don't care

This is the usual case - a client application using an ephemeral port.

> describes the consequence if a client does not require ports).

The paragraph above specifically says "to protect a TCP or UDP application".
In that case, ports MUST be allocated.

> values but the semantics are not consistent with any text in the protocol

That's because there is no analogous case in the protocol draft.

> * ASSIGN_REQUEST_RSIPSEC is missing the Overall Length parameter.

Thanks.  We'll fix this.

> not modify ports for tunnel mode IPsec.

Port mapping is not necessary at all with IPSEC.  That's what we're
using the SPIs for.

-Mike

-