Subject: Draft minutes for MALLOC @ IETF 46

From: Steve Hanna <[email-masked]>
Date: Wed, 01 Dec 1999 10:03:27 -0500

Here is a draft copy of the minutes from the MALLOC meeting at IETF 46.
Please get comments to me by Friday morning.

Speakers, please submit your slides to the secretariat if they contain
significant information not contained in the minutes (or ask me to add
it to the minutes).

Thanks,

Steve

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

Minutes of MALLOC Working Group
IETF 46 (Washington, DC)
Friday, November 12, 1999

Minutes reported by R. Quinn and S. Hanna.

Agenda:

- Agenda Bashing
- Introduction and Document Status
- Architecture Updates: Dave Thaler
     (draft-ietf-malloc-arch-03.txt)
- MADCAP Updates: Steve Hanna
     (draft-ietf-malloc-madcap-07.txt)
- MADCAP Scope Nesting Option Updates - Roger Kermode
     (draft-ietf-malloc-madcap-nest-opt-02.txt)
- AAP Updates: Steve Hanna 
     (draft-ietf-malloc-aap-02.txt)
- MASC: Dave Thaler for Pavlin Radoslav
     (draft-ietf-malloc-masc-04.txt)
- Zero Configuration Multicast - Dave Thaler
     (draft-thaler-zeroconf-multicast-00.txt, sent to malloc list)

Agenda Bashing                     Thaler
Introduction & Document Status     Thaler
Architecture Document Update       Thaler
MADCAP Update                      Hanna
MADCAP Scope Nesting Option Update Kermode
AAP Update                         Hanna
MASC Update                        Thaler
Zero Configuration Multicast       Thaler

I. Introduction and Document Status

Dave Thaler gave an overview of document status.

- Architecture doc: Recently revised to reflect comments from WG Last
Call
- MADCAP doc: Approved by IESG for Proposed Standard
- AAP doc: In WG Discussion (recently updated)
- MASC doc: Recently revised to reflect comments from WG Last Call
- Scope Nesting doc: Recently revised to reflect comments from WG Last
Call
- Abstract API doc: Sent to IESG for Informational
- MALLOC MIB doc: Waiting for AAP
- Static Allocation: moved out of MALLOC into MBONED

A revised version of the IPv6 multicast address static allocation
scheme described in draft-haberman-malloc-static-ipv6-alloc-00.txt is
expected soon (but this is not a MALLOC work item).

Dave also gave an overview of the MALLOC architecture.

II. Architecture Document Update

Dave described the changes made in the most recent version of the
architecture document (draft-ietf-malloc-arch-03.txt) in response to
feedback during the WG Last Call.

* A definition of "Allocation Scope" was added, with a proposed range
  of IPv4 admin scoped addresses and an IPv6 SCOP (6).

* A Security Considerations section was added.

There were no objections to sending the Architecture document directly
to the IESG without another WG Last Call. This will be confirmed on
the mailing list.

III. MADCAP Update

Steve Hanna explained that MADCAP (draft-ietf-malloc-madcap-07.txt)
has been approved by the IESG for publication as a Proposed Standard.
The changes since the last IETF meeting were pretty minor. The most
significant one was that the INFORM message type was renamed to
GETINFO, since the client uses it to request information from the
server, not to inform the server of anything.

The next steps are implementation, then interoperability testing and
eventually a move to Draft Standard status. Steve mentioned that
Microsoft has client and server implementations in Windows 2000 and
that he is working on a client implementation in Java.

Steve Casner asked what were the plans for the Java implementation and
Steve Hanna said that no solid plans have been established yet. Anyone
with strong opinions should contact him.

IV. Multicast Nesting State Option Update

Roger Kermode described the changes included in the latest version of
the Multicast Nesting State Option document, which was sent to the
malloc mailing list on Tuesday
(draft-ietf-malloc-madcap-nest-opt-03.txt).

Typos were fixed. The requirement that the Multicast Nesting State
Option appear after the Multicast Scope List option was removed. The
INFORM message type was renamed to GETINFO to match the change in the
MADCAP spec. Dependencies on MZAP were removed from the text (since
you can statically configure scopes or use some other protocol for
scope announcements and notification). And the document was
restructured.

The next step is to assign a MADCAP option ID for this option and send
the document to the IESG for publication as a Proposed Standard. Steve
Hanna pointed out that we need to wait for MADCAP to be published as
an RFC before this can happen.

V. AAP Update

Steve Hanna described the changes included in the latest version of
the AAP specification (draft-ietf-malloc-aap-02.txt). This was a
substantial rewrite of the document.

Support for IPv6 addresses was added. Address ranges are now used,
instead of single addresses. IPsec is now used for security. And there
is a new message type (ANA). Also several missing sections were filled
in.

Steve then described AAP Security in more detail. Authentication of
messages is the primary concern. The previous solution was to include
a digital signature in each packet, but this would be expensive. The
new solution is to use IPSec to authenticate packets. Because IPsec
does not currently include support for group key establishment,
manual keying will need to be employed for now to establish and
maintain a shared group key. However, the Secure Multicast Research
Group (SMuG) in the IRTF is working on group key mgmnt and efficient
per-sender authentication and it is hoped that this work will make
AAP key management simpler in the future.

The choice to use IPSec was the result of discussions on the MALLOC
mailing list. Steve asked if the group approved of the use of IPsec
and there was a generally positive repsponse from those present in the
room (noone was against it, anyway).

Steve described the ANA message type that was added to the latest
version of AAP. This message was added because the previous version of
the spec required that one MAAS in the domain send periodic ASRP
messages reporting on address space utilization, but it didn't provide
a way for this MAAS to find out about failed allocations.

A MAAS sends ANA (Address Not Available) when an allocation
fails. Other MAAS's make a note of the failure and address range. When
any MAAS sends an address space report (ASRP) message to the prefix
coordinator, it includes a summary of failed allocations. The ANA
message is just sent a few times (not forever).If it is lost, it's not
a big deal.

Dave Thaler said that the spec should point out that if you have
responsive prefix coordinators, this should be a rare
occurance. Normally, you won't have a huge jump in usage, so the
allocation coordinator can track and predict usge. Failed allocations
should be an exception condition rather than a normal state.  Hence,
using an ANA is a fall-back mechanism.

Roger Kermode asked if the ANA message could be used to mount a Denial
of Service (DoS) attack. Steve said yes, that's one reason why
authenticating AAP messages is important.

Steve asked that people read the latest spec and send comments to the
MALLOC mailing list ASAP. He plans to put out another version next
month and go to WG last call in December 1999. We hope to have the
spec approved for publication as a Proposed Standard by spring.

Dave Thaler asked if timer reconsideration (a la SAP) should be done
in AAP. Steve said that AAP uses a constant interval between messages,
so timer consideration does not apply. Dave pointed out that a
constant interval can cause scaling problems. Steve said that this
is understood and we do not expect to have lots of AAP speakers in an
allocation domain. We do not expect hosts to do AAP, except in highly
constrained environments (which have small numbers of hosts anyway).
Steve Casner pointed out that in SAP the number of announcements
depends on the number of sessions, not the number of servers. Because
AAP allows for many addresses to be included in a single AIU message,
this does not apply to AAP.

VI. MASC Update

This presentation was prepared by Pavlin Radoslavov. However, Pavlin
could not attend so Dave Thaler actually gave the presentation.

The MASC draft has recently been revised to reflect comments received
during working group last call. This draft will eventually be
submitted for publication as an Experimental RFC.

Summary of changes
- OPEN and UPDATE messages format modification: domain ID and Node ID 
  lengths depend on AddrFam to get their lengths (to accomodate IPv6)
- The "A-bit" (active prefix bit in a claim) was renamed to "D-bit" 
  (deprecated bit) and its polarity was reversed
- The "C-bit" (Close connection-bit in a notification message) was
renamed 
  to "O-bit" (the "keep connection Open" bit) and its polarity was 
  reversed, to align with BGP and BGMP (to be consistent and allow 
  code reuse).  The purpose of this bit is to allow sending a non-fatal 
  error that indicates the TCP connection should remain open.   

- Authentication code option must include 2 values instead of 3: "The 
  algorithm for computing values of Marker fields" is removed to try 
  to keep this info private (to avoid helping an attacker and because 
  it was unnecessary anyway).
- The "QUERY/RESPONSE debug messages" appendix was removed and is going
  to be put in separate document.

Any objections to submitting this to the IESG for publication as an
Experimental RFC? There was some discussion about whether we would
want to advance this to Proposed Standard at some later time and how
that might be accomplished. But no objections were raised to going to
Experimental at this time.

MASC Implementation Status

Pavlin has posted source code for a MASC implementation at
http://netweb.usc.edu/masc/mascd. The next step for this
implementation is to update it to reflect the changes in the latest
MASC spec.

Pavlin has an experimental top level domain (TLD) and is allocating
addresses. Feel free to launch your own experimental TLD and start
peering with his. In response to a question, Dave clarified that
Pavlin is using addresses from 225/8.

VII. Zero Configuration Multicast Allocation

Dave Thaler presented the ideas described in
draft-thaler-zeroconf-multicast-00.txt. He gave this talk in the
ZeroConf working group meeting, but only focused on the subset
relevant to requirements (since that is all they are currently
concentrating on there, as of yet).

A zeroconf environment is one where no configuration is done for any
device (e.g. a home network). A configured environment is one where
some devices (especially routers and servers) require configuration.
Also, the zeroconf working group has restricted its work to
environments which contain no more than one router and one gateway (a
router leading out of the zeroconf environment).

Dave described the scopes where dynamic allocation of multicast
addresses is allowed: node-local, link-local, local, other small
scopes, other large scopes, global, and global single-source.
Currently, node-local and link-local addresses are only available for
dynamic allocation with IPv6 addresses. And global single-source
addresses are only supported for IPv4 addresses (in 232/8).

Node-local, link-local, local, global, and global single-source scopes
are well-known. That is, they have a well-defined range of reserved
addresses that should always be present.

Dave pointed out that there may be a need for administratively scoped
single source addresses. Where should these go? In 232/8 or 239/8 or
somewhere else? Nobody expressed an opinion, so Dave promised to ask
on the list.

The protocols that Dave suggests using to implement zeroconf multicast
address allocation are: MADCAP, AAP, and MZAP.

The first service that applications need is scope enumeration:
obtaining a list of scopes to allocate from, so they can choose one.
Scope enum is NOT required to allocate from a well known scope.

Zeroconf hosts can assume existence of well-known scopes with default
names. The hosts SHOULD do a MADCAP scope-enum query and cache
answers. Preferably this should be done at startup and periodically
thereafter, but it could be done at request time. If no MADCAP
responses are received, the host MAY listen for MZAP messages.

A gateway should have the same behavior as a host, in a configured
environment. It should also create a local scope boundary between
the configured and zeroconf environments and reply to MADCAP
scope-enum queries from the zeroconf side.

The second service that applications need is address allocation.
Node-local and single source addresses can be allocated instantly,
since each node has its own pool of these addresses. Allocation of
link local, local, and other "small" addesses should always be
available. Allocation of other ("big" and global) addresses should be
available whenever possible.

Zeroconf hosts can handle allocation from node-local and single source
addresses on their own. Link-local addresses can be allocated using a
subset of AAP (what Dave calls "ARPing": choosing an address and
sending a multicast claim for it, then using and advertising it if no
collision is detected). For local and other "small" addresses, the
host should send a MADCAP request first. If that fails, the host can ARP
for an address. For global and other "big" scopes, the host should
send a MADCAP request. If that fails, no addresses should be allocated
from that scope.

Steve Hanna pointed out that there are scaling limits to the ARPing
technique. Also, if a zeroconf network is connected to another
zeroconf network (or to a configured network), previously allocated
addresses may encounter collisions. Thaler said that zeroconf hosts
must be able to deal with such situations.

Steve Casner asked how useful link-local allocaton is for hosts? Dave
said that it is mainly useful for expanding ring/scope searches and
situations where there is a large number of hosts and you want very
local scopes.

Zeroconf gateways can act as mini-MAAS's, providing multicast address
allocation services to hosts in the zeroconf area. For node-local,
link-local, and single source addresses, they won't be involved. For
local addresses, they can act as a full MAAS, but then they need to
have stable storage. Or they can let hosts ARP, but that doesn't scale
well. For other small addresses, they can pass requests to a parent
MADCAP server. If that fails, they can act as a full MAAS or let hosts
ARP. For global and other large addresses, they must pass requests to
a parent MADCAP server.

This is a nice extension to what the MALLOC group has done.

Steve Hanna asked why not let the gateway act as a full MAAS for
global and other large addresses. Dave said maybe this is right.

Steve Hanna said this should not require any changes to the MADCAP
spec, which is good, but we may need changes to the AAP spec.
Dave said it requires an additonal field in AAP, but we wanted to do
this anyway.

Steve Casner asked what names should be assigned to scopes when
there's no MADCAP server. It was generally agreed that a host can
provide reasonable defaults if no information is available. But a
zeroconf gateway should provide a way to set the zone name for the
Local scope (for instance).

Steve Casner also asked how an application can figure out the
semantics of the scopes in the scope list. Dave said that the
application could use the scope ID for well-known scopes.

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Fri, 03 Dec 1999 14:04:09 -0800

> MASC Implementation Status

<del>

> Pavlin is using addresses from 225/8.

Just a clarification. Currently I am using 225.128/9 for the
experimental TLD, so this leaves 225.0/9 for other malloc
experiments.

BTW, the 225/8 block is going to expire this month, so it should be
renewed before the end of the year.

Pavlin