Subject: [SAVA] SAVI Charter Revision after Vancouver

From: christian.vogt at nomadiclab.com (Christian Vogt)
Date: Fri, 14 Dec 2007 23:08:50 +0100

Folks,

according to comments raised during the SAVI BoF in Vancouver as well
as meanwhile on the mailing list, I have revised the charter for the
proposed SAVI working group.  Enclosed is the new version of the
charter, followed by a change log.

Comments appreciated.

Best regards,
- Christian

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: savi-charter-2007-12-14.txt
Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20071214/3b9b5ecf/attachment.txt

---

From: danny at tcb.net (Danny McPherson)
Date: Sun, 16 Dec 2007 21:39:40 -0700

On Dec 14, 2007, at 3:08 PM, Christian Vogt wrote:
>
> - The working group considers only solutions implemented on systems
>   located on the same IP link as a to-be-verified host
> - The solutions verify the addresses of hosts; verification of router
>   addresses is out of scope

What does the above mean, exactly?  Addresses for transit
packets AND locally connected interfaces (e.g., any device
that'll forward IP packets and has one ore more IP interfaces)?

> - Two solutions are needed, one for IPv4 and another one for IPv6
> - The IPv4 solution depends on tracking the DHCP traffic

Why?  Seems to me this very quickly limits the solutions
space, when I'm not sure we've fully documented the
problem space?

> - The IPv6 solution depends on tracking the Neighbor Discovery traffic
>   or DHCP traffic

Same comment above applies here.

> - All address assignment mechanisms in IPv6 need to be supported,
>   including stateless, stateful, and manual configuration; as well as
>   privacy and cryptographically generated addresses

Then why not in IPv4?

> - The solutions must allow for interfaces with multipe IP addresses
> - The solutions must allow for hosts with multiple interfaces

What does that mean?

> - The solutions must interoperate with mobile hosts

Precisely what is a mobile host?

> - The working group will document how the to-be-developed solutions
>   relate to existing IP source address validation mechanisms

It sounds a lot like we've written the charter to comply
with them, so that shouldn't be to tough.

> The working group recognizes anti-spoofing deployment efforts,
> motivation, and best practices development in various forums around  
> the
> world (including RIPE).

AND the OPSEC WG?

> The working group is only chartered to deliver
> two specific solution components that such efforts could employ.  The
> bigger questions are out of scope.
>
> Milestones:

> Done      First draft on IPv4 solution
> Done      First draft on IPv6 solution

The two items above assume the SAVI community permits
the published documents as the basis for WG documents.
I'm not sure we're anywhere near reaching that consensus.

> Done      BOF decision
> Dec 07    BOF in IETF-70

Guess that's done..

> Jan 08    WG approval

I really believe the first document here needs to be a
full problem statement.  From there, drafts on v4 and
v6 solutions need to talk about which components of
that problem space they address.

The problem space document(s) should talk about all
the IP allocation schemas, the various topologies that
might be encountered in the LAN, and which problems
are believed exist as a result of spoofing (e.g., various
blind and non-blind attacks) that are worth addressing.
As noted, I'm happy to help draft such a document, as
I consider it a prerequisite to help with charter direction
and scope of SAVI.

I also believe SAVI needs to think about what protocol
what can be done that in some manner equates to
bits on the wire, versus intra-switch implementation
alone.

-danny

---

From: junbi at cernet.edu.cn (Jun Bi)
Date: Wed, 19 Dec 2007 16:58:04 +0800

----- Original Message ----- 
From: "Danny McPherson" <danny at tcb.net>
To: "Christian Vogt" <christian.vogt at nomadiclab.com>
Cc: "Bill Fenner" <fenner at gmail.com>; "Eric Rescorla" <ekr at rtfm.com>; "SAVI 
Mailing List" <sava at nrc.tsinghua.edu.cn>
Sent: Monday, December 17, 2007 12:39 PM
Subject: Re: [SAVA] SAVI Charter Revision after Vancouver

> that'll forward IP packets and has one ore more IP interfaces)?

The scope of the charter could be limited in the host-level, then
we may re-charter to resovle other problems.

> space, when I'm not sure we've fully documented the

I agree that we may need multipule solutions for opeators so that
the opeator can choce for different network environment.(e.g., some
opeator can upgrade the switches, somelese may not).

> bits on the wire, versus intra-switch implementation

I agree that we need a problem statement document.
We may also need a "framework" document to define the fundamental
to solutions (refer to Fred's comments below), and leave the design
details to different solution drafts. The WG should welcome
any new solution draft that follows the framework document,then choice
the best solution that resolves the same problem for same environment.

thanks,
Jun

>Fred wrote:
> The key point is the association of an IPv6 source address with a
> lower layer identifier, which might be purely local in significance
> like a port identifier on a switch, might be visible in the LAN like
> a MAC address, and might be a combination of lower layer identifiers
> like "the system on one of two ports using a stated MAC address". The
> association is called a "trust binding", and is fundamental to the
> solution. The implementation details are left to the implementor.

---

From: hiroa-ha at is.naist.jp (hiroa-ha)
Date: Wed, 19 Dec 2007 18:39:36 +0900

I have a question.

Current WG's mission is to write down several documents about ;

1. what kinds of problems we are bothered in daily operation or
    event operation like IETF meeting about source address validation ?

2. what we want to do against problems (prevent? guard? track? shoot?
    claim? clean up?) or what kinds of tools we need in daily/event
    operation?

3. what kinds of solutions are available now in each situation ?

, is it?

----
Hiroaki Hazeyama
Ph.D of Engineering
Internet Engineering Lab.
Nara Institute of Science and Technology

Jun Bi wrote:
> _______________________________________________
> SAVA mailing list
> SAVA at mail.nrc.tsinghua.edu.cn
> http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava

---

From: christian.vogt at nomadiclab.com (Christian Vogt)
Date: Fri, 21 Dec 2007 00:57:04 +0100

Danny -

> that'll forward IP packets and has one ore more IP interfaces)?

It means that the entities whose IP addresses will be verified by the
SAVI mechanism are supposed to be hosts, not routers.

Thinking more about it, I come to the conclusion that we should drop
this statement.  After all, we want the SAVI mechanism to also work for
nodes with multiple interfaces, and I don't see a reason why it should
not also work for routers (i.e., nodes with multiple interfaces that
forward packets between those interfaces).

Any comments?

> Same comment above applies here.

The rationale for these limitations is that they will keep us from
drifting away from the narrow charter that we proposed in Vancouver
compared to the much wider charter that was proposed in Prague.

>>   privacy and cryptographically generated addresses

Good point -- although in the v4 case, there are only stateful and
manual configuration modes.

>> - The solutions must allow for hosts with multiple interfaces

s/must allow for/must support/

> Precisely what is a mobile host?

A host that may change the point of network attachment for one of its
interfaces.  Do you think this is ambiguous?

>> motivation, and best practices development in various forums around the
>> world (including RIPE).
> 
> AND the OPSEC WG?

Added.

> that problem space they address.

How about the new milestones below?  It now includes the finalization of
the charter proposal and the (previously missing) problem statement.
Moreover, I removed the "first non-WG drafts" on IPv4 and IPv6
solutions, which were supposed to be done by now.

   Milestones:

   Done      BOF decision
   Done      BOF in IETF-70
   Dec 07    Charter proposal
   Jan 08    Problem statement
   Feb 08    WG approval
   Apr 08    First WG draft on IPv4 solution
   Apr 08    First WG draft on IPv6 solution
   Jun 08    Submit document on existing SAVI-related mechansims to IESG
             for Informational RFC
   Jun 08    Submit IPv4 solution to IESG for Proposed Standard
   Dec 08    Submit IPv6 solution to IESG for Proposed Standard

- Christian

---

From: christian.vogt at nomadiclab.com (Christian Vogt)
Date: Fri, 21 Dec 2007 01:00:09 +0100

Hiroaki,

yes, these items will be part of the proposed SAVI charter, and they are
to be tackled by a problem statement document.

- Christian

---

From: christian.vogt at nomadiclab.com (Christian Vogt)
Date: Sun, 23 Dec 2007 13:05:47 +0100

> forward packets between those interfaces).

Sorry, I have to correct myself.  I believe we should support multi-
interfaced hosts that do not forward packets, but the validation of
routers' IP addresses should be out of scope IMO.

The reason is that the validation of routers' IP addresses would likely
require a more complex technique than a Source-Guard-like function
because routers send packets from IP addresses of other hosts.

- Christian

---

From: miw at juniper.net (Mark Williams)
Date: Mon, 24 Dec 2007 12:34:29 +0800

> that'll forward IP packets and has one ore more IP interfaces)?
Hmm. I think transit packets are out-of-scope for SAVI. Am I correct in 
the assumption that we are looking at preventing spoofing from end 
systems here? Not saying transit packets aren't important. Just a 
different problem.
> Same comment above applies here.
Tend to agree here. It's the way it might end up, but at this stage I 
don't like to exclude any address-provisioning method.

--Mark

-- 
"Product roadmap and/or product discussion in this email set forth
Juniper Networks' current intention and is subject to change at any
time without notice.  No purchases are contingent upon Juniper
Networks delivering any feature or functionality expressed or implied
in this roadmap or product discussion."
-----------------------------------------------------------------
Mark Williams                        Juniper Networks
Liaison                              Beijing Office
Academic Networking Sector           Tel: +86 10 6528 8800 x16032
Asia Pacific                         FAX: +61 7 3251 0155
miw at juniper.net                      Cell: +86 1370-111-4749