Subject: Draft minutes for IETF 43

From: Steve Hanna <[email-masked]>
Date: Fri, 18 Dec 1998 17:06:57 -0500 (EST)

Here are the draft minutes from last week's malloc working group meeting. Please 
send any comments to the list by end of day Tuesday, December 22.

Thanks,

Steve

-------------

Minutes of MALLOC Working Group
IETF 43 (Orlando, FL)
Thursday, December 10, 1998

Minutes reported by B. Quinn and S. Hanna.

Agenda:

Agenda Bashing       Hanna
Architecture         Hanna
MASC Deployment      Govindan
Language Tags        Hanna
MDHCP Changes        Shah
MDHCP Issues         Thaler

I. MALLOC Architecture

Steve Hanna described the malloc architecture, explaining why dynamic
allocation of IP Multicast addresses is important, what the
requirements are, and how those requirements are supported by the
different parts of the malloc architecture.

Steve also gave a document status update. MDHCP is expected to go to
last call in January 1999. MASC, AAP, the malloc architecture, and the
Abstract API should all go to last call in the spring.

II. MASC Deployment

Ramesh Govindan of USC/ISI gave a presentation on possible MASC
deployment techniques.

In the long run, each AS will probably be its own MASC domain, with a
limited number of top-level domains functioning as peers (with
children of those TLDs, etc.). However, we can start out with a single
root domain that injects the address sets and a small number of
well-known TLDs that are children of that root. This will be simple
and good for debugging.

Over time, we can move to a more decentralized model with children of
the TLDs, shortcuts between the TLDs, and the eventual elimination of
the root TLD.

Ramesh briefly outlined the latest changes to the MASC protocol:
refining processing of UPDATE messages and adding type-based ordering
of exchanged messages after reestablishment of peering.

Finally, Ramesh explained that a standalone implementation of MASC is
being developed at USC/ISI. Alpha code should be ready by next IETF.
Mark Handley announced that we have asked the IANA to allocate a range
of multicast addresses for dynamic allocation with malloc.

III. Language Tags

Steve Hanna explained why language tags have been added to zone names
and how they work. The problem is that zone names are user visible
strings and different users speak different languages. For instance, a
zone named "IBM Switzerland" would not be appropriate for someone who
doesn't speak English.

The solution we have adopted is to apply RFC 1766 language tags to
zone names and allow more than one name per zone. This meets
requirements of RFC 2277, which says (roughly) if you have user
visible strings you need to have a way to indicate which language they
are in and, when appropriate, support multiple languages.

For MZAP, we have added a language tag for each zone name and added
support for having more than one name per zone. We have also added a
default flag, which indicates which name should be used if no language
tag matches the user's preferences. A conflict in names (two routers
configured with different names or language tags) indicates a
configuration error.

MASC and AAP are not affected by language tags on zone names since
they do not deal with zone names.

MDHCP has been modified to allow a host to specify a preferred
language in the MDHCPINFORM message. The MDHCP server will return the
best match for each zone. For multilingual hosts, the host should not
specify a preferred language. In this case, the MDHCP server will
return all names for each zone.

The Abstract API has been changed to include all zone names in the
Scope data type. The get_zone_name function fetches the zone name that
best matches a given language tag from a given Scope.

IV. MDHCP

Munil Shah described the changes to the MDHCP specification since the
last IETF. A new port number has been assigned by the IANA: 2535. The
unused chaddr, sname and file fields have been removed. The MDHCP
option space has been split off from the DHCP option space. And
support for language tags has been added (as described above).

V. MDHCP Issues

Dave Thaler led a discussion of unresolved issues with MDHCP. The goal
was to discuss these issues and achieve consensus, then confirm this
consensus on the mailing list to allow us to take the spec to last
call in January, as listed in our working group charter.

Dave listed the issues scheduled for discussion and asked for any
others. Two more were raised and added to the list (issues 6 and 7
below).

Before beginning the issues discussion, Dave presented a summary of
the answers to a questionnaire that Steve Hanna sent to the dhcp-v4
and dhcp-impl mailing lists. 5 DHCP implementors responded.

Do you think that you might implement an MDHCP client or server?

3 Yes, 1 will accept mods, 1 if there's demand

If you were to do so, would you attempt to share code with your DHCP client 
or server?

3 Yes, 1 Maybe, 1 Little

Do you think that we should continue to maintain a similarity between MDHCP 
and DHCP?

3 Yes, 1 No Opinion, 1 Do The Right Thing

*Issue 1* Unused Fields

The first issue was whether the remaining reserved fields (op, htype,
hlen, hops, secs, flags, ciaddr, yiaddr, siaddr, and giaddr) should be
removed. The argument in favor of retaining them was to make it easier
to reuse existing DHCP code. The argument in favor of removing them
was that they are unnecessary and the savings due to reuse here is
minimal. After much discussion, it was agreed to drop these unused
fields. It was also agreed (at the suggestion of DHCP implementers)
that we add a version number to the header.

*Issue 2* Security

The second issue was security. Dave Thaler summarized the problem by
saying that our primary goal is to authenticate messages so we can
check authorization. DHCP has a harder problem, since a DHCP client
may not have a unicast address. The authors' proposal was to secure
unicast messages with an existing security protocol (undecided which
one), not secure the multicast INFORM message (used to request scope
list), and require secure servers to ignore multicast DISCOVER
and REQUEST messages (which would not be secured).

Ted Tso and Bob Moskowitz (cochairs of the IPsec working group)
summarized the advantages and disadvantages of several existing
security protocols for this purpose. First, they confirmed their
understanding that we want user-based security for UDP packets. The
answer was yes, since we want to be able to base authorization on user
identity.

They explained that current implementations of IPsec provide
host-based security. More work needs to be done on APIs and
implementation before user-based IPsec will be ready. Also, installing
IPsec requires OS-level modifications and IPsec is not yet widely
available.

Then they discussed other possible solutions. Of these, the most
promising seemed to be TLS/SSL. TLS is user-based, but it is also
TCP-based. Using TLS with MDHCP would require sending the payload that
would normally be carried over UDP over an authenticated TCP
connection. Another advantage of TLS over IPsec is wide availability
and no OS-level modifications required.

It was generally agreed that IPsec was probably the right decision
long-term, but it would be difficult in the next few years to require
all MDHCP clients to support IPsec. Support for user-level security in
IPsec will also take a while to become available.

It was agreed that we will go with IPsec for MDHCP security, but ask
the IESG to not require security in all MDHCP implementations for the
time being, since IPsec deployment is just beginning. Also, even
perfect security in our multicast address allocation protocols can't
keep somebody from just choosing an address and starting to use it. At
least, not with current implementations of IP Multicast.

*Issue 3* One-byte option length

Currently, each MDHCP option includes a one byte length field. We
expect to exceed this length with long scope lists or address block
lists. DHCP will probably move to a two byte option length field in
the future. Shall we move to it now?

After some discussion, the general consensus was that we should.

*Issue 4* Allocation scope referenced but not defined

The current MDHCP draft says that clients looking for a server should
first look in the local scope, then the scope from which they're
trying to allocate, then the Allocation Scope. Unfortunately,
there is no document defining Allocation Scope yet. The authors
recommend removing all mention of Allocation Scope from the document.

It was pointed out that this would require you to have an MDHCP server
in each scope from which you want to allocate. Also, unless you use
DHCP (or some other mechanism) to provide an MDHCP Server Multicast
Address, you would need to have an MDHCP server in each local scope
where you have MDHCP clients.

It was also pointed out that providing MDHCP services for a scope when
the server is not in that scope is very difficult. The server must
know exactly which scopes the client is in and which addresses are
available in those scopes. This is not easy and not recommended at
this point.

It was agreed to remove all mention of Allocation Scope from the
document. Use of MDHCP with the Allocation Scope may be defined by a
future RFC, once the Allocation Scope has been defined.

*Issue 5* IPv6 support

Currently, MDHCP only supports IPv4. The authors recommend adding
address type fields to allow MDHCP to support IPv6. We quickly agreed
to this recommendation.

*Issue 6* One-byte option code

Currently, each MDHCP option includes a one byte option code. Based on
DHCP's experience of running low on option codes and their decision to
move to a two byte option code in the future, we quickly agreed to
move to a two byte option code for MDHCP.

It was also suggested and agreed to number our options from 1 instead
of attempting to match them to DHCP option numbers.

*Issue 7* MDHCP Name Change

Steve Deering suggested that since MDHCP has diverged from DHCP, 
it might make sense to change its name. After some discussion, this
was agreed. Discussion of what the new name should be was moved to the
list.