Subject: [Gen-art] Generate Review of RFC 3989 as Proposed Standard

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 16 Jan 2007 09:54:36 -0500

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>http://www.alves
trand.no/ietf/gen/art/gen-art-FAQ.html). 

Please resolve these comments along with any other Last Call comments
you may receive.

Document: Middlebox Communications (MIDCOM) Protocol Semantic
Summary: This document is ready for publication/advancement, but has the
following nits that should be resolved.

Comments
---------

There is a lot of text in the document and I will confess I skipped over
some of it. I'm already late on the review and the document seems
reasonable (it has already been published), so I figured it was best
just to send what I had. I did note the following, where issue 5 is the
one that identifies something introduced by becoming a normative
document. 

1. I didn't find where it was explained the reasoning behind being able
to send a request that reserves stuff on neither side of the middlebox.
It would seem a waste of processing.

2. In section 2.1.1 it says "Asynchronous transactions allowing the
middlebox to change state without a request by an agent." but it would
seem that asynchronous transactions would allow for the reporting of the
change of state but not be able to trigger it. Or are we saying that the
asynchronous transaction does not originate from the agent but triggers
the state change?

3. In section 2.1.6 it says that capabilities include "Optional
interface-specific policy rule support: not supported or supported" but
it wasn't clear to be whether this was the advertisement of specific
optional capabilities or whether it was a simple yes or no that some
optional capabilities were supported.

4. In section 2.1.7, I was confused as to whether the parameter
identifying the requesting agent were specified or not. At first it says
they are but then it says 'Although, they are not necessarily passed
explicitly as parameters of the MIDCOM protocol, they might be provided
by the underlying (secure) transport protocol being used." Are they only
sent if they can't be sent via the underlying layers, because if so that
seems like a layering issue. The protocol should be independent. In
general, this section wasn't clear to me on this issue.

5. In section 2.1.8 and at least one other place (section 3, first
paragraph) in the document it says something along the lines of
"However, an actual implementation of a middlebox may support only a
subset of these transactions." which I think is trying to say that
people shouldn't assume the middlebox supports everything but in the
context of a normative document may get misinterpreted to indicate that
the middlebox MUST NOT support everything.

6. Does the noauth state consume any resources. If so, doesn't this
leave the box vulnerable to attack? (section 2.2.5)

7. In section 2.3.4, it indicates "If the state or lifetime change was
requested explicitly by a request message, then the middlebox notifies
the requesting agent by returning the corresponding reply." Is this
instead or in addition to the asynchronous message?

8. In section 2.3.6, it wasn't obvious to me how I was support to
indicate a port range of lets say 200-205. The text says "A single
policy rule P containing a port range value greater than one is
equivalent to a set of policy rules containing a number n of policies
P_1, P_2, ..., P_n where n equals the value of the port range parameter.
".

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 16 Jan 2007 11:19:06 -0500

Hi

The text shows up in a number of requests

For example, in the terminology section, there is the following definition

"policy reserve rule        A policy rule containing a reserve action.
                              The policy condition of this rule is
                              always true.  The action is the
                              reservation of just an IP address or a
                              combination of an IP address and a range
                              of port numbers on neither side, one side,
                              or both sides of the middlebox, depending
                              on the middlebox configuration."

 Sharon

> -----Original Message-----
> From: Martin Stiemerling [mailto:[email-masked]] 
> Sent: Tuesday, January 16, 2007 11:00 AM
> To: Chisholm, Sharon (CAR:ZZ00)
> Cc: [email-masked]; Taylor, Tom-PT (CAR:AR00); Melinda 
> Shore; Magnus Westerlund; Jürgen Quittek
> Subject: Re: Generate Review of RFC 3989 as Proposed Standard
> 
> Hi Sharon,
> 
> Thank you very much for the review.
> 
> It looks like we can quickly fix issues 2 to 8 by adding 
> appropriate clarifications.
> 
> But we have a question on issue No.1:
> >
> > 1. I didn't find where it was explained the reasoning behind being 
> > able to send a request that reserves stuff on neither side of the 
> > middlebox.
> Which request are you referring to?
> 
> Thanks,
> 
>    Jürgen and Martin
> 
> 
>

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 16 Jan 2007 18:02:06 +0100

Hi Sharon,

--On 16.01.07 11:38 -0500 Tom-PT Taylor wrote:

> This was formulated for generality. In a pure firewall, no reservations occur or are needed, but the semantics were defined so that the invoker doesn't need to know the configuration of the middlebox.
>
> Chisholm, Sharon (CAR:ZZ00) wrote:
>> Hi
>>

On a NAT this transaction reserves resources.
On firewalls no resources are allocated by this transaction.

Still, it is useful implementing this transaction on a firewall,
as pointed out in section 2.3.1:

   Some cases require knowing in advance which IP address (and port
   number) would be chosen by NAT in a PER transaction.  This
   information is required before sufficient information for performing
   a complete PER transaction is available (see example in section 4.2).
   For supporting such cases, the core transactions are extended by the
   Policy Reserve Rule (PRR) transaction serving for

      - reserving addresses and port numbers at NATs (PRR)

the information that is returned by the middlebox is the IP address
that is externally used for the communication specified in the request.
Even though the reply from a pure firewall is obvious (in the absence
of address translation, the external IP address is the same address as
the internal address of the communication end point), it may make sense
to implement it, because then the client may use the same procedure for
both kinds of middleboxes (firewalls and NATS).

Thanks,

    Juergen

-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 4342-115
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 4342-155
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 16 Jan 2007 17:00:29 +0100

Hi Sharon,

It looks like we can quickly fix issues 2 to 8 by adding appropriate  
clarifications.

But we have a question on issue No.1:
> able

Thanks,

   Jürgen and Martin

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 16 Jan 2007 11:38:27 -0500

Hi Sharon,

Thanks,

   Jürgen and Martin

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 16 Jan 2007 11:38:27 -0500

This was formulated for generality. In a pure firewall, no reservations 
occur or are needed, but the semantics were defined so that the invoker 
doesn't need to know the configuration of the middlebox.

[email-masked]>
Cc: Martin Stiemerling <[email-masked]>,
	Magnus Westerlund <[email-masked]>,
	Melinda Shore <[email-masked]>, [email-masked],
	=?ISO-8859-1?Q?gen_Quittek?= <[email-masked]>,
	=?ISO-8859-1?Q?Jür?Subject: [Gen-art] Re: Generate Review of  RFC 3989 as Proposed Standard

This was formulated for generality. In a pure firewall, no reservations 
occur or are needed, but the semantics were defined so that the invoker 
doesn't need to know the configuration of the middlebox.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Jan 2007 10:20:31 +0100

I should explain the way I looked at this document (Sharon's
review being after the IESG discussion).

I decided only to look at the formality: can this be
promoted to standards track as-is? The answer turns out
to be no, since it contains non-standards track boilerplate.

Now, that's a bureaucratic point only, which Magnus has
taken care of, so my ballot is now No Objection.

I will add a pointer to Sharon's review in the tracker,
but it's for Magnus to say whether a new draft is actually
needed.

     Brian

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 17 Jan 2007 10:29:23 +0100

Magnus,

Sharon gave some very good comments that would result in
clarifications of the existing text.  The number of changes
to be made is probably five or six and most of them are would
be done by adding a single sentence or modifying a single sentence.

I would suggest that we handle these changes as notes to the RFC
Editor.  But if you prefer producing a new draft, that's also fine.

Thanks,

    Juergen

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 Jan 2007 10:33:06 +0100

> Editor.  But if you prefer producing a new draft, that's also fine.

I am fine with receiving RFC-editor style change notes.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 19 Jan 2007 10:37:59 +0100

Hi Magnus and Sharon,

Below please find replies to Sharons comments.
The replies include suggestions for clarification
that address the raised issues.

> It would seem a waste of processing.

We addresses this issue in an earlier email.
We do not think that there is an action required.

> asynchronous transaction does not originate from the agent but triggers

In section 2.1.1:
OLD:
      - Asynchronous transactions allowing the middlebox to change state
        without a request by an agent.
NEW:
      - Asynchronous transactions allowing to report state changes that
        have not been requested by the agent.

> optional capabilities were supported.

This was a late change and phrasing is bad.  The background is that
some NAT support interface-specific rules and some don't.
The capability information for this is just a 'yes' or a 'no'.

In section 2.1.6:
OLD:
      - Optional interface-specific policy rule support: not
        supported or supported
NEW:
      - Support for interface-specific policy rules

> general, this section wasn't clear to me on this issue.

The semantics specification is independent of a concrete protocol
implementing the semantics.  The section states that identifiers
need to be exchanged, either by the protocol or by the underlying
security mechanism.

Existing implementations of the semantics (MIDCOM MIB, SIMCO) solve
this point differently.  The MIDCOM MIB uses identifiers provided
by SNMP, while SIMCO uses certificates.

> the middlebox MUST NOT support everything.

OLD:
2.1.8.  Conformance

   The MIDCOM requirements in [MDC-REQ] demand capabilities of the
   MIDCOM protocol that are met by the set of transactions specified
   below.  However, an actual implementation of a middlebox may support
   only a subset of these transactions.  The set of announced supported
NEW:
2.1.8.  Conformance

   The MIDCOM requirements in [MDC-REQ] demand capabilities of the
   MIDCOM protocol that are met by the set of transactions specified
   below.  However, it is not required that an actual implementation of a
   middlebox supports all these transactions.  The set of announced supported

OLD:
3.  Conformance Statements

   A protocol definition complies with the semantics defined in section
   2 if the protocol specification includes all specified transactions
   with all their mandatory parameters.  However, concrete
   implementations of the protocol may support only some of the optional
   transactions, not all of them.  Which transactions are required for
   compliance is different for agent and middlebox.
NEW:
3.  Conformance Statements

   A protocol definition complies with the semantics defined in section
   2 if the protocol specification includes all specified transactions
   with all their mandatory parameters.  However, it is not required that
   an actual implementation of a middlebox supports all these transactions.
   Which transactions are required for compliance is different for agent
   and middlebox.

> leave the box vulnerable to attack? (section 2.2.5)

It may create state, depending on a concrete protocol specification.
However, the middlebox may at any time remove the state using an AST
transaction that returns the session to state CLOSED.
So, if an attacker creates too much state, the middlebox can easily
get rid of all sessions in state NOAUTH.

> instead or in addition to the asynchronous message?

This is explained two paragraphs below the sentence you cite:

   In case of a PER, PRR, or RLC transaction, the requesting agent
   receives a PER, PRR, or RLC reply, respectively.  To all other agents
   that can access the created, modified, or terminated policy rule (and
   that participate in an open session with the middlebox) the middlebox
   sends an REN message carrying the policy rule identifier (PID) and
   the remaining lifetime of the policy rule.

> P_1, P_2, ..., P_n where n equals the value of the port range parameter.

We think this is well explained in the paragraph above.
It states

   The port range parameter specifies a number of consecutive port
   numbers.  Its value is a positive integer.  Like the port number
   parameter, this parameter defines a set of consecutive port numbers
   starting with the port number specified by the port number parameter
   as the lowest port number and having as many elements as specified by
   the port range parameter.  A value of 1 specifies a single port
   number.  The port range parameter must have the same value for each
   address tuple A0, A1, A2, and A3.

This means that for the range 200-205 you specify

    port number: 200
    port range: 6

> Canada

Thanks a lot!

    Martin and Juergen