Subject: RE: (NAT) RSIP protocol-04 draft - suggested changes

From: "Iyer, Prakash" <[email-masked]>
Date: Wed, 24 Nov 1999 08:48:39 -0800

It won't be sufficient to indicate a list with a "complete" bit. The -03
draft reads

"The RSIP server MAY respond with a list of all networks and/or addresses
that 
are on the private side of the network."

Implementations may never return a complete list and will still be compliant
with
the spec.

To make this work, 2 changes are necessary:
1. A change to QUERY_REQUEST and QUERY_RESPONSE semantics so that an RSIP
client
   can request and obtain a complete list of internal addresses / subnets
from an
   RSIP server.

   Suggested solution:
   -------------------
   Change the text to reflect the following:
   If a client sets "don't care" values in <Address> AND [Address (netmask)]
in the 
   QUERY_REQUEST message, an RSIP server MUST respond with a COMPLETE list
of addresses 
   / subnets.

   If a client sets specific values in <Address> OR [Address (netmask)] then
an RSIP
   server MAY respond with a COMPLETE list OR a list of addresses / subnets
included
   in the QUERY_REQUEST OR "don't care" if the addresses / subnets in the
QUERY_REQUEST
   are NOT local. 
   
2. The ability for an RSIP server to indicate asynchronously if addresses or
subnets
   change so that clients can query and obtain updated lists. This is
necessary to
   avoid having to poll the RSIP server on a very regular basis.

   Suggested solution:
   -------------------
   Define a new message,
   <UPDATE_NETWORK> ::= <Version>
                       <Message Type>
                       <Client ID>
                       <Bind ID>
                       [Message ID]

   An RSIP server sends this message to registered clients if address(es) or
subnets
   change. RSIP clients MAY respond with an OK message, and MAY follow-up
with a
   QUERY_REQUEST message. Again, RSIP clients can set "don't care" values in
   [Address (netmask)] to require that the RSIP send back a complete list of

   address(es) / subnets.

-----------------------

The other point was a general clairification on the sematics of resource
allocation request messages, for example PORTS. The format for requesting
PORTS as defined in the draft is
reproduced below:

7.2.  Ports

         Code    Length   Number     Port            Port
      +-------+---------+--------+---------+     +---------+
      |   2   | 2 bytes | 1 byte | 2 bytes | ... | 2 bytes |
      +-------+---------+--------+---------+     +---------+

      The ports parameter encodes one or more TCP or UDP ports.  When a
      single port is specified, the value of the number field is 1 and
      there is one port field following the number field.  When more
      than one port is specified, the value of the number field will
      indicate the total number of ports contained, and the parameter
      may take one of two forms.  If there is one port field, the ports
      specified are considered to be contiguous starting at the port
      number specified in the port field.  Alternatively, there may be a
      number of port fields equal to the value of the number field.  The
      number of port fields can be extrapolated from the length field.

      In some cases, it is necessary to specify a don't care value for
      one or more ports.  This is accomplished by filling the one or
      more port fields with zeros.

Can this mean one of the following: (depending on micro or macro policy)

1. An RSIP server can reject all of the PORTS "suggested" by a client in an 
   ASSIGN_REQUEST message.

2. An RSIP server can respond with a subset or the entire list of ports
suggested
   by the client.

3. An RSIP server can respond with a subset of ports suggested by the RSIP
client
   plus new ports that it allocates. The number of ports returned MUST not
exceed
   the number requested by the client.

4. An RSIP server may respond with a different list of PORTS, the number of
which
   MUST NOT exceed the number requested by an RSIP client.

5. In case where a client sets "Don't Care" values in its suggested list of
ports,
   an RSIP server MAY respond with a subset of valid ports suggested by the
RSIP 
   client plus new ports that it allocates, the total number of ports NOT
exceeding
   what was requested by the client.

If all the above are true, I'd recommend that we include text to this effect
in the
-04 draft.

-----Original Message-----
From: Mike Borella [mailto:[email-masked]]
Sent: Tuesday, November 23, 1999 3:16 PM
To: Shane Kerr
Cc: Bernard Aboba; 'Steven M. Bellovin'; 'Iyer, Prakash'; 'Pyda
Srisuresh'; 'Eliot Lear'; [email-masked]
Subject: (NAT) Re: RSIP traffic load

I haven't figured out exactly how to do this yet,
but it would be useful to be able to set a "complete" bit in
the query response which tells the client that *all* of the local addresses
are listed in the message.  This would prevent the client from querying more
than once per RSIP session.

This isn't in -04, but I hope to get it in soon.

-Mike

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

---

From: "Saint-Hilaire, Ylian" <[email-masked]>
Date: Wed, 24 Nov 1999 11:03:35 -0800

RSIP-03: "Pipelining of requests and aggregation of responses MUST NOT be
allowed."

Since we now are using TCP, I was wondering if pipelining of RSIP requests
could be allowed.    Right now, an RSIP client implementation must keep a
list of pending requests and hand them off to the network one by one as
responses come in. With TCP, we could hand-off all the requests to the
network and wait for responses. An RSIP server must be required to respond
to the messages in the same order, but since TCP will never place the
messages out of order, clients should not have a problem pairing the
requests with the responses. At the very least, the restriction can be
lifted and implementations simplified.

Ylian Saint-Hilaire
INTEL - Communication Architecture Labs

-

---

From: Shane Kerr <[email-masked]>
Date: Wed, 24 Nov 1999 13:19:27 -0800 (PST)

>    avoid having to poll the RSIP server on a very

This actually touches on a larger issue.  The RSIP
protocol, as written, can be implemented by a simple
request/response program, EXCEPT for this proposed
change, and the DEALLOCATE message, which are
initiated by the server.  I don't especially mind
this, but it does complicate clients somewhat.

We'll probably need to make message ID's mandatory for
all messages if this is the case, so that the client
can figure out what packets are responding to what. 
Either that, or make the protocol a symmetric
request/response protocol, where the client and the
server can have at most one outstanding request at a
time.  Yuck.

Personally, I'd rather not have asynchronous messages
from the server.

Shane Kerr
__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: "Mike Borella" <[email-masked]>
Date: Wed, 24 Nov 1999 16:01:46 -0600

I'm not sure why we'd need to keep a list of requests.  It seems
easier for implementations to perform the request, wait for the
response, and then follow the next action determined by the
state machine.

What if the first request of a list is denied?  Then it is likely that
the rest will be denied as well because the client and server are
not in synch.

-Mike

"Saint-Hilaire, Ylian" <[email-masked]> on 11/24/99 01:03:35 PM

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

To:   [email-masked], Mike Borella/MW/US/3Com, Shane Kerr
      <[email-masked]>
cc:   Bernard Aboba <[email-masked]>, "'Steven M. Bellovin'"
      <[email-masked]>, "'Pyda Srisuresh'" <[email-masked]>, "'Eliot
      Lear'" <[email-masked]>
Subject:  RE: (NAT) RSIP protocol-04 draft - suggested changes

Ylian Saint-Hilaire

-

---

From: "Mike Borella" <[email-masked]>
Date: Wed, 24 Nov 1999 15:55:27 -0600

How about the server can do one of two things:

- Transmit a single response (address)
- Transmit all of the addresses.

Then if a client gets more than one address, it can assume that it has them all.

The client should not be able to "force" the server to make certain
decisions.  Since the server enforces policy, the client will always
have to play by the server's rules.

I tihnk it would be better to avoid the asychronous server messages,
and I'm basically in  agreement with Shane regarding them.

I like the clarification about regarding port allocation.  That would
be a good thing to make explicit.

-Mike

"Iyer, Prakash" <[email-masked]> on 11/24/99 10:48:39 AM

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

To:   Mike Borella/MW/US/3Com, Shane Kerr <[email-masked]>
cc:   Bernard Aboba <[email-masked]>, "'Steven M. Bellovin'"
      <[email-masked]>, "'Pyda Srisuresh'" <[email-masked]>, "'Eliot
      Lear'" <[email-masked]>, [email-masked]
Subject:  RE: (NAT) RSIP protocol-04 draft - suggested changes

   Suggested solution:
   -------------------

   Suggested solution:
   -------------------
   Define a new message,

   address(es) / subnets.

-----------------------

7.2.  Ports

-----Original Message-----
From: Mike Borella [mailto:[email-masked]]
Sent: Tuesday, November 23, 1999 3:16 PM
To: Shane Kerr
Cc: Bernard Aboba; 'Steven M. Bellovin'; 'Iyer, Prakash'; 'Pyda

-Mike

-

---

From: "Iyer, Prakash" <[email-masked]>
Date: Wed, 24 Nov 1999 15:29:22 -0800

As long as the doc states explicitly that whenever more than 1 address is
returned, the list is ALWAYS expected to be complete, I'm OK with it. That's
the only way the client can assume that it has the complete list. Otherwise
we have not solved the problem - we are back to the MAY semantics as
currently specified.

Secondly, if a client has a "complete" list, it is safe to interpret that
there is no need to query the RSIP server if a new destination address is
encountered. So now the client may end up encapsulating a packet bound to a
new local subnet in an RSIP IP-IP tunnel. This will cause additional
handshake between the client and the server, loss of packets etc. From an
implementation standpoint this is not graceful by any means.

The notify packet is not expected to be used often and is a much cleaner
solution. Don't understand why you are so concerned with it.

-Prakash

-----Original Message-----
From: Mike Borella [mailto:[email-masked]]
Sent: Wednesday, November 24, 1999 1:55 PM
To: Iyer, Prakash
Cc: [email-masked]
Subject: RE: (NAT) RSIP protocol-04 draft - suggested changes

Then if a client gets more than one address, it can assume that it has them
all.

-Mike

      <[email-masked]>, "'Pyda Srisuresh'" <[email-masked]>,
"'Eliot

   Suggested solution:
   -------------------

   Suggested solution:
   -------------------
   Define a new message,

   address(es) / subnets.

-----------------------

7.2.  Ports

-----Original Message-----
From: Mike Borella [mailto:[email-masked]]
Sent: Tuesday, November 23, 1999 3:16 PM
To: Shane Kerr
Cc: Bernard Aboba; 'Steven M. Bellovin'; 'Iyer, Prakash'; 'Pyda

-Mike

-

---

From: "Mike Borella" <[email-masked]>
Date: Wed, 24 Nov 1999 17:40:27 -0600

Another thought - the client SHOULD re-query the server every so often
(say, upon lease renewal) in order to catch changes.

-Mike

"Iyer, Prakash" <[email-masked]> on 11/24/99 05:29:22 PM

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

To:   Mike Borella/MW/US/3Com, "'Shane Kerr'" <[email-masked]>
cc:   [email-masked]
Subject:  RE: (NAT) RSIP protocol-04 draft - suggested changes

-Prakash

-----Original Message-----
From: Mike Borella [mailto:[email-masked]]
Sent: Wednesday, November 24, 1999 1:55 PM
To: Iyer, Prakash
Cc: [email-masked]
Subject: RE: (NAT) RSIP protocol-04 draft - suggested changes

-Mike

   Suggested solution:
   -------------------

   Suggested solution:
   -------------------
   Define a new message,

   address(es) / subnets.

-----------------------

7.2.  Ports

-----Original Message-----
From: Mike Borella [mailto:[email-masked]]
Sent: Tuesday, November 23, 1999 3:16 PM
To: Shane Kerr
Cc: Bernard Aboba; 'Steven M. Bellovin'; 'Iyer, Prakash'; 'Pyda

-Mike

-

-

---

From: "Mike Borella" <[email-masked]>
Date: Wed, 24 Nov 1999 17:39:24 -0600

We have to consider the "little RSIP" scope here - small number
of clients, small number of local subnets, static configuration, few changes.
There is no need for a notify message under these considerations.

There may be a need for such a thing in the "big RSIP" case where
there is a large number of local subnets and they may be arriving/departing
often (mobile IP?).  Then the issue becomes scalability of the update message -
it may cause a great deal of traffic, especially if there are 1000's of clients.
Multicast? Ugh.  We'd rapidly dig ourselves a hole.  Let's stick with the
little RSIP assumptions right now and try to keep things as simple as possible.

-Mike

-Prakash

-----Original Message-----
From: Mike Borella [mailto:[email-masked]]
Sent: Wednesday, November 24, 1999 1:55 PM
To: Iyer, Prakash
Cc: [email-masked]
Subject: RE: (NAT) RSIP protocol-04 draft - suggested changes

-Mike

   Suggested solution:
   -------------------

   Suggested solution:
   -------------------
   Define a new message,

   address(es) / subnets.

-----------------------

7.2.  Ports

-----Original Message-----
From: Mike Borella [mailto:[email-masked]]
Sent: Tuesday, November 23, 1999 3:16 PM
To: Shane Kerr
Cc: Bernard Aboba; 'Steven M. Bellovin'; 'Iyer, Prakash'; 'Pyda

-Mike

-

-

---

From: "Saint-Hilaire, Ylian" <[email-masked]>
Date: Wed, 24 Nov 1999 16:27:54 -0800

Request for port or (SPI/Cookies) or lease renewals or network queries are
all possibly independent events. If I have to send one or more of there
messages at the same time, the standard prevents me from doing so, even if
TCP is being used.

I will have multiple state machines running at the same time, and I have to
arbitrate who get to send his request now. I am handling it correctly, but
the "no pipelining" restriction could be removed if TCP is used, it only
make sense under UDP.

Ylian Saint-Hilaire

-----Original Message-----
From: Mike Borella [mailto:[email-masked]]
Sent: Wednesday, November 24, 1999 2:02 PM
To: Saint-Hilaire, Ylian
Cc: [email-masked]
Subject: RE: (NAT) RSIP protocol-04 draft - suggested changes

-Mike

"Saint-Hilaire, Ylian" <[email-masked]> on 11/24/99 01:03:35
PM

Ylian Saint-Hilaire

-

-

---

From: "Iyer, Prakash" <[email-masked]>
Date: Wed, 24 Nov 1999 16:27:28 -0800

I don't expect subnets to change every few minutes either, but when they do,
clients (and we are talking a small number here) should be at least notified
immediately. Polling as you suggest below does not help in that if a subnet
configuration changes in between, we run into the problem described earlier.

And we already have an asynchronous DEALLOCATE message, so not sure adding
this one would impact the overall architecture much. We should revisit RSIP
requirements for the Enterprise after we nail requirements for consumer
networks. 

-Prakash

-----Original Message-----
From: Mike Borella [mailto:[email-masked]]
Sent: Wednesday, November 24, 1999 3:40 PM
To: Iyer, Prakash
Cc: 'Shane Kerr'; [email-masked]
Subject: RE: (NAT) RSIP protocol-04 draft - suggested changes

-Mike

-Prakash

-----Original Message-----
From: Mike Borella [mailto:[email-masked]]
Sent: Wednesday, November 24, 1999 1:55 PM
To: Iyer, Prakash
Cc: [email-masked]
Subject: RE: (NAT) RSIP protocol-04 draft - suggested changes

-Mike

   Suggested solution:
   -------------------

   Suggested solution:
   -------------------
   Define a new message,

   address(es) / subnets.

-----------------------

7.2.  Ports

-----Original Message-----
From: Mike Borella [mailto:[email-masked]]
Sent: Tuesday, November 23, 1999 3:16 PM
To: Shane Kerr
Cc: Bernard Aboba; 'Steven M. Bellovin'; 'Iyer, Prakash'; 'Pyda

-Mike

-

-

-