Subject: [midcom] semantics discussion

From: "Juergen Quittek" <[email-masked]>
Date: Mon, 15 Jul 2002 13:00:20 +0200

Hi all,

For preparing a semantics discussion at the session
tomorrow, we just discussed with Tom difference between 
his and our semantics I-D.

Tom's I-D lists a lot of issues that were raised on 
the list, while our I-D already contains (explicitly or
implicitly) our answers to most of these questions.

Now we want to find out tomorrow, what is the position
of the working group.

Therefore, we list our answers to several of the discussion
points below. (Please note, that not all answers does exactly
match our current version of the draft.)

    Martin and Juergen

- Session/Policy handover:

  Is there a handover mechanism required?

     our position: yes

  On what basis is handover of policies organized:
  per session or per policy?

     suggestion: policies are tied to authenticated users, 
                 not to sessions. A user takes over policies
                 created or modified in a different session
                 by authenticating properly.

- Combining policies 

  Is there a need to combine policies by AND in a single request
  (atomic operation, framework says "multiple filters in a rule")? 

     suggestion: no, but use grouping of policies for joint actions
                 on them (extend, terminate)

- Deterministic result

  To what degree or with respect to which observer does the middlebox 
  have to operate deterministically?

    Our view: I only has to operate deterministically to the middlebox
              administrator. And the administrator is not necessarily
              involved into the midcom protocol at all.
              At any time the administrator may modify the access control
              configuration policy. So, an agent might be able to configure
              a policy once, but at the second time the administrator
              changed admission policies and this time the same request
              fails.

- Meaning of end of session

  What happens to existing policies if the session is terminated?

    Suggestion: In general all policies remain in place until they expire
                if the agent has not explicitly requested termination
                and the middlebox has not signaled termination.
                However, the middlebox may terminate any policy at any time.

- Should policiess be persistent (survive middlebox reboot)

    Suggestion: Yes, as an option. The middlebox may inform the agent by
                capability exchange whether the middlebox offers persistent
                or non-persistent policies.

- How should timers be supported by the protocol?

    Our suggestion: The agent request lifetimes for each policy and each group.
                    The middlebox decides on what lifetime is granted.
                    The agent may request extension of lifetimes.

- When are policies assigned to a group?

    Suggestion: At the time they are installed policies are tied to a group
                The group cannot be changed during lifetime of the policy.

- Is there a need for deny actions in a policy?

    Our view: No, we do not see any use of it.

-- 

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

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 16 Jul 2002 16:10:30 -0400

The proposed representation of the filter part of the Policy Rule in section
2.3 of draft-taylor-midcom-semantics-00.txt supports only Traditional
NAT/NAPT. Does MIDCOM need to support Twice-NAT (see RFC 2663) where both
the source and destination addresses&ports are modified?

The Taylor draft includes only a single mapped-address in the Policy Rule.
The Stiemerling draft (draft-stiemerling-midcom-semantics-01.txt) has the
same limitation in that the Resource Reservation reserves only one mapped
address and only one resource can be specified (by its rule identifier) in a
Policy Rule Configuration.

BTW, in the Stiemerling draft, if the mapped address is pre-determined
(already known by the MIDCOM Agent), there does not appear to be a way to
specify that known mapped address to the middlebox.

Aside from the historical uses of Twice-NAT, consider a scenario where there
are multiple parallel NAT middleboxes to get out of a private network (maybe
to different service providers). The only way to get the packets for a given
RTP stream to go out a specific middlebox is to allocate a port on the
internal interface of the middlebox to be used as the destination address by
an internal/private endpoint. Thus when the packet traverses the middlebox,
both the source and destination addresses need to be changed.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 17 Jul 2002 02:31:41 +0200

Hi Bob,

thanks for comments and please find my answers in the text. I hope I've 
gotten the points, since I'm lacking at least three cups of coffee... :-)

Cheers
Martin

> Policy Rule Configuration.

We have the support for modified source and destination address in the 
current simco draft (draft-stiemerling-midcom-simco-01.txt), but we 
dropped it in the semantics, because we haven't seen any reason, since 
now :-( .
So we should put this into the semantics.

> specify that known mapped address to the middlebox.

When the agent does know the mapped address, he has learned the address 
from the middlebox, isn't it? So the middlebox knows the address already 
and I see no need to tell the address to the middlebox. May be I'm 
wrong, so can give me an example if there is a special case for this 
scenario?

> both the source and destination addresses need to be changed.

Supported by simco.

Thanks again for the comments.

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 17 Jul 2002 09:40:15 -0400

> > both the source and destination addresses need to be changed.
I studied the SIMCO draft, but was unable to figure how you would do this.
You could do 2 resource reservations to allocate the mapped addresses, but
how would you bind both mapped addresses to the same rule identifier?

In general I find the SIMCO draft lacks sufficient explanation of procedures
for the middlebox for the various commands and explanation of the uses of
the fields.

cheers,
(-:bob

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 18 Jul 2002 03:38:37 +0200

[...]
> how would you bind both mapped addresses to the same rule identifier?

Yes you're right, the current draft version (-01) has been already 
aligned to the semantics. I had still the first version (-00) in mind. 
In this version the `242' reply of the `bind_full' request, returns two 
addresses: the mapped internal address/port (if applicable) und the 
external mapped address/port. I think that's what you're looking for.

> for the middlebox for the various commands and explanation of the uses of

Will take care about this in the next revision. Thanks for the hint.

Martin