Subject: Re: (NAT) RSIP Optional Messages

From: "Mike Borella" <[email-masked]>
Date: Wed, 15 Dec 1999 14:10:30 -0600

I've had a chance to step back from the protocol draft for a while and look
at it with a fresh perspective.  As a result of re-examining some sections and
some off-line feedback that I've received, I'd like to propose the following
changes.

- With respect to the types of messages (mandorty or option):
     - EXTEND_REQUEST and EXTEND RESPONSE: mandatory since
          some RSIP server may use short lease times to manage resources.
     - ASSIGN_REQUEST_RSAP-IP and ASSIGN_RESPONSE_RSAP_IP:
          mandatory default for interop.  The RSA-IP mode should be optional
          because it is much less likely to be used.
     - FREE_REUEST and FREE_RESPONSE: mandatory (see below)
     - QUERY_REQUEST: optional
     - QUERY_RESPONSE: mandatory
- FREE_REQUEST and FREE_RESPONSE should be able to indicate
     more than one binding.
- Likewise, the DEREGISTER_RESPONSE should be used as an asynchronous
     message to deregister a client (deleteion of all binds implied).
- DEALLOCATE is exactly the same as FREE_RESPONSE right now.  It
     should be removed from the spec and FREE_RESPONSE used in
     its place as an asynchronous method for deallocating one or more bindings.
- OK message is not necessary and should be removed.
- A disposition byte should be added in the ADDRESS and PORT parameters
     to indicate the client's willingness to either (1) only be allocated the
     specific parameter values that it indicates or (2) accept other values that
     the server may assigned, but that it prefers the values suggested.

All in all, these changes would make the expected behavior of both clients and
servers more clear, which would make interpretation and use of error messages
simpler.

Thoughts?

-Mike

Jeffrey Lo <[email-masked]> on 12/09/99 02:31:23 PM

Please respond to Jeffrey Lo <[email-masked]>

Sent by:  Jeffrey Lo <[email-masked]>

To:   Mike Borella/MW/US/3Com
cc:   [email-masked]
Subject:  (NAT) RSIP Optional Messages

Hi,

Pertaining to protocol draft -04. We came across the question of what
minimal set of message type to implement and could still claim RSIP
protocol conformance. For this reason, I propose stating explicitly in
the draft what message types to be optional vs compulsory. Example of
modifications to Appendix B of draft-ietf-nat-rsip-protocol-04.txt is as
follow:

               Sent by        Sent by    Type
               RSIP client    RSIP server
1 ERROR_RESPONSE                  X           Compulsory
2 REGISTER_REQUEST       X                    Compulsory
3 REGISTER_RESPONSE                    X           Compulsory
4 DE-REGISTER_REQUEST         X                    Compulsory
5 DE-REGISTER_RESPONSE                       X          Compulsory
6 ASSIGN_REQUEST_RSA-IP       X                    see 1
7 ASSIGN_RESPONSE_RSA-IP          X           see 1
8 ASSIGN_REQUEST_RSAP-IP     X                     see 1
9 ASSIGN_RESPONSE_RSAP-IP              X           see 1
10 EXTEND_REQUEST        X                    option
11 EXTEND_RESPONSE                X           option
12 FREE_REQUEST               X                    option
13 FREE_RESPONSE                  X           option
14 QUERY_REQUEST         X                    option
15 QUERY_RESPONSE                 X           option
16 DEALLOCATE                     X           option
17 OK                    X                    compulsory
18 LISTEN_REQUEST                 X           option
19 LISTEN_RESPOSNE       X                    option

Note :
1. We propose making ASSIGN family of messages optional with the condition
that at least either RSA-IP or RSAP-IP has to be implemented.
2. Under this, it will be possible to introduce the asychronous subnet
update message that was proposed some time back as an option. (Point of
further study and discussion)
3. Some error fields may have to be introduced accordingly.

----

Jeffrey Lo
C&C Research Labs,
NEC USA, Inc.
Tel : (408) 943 3033
Fax : (408) 943 3099

On Thu, 9 Dec 1999, Mike Borella wrote:

>
>
> Yes, this is what I've had in mind the whole time, though I may have
> never made it explicit - since RSIP shares IP addresses, IPSEC SAs
> MUST have address/port filters.
>
> Furthermore, endpoint authentication MUST use something other than
> source IP.
>
> -Mike
>
>
>
>
>
> "Bernard Aboba" <[email-masked]> on 12/07/99 07:48:47 AM
>
> Please respond to [email-masked]
>
> Sent by:  "Bernard Aboba" <[email-masked]>
>
>
> To:   Mike Borella/MW/US/3Com, "'Saint-Hilaire, Ylian'"
>       <[email-masked]>
> cc:   [email-masked]
> Subject:  RE: (NAT) RSIP and IKE rekey
>
>
>
>
> >On the other hand, Ylian is referring to the case in which an external
> >host talking to multiple RSIP clients doesn't know which isakmp SA
> >to use because it is basing the identity of its peer on the shared
> >IP address.  Here, IMO, the external implementation is not making the
> >right assumption.
>
> I think that the solution to this one is for the IKE initiator to
> negotiate *very* specific filters for the IPSEC SA so that the
> destination will not be confused. For example, if the RSIP
> client were to dynamically plumb a filter corresponding
> to the RSIP port/address that it was allocated, this would guarantee
> uniqueness.
>
> Example filter:
> From: <RSIP allocated IP address> To: destination address
> Source Port: <RSIP allocated port> Dest Port: destination port
>
>
>
>
>
> -
> 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.

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

---

From: Jeffrey Lo <[email-masked]>
Date: Thu, 16 Dec 1999 12:28:47 -0800 (PST)

See my comments attached.

Jeffrey Lo

>      - QUERY_RESPONSE: mandatory

An error message has to be introduce to handle the case when no subnet
information has been configured on the server. In anycase, having a
generic METHOD_NOT_SUPPORTED error message will be essential for rejecting
optional messages not supported. 

> - FREE_REQUEST and FREE_RESPONSE should be able to indicate

Is there any significant performance improvement introducing this? I
don't see any one client having more than a couple of binds. If all
binds need to be release in on short, the client can just deregister. On
the other hand, it complicates the protocol a great deal. What's the
response of the server if one of the binds is invalid? Does it
ignore the request or free all valid binds and keep the invalid on
intact? Client may receive multiple replies in response to a free request.
Error messages may have to support multiple binds too.

>      message to deregister a client (deleteion of all binds implied).

Good point. 

-