Subject: Proposed changes to RSIP evaluation (was RE: [midcom] Comments on protocol evaluation draft

From: "Mary Barnes" <[email-masked]>
Date: Fri, 2 Aug 2002 09:48:23 -0500

Jim et al, 

I've not thoroughly reviewed all the proposed changes in detail, but will do
so shortly, but I also did want to respond to the Category 4 to which Tom
also responded wrt security.  We have already discussed and resolved this
concern per email discussions based on the -01 version.  Refer to:
http://www.ietf.org/mail-archive/working-groups/midcom/current/msg02397.html

Now, you're also proposing that RSIP be "upgraded" for the security ones
that you had scored as Failing to meet compliancy in your analysis.  Based
upon the text currently in section 2.1.8, 2.3.1, which also applies to
2.3.2-2.3.4, I don't have a problem changing those to Ps.  The P+ category
would only apply if these changes could be made to RSIP as a natural
extension of the protocol with no impact to current users of that protocol
(i.e. current users don't make use of the information, and wouldn't be
bothered by it being in the messages).  

There are a many other RSIP scores, many of which were derived from your
original analysis, that you're also now proposing changes for:
2.1.2 - The text for this one clearly states that an extension is required.
2.2.1 - The text currently supports the P+ score. 
2.2.2 - I think a P+ needs additional text to substantiate that this would
be a compatible extension of the protocol (OR we need some text upfront in
the RSIP overview describing the extensibility mechanisms defined by RSIP)
2.2.3 - ditto 
2.2.7 - I can't quite see how this goes from F to P+; you'll need to provide
more text or clarification.
2.2.8 - I think a P+ needs additional text to substantiate that this would
be a compatible extension of the protocol 
2.2.9 - I don't have a problem with changing this to P.  Again, P+ would
require additional text to substantiate that this would be a compatible
extension of the protocol.
2.2.11 -ditto 
  
Upon another quick glance, I think many of the proposed changes for the
other protocols are bringing forth issues with other "scores" that we have
already discussed (e.g. 2.2.2 for Megaco)  Certainly, if there is
overwhelming support for your changes, then they can be done, but we've got
to have more than one person supporting the change for something that we
have previously discussed and I certainly thought had reached concensus on.
I won't be responding to each of these that we've already discussed, you can
search the email archives, where each has been addressed in a separate email
thread. 

Again, I haven't looked at each in detail, and you may indeed have found
some changes which are valid, so I will post separately each of those which
I would agree to change provided there is WG concensus (i.e. no negative
responses to my proposals).

Regards,
Mary.

-----Original Message-----
From: Taylor, Tom-PT [CAR:B602:EXCH] 
Sent: Friday, August 02, 2002 9:01 AM
To: [email-masked]'; Barnes, Mary [NGC:B602:EXCH]
Cc: 'midcom'
Subject: RE: [midcom] Comments on protocol evaluation draft

From my point of view you raise two issues I cannot leave unanswered.  The
first has to do with P+ extensions and your first scoring inconsistency, the
second with security.

I confess that the need for protocol extensions poses a logical issue: how
to treat this need when it affects multiple categories of response.  On the
one hand, I think it is over-stating things to simply score 1 against each
category that depends on the extension.  On the other, it is certainly true
that, whether you are defining a new MIB, a new DIAMETER application, or a
new Megaco package, you imply the need for extra code in both the Agent and
the Middlebox above that supplied by the base protocol implementation.  I
myself would propose adding an evaluation category that specifies the
increment to the base protocol implied by its use for MIDCOM.  Leaving that
aside, any protocol that fails to meet one of the MIDCOM requirements is
probably beyond our consideration.

On the security issue: you dismiss too quickly those protocols that rely on
lower layers for their necessary degree of security.  The RFCs specifying
these protocols have security sections.  The protocol security architecture
in each case was arrived at by considering the specific threats that had to
be countered in the protocol's domain of application.  An architecture that
relies on lower layer security is perfectly valid if that meets the
requirements for that protocol.

What we do have to think about is whether the threats are different for the
MIDCOM application from those considered when the candidate protocol was
being designed.  If so, the security architecture for that protocol may have
to be modified to fit MIDCOM application.  But the security section of the
MIDCOM requirements document reflects the results of the MIDCOM threat
analysis.  Thus if our candidate protocols, including their specified
security architectures, can meet these requirements in a practical way, they
must be scored as passing those requirements.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 02, 2002 12:45 AM
To: Barnes, Mary [NGC:B602:EXCH]
Cc: 'midcom'
Subject: RE: [midcom] Comments on protocol evaluation draft

Mary (and other middlebox experts),

Thank you much for your reply.

The clarification of the grading system is especially useful. I had a
lot of trouble understanding it before, but I think I got it now.

Here's what I now understand the grades to mean:
T  - Compliance to the requirement with the protocol as is
P+ - Compliance to the requirement with an extension to the protocol
P  - Compliance to the requirement with a change, or an extension that
     impacts existing users of the protocol
F  - No compliance (even with extension of the protocol???)

Some observations on this:

- Since all the protocols are extensible and extensions can generally be
made, one way or another, to be backward compatible, I'm surprised that
we have any P's of F's. :-)

- We seem to have lost the concept of how large an extension needs to be
made to add a "thing" to the protocol. Is the protocol close to the
requirement and just needs a little extension? Or does the protocol have
nothing to offer and the thing has to be added completely? I originally
thought that was the idea behind the the T, P and F grades ("How much do
ya have to change the protocol to satify the requirement? None, a little,
and a lot, respectively"), but I guess we evolved from that, assuming
that was the original intention.

As you suggested, I went back and looked for what I thought were incon-
sistencies in P+ and P grades. Once I got started digging, what I wound
up doing was quickly reviewing all the scores for consistency with the
grading system as I now understand it and the summary information for
each protocol's compliance with each requirement as given in the
protocol evaluation I-D (BTW, I used the -02 version of the I-D, without
any of the changes that have been discussed since it was published.).

The grading inconsistencies that I saw fell into 4 categories:

1. The requirement compliance text for the protocol basically said "This
can be done with an extension to this protocol" and the grade was a T,
instead of a P+ as I believe it should be. I included the closely related
"The protocol does not preclude this extension from being made." in this
category.

2. The requirement compliance text for the protocol says the protocol
has something here but extension is required and can be made with no
impact, but graded it as a P instead of a P+.

3. The requirement compliance text for the protocol says the protocol has
nothing here but the necessary extension can be made without impact, and
graded it as an F instead of a P+.

4. The requirement compliance text for the protocol says the protocol has
nothing here but if ya use TLS or IPsec or whatever for security ya get
everything, and graded it as a T.

In the last case, I'm not sure what the right score is, but I would
suggest at most P+, to distinguish these from protocols that have the
right thing here without resorting to TLS or IPsec or whatever for
security, which I think should get a T grade. (For consistency, I
considered grades of F (Honestly given, in my opinion, but I could be
wrong.) but the requirement could be fulfilled with TLS or IPsec or
whatever for security, hence now graded P+ for consistency, as instances
of this case also.)

I also found a few other what I believe to be inconsistencies, at least
based on the scoring system as I now understand it. Call this category 5.

I list the inconsistencies I found at the end of this message, but
here's some statistics. Take 'em for whatever ya think they're worth.

Out of a total of 135 scores (27 requirements times 5 protocols) I found
what I thought were 31 inconsistencies. That's just less than 23%.

The number of inconsistencies by category by protocol are:

Category        SNMP    RSIP    MEGACO   DIAMETER        COPS    Total
--------        ----    ----    ------   --------        ----    -----
1        1       0       3       3        1       8
2        0       2       0       1        0       3
3        0       4       0       0        0       4
4        0       5       4       5        0      14
5        0       2       0       0        0       2
        --      --      --      --       --      --
Total    1      13       7       9        1      31

The resulting adjustments in protocols scores are:

Protocol        T       P+      P        F
--------        ---     ---     ---      ---
SNMP    - 1     + 1
RSIP    + 2     +10     - 3     - 9
MEGACO  - 7     + 7
DIAMETER        - 8     + 9     - 1
COPS    - 1     + 1
        ---     ---     ---     ---
Total   -15     +28     - 4     - 9

And the resulting protocol scores are:

Protocol        T       P+      P        F       Total
--------        ---     ---     ---      ---     -----
SNMP     18       9       0       0       27
RSIP     14      13       0       0       27
MEGACO   13      11       2       1       27
DIAMETER         13      13       1        0      27
COPS     19       6       1       1       27
        ---     ---     ---     ---      ---
Total    77      52       4       2      135

This was done real quick, so there's probably still stuff not right, but
now, at least to me, the numbers better match the general feeling I get
when reading the I-D.

Comments expected and welcome.

Jim

================

Inconsistencies I found in the MIDCOM protocol evaluation grades
(This was composed with tab stops every 8 characters.)

                       Score
Require-                -------------------              Inconsistency
ment    Protocol        Was     Should be                Category
--------        --------        ---      ---------               --------
2.1.2   RSIP    P       T                5
2.1.8   RSIP    F       P+               4
        MEGACO  T       P+               4
        DIAMETER        T       P+               4
2.2.1   RSIP    P+      T                5
2.2.2   SNMP    T       P+               1
        RSIP    P       P+               2
        MEGACO  T       P+               1
        DIAMETER        T       P+               1
2.2.3   RSIP    P       P+               3
2.2.4   MEGACO  T       P+               1
        DIAMETER        T       P+               1
2,2,6   DIAMETER        T       P+               1
        COPS    T       P+               1
2.2.7   RSIP    F       P+               3
        DIAMETER        T       P+               1
2.2.8   RSIP    P       P+               2
        MEGACO  T       P+               1
2.2.9   RSIP    F       P+               3
2.2.11  RSIP    F       P+               3
2.3.1   RSIP    F       P+               4
        MEGACO  T       P+               4
        DIAMETER        T       P+               4
2.3.2   RSIP    F       P+               4
        MEGACO  T       P+               4
        DIAMETER        T       P+               4
2.3.3   RSIP    F       P+               4
        MEGACO  T       P+               4
        DIAMETER        T       P+               4
2.3.4   RSIP    F       P+               4
        DIAMETER        T       P+               4

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

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

---

From: [email-masked]
Date: Sun, 4 Aug 2002 22:41:51 -0500

I'll respond to your RSIP specific comments in this e-mail, and address
general comments separately. My response here assumes the use of the 4
grade grading system that has been agreed to.

On 08/02/2002, at 09.48.23 A.M., Mary Barnes wrote, in part:

>
> Now, you're also proposing that RSIP be "upgraded" for the security
> onesthat you had scored as Failing to meet compliancy in your analysis.
> Based upon the text currently in section 2.1.8, 2.3.1, which also
> applies to 2.3.2-2.3.4, I don't have a problem changing those to Ps.
>

MEGACO and DIAMETER do not have "native" support for capabilities
satisfying these requirements, they depend on operation over, e.g.,
TLS or IPsec to satisfy them, and they were scored a T. RSIP is no
different: no native support; but the cappability can be added by
operating over TLS or IPsec; so, it too should be scored a T. All I'm
asking for here is consistency of scoring for all the protocols.

Additionally, the "native" communications between hosts and RSIP gateways
is over tunnels for the data connections. Although not explicitly stated,
the preferred operation of the control channel is over that same tunnel.
If that tunnel is IPsec, then the control channel is secured. At least
with RSIP, the tunnel is already there.

At to replacement for the RSIP portions of the text following requirements
2.1.8, and 2.3.1 through 2.3.4, I would suggest:

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

>
> The P+ category would only apply if these changes could be made to
> RSIP as a natural extension of the protocol with no impact to current
> users of that protocol (i.e. current users don't make use of the
> information, and wouldn't be bothered by it being in the messages).
>

If the score for these requirements is not to be T, then ....

The first value found in every RSIP message is the version of the
protocol being used. RSIP as currently defined is version 1. RSIP, as
extended to support the MIDCOM requirements would be version 2.

When a host initiates communications with an RSIP gateway / middlebox
(The host sends a REGISTER-REQUEST message, and the RSIP gateway /
middlebox responds with a REGISTER-RESPONSE if the registration is
successful, else an ERROR-RESPONSE.), the host and the RSIP gateway /
middlebox would negotiate the version of the RSIP protocol to be used
for the session, assuming it is established successfully. I'll give
the strongest, most restrictive, least "friendly" version of this
negotiation; weaker, less restrictive, more "friendly" versions may
be possible.

1. The host sends the REGISTER-REQUEST indicating the version of the
protocol that it wishes to use for the session; initially this would
presumably be the latest, greatest version of RSIP that it supports;
but if it is discovered that that version is not also supported by
the RSIP gateway / middlebox, then a lesser version could subsequently
be tried; if there is no lesser version supported by the host, then
the host and the RSIP gateway / middlebox support no versions in
common, and useful communications between them is impossible;

2. If the RSIP gateway / middlebox also supports that version, it
continues with processing the request and returns either a REGISTER-
RESPONSE or an ERROR-RESPONSE as approriate to the request, but in
either case the response's version parameter indicates the version
proposed by the host; since the host and RSIP gateway / middlebox both
support the same version of RSIP, further useful communication between
them is possible.

3. If the RSIP gateway / midldebox does not support the version
proposed by the host, it responds with an ERROR-RESPONSE, whose error
parameter is set to 106: UNSUPPORTED_RSIP_VERSION and whose version
parameter would indicate the greatest version of RSIP less than the
proposed version that the RSIP gateway / middlebox *does* support, and
the host may try that version or a lesser version that the host
supports; if the RSIP gateway / middlebox does not support any version
of the protocol less than that proposed, it responds indicating the
greatest version it *does* support, indicating that useful
communications between them is impossible.

This is the traditional "negotiate down" version negotiation scheme.
With this scheme the host and the RSIP gateway / middlebox find the
greatest version of the protocol that they both support.

The implications of this for protocol (re)design are, in the extreme,
that each version can be completely different from all other versions
so long as the version negotiation mechansims is preserved. Now I would
never propose doing that in the extreme, I would try to make new versions
as backward compatible as possible on a message by message, parameter by
parameter basis. But if ya had to, a new version could be radically
different from previous version and still technically be backward
compatible. Fortunately, in the case of the adapting RSIP to the MIDCOM
requirements, I believe all the extensions are rather natural backward
compatible extensions, nothing radical.

> 2.1.2 - The text for this one clearly states that an extension is

This may be a fine point, but the *RSIP framework and semantics* would
require an extension, the *protocol* itself would not (BTW, that's what
the text for the RSIP evaluation of the requirement says: " ... the RSIP
*architecure* could be extended ..." [Emphasis added.]). The extension
would be the explicit removal of an unstated (and usually unimplemented!)
restriction that an RSIP request must come from the host whose
communications would be affected by the request.

Or looking at it another way, a given installation's policy may be that
RSIP requests must come from the host that is affected. RSIP permits that
policy to be enforced, but it also, through it's silent on the matter,
allows the opposite policy. I could certainly envision both of these
policies with MODCOM, also.

So either way ya look at it, the RSIP documentation should be clarified,
but no change to the protocol is required. I, being the hard grader that
I am and wanting to give the most information on and insight into RSIP
as possible, graded this a P. But with the grading system as I now
understand it, and for consistency with the way the other protocols were
graded, I think that this should be a T.

If replacement text is necessary, I would suggest:

     RSIP allows a client to simultaneously have RSIP sessions with
     multiple RSIP gateways.

> 2.2.1 - The text currently supports the P+ score.

I scored this a T, which was subsequently lowered to P+, presumably
based on the explanation I gave. But if you look carefully at the text
I gave, it desribes how the extension mechanism might be used in a number
of different ways: defining new messages, parameters, and parameter
values; extending existing messages with additional parameters and
parameter values, which may be either new or existing; defining a new
version number if appropriate.

But no backward compatible extension *to the extension mechanism itself*
is needed. If an extension to the extension mechanism were needed, then
the score should be P+ or P, depending on if the extension to the extension
mechanism were backward compatible or not. But since it's not even
needed, the score should revert to a T.

Additionally, I believe if you compare the facts on extensibility of RSIP
to the extensibilities of the other protocols, you would find them the
same, although they didn't go into as great a level of detail, and they
were scored a T. Perhaps if more specifics were given for the other
protocols as were for RSIP, they would also be scored a P or P+. :-)

Again, what I'm really looking for here is consistency: with the grading
system; and across the protocols.

>
> 2.2.2 - I think a P+ needs additional text to substantiate that this
> would be a compatible extension of the protocol (OR we need some text
> upfront in the RSIP overview describing the extensibility mechanisms
> defined by RSIP)
> 2.2.3 - ditto
>

Since, in recent semantics discussions, I believe we have agreed that
the only ruleset action needed is permit, the statement in the text may
be true as it stands.

If it is desirable to include some kind of parameter that indicates the
type of middlebox being manipulated (NATter, firewall, VPN tunnel switch,
etc.), that certainly can added, and in a completely backward compatible
way. As I read the text for SNMP and COPS, they seem to imply that they
already have this parameter, and therefore deserve a T (But more on this
later.).

The MEGACO text says multiple middlebox types can be supported when you
define the middlebox package for MEGACO, and is scored a T. But an
extension to MEGACO (i.e., one or more new packages) is required, so I
think this ought to be a P+ (presumably it can be done with backward
compatibility).

The DIAMETER text says an extension is necessary, and is scored a P, now
presumably a P+.

But if ya look at the MIDCOM requirements (I'm looking at the -05
draft.), it says under requirement 2.2.2:

     This states that a the protocol must support rules and actions for
     a variety of types of middleboxes.

According to this as I read it, just having a parameter that
distinguishes among types of middleboxes isn't suffucient, ya gotta have
rules and actions already defined in the protocol to justify a T score.
I don't think this is the case for any of the protocols (Although RSIP
probably comes the closest: it does have the notion of rules defined; not
actions, but they may not be needed anymore.), so I think the T scores for
SNMP and COPS should also be P+.

Again, I'm looking for consistency here. All require extension, so all
should be graded the same, and I think that's a P+.

If the question had simply been "Can ya already distinguish between
multiple middlebox types?", then the T scores for SNMP and COPS would be
justified.

As to 2.2.3, ruleset groups, they can be added compatibly by adding a
ruleset identifier parameter to the appropriate RSIP request and
response messages. If new operations on rulesets are required beyond
those provided by the existing RSIP requests and responses, they can be
added compatibly.

As to a fuller explanation of the RSIP extension mechanism, I believe
that text is already there under requirement 2.2.1. If necessary, maybe
that should be moved to the overview (Or a pointer from the overview to
the 2.2.1 text could be added.). If we need a fuller or different
explanation, let me know and I'll provide it.

>
> 2.2.7 - I can't quite see how this goes from F to P+; you'll need to
> provide more text or clarification.
>

RSIP ASSIGN_RESPONSEs to successful ASSIGN_REQUESTs include a bindID
parameter that uniquely identifies the binding (read "ruleset"). The
bindID is specified in subsequent requests, e.g., EXTEND_REQUEST to
extend the lease time of a binding, to identify the binding to which
the request is to apply.

I believe the RSIP specification intended, though never explicitly stated,
that further requests on a binding be restricted to the to the host that
created the binding; although once again, one might say that that is a
matter of installation policy. To clearly satisfy the MIDCOM requirements,
the RSIP semantics would be explicitly extended to permit any authorized
host to request operations on a binding.

As to text to use in the evaluation document, I would suggest:

     RSIP does not explicitly either permit or preclude an operation on
     a binding being requested by a host other that the host that created
     the binding. The RSIP semantics would need to be explicitly extended
     to permit any authorized host to request operations on a binding. No
     change to the protocol would be required.

BTW, since the "The diameter protocol as currently defined offers no
impediment [to] such an operation." and is scored a T, maybe either RSIP
should be scored a T or DIAMETER should also be scored a P+?

>
> 2.2.8 - I think a P+ needs additional text to substantiate that this
> would be a compatible extension of the protocol
>

RSIP would add a new optional enumeration parameter called
transportProtocol to the ASSIGN_REQUESTs. If specified, the binding
created would apply only to the use of the bound addresses / ports by the
specified transport protocol. If not specified, the binding would apply to
all use of the bound addresses / ports by any transport protocol, thus
maintaining backward compatibility with the current definition of RSIP.

BTW, MEGACO is scored a T on this requirement for a package that isn't
yet defined. :-(

> extension of the protocol.

RSIP would add a new optional boolean parameter called portOddity to the
ASSIGN_REQUESTs. If specified as TRUE, the remote port number of the
binding created would have the same oddity as the local port. If not
specified (or specified as FALSE), the remote port's oddity is independent
of the loacl port's oddity, thus maintaining backward compatibility with
the current definition of RSIP.

BTW, MEGACO is again scored a T on this requirement for a package that
isn't yet defined. :-(

Overlapping rulesets may have gone away with recent semantics discussions,
but ...

RSIP would add a new optional boolean parameter called overlapOK to the
ASSIGN_REQUESTs. If specified as TRUE, the binding created may overlap with
another existing binding. If not specified (or specified as FALSE), the
binding will only be created to not overlap with an existing binding, thus
maintaining backward compatibility with the current definition of RSIP.

For this requirement, I believe MEGACO was correctly scored as a P+.

Whew! I think that addresses all of Mary's response.

Commented expected and welcome.

Jim