Subject: Re: (NAT) NAT internet/outside miss

From: "Mike Borella" <[email-masked]>
Date: Mon, 1 Nov 1999 14:53:13 -0600

---------------------- Forwarded by Mike Borella/MW/US/3Com on 11/01/99 02:57 PM
---------------------------

Mike Borella/MW/US/3Com
11/01/99 02:51 PM

Sent by:  Mike Borella

To:   "Saint-Hilaire, Ylian" <[email-masked]>
cc:
Subject:  Re: (NAT) NAT internet/outside miss  (Document link not converted)

Using RSIP, the clients should always be able to figure out
which addresses are inside and which are outside.  In practice,
in most cases it should be obvious.  For those in which it is not,
there is the QUERY method.

-Mike

"Saint-Hilaire, Ylian" <[email-masked]> on 10/29/99 08:41:57 PM

Please respond to "Saint-Hilaire, Ylian" <[email-masked]>

Sent by:  "Saint-Hilaire, Ylian" <[email-masked]>

To:   [email-masked]
cc:    (Mike Borella/MW/US/3Com)
Subject:  (NAT) NAT internet/outside miss

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.

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

---

From: "Mike Borella" <[email-masked]>
Date: Mon, 1 Nov 1999 14:58:23 -0600

I think that every time a client registers it should time out a cache, if not
sooner.
But in general, caching the info is up to the client.  I can't think of subnet
topology
changing *that* fast...

-Mike

"Saint-Hilaire, Ylian" <[email-masked]> on 10/30/99 06:39:23 PM

To:   "'Michael C. Richardson'" <[email-masked]>, [email-masked]
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: (NAT) NAT internet/outside miss

If the RSIP server could notify that the list of intranet addresses is
complete (not a subset), the client could choice not to query each time or
maintain a cache, it could save a trip to the RSIP server each time the
client initiates traffic to a new address. Still, the current system should
also be maintained.

If a caching scheme is used, should there be a recommended cache lifetime or
a way for the server to invalidate client caches?

Ylian Saint-Hilaire
Intel Communication Architecture Labs

-----Original Message-----
From: Michael C. Richardson [mailto:[email-masked]]
Sent: Saturday, October 30, 1999 3:54 PM
To: [email-masked]
Subject: Re: (NAT) NAT internet/outside miss

>>>>> "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.
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

-