Subject: RE: (NAT) RSIP and IKE rekey

From: "Mike Borella" <[email-masked]>
Date: Thu, 9 Dec 1999 08:37:06 -0600

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.

---

From: Jeffrey Lo <[email-masked]>
Date: Thu, 9 Dec 1999 12:31:23 -0800 (PST)

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

-