Subject: Re: (NAT) RSIP Optional Messages

From: "Mike Borella" <[email-masked]>
Date: Fri, 17 Dec 1999 09:53:03 -0600

I'll address you comments in the order in which they appear.

- Agreed about the error message.  I'm in the processing of refining the error
     conditions for the -05 draft.
- If a client says something like "free binds 1, 2, 3" but 2 is not valid, then
     the server can safely ignore the request to free 2, but it can free
     1 and 3 and indicate that it did so.  An error message isn't really
     necessary, and if the client is confused, it can send a "free bind 2"
     to which the server will send an error message.  However, I do see
     your point about the number of binds being small in some cases.
     On the other hand, if strict flow policy is used, then there is a separate
     bind per socket (addr/port, addr/port 4-tuple) and for multiple-session
     protocols there may be say, 3-4 binds per, in addition to whatever else
     the client is doing.  In these cases, it is important that when the client
     closes the socket, it frees each bind.  So, if these actions are atomic,
     I can see each bind being freed separately.  Occam's Razor of
     Protocol Design suggests that we keep it the way it is, then. :-)

-Mike

PS: The goal of all this is to clarify which error messages should be sent in
response
     to what conditions.  I'm trying to make all conditions have a well-defined
     error behavior because if there is anything that it open to interpretation,
     n people will interpret it in n different ways.

Jeffrey Lo <[email-masked]> on 12/16/99 02:28:47 PM

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

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

See my comments attached.

Jeffrey Lo

> 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

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
>      more than one binding.

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.

> - Likewise, the DEREGISTER_RESPONSE should be used as an asynchronous
>      message to deregister a client (deleteion of all binds implied).

Good point.

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

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