Subject: [savi] Draft Minutes - IETF 78 meeting

From: Jean-Michel Combes <[email-masked]>
Date: Tue, 3 Aug 2010 19:18:58 +0200

Folks,

Here are the draft minutes regarding the last IETF meeting (thanks
again Eric and Joel for the notes):

---------------------------------------------------------------------
Draft Minutes of the SAVI working group meeting at IETF 78
Monday, July 26, 9:00 - 11:30, Berlin room
Chairs: Christian Vogt, Jean-Michel Combes
Jabber scribe: Fred Baker
Minutes takers: Joel Halpern, Eric Vyncke
---------------------------------------------------------------------

Introduction and Administrativa
Jean-Michel Combes, Christian Vogt

- Threats draft
A new version of this draft will be submitted in September
- Framework draft
Co-authors are needed. Please contact Christian.
- Reviews of the current WG draft
Don't hesitate to review the drafts and comment them on the ML

+++++

SAVI solution for SLAAC
draft-ietf-savi-fcfs-04
Marcelo Bagnulo

Updated to reflect SHOULD trigger binding creation up the reception of
binding from data packet, with qualification in an appendix.
Updated to reflect that SAVI devices MUST learn prefixes from the
router advertisement.

Open Questions:

- Do we need router ports?
Currently there are only trusted and validating ports. Routers will
probably on trusted ports. Adding a third type of ports for routers
where the local address is validated but remote address (for
transit/forwarded traffic) is blindly trusted. Discussion of
benefits/costs of allowing this. Including related issues of where we
accept RAs (all trusted ports, or some specific kind of trusted
ports). General agreement in room that we don't need the complication.
Suggested alternative from Jean-Michel Combes that Router Port would
be a trusted port with logging. Concern that logging is a DoS vector.
It is noted that SAVI has to defend the router link address as it
defends other bindings.
Consensus seems to stay with 2 kinds of ports and update security
considerations.

- When to delete bindings?
It is necessary that usage extends the lifetime of the binding.
So what is the default lifetime?
Obvious choice is to keep the lifetime as long as there is traffic.
Using the RA prefix lifetime. OTOH could also send a NUD before
deleting. Also removing a binding does not mean blocking traffic but
rather stopping the protection.
Fred Baker and others observed that the Prefix Lifetime from the
router is not a good basis for the SLAAC lifetime. Suggested that
timeouts on the same order as classic bridge MAC lifetimes seems
attractive.
Other factors were presented. Including the question of what the right
response is to attack via traffic that produces many bindings (under
attack such as DAD flooding very similar to the CAM overflow),
proposal delete newest bindings or limit the number of bindings per
port (configurable, which default?, could be used to prevent privacy
extension), should we rate limit the NUD probe before deleting? (or is
it left to the implementers?) but of course the attacker will reply to
NUD probe.
Discussion of responses and implications.
There is agreement that old bindings are more valuable than new ones.
It is noted that with privacy addresses this is more complicated.
Question to room:  Should we send a NUD probe before deleting a
binding? Suggestion is to probe for timeout but not for memory
exhaustion.
Discussion moved to the question of how to handle moves safely, and
how this interacts with lifetimes.
Conclusion at meeting we will have lifetimes on entries.
Which one? Using the 802.1d default time (5 minutes)? Consensus is to
keep the lifetime mean for garbage collect (main benefit is to be able
to differentiate normal situation and an attack). Fred’s default would
be MAC address in CAM (5 minutes perhaps too short but the NUD probe
will keep it alive), Eric’s default would be TCP timer (1 hour).
On the related issue of how many entries to have per port, the
discussion noted that the minimum requirements are tricky, since link
local and privacy leads to needing at least 4 entries, and virtual
machines require the ability to have more entries.
Discussion of whether there should be default values for the minimum
and maximum number of addresses and for the lifetime of entries.
Agreement that these values need to have defaults and need to be
configurable. Consensus for default values is 5 minutes for lifetime
and a minimum of 4 bindings per port.

- Rate limiting SAVI generated packets
Christophe Alter: use the DAD rate limiting
Chairs: We are late. Please, continue the discussion on the ML.

+++++

SAVI solution for DHCP
savi-ietf-dhcp-04
Jun Bi

Started with a review of the document structure and content.
The port could have multiple attributes: drop/forward DHCP server type
message, snooping DHCP, ...
Port attributes include compatibility, may need amplification.
Already implemented by ZTE, Huawei, Ruije, H3C, Digital China, Bitway,
Centec, ... Example given Tsinghua University Campus with different
vendors.
Changes: the prefix configuration is removed.

Open question:

- Support of mixed address assignment (DHCP and SLAAC), should it be supported?
Jun: yes because a lot of OS lack DHCP client. In order to support
mixed environment, the finite state machine has to change.
Joel Halpern suggested that we separate issues, write documents for
the single cases, and deal with mixed-mode cases completely
separately.
Proposal is to remove mixed-mode from SLAAC & DHCP documents to move
them ASAP to the IESG while adopting a new work item for this WG for
mixed-mode.

+++++

CNGI-CERNET2 deployment update
Jun Bi

CNGI-CERNET 100 campuses, 1 million users.
Vendors are the one previously mentioned by Jun in his previous talk.
A lot of CLI examples.
Testing was done for conformance, performance, test bed and in
production network using SLAAC-only, DHCP-only and mixed mode
(performance and binding size numbers reported). Performance graphs
were mostly in Chinese but the conclusion is that SAVI does not add
any delay. Interoperability was tested also.
Management was done by using a SAVI-MIB (including whether SLAAC-only
or DHCP-only FSM).
One operational issue was packet lost but 802.1x and SAVI were working
fine together.

+++++

Liaison with BBF
draft-costa-6man-dad-proxy-00
Christophe Alter, Jean-Michel Combes

The issues is DAD in N:1 VLAN configurations. This was presented at IETF 76.
In an access node, in some case there are multiple subscribers in a
shared VLAN but CPE do not have direct layer-2 connectivity to each
other: they talk at the IP level through the BNG (Broadband Network
Gateway). As seen at the BNG, all users are on one VLAN, but Ethernet
Frames are not forwarded from one user to another. This is because the
access network is designed to drop all frames sent from CPE to another
CPE. This is called split-horizon or E-tree service (in
Metro-Ethernet) or N:1 VLAN (broadband forum). It was mainly done for
scalability (10,000 subscribers per VLAN) and for privacy among
subscribers. As some CPE have duplicate MAC addresses, some access
networks do MAC address translation.

Issues to be resolved:

- LLA cannot be derived from MAC as there is duplicate MAC…

- BBF would love to have SAVI to define how a helper function could
allow DAD without any CPE-to-CPE layer-2 connectivity. Indeed, SAVI
should have all LLA bindings. Discussion: is it a SAVI item? Or 6MAN
or 6OPS ? Other topic: DAD will not make SAVI stronger of course. Is
the layer-2 MAC NAT (used in some access network) part of the issue?
(not really dixit Christophe but uniqueness of MAC address is not
guaranteed).

Draft-costa-6man-dad-proxy is a solution for this problem and is
presented by Jean-Michel. The best WG is probably 6MAN but authors are
open to any host WG. The I-D presents the N:1 VLAN split-horizon + why
existing protocols do not work (even RFC4389 ND proxy because of lack
of multicast support) + solution of DAD proxy. SAVI device uses the
binding to signal to the 2nd CPE doing DAD for one already-bound LLA
that this LLA is already used (minimal amount of traffic).

There was discussion of whether the use of MAC address translation in
some of these access networks has to be part of the discussion at the
IETF.
Several people want to analyze the issues linked to the MAC NAT,
probably into another document.

+++++

Analysis of SAVI in PANA with SLACC
draft-ding-savi-pana-with-slacc-00
Yilan Ding

No time for this presentation.

--- End of working group meeting ---

Please review the minutes and send comments/modifications before August 20.

Thanks in advance.

Christian & Jean-Michel.