Subject: (NAT) request for clarification on RSIP

From: "Warrier, Ulhas" <[email-masked]>
Date: Tue, 31 Aug 1999 15:02:17 -0700

The protocol draft does not mention whether an RSIP server is
required to support multiple REGISTER_REQUEST messages (originated by 
different applications) from the same client system. Or is there an 
assumption that the RSIP client is implemented as a system-wide entity 
that all applications on that system share?
- Ulhas

-----Original Message-----
From: Iyer, Prakash [mailto:[email-masked]]
Sent: Monday, August 30, 1999 5:34 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: (NAT) More questions on RSIP

Looking for further clarifications on the RSIP drafts:
- Can you clarify how the RSIP "control channel" works. For example, a
client
starts off by creating a TCP connection (port 4455) to an RSIP server and
registers
using the Register_Request message. Its a little confusing after that.

For parameter assignment, the drafts list COPS, DHCP etc. as possibilities.
If we use DHCP for example, should Assign_Request messages be directed at a
DHCP
server from the RSIP client or is the interaction between an RSIP server and
the
DHCP server.

        RSIP client  ----------  RSIP server  ------------------  DHCP
server
                    RSIP protocol             encap. in DHCP messages

         OR

        RSIP client ------------------------  RSIP server
            |
            |
            --------------------------------  DHCP server

- Most IKE implementations I presume use some crypto functions to generate
initiator
cookies. In the RSIP protocol, I think you assume that the RSIP server
generates
/ allocates a pool of initiator cookies for RSIP clients. This may be an
issue
for gateways that don't support RNG, hashing or other crypto functions. Has
this
issue been discussed on the list.

>>> text from RFC 2408 on cookie generation

2.5.3 Anti-Clogging Token ("Cookie") Creation

   The details of cookie generation are implementation dependent, but
   MUST satisfy these basic requirements (originally stated by Phil Karn
   in [Karn]):

      1.    The cookie must depend on the specific parties.  This
            prevents an attacker from obtaining a cookie using a real IP
            address and UDP port, and then using it to swamp the victim
            with Diffie-Hellman requests from randomly chosen IP
            addresses or ports.

      2.    It must not be possible for anyone other than the issuing
            entity to generate cookies that will be accepted by that
            entity.  This implies that the issuing entity must use local
            secret information in the generation and subsequent
            verification of a cookie.  It must not be possible to deduce
            this secret information from any particular cookie.

      3.    The cookie generation function must be fast to thwart
            attacks intended to sabotage CPU resources.

   Karn's suggested method for creating the cookie is to perform a fast
   hash (e.g.  MD5) over the IP Source and Destination Address, the UDP
   Source and Destination Ports and a locally generated secret random
   value.  ISAKMP requires that the cookie be unique for each SA
   establishment to help prevent replay attacks, therefore, the date and
   time MUST be added to the information hashed.  The generated cookies
   are placed in the ISAKMP Header (described in section 3.1) Initiator
   and Responder cookie fields.  These fields are 8 octets in length,
   thus, requiring a generated cookie to be 8 octets.  Notify and Delete
   messages (see sections 3.14, 3.15, and 4.8) are uni-directional
   transmissions and are done under the protection of an existing ISAKMP
   SA, thus, not requiring the generation of a new cookie.  One
   exception to this is the transmission of a Notify message during a
   Phase 1 exchange, prior to completing the establishment of an SA.
   Sections 3.14 and 4.8 provide additional details.

>>> end of inserted text

- How is DEALLOCATE handled by the RSIP server if UDP is used as the
transport.
It will help if the sections that talk about transports discuss
implementations
based on TCP and UDP.

- It seems like there is a need to specify the authentication mechanism to
be used
by the RSIP client and server to guarantee interop. Will this be specified
in the next
rev of the doc. Mike mentions below that some SOCKS-like mechanism is used.
Are
other light-weight options (non-IPSEC) being considered.

- Is RSIP server discovery to be made part of the protocol itself, or are we
planning
to rely on some other UP&P-like resource discovery protocol for this. It
will be
nice if RSIP clients don't have to be configured (such as in consumer
networks).

-Prakash

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 20, 1999 11:26 AM
To: Iyer, Prakash
Cc: [email-masked]'
Subject: Re: (NAT) Questions on RSIP

As of the last IETF, the consensus was to use a port number for now until
the transport issue is resolved.  FYI, I'm using port 4455 in my
implementation.

IPIP is the prefered mode and is mandatory to implement.   The rest are
optional, and can be negotiated.

IPSEC may be a good choice in some scenarios but not in others.  RSIP
has a lot of appeal to the thin client people, who don't have the room for a
full-blown IPSEC client on their boxes.  We're tackling the autentication
issue with a SOCKS-like mechanism.

All of these questions will be addressed in the next rev of the RSIP drafts.

Thanks,
Mike

"Iyer, Prakash" <[email-masked]> on 08/19/99 07:56:17 PM

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

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

To:   "'nat @livingston.com'" <[email-masked]>
cc:    (Mike Borella/MW/US/3Com)
Subject:  (NAT) Questions on RSIP

I had some questions on the RSIP drafts:

- The framework draft mentions a variety of transports for RSIP parameter
negotiation (e.g. COPS,
DIAMETER etc.). Is there a mechanism for a client and an RSIP server to
agree on a transport. How
is interoperability addressed? Are there implementations out there based on
one or more of these
transports?

- The framework draft also lists a variety of tunnel types (IP-IP, GRE
etc.). Again, is there some consensus
among implementors preferred modes.

- Are there proposed mechanisms to authenticate RSIP clients and servers.
For e.g. will IPSEC be a
good choice.

Prakash Iyer
Intel Corp.; Intel Architecture Labs
[email-masked]
Ph: 503-264-1815  Fx: 503-264-3483

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