[midcom] IETF 55 minutes

[Melinda Shore <[e-mail]>]

Many thanks to Bob Penfield for his thorough minutes and
for getting them out so quickly.  The minutes are appended;
comments and corrections to the mailing list.

Thanks,

Melinda

========

Minutes of midcom working group at 55th IETF Meeting,
Atlanta, Georgia, USA

Chaired by Melinda Shore ([e-mail])
Reported by Bob Penfield ([e-mail]), edited by Melinda Shore 

=============
Status update
-------------

pre-midcom:

- The STUN document has come back from the IESG with some
  issues that require a Working Group decision (see STUN
  section below)

- SPAN has been cancelled due to lack of interest and activity
  on the list and due to intractable security problems.

Protocol evaluation:

- The protocol evaluation document came back from the IESG.
  The most significant issue was there desire for more detail
  in the SNMP discussion.

Semantics:

 - The two semantics documents have been combined into a single
   document.

Milestones:

- The original milestone was to complete a protocol document by
  December which obviously will not be achieved. We do need to "choose"
  one of the candidate protocols as a based in the next month.

- There was a discussion on whether the STUN document would have to
  go thru WGLC again. A couple of people felt that the changes required
  were not significant enough to warrant a new WGLC.

====================================
STUN - draft-ietf-midcom-stun-03.txt
------------------------------------

Jonathan Rosenberg went over the STUN issues raised by the IESG.
Most of them are clarifications including text to point out the
known limitations when both sides of a communication are behind
the same NAT:

The issues requiring resolution are:

1) Response Codes - the IESG felt that the response codes
   should conform to other IETF protocols (e.g. SIP, HTTP,
   etc).  The proposed resolution is to define 4xx & 5xx
   class responses an behavior consistent with the other
   protocols. 1xx are to be avoided, 3xx do not
   apply. Currently, the error response and success response
   are 2 different messages so an error response would never
   contain a 2xx response code. One person was a little
   uncomfortable with not having 2xx response code (they
   will discuss offline).

2) Unknown Attributes. The spec says that unknown attributes
   should just be discarded. This is broken. Proposal is to
   send back an error response (with code like 420) and a
   list of unrecognized attributes.

3) Flags Extension. What happens when there are more than 32
   flags? The proposal is to use the length in the TLV to
   indicate how many flags are present. There was some
   discussion about making the flags field shorter since we
   have committed to not extend the protocol, and whether
   implementers would ignore the length field.

4) No IANA procedures. Even if you are not going to allow
   extensions you need to say that. There is already some
   extensibility built in.  It was proposed that a standards
   track RFC be required to extend it.  Some felt it should
   require a new version of the protocol, but that was too
   extreme for many people.

5) Reflector Attack vulnerability with the RESPONSE_ADDRESS
   attribute.  Proposal is too include a REFLECTED-FROM
   attribute to identify who sent the original request. This
   would be from the TLS connection that established the
   username and password. Some felt this was too complicated
   with little benefit.  It was suggested that the STUN
   packets need to be easily identifiable so that routers
   could discard them. This issue requires further
   discussion on the mailing list.

6) Client Certificates are considered harmful. The spec
   currently says they MAY be used. Proposal is to change to
   "MUST NOT use".

7) No recommendations for stateless generation of
   username/password. Steve Bellovin has recommended an
   algorithm. The Proposal is to include the algorithm as
   non-normative text as an example of how one could do
   this.

8) Remove IPv6 Support. Since this is a short-term protocol
   to work around problem of IPv4 NATs, the IESG does not
   want IPv6 support. The proposal was to remove the v6
   family. Some felt the address family should be removed
   altogether because people could hack in IPv6 support.

9) Discard Flag is broken. Was used to prime the NAT with
   suicide packets.  It does not work because you need the
   response to know the packet got thru.  Proposal is to
   remove the discard flag.

Some of these issues require further list discussion, but
they need to be resolved quickly so that the spec can
proceed.

==============================================================
Midcom protocol semantics - draft-ietf-midcom-semantics-00.txt
--------------------------------------------------------------
Juergen Quittek presented the Semantics document issues.

- There is now one combined semantics document.

- There is one transaction set for Firewall and NAT.

- Works on first-come, first-served basis.

- Goal is to keep the semantics simple & stupid.

- Why PRR? Need to do the binding to complete the 5-tuple in order
  for agent to pass on signaling message. Is Twice-NAT required?

- Group Transactions have been removed. Group creation is now implicit
  in PRR and PER transactions.

- Wildcarding needs list discussion

- Return Values: Should full 5-tuple be included in response so
  that FW/NAT function is transparent to the agent?

- Should PER be split into two requests?

- Message Queuing. Transactions need to be atomic and operate on
  first come first served basis.

- Capabilities exchange: is list in spec complete?

- Encryption Method - It was pointed out that the encryption method and
  keying needs to be decoupled. Issue needs list discussion.

It was reported that the NSIS WG had discussed using CASP and TIST to talk
to FW/NATs.


===================================================================
Midcom protocol evaluation - draft-ietf-midcom-protocol-eval-05.txt
-------------------------------------------------------------------

Mary Barnes presented status of the protocol evaluation document.

The document case back from the IESG. The main issue is that they wanted a
revamp of the SNMP discussion to include more detail and background of how
it meets the requirements.

A new version (-06) will be posted which include the SNMP changes, and
other miscellaneous updates. It will also reflect the WG decision that RSIP
is not appropriate.

Feedback is needed by November 29th so that a revised version can be
submitted.

It was asked if the document should recommend a protocol, but the protocol
selection process (see below) will "choose" one.

It was also asked if there could be a weighting of the requirements,
but it was felt that that would be too subjective.

=================================
Midcom protocol selection/process
---------------------------------

The proposed process for selecting a protocol would be to eliminate any
unsuitable candidates (as we have done with RSIP), and then to choose
from the remaining candidates. Would like to eliminate at least one more.

Other considerations:
  - would we expect to see the candidate protocol already present in the
    device (middlebox and/or agent).
  - what is the level of standardization of the candidate protocol
  - other intangibles

It was suggested that the directionality problems and awkwardness of session
establishment procedures in COPS make it unsuitable.

The chair pointed out that we need to make progress. People need to read the
documents and participate.

Not choosing any protocol is also an option (better none than one that is
never used).

Some people felt we should have the option of developing a protocol.
To do that, we must demonstrate that all the candidates are unsuitable.

It was pointed out that of all the candidates, the one which
is most likely to be there already is SNMP, and that we
should just propose that SNMP be the selected protocol.

Others pointed out that SNMPv3 not widely used and it is a big leap from
SNMPv2 to v3. It was also pointed out that SNMP is not used very much for
configuration.

There were a number of suggestions for things that could be done in the
eval document for providing more information to make a decision from.
This included describing how each protocol would be used in a midcom
environment. However, it was pointed out that there has been fair
opportunity to do that and that it would only delay the process.

The COPS supporters felt that if you look at protocol reuse, COPS already
has the policy rule exchange needed for midcom.

It was suggested that the bar was set too high in not
allowing us to consider writing a new protocol. This too
though might have the same problem in selecting from a set
of existing proprietary protocols.

The commenter listed a number of devices which already support SNMPv3.

Discussion to be continued on the mailing list.
_______________________________________________
midcom mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/midcom