Subject: [midcom] Fwd: Draft MIDCOM Minutes

From: Melinda Shore <[email-masked]>
Date: Tue, 02 Apr 2002 09:13:00 -0500

Here are the draft minutes from the recent IETF meeting.  As always,
let us know about errors, omissions, etc.

Thanks,

Melinda

The MIDCOM (Middlebox Communications) Working Group met Thursday, March 21 at 1530-1730.  Melinda Shore <[email-masked]> chaired the meeting.  Notes were taken by Tom Taylor ([email-masked])

Agenda Bashing 
============== 

The agenda was accepted as proposed. 

Status 
========= 

The MIDCOM Framework and Requirements documents have both been approved for publication. 

The new charter has been approved and posted. 

STUN is due April 2002. 

Our unnamed pre-MIDCOM deliverable is due in May. 

Process Going Forward 
===================== 

Mary Barnes <[email-masked]> is to be the editor for the protocol evaluation document. 

The Working Group is doing the semantic work in parallel. 
  -- process to be announced next week  (last week of March) 
  -- Tom Taylor <[email-masked]> is doing work on the semantic model. 

Jonathan Rosenberg <[email-masked]> commented that he was not sure if the work should go in parallel, given that the semantic description can be disposed of quickly.  Melinda responded that the protocol evaluation will be messy and political, hence is best started as soon as possible. 

Mary Barnes presented charts describing the process going forward. 

Chart 1: Methodology Overview - Part 1 
-------------------------------------- 

- Process open to entire WG. 

- Contributors need to specify their intention to contribute 
  an objective evaluation of a specific protocol (by April 3rd). 
  -- If there are multiple volunteers for the same protocol, 
     priority is given to whomever puts in the first claim 
     with a suggestion that the interested parties work together. 
  -- Objective is to NOT have multiple individual contributions 
     for the same protocol. 

- Specific protocol evaluation to be completed by April 19th. 

- Open WG feedback on the specific proposals on the mailing list, 
  allowing authors to incorporate WG feedback into their contribution 
  to improve its positioning and completeness (April 19th- May 3rd). 

- Final version of specific protocol evaluations due on May 10th. 

- Final versions of specific protocol evaluationss due May 10 
  -- template will be provided 

Some discussion of IPR followed the presentation.  IPR claims must be revealed by April 3 to help people decide which protocols they want to work with.

Chart 2: Methodology Overview - Part 2 
-------------------------------------- 

- MIDCOM WG protocol evaluation document to be comprised 
  from the information from the specific protocol drafts 
  (May 10th-May 24th) 
  -- Information is synthesized by the editor into a consistent 
     format, with an objective comparison of the various proposals 
     based upon the drafts (thus the responsibility is on the draft 
     writers to ensure they completely evaluate their protocol 
     against the requirements and framework and incorporate 
     constructive input from mailing list). 
  -- first version of protocol evaluation draft available on May 24th. 

- Open WG feedback on the draft (May 24th - June 7th)  : 
  -- Discussion of amalgamated pros/cons of the various proposals 
  -- Any other issues with the draft. 

- Second version of draft available on June 14th: 
  -- One Week mailing list discussion. 
  -- Updated draft posted for WGLC: June 28th 
  -- WGLC: June 28th-July 19th. 
  -- Time allowed for a second iteration of WGLC 

Chart 3: Basis for evaluation 
----------------------------- 

- Fundamental basis for evaluation is: 
  -- MIDCOM Requirements: draft-ietf-midcom-requirements-05.txt 
  -- MIDCOM Framework: draft-ietf-midcom-framework-07.txt 

- Format for individual protocol evaluations is not 
  prescriptive but for an objective analysis should include 
  the following sections/content: 
  -- Applicability to the MIDCOM Framework. 
  -- Identification of the MIDCOM Requirements that are satisfied 
  -- Identification of the MIDCOM Requirements that are 
     "partially" satisfied 
  -- Identification of the MIDCOM Requirements that are NOT 
     satisfied 

- Template for WG protocol evaluation draft will be made available 
  early in the process to provide some guidance and to solicit 
  WG feedback. 

Discussion of this chart revealed a concern to have detailed criteria beyond those shown.  The WG will generate these more detailed requirements over next couple of weeks on the list.

Mary's next few charts summarized the timeline for the process, based on the dates given in the preceding charts.  Her final chart was as follows:

Chart 8: Other Considerations 

- Conference calls can be scheduled to discuss issues that 
  have not been resolved on the list or have deadlocked, 
  but the goal is to work primarily via email. 

- Specific dates are subject to change, however, to meet 
  the August deadline, we need to stick with these at a high 
  level.  Any changes to these proposed dates will be posted 
  to the list. 

- IF progress isn't being achieved with the open nature of the 
  proposed process, a design team MAY be formed to get the work 
  back on track to meet the August delivery to IESG per the WG charter. 

Melinda called for feedback on the process and on the criteria. 

Pre-MIDCOM Design Team 
====================== 

Melinda named the members: Jonathan Rosenberg, Ram Dantu <[email-masked]>, Mahadev Somasundaram <[email-masked]>, Sanjoy Sen <[email-masked]>, and Steve Davies <[email-masked]> (being replaced by Pete Cordell <[email-masked]>).

STUN Open Issues (Jonathan Rosenberg) 
===================================== 
Changes in -00: 

- Answered UNSAF considerations - still awaiting response from IAB 

- Alignment of parameters on word boundaries 
  -- not compatible with original draft 

- Added missing parameter code 

- Clarified meaning of changed-address 

- Added security 

Security issue: theft attack 
---------------------------- 

 - attacker snoops request 
 - injects fake response 
 - MAPPED-ADDRESS points to attacker 
 - client thinks this is its own address, hands it out 
 - media signalling applications go to attacker 
Bad because it gives the attacker access to a variety of applications. 

Rohan Mahy <[email-masked]> noted limitations to the attack.  If the NAT is not full cone, the attacker has to fake its source IP address to be that of STUN server.  Attacker has to be on the path or local to the client.

Solution Requirements 
--------------------- 

Server authenticates itself to the client 
 - same domain as the in which the client launched the request. 

Client can validate the integrity of the entire response. 

Server to client authentication typically based on PK 
 - web model 
 - want to work with servers you don't share a secret with. 

Christian Huitema <[email-masked]> warned that there are NATs that will remap what they perceive to be IP addresses in the content.  Hence applications have to obfuscate vulnerable portions of the content.

-- take off-line. 

Solution approach: 
----------------- 

Cryptographic Message Syntax (CMS) RFC 2630 

- heart of S/MIME 
- syntax for signatures, certificates, etc. 

Problem: don't want to sign responses for just any request 
 -- would set up a potential distributed denial of service attack. 

Hence the proposed procedure has a two-stage handshake, with a cookie in the initial response. 

Issue: CMS implementation is probably 10-20 times bigger than STUN itself 
- other approaches? 

Christian Huitema suggested that we may not need security for every mapping.  If the first response looks OK, it should be optional to require the full signature.  

Note to authors: add the is remark to the document. 

Cullen Jennings <[email-masked]> asked why the exchange could not use a shared secret. 
Jonathan responded: this would be a brake on deployment.  A single STUN server may have many clients.  Cullen asked why the SMTP model would not work.  Melinda answered this: the trust model different -- it is necessary to narrow access to prevent spoofing.  Kerberos may be applicable in a year.  Cullen remarked that SIP phones don't do that.  Jonathan explained further that he wanted to preserve the nature of the server as a stand-alone resource.  The code readily available.  Cullen indicated that code size is his precise concern.  The mitigating circumstance is that TLS and MIME share technology.

Ruling from the Chair: put it in the document, since the latter is a team output rather than a WG output. 

Jonathan continued his review of STUN status in general.  Beyond what had already been described, there is little else to do.  Lots of implementations are underway, and products will soon be available.  draft-ietf-midcom-stun-00 will be revised and reissued after the blackout.  Then it will be ready for Working Group Last Call.

Comment: we could make the operation of the protocol more efficient by not having a timeout in the NAT so probes are not needed.  Suggestion: put time value in the STUN packet from the server.  Jonathan declared himself in favour.  Melinda said it was in her draft last year.  She will reissue that draft, ask for BOF in Yokohama (but this is a separate problem).

Pre-MIDCOM Update  (Steve Davies) 
================= 

'Thing' 

Now a chartered item 

Design team set up to propose a solution to the Working Group. 
- Draft submission date May 2. 

Allow inbound connections through midcom-unaware symmetric NATs using communications with server elements on the public side.

Mechanism: enable a client to obtain an address at a public relay. 

PPP is in scope. 

Issues: 
 - avoid implicit subversion of security policy e.g. running unauthorized servers 
 - out-of-band vs. in-band control of relay 
 - are symmetric paths required? 

Tom Taylor 
[email-masked] 
Ph. +1 613 736 0961 (ESN 396 1490) 

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

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 03 Apr 2002 11:05:42 +0200

>Process Going Forward 

Melinda,

My notes tell me I had questions on the process which did not 
make it to the minutes. 

Jiri: "How will the protocol selection useful in getting to a simple,
      interoperable protocol? I suspect that will just take time and 
      result in taking a complex protocol which does unnecessarily more
      than needed?"
Melinda: "thats how IESG wants it".
Jiri: "What will we do if all protocols qualify?"
Melinda: "we will shop for more features, such as low complexity."

-Jiri

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 8 Apr 2002 18:27:16 +0100

Melinda/Tom,

Towards the end where TOM has said 'PPP is in scope', I think it should read
'TCP is in scope'.

Also, THING is due May 02 as in May 2002 rather than 2 May.  That means 32nd
May to a delivery chap like me!  The date is from the charter.  (I thought
when Steve said it that it sounded confusing.)

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================

----- Original Message -----
From: Melinda Shore <[email-masked]>
To: <[email-masked]>
Sent: 02 April 2002 15:13
Subject: [midcom] Fwd: Draft MIDCOM Minutes

> The MIDCOM (Middlebox Communications) Working Group met Thursday, March 21
at 1530-1730.  Melinda Shore <[email-masked]> chaired the meeting.  Notes
were taken by Tom Taylor ([email-masked])
> Jonathan Rosenberg <[email-masked]> commented that he was not
sure if the work should go in parallel, given that the semantic description
can be disposed of quickly.  Melinda responded that the protocol evaluation
will be messy and political, hence is best started as soon as possible.
> Some discussion of IPR followed the presentation.  IPR claims must be
revealed by April 3 to help people decide which protocols they want to work
with.
> Discussion of this chart revealed a concern to have detailed criteria
beyond those shown.  The WG will generate these more detailed requirements
over next couple of weeks on the list.
>
> Mary's next few charts summarized the timeline for the process, based on
the dates given in the preceding charts.  Her final chart was as follows:
> Melinda named the members: Jonathan Rosenberg, Ram Dantu
<[email-masked]>, Mahadev Somasundaram <[email-masked]>, Sanjoy Sen
<[email-masked]>, and Steve Davies <[email-masked]>
(being replaced by Pete Cordell <[email-masked]>).
> Rohan Mahy <[email-masked]> noted limitations to the attack.  If the NAT
is not full cone, the attacker has to fake its source IP address to be that
of STUN server.  Attacker has to be on the path or local to the client.
> Christian Huitema <[email-masked]> warned that there are
NATs that will remap what they perceive to be IP addresses in the content.
Hence applications have to obfuscate vulnerable portions of the content.
> Christian Huitema suggested that we may not need security for every
mapping.  If the first response looks OK, it should be optional to require
the full signature.
> Jonathan responded: this would be a brake on deployment.  A single STUN
server may have many clients.  Cullen asked why the SMTP model would not
work.  Melinda answered this: the trust model different -- it is necessary
to narrow access to prevent spoofing.  Kerberos may be applicable in a year.
Cullen remarked that SIP phones don't do that.  Jonathan explained further
that he wanted to preserve the nature of the server as a stand-alone
resource.  The code readily available.  Cullen indicated that code size is
his precise concern.  The mitigating circumstance is that TLS and MIME share
technology.
> Jonathan continued his review of STUN status in general.  Beyond what had
already been described, there is little else to do.  Lots of implementations
are underway, and products will soon be available.
draft-ietf-midcom-stun-00 will be revised and reissued after the blackout.
Then it will be ready for Working Group Last Call.
>
> Comment: we could make the operation of the protocol more efficient by not
having a timeout in the NAT so probes are not needed.  Suggestion: put time
value in the STUN packet from the server.  Jonathan declared himself in
favour.  Melinda said it was in her draft last year.  She will reissue that
draft, ask for BOF in Yokohama (but this is a separate problem).
> Allow inbound connections through midcom-unaware symmetric NATs using
communications with server elements on the public side.

---

From: "Saqib Jang" <[email-masked]>
Date: Mon, 8 Apr 2002 16:01:30 -0700

What does "TCP is in scope" mean? Also, how do the
goals behind the "other thing" differ from STUN?

Saqib

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Pete Cordell
Sent: Monday, April 08, 2002 10:27 AM
To: [email-masked]; Melinda Shore; Tom Taylor
Subject: Re: [midcom] Fwd: Draft MIDCOM Minutes

Melinda/Tom,

Pete.