Subject: (NAT) NAT internet/outside miss

From: "Saint-Hilaire, Ylian" <[email-masked]>
Date: Fri, 29 Oct 1999 18:41:57 -0700

Clients using an RSIP gateway know that addresses or subnets are "inside" or
must be NAT'ed. Unless they query the RSIP server every time, or the server
gave the clients a complete list of "inside" addresses, clients could "host
nat" and send to the gateway "inside" traffic. Does RSIP presume that
clients will always figure correctly inside from outside addresses?

If RSIP is used with IPsec, the clients must be correct all the time since
the AH hash is computed on an outside address. When the client gets a list
of "inside" subnets from RSIP, should the client know or assume this list to
be complete? If not, should the client query every address that looks to be
"outside"?

Ylian Saint-Hilaire
Intel - Communication Architecture Labs
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: "Michael C. Richardson" <[email-masked]>
Date: Sat, 30 Oct 1999 18:53:39 -0400

>>>>> "Saint-Hilaire," == Saint-Hilaire, Ylian <[email-masked]> writes:
    Saint-Hilaire,> Clients using an RSIP gateway know that addresses or
    Saint-Hilaire,> subnets are "inside" or must be NAT'ed. Unless they query
    Saint-Hilaire,> the RSIP server every time, or the server gave the

  They could query the RSIP gateway every time, and cache the answers.
  A DNS record could also be designed to indicate things (in the in-addr.arpa
reverse map), and RSIP-aware internal DNS servers could add that info to
queries. That would piggy back the query into an operation the client is
already doing, and reuse the DNS caching and signing mechanisms.

   :!mcr!:            |  Cow#1: Are you worried about getting Mad Cow Disease?
   Michael Richardson |  Cow#2: No. I'm a duck.
 Home: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[email-masked]</A>. PGP key available.
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.