Subject: [midcom] Protocol eval: 2.1.8 and 2.3.1 through 2.3.4 RSIP - proposal to change score and text

From: [email-masked]
Date: Mon, 5 Aug 2002 13:11:54 -0500

Middlebox experts,

As I have said in a previous e-mail, RSIP's capabiltiies are no
different w.r.t.:
- mutual authentication (2.1.8) than MEGACO and DIAMETER;
- message authentication, confidentiality, and integrity (2.3.1) than
  MEGACO and DIAMETER;
- optional confidentiality protection (2.3.2) than MEGACO and perhaps
  DIAMETER;
- operation across untrusted domains (2.3.3) than MEGACO and DIAMETER;
  and
- mitigation against replay attacks (2.3.4) than perhaps MEGACO and
  DIAMETER.

(The "perhaps" in the above statements indicates that the protocol may
have some native capabiltiies in the area.)

Those protocols were scored T for those requirements by suggesting that
the requirement could be completely satisfied if the protocol were
operated over TLS or IPsec.

The same is true of RSIP: all these requirements may be completely
satisfied by operating RSIP over TLS or IPsec.

For consistency of scoring, I propose that the scores of RSIP for these
requirements be changed to T, and the RSIP text under these requirements
be changed to:

     RSIP does not have "native" support for this capability, but the
     capability can be obtained by operating RSIP over TLS or IPsec.

Comments expected and welcome.

Jim

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 6 Aug 2002 08:30:58 -0400

I think I would concede your basic point.

As I said in a previous E-mail, the appropriate test is the protocol
security architecture as defined in the protocol documentation.  I find this
information in the RSIP framework document (RFC 3102):

   If an RSIP negotiation protocol is implemented at the application
   layer, a choice of transport protocol MUST be made.  RSIP hosts and
   gateways may communicate via TCP or UDP.  TCP support is required in
   all RSIP gateways, while UDP support is optional.  In RSIP hosts,
   TCP, UDP, or both may be supported.  However, once an RSIP host and
   gateway have begun communicating using either TCP or UDP, they MAY
   NOT switch to the other transport protocol.  For RSIP implementations
   and deployments considered in this document, TCP is the recommended
   transport protocol, because TCP is known to be robust across a wide
   range of physical media types and traffic loads.

   It is recommended that all communication between an RSIP host and
   gateway be authenticated.  Authentication, in the form of a message
   hash appended to the end of each RSIP protocol packet, can serve to
   authenticate the RSIP host and gateway to one another, provide
   message integrity, and (with an anti-replay counter) avoid replay
   attacks.  In order for authentication to be supported, each RSIP host
   and the RSIP gateway MUST either share a secret key (distributed, for
   example, by Kerberos) or have a private/public key pair.  In the
   latter case, an entity's public key can be computed over each message
   and a hash function applied to the result to form the message hash.

The RFC protocol document (RFC 3103) steered me back to this.  RFC 3103
itself concentrated on the threat of denial of service attacks at the
server.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, August 05, 2002 2:12 PM
To: midcom
Subject: [midcom] Protocol eval: 2.1.8 and 2.3.1 through 2.3.4 RSIP -
proposal to change score and text

Middlebox experts,

Jim