Subject: [midcom] Fw: minutes

From: "Melinda Shore" <[email-masked]>
Date: Sat, 24 Mar 2001 08:19:15 -0500

I've appended Ted's meeting minutes.  Please send
any corrections, etc. to the mailing list.

Once again, many thanks to Ted for taking this on.

Melinda

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: "Ted Hardie" <[email-masked]>
Sent: Thursday, March 22, 2001 5:14 PM
Subject: minutes

> MIDCOM Meeting Minutes, 50th IETF
> Chair: Melinda Shore 
> Minutes: Ted Hardie
> March 22, 2001
> 
> Agenda:
> 
> Agenda Bashing
> Update on Working Group Status
> Discussion of Framework Draft
> Discussion of Requirements Draft
> AOB
> Agree on next steps.
> 
> Resulting Action Items:
> 
> Both sets of document authors will present new versions of their
> drafts on the most aggressive schedule they can support.  Those
> documents will eliminate references to the functions inside the
> middlebox and focus on the use of the midcom protocol.
> 
> Members of the mailing list will send scenarios (use cases) for midcom
> to the authors of the framework document, who will incorporate
> appropriate scenarios into their document.  Christian Huitema has
> volunteered to compose scenarios for the document.
> 
> No resolution was reached on the inconsistent usage of definitions
> between the drafts; working members should propose specific text for
> the definition to the mailing list, which will need to resolve the
> inconsistencies.
> 
> An interim meeting has been proposed in conjunction with the SIP
> summit in Richardson, TX.  The SIP meeting is May 1 & May 2nd, 2001.
> The chair and ADs will discuss the scheduling of an interim meeting.
> The interim meeting will be focused on eliminating any remaining
> confusion on models, and attendees will be expected to volunteer to
> produce text for working group documents based on the results.
> 
> The Chair reminded the working group that early review and objection
> was critical to meeting the time lines of the working group and urged
> working group members to make objections known as early as possible.
> 
> 
> Meeting Recap:
> 
> The Chair began the meeting by saying that most important aim for the
> morning was to work through the drafts and eliminate any conflicts
> between them. She then began reviewing the status of the drafts.  The
> deadline for both in the current milestones is August 2001, but the
> Chair hopes quicker progress can be made within the working group, in
> order to incorporate potential delay time at the IESG review stage.
> 
> The Chair then stated that the group needs to resolve some
> definitions, both for the clarity of its own discussions and in order
> to assist the IETF as a whole.  Among the terms which need clear
> definitions are: middlebox, proxy, Application Layer Gateway, and the
> various participants in a Midcom protocol exchange.
> 
> Pyda Srisuresh then presented the framework draft.
> 
> The main goal for the draft is to create an architecture for
> middleboxes needing to externalize application intelligence.  That
> framework should guide the development of the midcom protocol, with
> especial guidance for the security necessary when connecting midcom
> agents to middlebox.  The architecture is restricted to firewalls and
> NATs, in accordance with the group's charter, and it does not discuss
> discovery.
> 
> The architecture presumes that there is a single midcom protocol
> interface, no matter what middlebox function or functions are in the
> midbox (i.e., the same interface for firewalls and nats).  The current
> draft creates a taxonomy, however, for the midcom agents, dividing
> in-path midcom agents and out-of path midcom agents.  A great deal of
> discussion from the floor challenged the distinction as written.
> Christian Huitema asked that "enterprise boundary" be eliminated from
> the description, as the use of "enterprise" might carry the wrong
> implication to some readers; he suggested "domain" as a possible
> replacement.  It was suggested that a reference to Brian Carpenters
> Middlebox taxonomy document would be useful in clarifying the
> difference between in path and out-of path systems.  Others felt that
> the basic distinction was flawed, as the functions were the same
> whether there were multiple boxes implementing those functions or
> note.  The draft author asked for further review of the draft and
> asked for proposed language from those raising objections.  The chair
> indicated that further examples would be useful, especially for
> out-of-path middlebox agents as the only example available appeared to
> be the decomposed NAT, where the ALG functions are diverted to
> external software processing boxes.
> 
> A question on the floor asked for clarification between the
> middleboxes treated in this draft and those examined in OPES; the
> Chair responded that this is the transport layer, where OPES is
> application layer.  Michael Condry suggested that further language in
> the draft to clarify which middle boxes are at issue would be useful.
> The author agreed to add such language.
> 
> Christian Huitema pointed out that SIP proxies are in path for SIP
> messages, but out of path for media stream; he said that this seems to
> create confusion in the application of the in-path midcom agents.
> Author agreed to clarify that the signaling message path is meant in
> the existing distinction.
> 
> Christian asked whether outsourced agents for some of these
> middleboxes would affect the architecture.  In particular, he noted
> you lose implicit knowledge of the path if you have something like a
> sip proxy which may need to talk to firewalls in multiple exit points.
> Chair noted that the discovery of which firewall is salient is out of
> scope.  Christian agreed that this was fine, but that there was a
> design implication that the signaling cannot assume anything about
> whether its messages will take the same path as the packet flows.
> Author agreed that this was a design implication..
> 
> After further discussion of the distinctions among packet flows, the
> AD asked to remember that we were not here to define the
> characteristics of a middle box, but to design a communication system
> to cope with them.  Elements of the middlebox operation (like packet
> diversion) are out of scope except as related to midcom protocol
> signaling.
> 
> Christian then indicated his belief that the confusion around some of
> these issues derived from the draft's never making clear the
> fundamental requirement of midcom, that we need a mechanism for
> allowing a client to open a tcp_listen in the presence of a NAT or a
> firewall.
> 
> The group then moved on to a discussion of the requirements draft,
> presented by Richard Swale.  He first noted that the document as
> developed in parallel with the framework, so there have been some
> cases in which the two have diverged in terminology and architecture.
> 
> Discussion of the draft began with questions around the use of
> specific terms, such as "application client" and "application server",
> but moved quickly to a question of whether the draft serves the
> purpose of a requirements document at all.  In particular, it was
> agreed that the document needs a set of scenarios or uses cases.  The
> AD (Scott Bradner) noted that the draft contains descriptions of the
> middlebox functions which are valuable, but not appropriate for this
> draft.  He asked that this draft focus more specifically on
> communication *to* the middlebox rather than the function within it.
> 
> It was proposed that the current requirements draft be abandoned and
> the requirements should be redrafted with the caveat that the
> requirements draft should use only terms that are in the framework
> document, with a strong focus on service scenarios.  The focus on
> scenarios was strongly supported, but it was not clear that the draft
> needed to be scrapped.
> 
> After a suggestion from the floor that work on the requirements be
> suspended until the framework is completed, it was agreed that the
> working needed to work on both in parallel to achieve its milestones.
> The Chair asked both sets of document authors to eliminate text in
> their drafts that describes middlebox functioning unless that function
> is explicitly related to the processing of midcom messages.
> 
> The Chair then asked that as part of their re-write, both sets of
> document author expand their security sections and examine the current
> text, as she believes it not correct.
> 
> Eliot then asserted that flow direction is creating a problem in our
> understanding of these.  He put forward an example derived from peer
> to peer communication (Gnutella).  Some device with a fully public IP
> address A, initiates a communication with a device B, which is behind
> a firewall.  How does device B get a publically addressable IP/PORT in
> order to be addressed by A?  Scott Bradner asserted that a FQDN from a
> two faced DNS is the external binding, so that the original message
> goes to the client's inside address, at which point it requests an
> outside address.
> 
> After a complain from the floor that none of the scenarios were
> written down in the drafts.  Christian volunteered to writes
> scenarios.  He then went back to Eliot's case, noting the case of a
> home network where an external port is mapped to an internal service;
> he wants a common way to do that mapping as it is currently being done
> in a proprietary way, using a very weak security model
> (inside/outside).  He believes we need scenarios and an inventory of
> existing mechanisms (in use in home gateways, socks, etc.).  Chair
> rules the second out of scope.  Agreement among volunteer, chair, and
> AD on scenarios as use cases for the protocol, not of the middleboxes.
> 
> Question from the floor about binding to ports; answer was that since
> it is not related to midcom function, it is a not issue.  In a
> discussion about whether "inbound and outbound" do not have to be
> separate, the Chair noted that you might have a midcom policy on a per
> interface basis.  After a further discussion of how complex the
> interface mappings might be, the Chair indicated that in this problem
> domain (firewalls and nats), that the inside/outside dual interface is
> a reasonable description.  You might not want to see it not in
> interface terms, but in terms of source and destination address.
> Andrew noted that this might not be sufficient if the charter is to
> deal with what is actually out there, because there are firewalls that
> have multiple interfaces and there are NATs that care deeply about who
> session direction as well as interface direction.
> 
> The Chair then concluded the meeting by reviewing the action items,
> noted above.
> 

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

---

From: John Ladwig <[email-masked]>
Date: Thu, 29 Mar 2001 15:22:55 -0600 (CST)

Is the proposed interim meeting actually going to happen?  Does there
have to be some sort of formal notice of it at least 30 days prior?
If so, seems like we're at decision-time.

Us here at Aravox, we think the interim meeting is a fine idea.

    -jml

>>>>> On Sat, 24 Mar 2001 08:19:15 -0500, "Melinda Shore" <[email-masked]> said:

    >> MIDCOM Meeting Minutes, 50th IETF

 [ snip ]

    >> An interim meeting has been proposed in conjunction with the
    >> SIP summit in Richardson, TX.  The SIP meeting is May 1 & May
    >> 2nd, 2001.  The chair and ADs will discuss the scheduling of an
    >> interim meeting.  The interim meeting will be focused on
    >> eliminating any remaining confusion on models, and attendees
    >> will be expected to volunteer to produce text for working group
    >> documents based on the results.

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 29 Mar 2001 16:34:34 -0500

> If so, seems like we're at decision-time.

An interim working group meeting requires 30 days
advance notice and the approval of the area directors.
A design team meeting isn't under the same strictures.
However, I would just as soon not have any kind of
meeting without 1) clear goals, 2) a clear agenda, 3)
significant progress by way of discussions conducted on 
the mailing list, and 4) revised documents available a 
reasonable amount of time in advance.  I think we need 
to be a bit sensitive to restricted travel budgets, if 
nothing else.

Melinda