Subject: [midcom] IETF 54 meeting minutes

From: Melinda Shore <[email-masked]>
Date: Thu, 15 Aug 2002 12:12:47 -0400

Minutes of midcom working group at 54th IETF Meeting,
Yokohama, Japan

Chaired by Melinda Shore ([email-masked]
Reported by Spencer Dawkins ([email-masked]),
  edited by Melinda Shore

Status update:

* Framework and requirements documents are still in RFC
  editor's queue 
* STUN is in last call -  please look at it, so we don't
  have another showstopper. 
* SPAN design team is stalled with a serious security issue,
  and the design team may be shut down. We are late with SPAN
  and very late with STUN.
* Two semantics documents need to be reduced to one.

MIDCOM Protocol Evaluation: Issues and Plans (Mary Barnes)

Five protocols have been evaluated (SNMP, RSIP, MEGACO,
DIAMETER, COPS) since last meeting. Evaluation document has
been cycled three times since last meeting.  COPS-PR (as
opposed to COPS) is required to meet two requirements. There
is a glaring mismatch between MIDCOM framework and COPS
model. MEGACO has a similar problem with implied
directionality. With SNMP, SNMPv3 is required to meet
security requirements.

There are still opportunities to improve the document (read:
"glaring errors") - review it on the plane on the way home, OK?

We're about two weeks late, on the current forecast (to IESG
in September).

MIDCOM Semantics (Tom Taylor)

We currently have two semantics drafts as candidates for
working group document.  The two documents differ primarily
because one makes simplifying assumptions.

Takeover -- is having one agent operate on rules established
by another agent really required? What granularity is
required? Should there be a formal handoff procedure?

Melinda pointed out that there is no requirement for a
handoff procedure in the requirements document.

The group agreed that there is a need to allow one agent to
operate on rules established by another agent. Granularity
could be per user (identity) as well as per rule or per
session.  We need a handle in order to do handoff. We had
quasi-consensus a year ago on takeover a year ago, based on
the idea that ACLs would be used as required.

Is a deterministic outcome required? Perhaps only in
the eyes of the administrator (agents can't know this).

Rules survive to the end of their lifetime.

Is there a requirement to move rules from one group to
another?  Christian pointed out that when you create a rule,
you place an arbitrary identifier on it, and the group is
the collection of rules with the same identifier.

Is a group timeout required? There was agreement that it is not.

Would you ever map an odd port to an even one, or vice
versa? The decision was that there is no need.

Is DENY actually needed? There was consensus with some
dissent that DENY is not needed.  A DENY would be needed if
midcom were to be used to support device configuration or if
it were to be used for intrusion detection/response.  It was
strongly felt that it would unnecessarily complicate rule
processing and that it isn't needed for normal midcom
operation, and so the decision was not to include a DENY rule.

Is AND required for multiple filters? The group agreed that
we don't need multiple filter conditions.

What query capabilities are required? Audit for takeover?
Wildcarded query filters? Scope issues? Martin said if you
have a point-to-point protocol, you can get the status of
your rule, but this doesn't work if we have handoff. Cedric
replied that this is already handled in the proposal. Martin
asked but if we have hundreds of rules, is that what we want
returned? Tom asked that if we want this, we need to specify
it in the concrete protocol we select.

Wildcards and Ranges -- is there any need to support address
ranges, port ranges, open-ended pinholes? Jim's RSIP
experience says 'yes' to all three questions. Elliot Lear
asked whether the document specify wildcards? Melinda thinks
this is implicit in the requirements. Elliot said we get into
trouble with wildcards and DENYs -- if we have one, we
shouldn't have the other.

Grace Period and Pre-Notification.  This matches DIAMETER's
capability. Jim said that RSIP has problems without
this. The issue is with agent restarts and recovery, when
rules time out during recovery.

Atomicity -- are multiple rules applied as a transaction
required, to avoid deadlock, etc.? Is there a need to
enforce bi-directional mappings? Melinda said that we
decided this is a sequence.

What about applications like VoIP where we need to be
stateful? Tom said this is an application issue, not a
middlebox issue, as he recalls the framework
document. Jonathan asked what to do if the sender is also
NATted and you can't hear them suddenly. Jim said that
they've seen this issue in tneir operational experience with
RSIP as well. If your rules are too selective, you're
swamped trying to keep up with rule changes. One of their
customers has an application where there are several servers
outside the middlebox, and they're bouncing the call from
inside the middlebox around. They really need an 'accept
from anybody' to have a prayer of keeping up. said that
these need to be separate sessions that need to be grouped
together -- that simplifies things.

Reconvening after the break, Jiri asked if we really insist
on reusing an IETF protocol?  Melinda replied that we have a
clear mandate from IESG to do so, unless we can prove that
no existing protocol works.  If you feel strongly, please
talk to the ADs.

STUN Update (Jonathan Rosenberg)

There's a -01 revision that went in just before the cut-off,
reflecting comments from WG last call on security. We're not
using CMS any more. We need integrity of requests to deal
with security problems, and CMS won't help with that.  It
also won't work with Secur-ID and Kerberos. The new solution
is to use server-side authentication in TLS, plus a one-time
password, used for HMAC SHA-1 protection of STUN requests.

This still doesn't solve the security problem described
during working group last call which allows an attacker to
launch a denial-of-service attach and spoof the source
address, which isn't covered by HMAC because of NATs.  There
is no way in the known universe to resolve this in a NAT
world, and it affects any NAT-friendly protocol that's
supposed to be secure.

We're hoping that the scope of this problem is limited.  The
attacker has to be on the path from server to the target.
Basically you can DoS on the same LAN, and hijack a
100-megabit stream that the target should be receiving.
There's another attack, to receive all packets, that also
works.

Christian said the only way to solve this problem is by
using end-to-end encryption. Jonathan answered that there
are heuristics to detect this attack, but not reliably.

Eric Rescorla said that we're already vulnerable to people
on the same LAN anyway. Christian replied if you are
actually receiving the packets, you can just drop them.  If
you're just a listener, the target still gets them. Eric
said that cryptographic signing doesn't protect the
important piece of information and asked about removing the
HMAC and use a random challenge? Jonathan answered that if
you remove the HMAC it's even easier to carry out the
attack with a greater scope of exposure.  The HMAC-capable
attack is a hard timing problem. Christian proposed no
security, because security wasn't helping anyway.

Security considerations section is much thicker now --
support for TLS is mandated, but Kerberos or SecurID can be
used instead. The only open issue is whether this security
mechanism is worthwhile.

Jiri asked about symmetric NATs. Jonathan said that he ran
STUN through the NAT at my house. Christian said symmetric
NATs are a relatively small subset of the market.  Cullen
said that he's seen about 30 versions of NATs, including S/W
release numbers.

Melinda said that we have one week left in last call and
asked for comments ASAP.

SPAN Update (Melinda Shore)

SPAN works across symmetric NATs and complements STUN.  It
provides an external Relay with TCP listeners and support
for UDP. The focus is on simplicity. The design team missed
May 02 milestone and is failing to make progress.

We also have a security problem with accepting incoming
connection requests that may violate firewall policy. We are
enabling listeners behind a firewall -- not just allowing
hosts inside the firewall to make outgoing connections, but
also allowing them to provide services to people outside the
firewall. Jonathan said that STUN is more restrictive than
TURN. Christian answered that STUN allows you to receive UDP
packets from people you've sent packets to -- and this is
still OK.  SPAN enables a random sender outside the
firewall.

Cullen asked if people see the need to allow TCP relays?
The answer was yes. He then asked how critical it is to keep
from increasing bandwidth utilization.  Jonathan asked if we
aren't looking at tunnelling UDP over TCP, are we?  Dave
Oran said as long as the client knows this is happening, the
client can adjust. And this should be compressible under
existing ROHC schemes, if not, this is a problem.  We can
add keep-alive traffic -- we might want to consider this.

Steve Bellovin is not thrilled with the concept of allowing
TCP connections between firewalls. Firewalls are there for a
reason, don't subvert them just because we can do
so technically.

Wrap Up

Please look at STUN during last call, and the protocol
evaluation document before last call.

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