Subject: [midcom] Reminder: wg last call

From: Melinda Shore <[email-masked]>
Date: Wed, 3 Sep 2003 15:12:06 -0400

This is a reminder that we're in WG last call on the semantics
document.  Last call closes on Tuesday, 9 September.  The URL
for the document is:

http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-04.txt

Melinda

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Sep 2003 09:56:16 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-04.txt

I will once more bring up a comment which I did already made when I
reviewed the previous revision of the document and where I did not
see much of a discussion.

I am still concerned about making all transactions that allow to 
retrieve what is actually installed on a device optional. For 
debugging and development purposes, I believe it is essential 
to be able to retrieve the installed policies and groups.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 6 Sep 2003 14:15:47 -0700 (PDT)

Below is text of the e-mail (a little revised) I sent to the authors earlier. I
am including the text for wider audience. Below are my outstanding comments on
the draft. 

1. For a NAT middlebox, I believe, the semantics ought to cover the following
transactions. My comments assume the following.

      A. NAT is configured on a per-interface basis. As such, the 
         Midcom/NAT transactions would be specified on a per-interface basis. 
      B. End-point below is to be refered as <IP addr, TCP/UDP, TU-port>  
         for a PortBind. End-point for an address Bind will be
         <IP address>. The IP address can be V4 or V6. 
      C. The transactions specified below can be applicable to one or more
         end-points. This will include address ranges, address 
         wild-carding, port ranges, and port wild-carding.

SetMapOwner <AddressMapEntryIndex> [Full | Partial] [<Subset of Map Entry>]
                      - SetMapowner may be used by an agent to claim 
                        ownership on a complete NAT map entry or a 
                        portion of the entry. AgentId will be set as the 
                        owner of the entire map entry or portion thereof.

(CreateBind | CreatePortBind)
            <AddressMapEntryIndex> <original End-point> <Xlated End-point>
                      - Agent specifies all the requisite Parameters for 
                        Bind(s) or PortBind(s). Agent requests middlebox 
                        to create a BIND and respond back with an assigned
                        BindId. Middlebox to validate the authorization 
                        prior to responding.

(RequestCreateBind | RequestPortCreateBind)
           <AddressMapEntryIndex> <original End-point> [Oddity option]
                      - Agent requests the Middlebox to create BIND(s) for
                        the given End-point, optionally with an Oddity
                        requirement. Middlebox to validate the 
                        authorization, prior to assgining a BIND and
                        a BindId and returning the response.

CreateOutboundSession
          <OutboundSrc map entry index> | <OutboundSrc end-point BindId>
          <OutboundDest map entry index> | <OutboundDest end-point Bindid>
          <Original Outbound session tuple>
          <Translated outbound session tuple>
                      - Agent specifies all the requisite Parameters for 
                        an outbound session. Agent requests middlebox 
                        to create a session as specified and respond back 
                        with an assigned BindId. 
                        The session may have one or two end-point 
                        translations. The session may be derived directly 
                        from the address map (or) from associated Bind-IDs.
                        Middlebox to validate the authorization prior to
                        responding. Note, the session tuple may have 
                        wild-card elements.

RequestCreateOutboundSession
          <OutboundSrc map entry index> | <OutboundSrc end-point BindId>
          <OutboundDest map entry index> | <OutboundDest end-point Bindid>
          <Original Outbound session tuple>
                      - Agent requests the Middlebox to create an outbound 
                        session for the given session tuple, using one or 
                        more map entries and/or end-point BINDs. Agent 
                        to validate he authorization prior to responding
                        back with a new session and session-id. As before,
                        the session tuple may have wild-card elements.

CreateInboundSession,
RequestCreateInboundSession
                      - Similar to the outbound counterparts.

ModifyBindParameters  <BindId> 
          [<MaximumLifetime>] [MaximumIdletime>] [<GroupId>]
                      - These parameters may be specified either at Bind
                        creation time or later.

ModifySessionParameters <SessionId>
          [<MaximumLifetime>] [MaximumIdletime>] [<GroupId>]
                      - These parameters may be specified either at session
                        creation time or later. Note, session here refers
                        to the NAT data sessions, not the Midcom agent 
                        session.

In particular, I would like to mention the notion of three resources 
a NAT middlebox and midcom agent need to be cognizant of - 
Address map entries, Binds and sessions. These resources may be a) created by
the agent, b) created by the NAT middlebox, or c) paramaters modified by the
agent.

2. The notion of PRR is incomplete without the context of the entire address
map entry. The reservation may not be specific to address/address-port alone.
My view of this is simply that PRR is just another notion of ownership claim.
it just happens to be in relation to an address map entry. 

3. When you combine the notion of PRR wth PER, the state transition diagram in
section 2.3.13 woudl be simplified, with the proviso that there would be three
types of policy rules (address map entries, binds and sessions).

4. I agree with your notion of Session establishment and session termination 
   transactions. 

5. I believe, the group Ids an agent would use during the lifetime of a Midcom
session should be specified by the agent - either at the midcom session
establishment time or afterwards whild the midcom session is alive. Given that
group-Ids are specific to an agent, it shoudl be agent's responsibility to
assign group IDs, not that of the middlebox's. Further, given that there are 3
different types of resources (map entries, Binds and sessions), there shoudl be
three different sets of group-Ids, one set for each resource type.
Middlebox will assign a default groupId of 0 to all entities that are not
assigned a groupId by the agent.

regards,
suresh

> http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-04.txt

=====

---

From: Jürgen Quittek <[email-masked]>
Date: Thu, 11 Sep 2003 13:45:50 +0200

Juergen,

I understand your concerns. They can be addressed by moving transactions
Policy Rule List  (PRL) and Policy Rule Status (PRS) from optional to
mandatory.

Still I do not have a strong feeling about whether or not applying this
change. But if not one objects on the list, I'm fine with applying it to
the next version.

    Juergen
-- 
Juergen Quittek        [email-masked]        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

---

From: Jürgen Quittek <[email-masked]>
Date: Thu, 11 Sep 2003 14:00:53 +0200

Pyda,

Thanks for your comments. Please see replies to some of them inline.

>          Midcom/NAT transactions would be specified on a per-interface basis.

I do not share this view. A midcom agent has the intention and capability
to specify endpoints of communication across the middlebox. Which interfaces
of the middlebox are affected is not subject of midcom transactions.

The MIDCOM information model simplifies the network view by just separating
an internal network and an external network. Whether or not the middlebox has
one or more interfaces connected to any of them is considered an internal matter
of the middlebox.

There is no statement in framework or requirements that oblige an agent to find
out which interfaces a middlebox is using.

> the agent, b) created by the NAT middlebox, or c) paramaters modified by the

The way I see it, MIDCOM does not distinguish binding and session (as the NAT MIB does).
The point is that the MIDCOM protocol is not a middlebox management protocol, but a
protocol that allows applications to express requests for enabling communication
across a middlebox.

> it just happens to be in relation to an address map entry.

The intention behind PRR is just to reserve addresses at the middlebox.
This can be doen without mapping them already.

> types of policy rules (address map entries, binds and sessions).

Again, binds and sessions cannot be distinguished in the midcom world.

> assign group IDs, not that of the middlebox's. Further, given that there are 3

Group IDs need to be unique per middlebox.
This is hard to achieve if the agent assigns them.

> assigned a groupId by the agent.

I prefer to have reservation rules and enable rules (bindings) to be
able to share a group. because then the agent can extend or delete
sets of them belonging together by just accessing a single group.

Cheers,

    Juergen

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 15 Sep 2003 09:32:39 -0700 (PDT)

Jurgen,

Please see my comments below.

regards,
suresh

> of the middlebox are affected is not subject of midcom transactions.

It would be when the middlebox has several interfaces.

> one or more interfaces connected to any of them is considered an internal

The above argument would suffice for an information model where the network
view is merely in terms of an internal network and an external network. This
would not be adequate on an operating middlebox. Both NAT and firewall oftne
have interface specific configurations. midcom agent will have all the
information it needs from the middlebox using per-intarface configurations.
 
> out which interfaces a middlebox is using.

The above two documents are agnostic to the deployment scenarios and do not
assume a specific type of middlebox or network configurations. 

> The way I see it, MIDCOM does not distinguish binding and session (as the NAT

Why is that? Binds and sessions must be distinguished. This is nothign new. You
might want to refer RFC 3489 as to why it is important to make this distinction
n the context of NAPT devices.

> protocol that allows applications to express requests for enabling

Agreed. But, you cannot mandate that a middlebox to support requests that it is
not capable of. Ex: If an agent creates a port-Bind-ID and expects this Bind-Id
to be used for all outgoign sessions by the NAPT device, the agent is going to
be disappointed on certain boxes. 
 
> This can be doen without mapping them already.

Jurgen - A middlebox may have several address map entries configured on an
interface. Which of the entries do you refer the addresses to? Why do you think
the agent shoudl be allowed to reserve addresses alone?

> Again, binds and sessions cannot be distinguished in the midcom world.

Again, this is not true. Can you point me to any reference that said this?

> Group IDs need to be unique per middlebox.

Why is that? Groups are a convenience concept introduced for the benefit of
agents and hence are relevant to midcom agents. Agents use Group Ids to process
a group of resources in a unique way. As such, the midcom agents ought to be
able to select groupIds unique to itself. I donot see a reason why the
uniqueness of the following tuple not be adequate? (AgentId,
MiddleboxFunctionResourceType, GroupId). 

> This is hard to achieve if the agent assigns them.

On the contrary, I believe the opposite. Please see my note above.

> able to share a group. 

Why do you need reservation rules to be able to share a group? I find the
reservation concept alien to NAT middleboxes. Are you talking about transfer of
ownership from an address map entry to BINDs? if so, I dont see that as
problem. If not, I donot know what you are talking about.

>                        because then the agent can extend or delete

I have no problem with grouping as such. I am in support of the grouping
concept. I see the benefit of group based handling for the midcom agents. For
this reason, I believe, the group IDs are to be assigned by the agents, and not
the middlebox. Further, I dont see how this is related to PRR reservations.

regards,
suresh

=====

---

From: Melinda Shore <[email-masked]>
Date: Mon, 15 Sep 2003 13:08:09 -0400

On Monday, September 15, 2003, at 12:32 PM, Pyda Srisuresh wrote:
>>>          Midcom/NAT transactions would be specified on a 
>>> per-interface
>> basis.
>>

The question is fraught with all sorts of problems.  For example, it's
probably not reasonable to expect agents to know not only which 
interfaces
a middlebox has but also how they're routed, at least in an even 
modestly
complex environment.  Nevertheless I do think that this is one area 
where
there are more benefits from allowing the possibility of doing this than
from not allowing it.  Frankly my expectation in the general case would 
be
for an agent to send a request without specifying the interface and 
allow
the middlebox to choose one, either returning (or not) the selected
interface.

Melinda

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 15 Sep 2003 16:51:47 -0700 (PDT)

> the middlebox to choose one, either returning (or not) the selected

In the case where a middlebox is configured with NAT/Firewall on a single
interface, I guess, the transactions could default to that specific interface
when the interface is not specified.

regards,
suresh

=====

---

From: Daniel Fonseca <[email-masked]>
Date: Mon, 15 Sep 2003 17:57:17 -0700 (PDT)

--- Pyda Srisuresh <[email-masked]> wrote:
> > >> I do not share this view. A midcom agent has
> the intention and 
> > >> capability
> > >> to specify endpoints of communication across
> the middlebox. Which 
> > >> interfaces

(I found the following explanation very hard to write
clearly about. Let me know if it's still confusing.)

suresh, I was thinking about the case you mentioned
previously, regarding specifically the interfaces
connected to networks with overlapping addresses or
different IP versions (did I get it right?). However,
I think the protocol is meant to be transparent to the
end applications.

Under those circumstances, I was not able to come up
with any realistic scenario where an app would attempt
to connect to an address of a different version, or
even know about a host in some other network with the
same address space. The former seems unlikely to me,
and the latter would only be possible if a Twice-NAT
was already defined at the middlebox. But then the
middlebox would already "know" which interfaces are
involved in the transaction. That is also the case
with different IP versions.

Will the ALG be responsible for keeping its own NAT
table, with all addresses and interfaces?

Hope that was clear enough,
Daniel

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 15 Sep 2003 20:09:50 -0700 (PDT)

> I think the protocol is meant to be transparent to the

If you are referign to the Midcom protocol, it is meant to manage middlebox
resources so the middlebox will not need ALG support. 
> to connect to an address of a different version, or

I was refering to a IPv4 or IPv6 public network.

> with different IP versions.

Why is that? There are NATs and forewalls that permit traffic between IPv4 and
IPv6 realms. 

> table, with all addresses and interfaces? 

Are you refering to a midcom agent? The midcom agent might do so. The middlebox
will also do that independent of the midcom agent.
> Hope that was clear enough,

Daniel - there are several scenarios where a middlebox might have multiple
initerface specific middlebox configurations on the same box. 

> Daniel
cheers,
suresh

=====

---

From: Jürgen Quittek <[email-masked]>
Date: Tue, 16 Sep 2003 13:11:26 +0200

Pyda,

--On 15.09.2003 9:32 Uhr -0700 Pyda Srisuresh <[email-masked]> wrote:

> --- J¸rgen_Quittek <[email-masked]> wrote:
>> Pyda,
>>

Then the MIDCOM server needs to identify the proper interfaces or configure
all of them. The primary goal is enabling communication between the specified
end points.

> would not be adequate on an operating middlebox. Both NAT and firewall oftne

You are right. It is not adequate within the middlebox. The MIDCOM server
needs to translate the higher-level information into the level required at
the middlebox. This internally required level heavily depends on the actual
implementation of the middlebox and should not be reflected by the MIDCOM
protocol.

> information it needs from the middlebox using per-intarface configurations.

We should not require all MIDCOM agents to interpret low-level configuration
information of any kind of firewall and NAT. Please see the comment on this
in my previous message.

> assume a specific type of middlebox or network configurations.

Yes. That's a feature, not a shortcoming. The MIDCOM protocol semantics also
does not assume a specific type of middlebox or network configurations.
Consequently, the semantics are defined in a way, that firewalls and NATs
share as much as possible.

> n the context of NAPT devices.

I do not see any contradiction with RFC 3489.

I understand that for a NAT it is important to distinguish binding and session
(depending of the funtionality and the implementation). However, I do not see
why this distinction would be an issue for a MIDCOM agent. Again: the agent
requests ENABLING communication between specified end points. The realization
in terms of bindings and sessions is left to the middlebox. The middlebox can
consider all its functionality and implementation properties when enabling
the communication.

> not capable of. Ex: If an agent creates a port-Bind-ID and expects this Bind-Id

If a NAT is not capable, it just should reject the request.

> be disappointed on certain boxes.

What do you mean with all outgoing sessions?
The operational model defined in RFC 3303 and used for the examples in the
semantics draft rather suggest to have a MIDCOM request per session (to be precisely:
here 'session' relates to application level session, not necessarily to NAT sessions).

I wonder why a middlebox would not be capable of providing such fine-grained bindings.

> the agent shoudl be allowed to reserve addresses alone?

It is the middlebox' task to find out which address mapping is affected.
The concept of address mapping remains hidden for the MIDCOM agent.

> Again, this is not true. Can you point me to any reference that said this?

This is in line with RFC 3303 and 3304, although not explicitly mentioned there.
Can you point to any reference that contradicts this?

> On the contrary, I believe the opposite. Please see my note above.

I see, agreed. But still I wonder why you say "group-Ids are specific to
an agent, it shoudl be agent's responsibility to assign group IDs"?

Why are group IDs specific to an agent?

They are used to address a group of rules on a certain middlebox.
So the primary requirement is having them unique per middlebox.

> problem. If not, I donot know what you are talking about.

Several of our controversies are based on our different view points.
You look a the issues from a NAT perspective, I am looking from a MIDCOM
agent perspective.

>From an agent perspective I would like to have rules belonging to the same
(application-level) session into one group. Then I can easily extend the
lifetime of all rules, when I want to extend the lifetime of the entire
session. Or I can terminate everything at once without forgetting a rule.

But when setting up a session, I can set up some reservation rules
immediately, for some I have to make a reservation first and wait
for more signaling messages until session setup is complete. During that
time, I assign all rules to the same group. When session setup is
complete, all rules are reserve rules. This is different during initial
setup or when the session is modified while being active. Then also
reserve rules are members. If session setup fails, I can just delete
the group with all rules including reservation rules.

Of course, from a NAT point of view, this is different. There are
essential differences between reservations and bindings/sessions.
However, this difference should be kept internal.

The MIDCOM server can easily maintain groups consisting of address
reservations, NAT bindings/sessions, and firewall rules. I do not think
NAT bindings and address bindings are much more alien to each other
than NAT bindings and firewall rules are.

Cheers,

    Juergen

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 16 Sep 2003 21:24:25 -0700 (PDT)

--- Jürgen_Quittek <[email-masked]> wrote:
> >> > am including the text for wider audience. Below are my outstanding
> comments
> >> on
> >> > the draft.
> >> >

I understand what you say about agent wanting to enable communication between
application end-points. I elieve, the agent cannot do this without the
knowledge of how the middlebox is configured. How can the agent know to make
the NAT transactions without the knowledge of how the address maps configured
on the middlebox?  

> implementation of the middlebox and should not be reflected by the MIDCOM

I understand where you are coming from. However, I do believe, an agent needs
to be aware of the middlebox configuration and resources so it knows what is
relevant for itself. Some of the transactions could possibly be made interface
independent. But, I believe, that cannot be the case for all transactions. 
(see my NAT transaction examples).

> information of any kind of firewall and NAT. Please see the comment on this

Is NAT address map and default idle-timeout configuration low level, in your
mind? If so, how do you propose to get this information at a high level? How do
you propose to reserve a bunch of addresses or TU-ports on a NAT middlebox
without knowing where these addresses are configured?

> >> > Address map entries, Binds and sessions. These resources may be a)
> created
> >> by
> >> The way I see it, MIDCOM does not distinguish binding and session (as the
> NAT
> >> MIB does).
> >
> why this distinction would be an issue for a MIDCOM agent. 

If an agent doesnt know the resources relevant to a NAT device, how do you
propose the agent communicate to the NAT device? A portbind does not make sense
to a symmetric NAT. It is simply meaningless to the device because, it uses the
same local tuple to bind to different public port tuples.

>                                                            Again: the agent
Please see my note above. The semantics draft refers to binds and does not
refer to sessions or address map entries.

> >> The point is that the MIDCOM protocol is not a middlebox management
> protocol,
> >> but a
Well, the midcom protocol just failed to accomplish what is required of it.
This would not have been the case had the semantics been aware of the fact that
the NAT middlebox was not using port-binds.

> here 'session' relates to application level session, not necessarily to NAT
NAT maintains a session for every 5-tuple that traverses it. 

> I wonder why a middlebox would not be capable of providing such fine-grained
That is my point, Jurgen. Not all NAT devices provide fine-grained binds. But,
an agent needs to work with the resources a middlebox manages.

> The concept of address mapping remains hidden for the MIDCOM agent.

I disagree.

> 
> >>
> >> > 3. When you combine the notion of PRR wth PER, the state transition
> diagram
> >> in

They do not mention it. 

> Can you point to any reference that contradicts this?

Take a look at RFC 3235 - section 3.1.1 & 3.2.1.
I would also suggest you to take a look at RFC 3489, section 5.

> >> > establishment time or afterwards whild the midcom session is alive.
> Given
> >> that

Well, the grouping is done by an agent for its convenience. The properties for
a group are set by the agent. An agent will not use or manipulate another
agent's group-Id etc.. 

Middlebox has no use for groups, if agents do not need them. Given that an
agent ID is unique, why should the middlebox be required to maintain unique
group IDs across all the various agents and resource types?

> So the primary requirement is having them unique per middlebox.

Well, the resource entity must be owned by an agent before the entity is
assigned a group ID. Given that the entity is already owned by the agent, the
agent might as well assign a group-Id as appropriate to itself.
 
> You look a the issues from a NAT perspective, I am looking from a MIDCOM

Well, here is what I think is the difference.

I look at MIDCOM as a transaction model in which an agent works with middlebox
resources.  This has been to central to all my arguments. Correct me if I am
wrong. But, I believe, you are creating an abstract model of resources (which,
I believe, you call as rules)  and mandate middleboxes to meet that abstract
resource model. That is the disconnect between us, in my opinion. 

Middleboxes have been here for sometime. Midcom protocol shoudl not mandate
dramatic change in their resource model or their way of basic operation. 

> than NAT bindings and firewall rules are.

Why is the semantics document mandating that middlebox assign and maintaing
unique group IDs, when in fact that may merely be an implementation option?

Why is the semantics document mandating reservation rules for addresses and
ports?  Why is this reservation construct more important than working with the
resources/objects that a NAT middlebox has ex: NAT address map entries, binds,
sessions.
 
cheers,
suresh

=====

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 17 Sep 2003 15:45:56 +0200

Pyda,

--On 16.09.2003 21:24 h -0700 Pyda Srisuresh <[email-masked]> wrote:

>> > --- J?rgen_Quittek <[email-masked]> wrote:
>> >> Pyda,
>> >>

What the agents need to know is basic topology information: which address is in
which realm and which gateway connects which realms. Based on this information
it can send requests to the middlebox for enabling communication between the
specified endpoint addresses. Whether or not the middlebox uses address maps,
bindings and fine grained sessions is not of particular interest for the agent.
The MIDCOM server has the task to map the well defined high-level request to
the existing configuration of the NAT or firewall.

> relevant for itself.

Why should it care about? It sends clearly defined requests and at the middlebox
there is all information available that is required for fulfilling the request.

>                      Some of the transactions could possibly be made interface

Yes, the transactions may concern specific interfaces, but the middlebox
has all information available to find out which are these specific ones.
Why should the agent duplicate this information and try to be smarter than
the middlebox itself concerning middlebox internal configuration issues?

> without knowing where these addresses are configured?

NAT address map yes, because it is not relevant for the MIDCOM information model.
The idle timeout can be visible for the agent, when the NAT terminates an enable
because the idle timeout expired. Then the MIDCOM server at the NAT needs to
send a notification to all affected agents.

>> share as much as possible.

 [...]

> same local tuple to bind to different public port tuples.

Again, the agent does not explicitly ask for a port bind.
It asks for enabling communication between the specified end points!
Whether or not the middlebox needs to establish a port bind for enabling
communication is not really what the agent cares about.

> refer to sessions or address map entries.

It looks like, here we are close to the core of our dispute:
Why does the middlebox has to care about details of the way the NAT or firewall
enables communication? The NAT should be smart enough to decide this by itself,
particularly, since it knows and understands its own configuration much better
than an agent would do.

> the NAT middlebox was not using port-binds.

Still I see this as a problem to be solved by the NAT.
Do I miss something important?

> NAT maintains a session for every 5-tuple that traverses it.

Yep, that's what the agent likes.

> an agent needs to work with the resources a middlebox manages.

If they don't, they probably have other means for enabling communication between
the specified endpoints, don't they?

>> The concept of address mapping remains hidden for the MIDCOM agent.

How can we solve our disagreement.

Your claim:

  - the agent needs to completely understand the entire middlebox
    configuration and its its way of operation (be it a firewall or
    a NAT or a combined device) and then determine which values it
    needs to write to which SNMP table (address map, bindings,
    firewall rules, ...).

Martin's and Juergen's claim:

  - The request sent by the agent should be as independent as possible
    from actual middlebox configurations and ways of operation. The
    middlebox needs to translate the high level requests sent by the
    agent to a set of local configuration parameters.

> I would also suggest you to take a look at RFC 3489, section 5.

I fully agree with all sections you mention.
Still, I do not see how they affect our discussion.

> a group are set by the agent. An agent will not use or manipulate another

It will. Here is a quote from RFC 3304, section 2.2.7:

    The Midcom protocol must not preclude multiple authorized agents from
    working on the same ruleset.

> group IDs across all the various agents and resource types?

See above. RFC 3304, section 2.2.7 requires this.

> agent might as well assign a group-Id as appropriate to itself.

According to the semantics document, acquiring a resource and assigning it
to a group is performed in a single transaction. There is no requirement
for ordering them. Actually, in an early version of the SIMCO protocol
the agent was required to establish a group first, before it could request
resources.

> resource model. That is the disconnect between us, in my opinion.

Completely agreed.

> dramatic change in their resource model or their way of basic operation.

Actually, there is no such request at all.

The only request is adding a MIDCOM server to the middlebox implementing the
MIDCOM protocol semantics.

This does not seem to be a dramatic change of the basic operation of a middlebox.
In contrary, I do not even require that the way of operation is visible outside
of the middlebox. The middlebox can operate as it likes and use any resource
model that is sufficient for its operation. Only the new MIDCOM server at the
middlebox needs to understand the way of operation.

> unique group IDs, when in fact that may merely be an implementation option?

They are not. They are required by RFC 3304, section 2.2.3.

> resources/objects that a NAT middlebox has ex: NAT address map entries, binds,

This a very good question. And sometimes I still wonder about that.
However, I have not seen any other satisfying solution for the application
scenario from which the need for this transaction was derived, see semantics
section 4.2.

Cheers,

    Martin and Juergen

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 18 Sep 2003 11:03:39 +0200

--On Thursday, September 11, 2003 13:45:50 +0200 Jürgen Quittek 
<[email-masked]> wrote:

| Juergen,
|
| I understand your concerns. They can be addressed by moving transactions
| Policy Rule List  (PRL) and Policy Rule Status (PRS) from optional to
| mandatory.
|
| Still I do not have a strong feeling about whether or not applying this
| change. But if not one objects on the list, I'm fine with applying it to
| the next version.

Since there are no objections from any of the mailing list, I would say 
that Policy Rule List (PRL) and Policy Rule Status (PRS) are going to be 
mandatory in the semantics.

Cheers
Martin

Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 19 Sep 2003 11:21:18 +0200

--On Donnerstag, 18. September 2003 20:11 -0400 Tom Taylor 
<[email-masked]> wrote:

| I support Jürgen in this, but it raises a couple of interesting points.
| The first is that the aims of the NAT MIB and the MIDCOM "whatever" are
| different, because the target users are different.  The NAT MIB is
| primarily there for administrators, while the MIDCOM "whatever" is for
| authorized hosts (MIDCOM agents) supporting applications.  The objects of
| interest are going to differ as a consequence.
|
| The second point is partly independent of this: my preference as a
| "semantics" author to take an abstract view of firewall and NAT
| operation, with the aim of avoiding as much as possible the need to know
| what services the middlebox supports, is in definite contrast to the
| content of the current NAT and firewall MIBs.  I am not surprised to find
| MIB designers scratching their heads over how to reconcile the two points
| of view.  My natural and naive inclination is to view the MIDCOM MIB as a
| logically separate beast.  The NAT or firewall MIB would merely reflect
| the results of MIDCOM operations, rather than be tied to the MIDCOM MIB
| explicitly.

Hi Tom,

I fully agree with your view that MIDCOM MIB and NAT MIB should be on two 
different levels, the MIDCOM MIB for agents and NAT MIB for system 
administrators.

However, in the design team I'm the only one who is sharing this view, most 
of the others are more in favour of implementing the MIDCOM MIB on the same 
level as the NAT MIB.

This issue is a fundamental one and depending on the choice the design of 
the MIB may vary significantly.

Cheers,
  Martin

|
| I suppose the question is whether the abstract view is acceptable to
| implementors, or whether they will insist that any MIDCOM protocol
| addresses precisely the functions offered by their middlebox.  If Pyda is
| representative of NAT implementors, the semantics need a bit of
| modification.
|
| Jürgen Quittek wrote:
|
|> Pyda,
|>
|> Thanks for your comments. Please see replies to some of them inline.
|>
|> --On 06.09.2003 14:15 Uhr -0700 Pyda Srisuresh <[email-masked]>
|> wrote:
|>
|>> Below is text of the e-mail (a little revised) I sent to the authors
|>> earlier. I
|>> am including the text for wider audience. Below are my outstanding
|>> comments on
|>> the draft.
|>>
|>> 1. For a NAT middlebox, I believe, the semantics ought to cover the
|>> following
|>> transactions. My comments assume the following.
|>>
|>>       A. NAT is configured on a per-interface basis. As such, the
|>>          Midcom/NAT transactions would be specified on a per-interface
|>> basis.
|>
|>
|> I do not share this view. A midcom agent has the intention and capability
|> to specify endpoints of communication across the middlebox. Which
|> interfaces
|> of the middlebox are affected is not subject of midcom transactions.
|>
|> The MIDCOM information model simplifies the network view by just
|> separating an internal network and an external network. Whether or not
|> the  middlebox has
|> one or more interfaces connected to any of them is considered an
|> internal matter
|> of the middlebox.
|>
|> There is no statement in framework or requirements that oblige an agent
|> to find
|> out which interfaces a middlebox is using.
|>
|>>       B. End-point below is to be refered as <IP addr, TCP/UDP, TU-port>
|>>          for a PortBind. End-point for an address Bind will be
|>>          <IP address>. The IP address can be V4 or V6.
|>>       C. The transactions specified below can be applicable to one or
|>> more
|>>          end-points. This will include address ranges, address
|>>          wild-carding, port ranges, and port wild-carding.
|>>
|>>
|>> SetMapOwner <AddressMapEntryIndex> [Full | Partial] [<Subset of Map
|>> Entry>]
|>>                       - SetMapowner may be used by an agent to claim
|>>                         ownership on a complete NAT map entry or a
|>>                         portion of the entry. AgentId will be set as the
|>>                         owner of the entire map entry or portion
|>>                         thereof.
|>>
|>> (CreateBind | CreatePortBind)
|>>             <AddressMapEntryIndex> <original End-point> <Xlated
|>> End-point>
|>>                       - Agent specifies all the requisite Parameters for
|>>                         Bind(s) or PortBind(s). Agent requests middlebox
|>>                         to create a BIND and respond back with an
|>> assigned
|>>                         BindId. Middlebox to validate the authorization
|>>                         prior to responding.
|>>
|>> (RequestCreateBind | RequestPortCreateBind)
|>>            <AddressMapEntryIndex> <original End-point> [Oddity option]
|>>                       - Agent requests the Middlebox to create BIND(s)
|>> for
|>>                         the given End-point, optionally with an Oddity
|>>                         requirement. Middlebox to validate the
|>>                         authorization, prior to assgining a BIND and
|>>                         a BindId and returning the response.
|>>
|>> CreateOutboundSession
|>>           <OutboundSrc map entry index> | <OutboundSrc end-point BindId>
|>>           <OutboundDest map entry index> | <OutboundDest end-point
|>> Bindid>
|>>           <Original Outbound session tuple>
|>>           <Translated outbound session tuple>
|>>                       - Agent specifies all the requisite Parameters for
|>>                         an outbound session. Agent requests middlebox
|>>                         to create a session as specified and respond
|>>                         back with an assigned BindId.
|>>                         The session may have one or two end-point
|>>                         translations. The session may be derived
|>>                         directly from the address map (or) from
|>>                         associated
|>> Bind-IDs.
|>>                         Middlebox to validate the authorization prior to
|>>                         responding. Note, the session tuple may have
|>>                         wild-card elements.
|>>
|>> RequestCreateOutboundSession
|>>           <OutboundSrc map entry index> | <OutboundSrc end-point BindId>
|>>           <OutboundDest map entry index> | <OutboundDest end-point
|>> Bindid>
|>>           <Original Outbound session tuple>
|>>                       - Agent requests the Middlebox to create an
|>> outbound
|>>                         session for the given session tuple, using one
|>>                         or more map entries and/or end-point BINDs.
|>>                         Agent to validate he authorization prior to
|>>                         responding back with a new session and
|>>                         session-id. As
|>> before,
|>>                         the session tuple may have wild-card elements.
|>>
|>> CreateInboundSession,
|>> RequestCreateInboundSession
|>>                       - Similar to the outbound counterparts.
|>>
|>> ModifyBindParameters  <BindId>
|>>           [<MaximumLifetime>] [MaximumIdletime>] [<GroupId>]
|>>                       - These parameters may be specified either at Bind
|>>                         creation time or later.
|>>
|>> ModifySessionParameters <SessionId>
|>>           [<MaximumLifetime>] [MaximumIdletime>] [<GroupId>]
|>>                       - These parameters may be specified either at
|>> session
|>>                         creation time or later. Note, session here
|>>                         refers to the NAT data sessions, not the Midcom
|>>                         agent session.
|>>
|>> In particular, I would like to mention the notion of three resources
|>> a NAT middlebox and midcom agent need to be cognizant of -
|>> Address map entries, Binds and sessions. These resources may be a)
|>> created by
|>> the agent, b) created by the NAT middlebox, or c) paramaters modified
|>> by the
|>> agent.
|>
|>
|> The way I see it, MIDCOM does not distinguish binding and session (as
|> the NAT MIB does).
|> The point is that the MIDCOM protocol is not a middlebox management
|> protocol, but a
|> protocol that allows applications to express requests for enabling
|> communication
|> across a middlebox.
|>
|>> 2. The notion of PRR is incomplete without the context of the entire
|>> address
|>> map entry. The reservation may not be specific to address/address-port
|>> alone.
|>> My view of this is simply that PRR is just another notion of ownership
|>> claim.
|>> it just happens to be in relation to an address map entry.
|>
|>
|> The intention behind PRR is just to reserve addresses at the middlebox.
|> This can be doen without mapping them already.
|>
|>> 3. When you combine the notion of PRR wth PER, the state transition
|>> diagram in
|>> section 2.3.13 woudl be simplified, with the proviso that there would
|>> be three
|>> types of policy rules (address map entries, binds and sessions).
|>
|>
|> Again, binds and sessions cannot be distinguished in the midcom world.
|>
|>> 4. I agree with your notion of Session establishment and session
|>> termination
|>>    transactions.
|>>
|>> 5. I believe, the group Ids an agent would use during the lifetime of
|>> a Midcom
|>> session should be specified by the agent - either at the midcom session
|>> establishment time or afterwards whild the midcom session is alive.
|>> Given that
|>> group-Ids are specific to an agent, it shoudl be agent's
|>> responsibility to
|>> assign group IDs, not that of the middlebox's. Further, given that
|>> there are 3
|>
|>
|> Group IDs need to be unique per middlebox.
|> This is hard to achieve if the agent assigns them.
|>
|>> different types of resources (map entries, Binds and sessions), there
|>> shoudl be
|>> three different sets of group-Ids, one set for each resource type.
|>> Middlebox will assign a default groupId of 0 to all entities that are
|>> not assigned a groupId by the agent.
|>
|>
|> I prefer to have reservation rules and enable rules (bindings) to be
|> able to share a group. because then the agent can extend or delete
|> sets of them belonging together by just accessing a single group.
|>
|> Cheers,
|>
|>    Juergen
|

Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
PGP Key at:        http://www.stiemerling.org/stiemerling_nec.gpg
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

---

From: Tom Taylor <[email-masked]>
Date: Thu, 18 Sep 2003 20:11:52 -0400

I support Jürgen in this, but it raises a couple of interesting points.  The first 
is that the aims of the NAT MIB and the MIDCOM "whatever" are different, because the 
target users are different.  The NAT MIB is primarily there for administrators, 
while the MIDCOM "whatever" is for authorized hosts (MIDCOM agents) supporting 
applications.  The objects of interest are going to differ as a consequence.

The second point is partly independent of this: my preference as a "semantics" 
author to take an abstract view of firewall and NAT operation, with the aim of 
avoiding as much as possible the need to know what services the middlebox supports, 
is in definite contrast to the content of the current NAT and firewall MIBs.  I am 
not surprised to find MIB designers scratching their heads over how to reconcile the 
two points of view.  My natural and naive inclination is to view the MIDCOM MIB as a 
logically separate beast.  The NAT or firewall MIB would merely reflect the results 
of MIDCOM operations, rather than be tied to the MIDCOM MIB explicitly.

I suppose the question is whether the abstract view is acceptable to implementors, 
or whether they will insist that any MIDCOM protocol addresses precisely the 
functions offered by their middlebox.  If Pyda is representative of NAT 
implementors, the semantics need a bit of modification.

Jürgen Quittek wrote:

>> comments on
>> created by
> protocol, but a
>> diagram in
>> Given that

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 19 Sep 2003 11:47:51 +0200

Tom,

--On 18.09.2003 20:11 Uhr -0400 Tom Taylor <[email-masked]> wrote:

> I support Jürgen in this, but it raises a couple of interesting
> points.  The first is that the aims of the NAT MIB and the MIDCOM
> "whatever" are different, because the target users are different.
> The NAT MIB is primarily there for administrators, while the MIDCOM
> "whatever" is for authorized hosts (MIDCOM agents) supporting
> The second point is partly independent of this: my preference as
> a "semantics" author to take an abstract view of firewall and NAT
> operation, with the aim of avoiding as much as possible the need>
> to know what services the middlebox supports, is in definite
> contrast to the content of the current NAT and firewall MIBs.
> I am not surprised to find MIB designers scratching their heads
> over how to reconcile the two points of view.  My natural and
> naive inclination is to view the MIDCOM MIB as a logically
> separate beast.  The NAT or firewall MIB would merely reflect the
> results of MIDCOM operations, rather than be tied to the MIDCOM
> MIB explicitly.

I share this view. The MIDCOM MIB should allow the agent to specify
requests on a higher level (i.e. with much less detail) than for
example the NAT MIB would require.  A consequence step based on
this view would be to specify the MIDCOM MIB straight forward
according to the semantics document.

A straight forward MIB would define a table per major section in the
semantics: A session table, a policy rule table and a group table
plus some scalars (or a small additional table) for the middlebox
capabilities. And this would be all.

This would most probably simplify and speed up the MIB definition
and based on this approach, we could have a first draft very soon.

    Juergen

> I suppose the question is whether the abstract view is acceptable
> to implementors, or whether they will insist that any MIDCOM
> protocol addresses precisely the functions offered by their
> middlebox.  If Pyda is representative of NAT implementors, the
> semantics need a bit of modification.
>
> Jürgen Quittek wrote:
>
>> Pyda,
>>

---

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 20 Sep 2003 11:21:50 -0700 (PDT)

--- Tom Taylor <[email-masked]> wrote:
> I support Jürgen in this, but it raises a couple of interesting points.  The

Well, it is good to agree on what we disagree about. The differences in our
view of Midcom semantics is that I look at Midcom as a transaction model in
which an agent works with middlebox resources.  Whereas, you created an
abstract model of resources(which, you call as rules)  and mandate middleboxes
to meet that abstract resource model. That is the disconnect between us.

> first 
The midcom semantics is transaction oriented to accomplish application specific
end-2-end session setup. The transactions are directed to a middlebox. For this
reason, the transactions (and hence the agents) must have a knowledge of
middlebox configuration. This is independent of whether the middlebox is
configured using a MIB or other means. One outcome we agreed on just recently
(in a different thread) as a result is the need for interface argument in
midcom transactions.

> is in definite contrast to the content of the current NAT and firewall MIBs. 

Please see my note above. 

The abstract transaction model in the semantics draft has shortcomings. 
a) PRR/PER will only work in simplest of configurations.
b) The transaction model, as specified, imposes rather unnecessarily complex
and yet times, impossible task on the middlebox.

Let us consider the "PRR" transaction (section 2.3.7). PRR is supposed to
reserve an address or a port number range. This might work in the case the
middlebox has just one map entry in the address map (say 0.0.0.0/0 -> X1 or
0.0.0.0/0 -> X2/n). This will fail the moment the address map has multiple map
entries. Further, an address or port-range reservation is meaningful only in
the context of an address map entry. Say, you had 3 address map entries as
follows.
                     10.1.0.0/16 -> X1/24; 
                     10.2.5.0/24 -> X2/28; 
                     0.0.0.0/0 -> X3;

Say, PRR made a request for an address without the context of a map entry. Say,
the middlebox responded back with an address in X1 range. This address would be
meaningless to the agent, if the agent happens to be using an address outside
the range of 10.1.0.0/16. So, the PRR request ought to specify the address map
entry from which the request is beign made. 

Even if the agent was using an address in the range of 10.1.0.0/16 - say,
10.1.0.1,  and the agent obtains an address, say X1.1, the middlebox has no way
to know that all sessions from 10.1.0.1 have to be bound to X1.1. The agent
might create a BIND (using PER) at a later time. But, prior to this, if NAT
sees any session originating from 10.1.0.1, it would bind the address to one of
the available addresses within X1/8 (different from X1.1, as X1.1 is reseved by
an agent). Now, lots of chaos ensues because, the PER from the agent would
fail.

This is why I suggested the tansaction "SetMapOwner <AddressMapEntryIndex>
[Full | Partial] [<Subset of Map Entry>]" to claim full/partial ownership of an
address map entry unequivocally. This is fully contextual and there are no race
conditions between the agent and the middlebox.

Now, let us consider the case of PER transaction(section 2.3.8). PER in the
context of a NAT refers to the agent creating a NAT binding with specific
parameters. This will fail if the prameters specified in the bind-create
request donot correspond to one or more (in the case of twice-NAT) address map
entries. Without reference of an address map entry, the agent has no knowledge
of whether to request for an address bind or a port bind. Further, the binding
is meaningless without the exact session description to a symmetric NAPT. This
is because symmetric NAPT uses different port bindings for the same (private IP
address, port) tuple used in different sessions. The port bind may work only
for the first session that originates from (provate IP address, port). There
are other caveats. Without a PRR preceding the PER, how is the PER to know what
external address to bound to? Why not let the middlebox select the external
address to bound to? 

This is why I suggested the tansactions CreateBind, CreateportBind,
RequestCreateBind, and RequestCreatePortBind to create binds unequivocally.
These transactions use address map as an argument. Either the agent or the
middlebox can create a bind. 

Creating binds is not adequate. The agent needs to be able to specify the
permitted sessions as well. Without going into the details, i will simply
suggest FTP(TCP based) and TFTP(UDP based) are examples of this.

This is why I suggested the tansactions CreateOutboundSesion,
CreateInboundSession, RequestCreateOutboundSession and
RequestCreateInboundSession to create sessions unequivocally. Either the agent
or the middlebox can create a session.

As for twice-NAT, I am frankly confused by the PRR/PER transactions. There was
reference to using a singe policy rule identifier for two address/port
reservations and two binds. Assuming all the parameters specified in a PER are
adequate (which I dont believe, they are), the requirement of using a new
artificial handle to represent two independent twice-nat bind is unnecessarily
complex on the part of the middlebox.

> I am 
> two points of view. 

MIB designers donot have a problem creating a MIB to run transactions. MIB
designers are having to scratch their head because the Midcom semantics works
only in the simplest of cases. 

>                     My natural and naive inclination is to view the MIDCOM
> MIB as a 

I donot have a problem provided the the midcom transactions are reasonable,
complete and donot impose impossible requirements on the middleboxes. It is my
view that the transactions are most meanigful when the transactions relate to
the resources/objects the middlebox can relate to.

> implementors, the semantics need a bit of modification.

I do believe, the transactions in the semantics document need modification. If
you like, I would be glad to work with the authors on this.

regards,
suresh

=====

---

From: Tom Taylor <[email-masked]>
Date: Sun, 21 Sep 2003 09:33:03 -0400

You have a couple of valid points in here that we have to address, but others that 
we need to discuss further.  Before we start, let me recall the terminology we use 
in the semantics document.  We speak of four addresses A0, A1, A2, and A3.  They are 
illustrated in this diagram:

        +----------+                                 +----------+
        | internal | A0    A1 +-----------+ A2    A3 | external |
        | endpoint +----------+ middlebox +----------+ endpoint |
        +----------+          +-----------+          +----------+

A0 and A3 are specified by the agent.  A1 and A2 are assigned by the middlebox in 
response to PRR or PER.

> --- Tom Taylor <[email-masked]> wrote:
[PTT - Generalities snipped]
> entry from which the request is beign made. 

[PTT] Looks like we should include address A0 (the inside endpoint address) as a 
parameter of the PRR.  That gives the middlebox the information it needs to select 
the right map entry.  It's still unnecessary for the agent to know the map entries 
themselves.

> an agent). Now, lots of chaos ensues because, the PER from the agent would

[PTT] This one is definitely a concern.  It seems to me we have to specify in the 
semantics of PRR that if a reservation is made, it must be honoured in subsequent 
sessions set up automatically by the middlebox (need better words).  In the context 
of your particular example, if the middlebox assigns address X1.1 (as address A2) to 
10.1.0.1 (address A0) as a result of PRR, then while the reservation holds, any 
subsequent BINDs for sessions from 10.1.0.1 must use address X1.1.

[PTT - implementation details snipped]
> middlebox can create a bind. 

[PTT] You are arguing that if the agent knows the map entries, it can request the 
specific binding that it needs.  I'll put it the other way: the current PER 
parameters include the internal endpoint address A0, the external endpoint address 
A3, and, if a PRR was performed previously, a reference to the A1 and A2 assignments 
that resulted from that PRR.  What other information does the middlebox need to 
complete the bind?

> suggest FTP(TCP based) and TFTP(UDP based) are examples of this.
[PTT] I want to carry on further discussion of this point with a clear understanding 
of your terminology.  Please indicate what additional parameters distinguish a 
session from a bind.

[PTT - remainder snipped]

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 22 Sep 2003 13:55:09 -0700 (PDT)

> illustrated in this diagram:

Assuming the agent is on A0, how does the agent know the session is between A0
and A3? A0 only knows that the session is to A1. Middlebox does the needed
translation from A1 to A3.

Also, I would like to point out that the agent need not be the end-host itself.
It could be a proxy in the middle, representing several end-hosts.

> the right map entry.  It's still unnecessary for the agent to know the map

That would make sense in the case the agent is representing just one host.
Otherwise, the agent needs to specify the address range the agent represents.

> subsequent BINDs for sessions from 10.1.0.1 must use address X1.1.

How is this different from the partial/full address map entry ownership I
mentioned?
 
> that resulted from that PRR.  What other information does the middlebox need

Couple of questions:
a) How did the agent know that the session is from A0 to A3? 

b) Assuming it knew the above somehow, you are saying that PRR should return
back a single handle to the agent. Now, is this going to be a handle for a
reserved session, not a BIND? There is a big difference between a bind and a
session. Depending upon what the middlebox returns, the agent has different
work to do. For example, if the agent knows a BIND is setup in a middlebox, it
doesnot need to make a request for every single session it needs to setup using
this bind. The middlebox does this automatically.

> of your terminology.  Please indicate what additional parameters distinguish

A Bind refers to half-session & its transaltion parameters. In the case of
address bind, only the address is translated; port does not get translated. In
the case of port bind, both address and port of the half session are
translated.

cheers,
suresh

=====

---

From: Tom Taylor <[email-masked]>
Date: Mon, 22 Sep 2003 18:11:10 -0400

You're under a misconception.  Address A0 is the internal address of the host whose 
application is being enabled, not of the agent.  And A3 is known (or sometimes not 
known, hence the need for wildcarding) from the application protocol as sent by the 
  endpoint via the agent.  This takes care of your first two comments, I think. 
More on bind vs. session near the bottom.

Pyda Srisuresh wrote:

>>>b) The transaction model, as specified, imposes rather unnecessarily
>>
>>complex
>>
>>>0.0.0.0/0 -> X2/n). This will fail the moment the address map has multiple
>>
>>map
>>
>>>entries. Further, an address or port-range reservation is meaningful only
>>
>>in
>>
>>>Say, PRR made a request for an address without the context of a map entry.
>>
>>Say,
>>
>>>the middlebox responded back with an address in X1 range. This address
>>
>>would be
>>
>>>meaningless to the agent, if the agent happens to be using an address
>>
>>outside
>>
>>>the range of 10.1.0.0/16. So, the PRR request ought to specify the address
>>
>>map
>>
>>>10.1.0.1,  and the agent obtains an address, say X1.1, the middlebox has no
>>
>>way
>>
>>>sees any session originating from 10.1.0.1, it would bind the address to
>>
>>one of
>>
>>>the available addresses within X1/8 (different from X1.1, as X1.1 is
>>
>>reseved by
>>
>>>request donot correspond to one or more (in the case of twice-NAT) address
>>
>>map
>>
>>>entries. Without reference of an address map entry, the agent has no
>>
>>knowledge
>>
>>>of whether to request for an address bind or a port bind. Further, the
>>
>>binding
>>
>>>is meaningless without the exact session description to a symmetric NAPT.
>>
>>This
>>
>>>is because symmetric NAPT uses different port bindings for the same
>>
>>(private IP
>>
>>>address, port) tuple used in different sessions. The port bind may work
>>
>>only
>>
>>>for the first session that originates from (provate IP address, port).
>>
>>There
>>
>>>are other caveats. Without a PRR preceding the PER, how is the PER to know
>>
>>what
>>

[PTT] As noted at the start of this note: from the application protocol sent by the 
interior end point.

> this bind. The middlebox does this automatically.
[PTT] Please see below.
> the case of port bind, both address and port of the half session are
[PTT] I think you are saying that a session is two binds, one in each direction. 
Aside from that, there are no additional parameters.  It does seem that our "policy 
rules" correspond to binds.  In addition, we don't have the concept of session (if I 
understand you correctly) because we request policy rules for the two directions 
independently.  In fact, I'm not sure the idea of a bidirectional session makes much 
sense -- the individual packet flows (e.g. outgoing signalling, incoming signalling, 
outgoing media1, incoming media1, etc.) are activated at different points in time. 
It seems likely that our "group" is the closest thing to a session.

As far as the difference between address bind and port bind, I think we express that 
by specifying whether we are asking for IP (no ports) or UDP/TCP (ports specified).

...

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 23 Sep 2003 07:13:04 -0700 (PDT)

Tom/Jurgen

I've changed the subject line. Please my comments inline. Thanks.

--- Tom Taylor <[email-masked]> wrote:
> application is being enabled, not of the agent.

I did assume A0 to be the address of the host. The agent had to be somewhere
along the line of communication. Since you were refering to an agent
representing just this host, I assumed the agent is also on A0. Now that you
bring this up, does it matter where the agent is located? The agent had to be
on A0, A1 or in-between as on a proxy, right? I dodnt think it mattered, except
when you start assuming the agent is representing just one host.

>                                                 And A3 is known (or
> sometimes not 
>   endpoint via the agent. 

OK. I guess you are using the traditional-NAT model, not twice-NAT. The diagram
implied twice-NAT and I assuemd that.
 
>                           This takes care of your first two comments, I
> think. 
As for bind vs. session, you did not interpret what I said correctly. sounds
like, there is some confusion. I suggest you lookup RFC 2663 or 3022 for what a
binding is. 

<... Rest of the e-mail snipped>

regards,
suresh

=====

---

From: Tom Taylor <[email-masked]>
Date: Wed, 24 Sep 2003 08:41:58 -0400

Comments in line.

> when you start assuming the agent is representing just one host.

[PTT] A PRR or PER is issued on behalf of a single host.  However, an agent may 
issue these requests on behalf of multiple hosts during a single MIDCOM session. 
Regardless, agreed that the only constraint on agent location is that it be on the 
application signalling path.

> implied twice-NAT and I assuemd that.
[PTT] We are using either model.  You seem to be assuming that the only way the 
application can know A3 is from the incoming IP header.  In fact, we assume it is 
known by any means except that.  Most typically the external address would be 
carried in the application protocol content (e.g. SDP) inside the packet.

> like, there is some confusion. I suggest you lookup RFC 2663 or 3022 for what a
[PTT] OK, looking at RFC 2663, I feel quite clear on what a session is.  It seems to 
imply application-level understanding on the part of the middlebox.  The whole point 
of MIDCOM is to restrict the application-level understanding to the agent and the 
endpoint hosts.  Thus the transactions between the agent and the middlebox are 
concerned with packet flows rather than session flows.

The MIDCOM "session" is a whole other matter.  It is simply a working relationship 
established between an agent and a middlebox.  The packet flows enabled during the 
MIDCOM session may or may not be related to each other.

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 24 Sep 2003 16:39:28 +0200

Hi Pyda,

I am splitting your email in several in order to reflect the different 
issues to be handled.

Martin

--On Samstag, 20. September 2003 11:21 -0700 Pyda Srisuresh 
<[email-masked]> wrote:

[...]
|> The second point is partly independent of this: my preference as a
|> "semantics"
|> author to take an abstract view of firewall and NAT operation, with the
|> aim of
|> avoiding as much as possible the need to know what services the middlebox
|> supports,
|> is in definite contrast to the content of the current NAT and firewall
|> MIBs.
|
| Please see my note above.
|
| The abstract transaction model in the semantics draft has shortcomings.
| a) PRR/PER will only work in simplest of configurations.
| b) The transaction model, as specified, imposes rather unnecessarily
| complex and yet times, impossible task on the middlebox.
|
| Let us consider the "PRR" transaction (section 2.3.7). PRR is supposed to
| reserve an address or a port number range. This might work in the case the
| middlebox has just one map entry in the address map (say 0.0.0.0/0 -> X1
| or 0.0.0.0/0 -> X2/n). This will fail the moment the address map has
| multiple map entries. Further, an address or port-range reservation is
| meaningful only in the context of an address map entry. Say, you had 3
| address map entries as follows.
|                      10.1.0.0/16 -> X1/24;
|                      10.2.5.0/24 -> X2/28;
|                      0.0.0.0/0 -> X3;
|
| Say, PRR made a request for an address without the context of a map
| entry. Say, the middlebox responded back with an address in X1 range.
| This address would be meaningless to the agent, if the agent happens to
| be using an address outside the range of 10.1.0.0/16. So, the PRR request
| ought to specify the address map entry from which the request is beign
| made.
|
| Even if the agent was using an address in the range of 10.1.0.0/16 - say,
| 10.1.0.1,  and the agent obtains an address, say X1.1, the middlebox has
| no way to know that all sessions from 10.1.0.1 have to be bound to X1.1.
| The agent might create a BIND (using PER) at a later time. But, prior to
| this, if NAT sees any session originating from 10.1.0.1, it would bind
| the address to one of the available addresses within X1/8 (different from
| X1.1, as X1.1 is reseved by an agent). Now, lots of chaos ensues because,
| the PER from the agent would fail.
|
| This is why I suggested the tansaction "SetMapOwner <AddressMapEntryIndex>
| [Full | Partial] [<Subset of Map Entry>]" to claim full/partial ownership
| of an address map entry unequivocally. This is fully contextual and there
| are no race conditions between the agent and the middlebox.

Ok, in this point I do agree with Tom's proposal to add A0 to the PRR 
transactions, so the middlebox can find out from where the request is 
coming and which address range to choose.

As long as nobody else from the mailing list has any objections to that, we 
will put this is the next revision of the semantics.

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 26 Sep 2003 16:54:15 +0200

here is the second part of my answer.

Cheers
Martin

| Now, let us consider the case of PER transaction(section 2.3.8). PER in
| the context of a NAT refers to the agent creating a NAT binding with
| specific parameters. This will fail if the prameters specified in the
| bind-create request donot correspond to one or more (in the case of
| twice-NAT) address map entries. Without reference of an address map
| entry, the agent has no knowledge of whether to request for an address
| bind or a port bind.

Assuming that A0 is given (as specified in PER and will be specified in PRR 
in the upcoming version of the semantics), the middlebox knows the 
corresponding mapping as well. The choice wether to do an address or port 
map depends on the middlebox type and may depend on the requested 
configuration as well (for instance if a binding for IP-only is requested).

|                      Further, the binding is meaningless without the
| exact session description to a symmetric NAPT. This is because symmetric
| NAPT uses different port bindings for the same (private IP address, port)
| tuple used in different sessions. The port bind may work only for the
| first session that originates from (provate IP address, port). There are
| other caveats. Without a PRR preceding the PER, how is the PER to know
| what external address to bound to? Why not let the middlebox select the
| external address to bound to?

When I understand it in the correct way, you see the problem that the 
middlebox many not be able to associate to reference certains configuration 
in the NAT? But there is the policy rule identifier, which is not the 
session or whatever identifier in the box, but it may correlate to that.
Furthermore, the middlebox never can know the external address (as in 
semantics terminology) by heart. The outside (I think that is what you are 
referring to as external address) address is always determined by the 
middlebox.

|
| This is why I suggested the tansactions CreateBind, CreateportBind,
| RequestCreateBind, and RequestCreatePortBind to create binds
| unequivocally. These transactions use address map as an argument. Either
| the agent or the middlebox can create a bind.
|
| Creating binds is not adequate. The agent needs to be able to specify the
| permitted sessions as well. Without going into the details, i will simply
| suggest FTP(TCP based) and TFTP(UDP based) are examples of this.

Perhaps the key point in our discussions is our use of 'NAT binding'?
The pure NAT terminology says that a binding is (A0, A2) and a session is 
(A0, A2, A3) and where are using the term of NAT binding more loosely. 
Because in our view we are not interested whether a NAT binding, or session 
is established. For example, when we refer to NAT binding in PER, we mean a 
full configured policy rule for the middlebox (A0, A2, A3) that allows only 
to traverse packets belonging to that specific data flow. But we have to 
use some more loosely terminology due to the fact we handle a whole bunch 
of different packet filter firewalls and network address translators. So we 
need to talk more broad. Perhaps we should clearly mention that first and 
foremost of the semantics, so that no or less confusions will come up.

Martin

|
| This is why I suggested the tansactions CreateOutboundSesion,
| CreateInboundSession, RequestCreateOutboundSession and
| RequestCreateInboundSession to create sessions unequivocally. Either the
| agent or the middlebox can create a session.
|
| As for twice-NAT, I am frankly confused by the PRR/PER transactions.
| There was reference to using a singe policy rule identifier for two
| address/port reservations and two binds. Assuming all the parameters
| specified in a PER are adequate (which I dont believe, they are), the
| requirement of using a new artificial handle to represent two independent
| twice-nat bind is unnecessarily complex on the part of the middlebox.
|
|> I am
|> not surprised to find MIB designers scratching their heads over how to
|> reconcile the
|> two points of view.
|
| MIB designers donot have a problem creating a MIB to run transactions. MIB
| designers are having to scratch their head because the Midcom semantics
| works only in the simplest of cases.
|
|>                     My natural and naive inclination is to view the
|>                     MIDCOM
|> MIB as a
|> logically separate beast.  The NAT or firewall MIB would merely reflect
|> the results
|> of MIDCOM operations, rather than be tied to the MIDCOM MIB explicitly.
|
| I donot have a problem provided the the midcom transactions are
| reasonable, complete and donot impose impossible requirements on the
| middleboxes. It is my view that the transactions are most meanigful when
| the transactions relate to the resources/objects the middlebox can relate
| to.
|
|>
|> I suppose the question is whether the abstract view is acceptable to
|> implementors,
|> or whether they will insist that any MIDCOM protocol addresses precisely
|> the  functions offered by their middlebox.  If Pyda is representative of
|> NAT  implementors, the semantics need a bit of modification.
|
| I do believe, the transactions in the semantics document need
| modification. If you like, I would be glad to work with the authors on
| this.
|
| regards,
| suresh
|
|>
|> Jürgen Quittek wrote:
|>
|> > Pyda,
|> >
|> > Thanks for your comments. Please see replies to some of them inline.
|> >
|> > --On 06.09.2003 14:15 Uhr -0700 Pyda Srisuresh <[email-masked]>
|> > wrote:
|> >
|> >> Below is text of the e-mail (a little revised) I sent to the authors
|> >> earlier. I
|> >> am including the text for wider audience. Below are my outstanding
|> >> comments on
|> >> the draft.
|> >>
|> >> 1. For a NAT middlebox, I believe, the semantics ought to cover the
|> >> following
|> >> transactions. My comments assume the following.
|> >>
|> >>       A. NAT is configured on a per-interface basis. As such, the
|> >>          Midcom/NAT transactions would be specified on a
|> >>          per-interface  basis.
|> >
|> >
|> > I do not share this view. A midcom agent has the intention and
|> > capability to specify endpoints of communication across the middlebox.
|> > Which  interfaces
|> > of the middlebox are affected is not subject of midcom transactions.
|> >
|> > The MIDCOM information model simplifies the network view by just
|> > separating an internal network and an external network. Whether or not
|> > the  middlebox has
|> > one or more interfaces connected to any of them is considered an
|> > internal matter
|> > of the middlebox.
|> >
|> > There is no statement in framework or requirements that oblige an
|> > agent  to find
|> > out which interfaces a middlebox is using.
|> >
|> >>       B. End-point below is to be refered as <IP addr, TCP/UDP,
|> >>       TU-port> for a PortBind. End-point for an address Bind will be
|> >>          <IP address>. The IP address can be V4 or V6.
|> >>       C. The transactions specified below can be applicable to one or
|> >> more
|> >>          end-points. This will include address ranges, address
|> >>          wild-carding, port ranges, and port wild-carding.
|> >>
|> >>
|> >> SetMapOwner <AddressMapEntryIndex> [Full | Partial] [<Subset of Map
|> >> Entry>]
|> >>                       - SetMapowner may be used by an agent to claim
|> >>                         ownership on a complete NAT map entry or a
|> >>                         portion of the entry. AgentId will be set as
|> >>                         the owner of the entire map entry or portion
|> >>                         thereof.
|> >>
|> >> (CreateBind | CreatePortBind)
|> >>             <AddressMapEntryIndex> <original End-point> <Xlated
|> >> End-point>
|> >>                       - Agent specifies all the requisite Parameters
|> >>                       for Bind(s) or PortBind(s). Agent requests
|> >>                         middlebox to create a BIND and respond back
|> >>                         with an
|> >> assigned
|> >>                         BindId. Middlebox to validate the
|> >>                         authorization prior to responding.
|> >>
|> >> (RequestCreateBind | RequestPortCreateBind)
|> >>            <AddressMapEntryIndex> <original End-point> [Oddity option]
|> >>                       - Agent requests the Middlebox to create
|> >>                       BIND(s)
|> >> for
|> >>                         the given End-point, optionally with an Oddity
|> >>                         requirement. Middlebox to validate the
|> >>                         authorization, prior to assgining a BIND and
|> >>                         a BindId and returning the response.
|> >>
|> >> CreateOutboundSession
|> >>           <OutboundSrc map entry index> | <OutboundSrc end-point
|> >>           BindId> <OutboundDest map entry index> | <OutboundDest
|> >>           end-point
|> >> Bindid>
|> >>           <Original Outbound session tuple>
|> >>           <Translated outbound session tuple>
|> >>                       - Agent specifies all the requisite Parameters
|> >>                       for an outbound session. Agent requests
|> >>                         middlebox to create a session as specified
|> >>                         and respond back with an assigned BindId.
|> >>                         The session may have one or two end-point
|> >>                         translations. The session may be derived
|> >>                         directly from the address map (or) from
|> >>                         associated
|> >> Bind-IDs.
|> >>                         Middlebox to validate the authorization prior
|> >>                         to responding. Note, the session tuple may
|> >>                         have wild-card elements.
|> >>
|> >> RequestCreateOutboundSession
|> >>           <OutboundSrc map entry index> | <OutboundSrc end-point
|> >>           BindId> <OutboundDest map entry index> | <OutboundDest
|> >>           end-point
|> >> Bindid>
|> >>           <Original Outbound session tuple>
|> >>                       - Agent requests the Middlebox to create an
|> >> outbound
|> >>                         session for the given session tuple, using
|> >>                         one or more map entries and/or end-point
|> >>                         BINDs. Agent to validate he authorization
|> >>                         prior to responding back with a new session
|> >>                         and session-id. As
|> >> before,
|> >>                         the session tuple may have wild-card elements.
|> >>
|> >> CreateInboundSession,
|> >> RequestCreateInboundSession
|> >>                       - Similar to the outbound counterparts.
|> >>
|> >> ModifyBindParameters  <BindId>
|> >>           [<MaximumLifetime>] [MaximumIdletime>] [<GroupId>]
|> >>                       - These parameters may be specified either at
|> >>                       Bind creation time or later.
|> >>
|> >> ModifySessionParameters <SessionId>
|> >>           [<MaximumLifetime>] [MaximumIdletime>] [<GroupId>]
|> >>                       - These parameters may be specified either at
|> >> session
|> >>                         creation time or later. Note, session here
|> >>                         refers to the NAT data sessions, not the
|> >>                         Midcom agent session.
|> >>
|> >> In particular, I would like to mention the notion of three resources
|> >> a NAT middlebox and midcom agent need to be cognizant of -
|> >> Address map entries, Binds and sessions. These resources may be a)
|> >> created by
|> >> the agent, b) created by the NAT middlebox, or c) paramaters modified
|> >> by the
|> >> agent.
|> >
|> >
|> > The way I see it, MIDCOM does not distinguish binding and session (as
|> > the NAT MIB does).
|> > The point is that the MIDCOM protocol is not a middlebox management
|> > protocol, but a
|> > protocol that allows applications to express requests for enabling
|> > communication
|> > across a middlebox.
|> >
|> >> 2. The notion of PRR is incomplete without the context of the entire
|> >> address
|> >> map entry. The reservation may not be specific to
|> >> address/address-port  alone.
|> >> My view of this is simply that PRR is just another notion of
|> >> ownership  claim.
|> >> it just happens to be in relation to an address map entry.
|> >
|> >
|> > The intention behind PRR is just to reserve addresses at the middlebox.
|> > This can be doen without mapping them already.
|> >
|> >> 3. When you combine the notion of PRR wth PER, the state transition
|> >> diagram in
|> >> section 2.3.13 woudl be simplified, with the proviso that there would
|> >> be three
|> >> types of policy rules (address map entries, binds and sessions).
|> >
|> >
|> > Again, binds and sessions cannot be distinguished in the midcom world.
|> >
|> >> 4. I agree with your notion of Session establishment and session
|> >> termination
|> >>    transactions.
|> >>
|> >> 5. I believe, the group Ids an agent would use during the lifetime of
|> >> a Midcom
|> >> session should be specified by the agent - either at the midcom
|> >> session establishment time or afterwards whild the midcom session is
|> >> alive.  Given that
|> >> group-Ids are specific to an agent, it shoudl be agent's
|> >> responsibility to
|> >> assign group IDs, not that of the middlebox's. Further, given that
|> >> there are 3
|> >
|> >
|> > Group IDs need to be unique per middlebox.
|> > This is hard to achieve if the agent assigns them.
|> >
|> >> different types of resources (map entries, Binds and sessions), there
|> >> shoudl be
|> >> three different sets of group-Ids, one set for each resource type.
|> >> Middlebox will assign a default groupId of 0 to all entities that are
|> >> not assigned a groupId by the agent.
|> >
|> >
|> > I prefer to have reservation rules and enable rules (bindings) to be
|> > able to share a group. because then the agent can extend or delete
|> > sets of them belonging together by just accessing a single group.
|> >
|> > Cheers,
|> >
|> >    Juergen
|>
|
|
| =====
|

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 29 Sep 2003 07:53:30 -0700 (PDT)

--- Martin Stiemerling <[email-masked]> wrote:
> corresponding mapping as well. 

Just to be clear, the middelbox has to know the full tuple of the session A0 is
initiating in order to determine which of its address map entries will be
applicable. Ex: (A0, SrcPort, A1, DestPort-on-A1) or (A0, SrcPort, A3,
DestPort-on-A3). 

>                                 The choice wether to do an address or port 
> map depends on the middlebox type 
                     ^^^^^^^^^^^^^^
Assuming this is the first packet of a session, address map entries on the
middlebox determine which of the fields in the session will undergo
translation. This may be source adress (and port), destination address (and
port) or both.

>                                    and may depend on the requested 
                                                           ^^^^^^^^^
> configuration as well (for instance if a binding for IP-only is requested).
  ^^^^^^^^^^^^^                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I assume, you are refering to midcom "requests" here. What is a midcom config
request? Midcom will not configure new address map entries on the middlebox.

An agent may make binding requests, only so long as it is meaningful and refers
to an address map. 

> session or whatever identifier in the box, but it may correlate to that.

How? 

I think, you are saying that PER has all the information an application needs.
Let the middlebox figure out how this relates to its objects. Let us pursue
this further.

Policy Rule Identifier is empty when there is no PRR preceding. If PER has all
the original session parameters as seen by A0 or A3, NAT can use this to set a
NAT flow, if there isnt one existing and return back the NAT flow handle(also
called NAT session handle in previous e-mails), provided it knows the interface
context of the session. This would be same as requesting a NAT session. Is this
what you are talking about?

When Policy Rule Identifier is non-empty (as in filled with a previous PRR rule
handle), the policy rule identifier would presumably contain all the
translation parameters for that session. However, PRR as described in the
document, does not contain BINDs, but a bunch of address/port reservations from
one or more address map entries.

This is why, I suggested splitting this up into (a) ownership claims on
full/partial map entries, and (b) setting/requesting address/port bndings.

Once the midcom transactions, as existing, are redefined as instruments on top
of middlebox resources, the whole thing thign will make more sense. Further,
the semantica model can be enriched with transactions not defined as yet.

> Perhaps the key point in our discussions is our use of 'NAT binding'?

That certainly sounds like one of the key items.

> The pure NAT terminology says that a binding is (A0, A2)

Yes.

>                                                          and a session is 
> (A0, A2, A3) and 
  ^^^^^^^^^^^^
Yes, in case of traditional NAT. That is what a NAT session (or NAT flow) would
represent for a traditional NAT.

>                     where are using the term of NAT binding more loosely. 

Sounds like it. You do bring up a good point.

> to traverse packets belonging to that specific data flow. 

OK. This is what I refer to as NAT session or NAT flow. This is a native NAT
resource. I see no problem with NAT middlebox returning this. 

>                                                           But we have to 
> of different packet filter firewalls and network address translators. 

I disagree. This would not be the case if the semantics document identified
transactions based on middlebox resources instead of abstracting them.

>                                                                       So we 

I continue to believe, the right approach is not to proliferate with more
terms, but work with the resources of middlebox functions.

cheers,
suresh

=====