Subject: [SAVA] Charter Proposal To Be Discussed at BoF

From: christian.vogt at nomadiclab.com (Christian Vogt)
Date: Tue, 04 Dec 2007 23:40:20 -0800

Folks,

below is a copy of the charter proposal that we are going to discuss in
tomorrow's SAVI BoF.  This is the same charter proposal that has been
discussed on this mailing list, and that was sent by Jari on Oct. 24,
modulo some updated milestones.

CU tomorrow,
- Christian

Source Address Validation Improvements (SAVI)

While the MIT Spoofer project has measured that about 75% of networks
deploy ingress filtering, ingress filtering at a finer granularity is
not yet as common.  A number of proprietary mechanisms exist (e.g., "IP
source guard") which offer partial solutions to prevent hosts from
spoofing the source address of another host in the same subnet.  The
purpose of the proposed "Source Address Validation Improvements" working
group is to standardize mechanisms to prevent source address spoofing in
the access network.

Specifically, the group shall define solutions such that hosts attached
to the same router cannot spoof each other's addresses. The following
assumptions apply:

- The WG considers only solutions on layer 3 aware Ethernet switches.
- Two solutions are needed, one for IPv4 and another one for IPv6
- The IPv4 solution depends on tracking the DHCP traffic on a port.
- The IPv6 solution depends on tracking the ND and DHCP traffic on a
   port.
- All address assignment mechanisms in IPv6 need to be supported,
   including stateless, stateful, privacy, and so on.
- The solutions are turned on for on host ports by configuration, and
   do not apply to routers.

The WG recognizes anti-spoofing deployment efforts, motivation, and best
practices development in various forums around the world (including
RIPE). The WG 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
Done      BOF decision
Dec 07    BOF in IETF-70
Jan 08    WG approval
Feb 08    First WG draft on IPv4 solution
Apr 08    First WG draft on IPv6 solution
Jun 08    Submit IPv4 solution to IESG for Proposed Standard
Dec 08    Submit IPv6 solution to IESG for Proposed Standard

---

From: fred at cisco.com (Fred Baker)
Date: Wed, 5 Dec 2007 08:05:55 -0800

comments inline

> - The WG considers only solutions on layer 3 aware Ethernet switches.

I would also suggest that we develop tools for switchless (wireless,  
dumb switch, etc) environments.

> - Two solutions are needed, one for IPv4 and another one for IPv6

query: to what degree is an IPv4 solution a special case of an IPv6  
solution, as far as algorithms go? For example, having solved the  
multiple address problem for v6, restricting to one address in v4  
makes sense.

> - The IPv4 solution depends on tracking the DHCP traffic on a port.

or manual configuration

> - The IPv6 solution depends on tracking the ND and DHCP traffic on a

what I proposed actually doesn't use DHCP - you need a solution for  
SAA as well. It turns out that once the address is configured,  
whether auto or dhcp, it has to be exchanged. You only need ND. You  
could, though, additionally watch DHCP as an authorization approach.

> - The solutions are turned on for on host ports by configuration, and

you might say that it cannot protect against routers. I first read  
this as saying "hosts and routers need not be changed", and that is  
only true in the switched solution; switchless environments call for  
host and router changes as they are the only systems there.

> components that such efforts could employ. The bigger questions are  

Too narrow. Include wireless network solutions.

---

From: junbi at cernet.edu.cn (Jun Bi)
Date: Thu, 6 Dec 2007 01:11:06 +0800

----- Original Message ----- 
From: "Fred Baker" <fred at cisco.com>
> dumb switch, etc) environments.

Agree.
Multiple solutions for operators would be good, because a operator could 
chose
the best he can deploy for his situation.

> host and router changes as they are the only systems there.

Agree, different environment may require different solution (e.g. for the 
switchless
environment as Fred mentioned, or for a situation that the network 
administrator
 can't fully upgrade switches in a big campus network).

Thanks,
Jun Bi

---

From: jari.arkko at piuha.net (Jari Arkko)
Date: Wed, 05 Dec 2007 10:03:40 -0800

Lets be careful with those calls for extending the scope. I think I
understand what we need to do technically in the switch case. I'm not
sure I do in other cases. Perhaps you can educate me and if the support
for the other cases falls nicely within the same behaviour for an
implementation, maybe we can extend the scope. Otherwise, do the simple
thing first and recharter/extend later for other cases.

Jari

---

From: bgreene at cisco.com (Barry Greene (bgreene))
Date: Wed, 5 Dec 2007 10:22:52 -0800

Change:

"The purpose of the proposed "Source Address Validation Improvements"
working group is to standardize mechanisms to prevent source address
spoofing in the access network."

To:

"The purpose of the proposed "Source Address Validation Improvements"
working group is to update practices, document experience with
existing technology, document all existing practices and limitations,
and develop potential new mechanisms which would allow a broad
anti-source spoof capabilities."

The language focused on "IP source address" needs to be expanded to
any source spoof. IP address, MAC, DSCP, protocol type, etc. etc. all
need to be included. 

> -----Original Message-----
> From: sava-bounces at mail.nrc.tsinghua.edu.cn 
> [mailto:sava-bounces at mail.nrc.tsinghua.edu.cn] On Behalf Of 
> Christian Vogt
> Sent: Tuesday, December 04, 2007 11:40 PM
> To: SAVA Mailing List
> Subject: [SAVA] Charter Proposal To Be Discussed at BoF
> 
> Folks,
> 
> below is a copy of the charter proposal that we are going to 
> discuss in tomorrow's SAVI BoF.  This is the same charter 
> proposal that has been discussed on this mailing list, and 
> that was sent by Jari on Oct. 24, modulo some updated milestones.
> 
> CU tomorrow,
> - Christian
> 
> 
> While the MIT Spoofer project has measured that about 75% of 
> networks deploy ingress filtering, ingress filtering at a 
> finer granularity is not yet as common.  A number of 
> proprietary mechanisms exist (e.g., "IP source guard") which 
> offer partial solutions to prevent hosts from spoofing the 
> source address of another host in the same subnet.  The 
> purpose of the proposed "Source Address Validation 
> Improvements" working group is to standardize mechanisms to 
> prevent source address spoofing in the access network.
> 
> Specifically, the group shall define solutions such that 
> hosts attached to the same router cannot spoof each other's 
> addresses. The following assumptions apply:
> 
> - The WG considers only solutions on layer 3 aware Ethernet
> switches. - Two solutions are needed, one for IPv4 and another one
> for IPv6
> The WG recognizes anti-spoofing deployment efforts, 
> motivation, and best practices development in various forums 
> around the world (including RIPE). The WG is only chartered 
> to deliver two specific solution components that such efforts 
> could employ. The bigger questions are out of scope.
> 
> Milestones:
> 
> _______________________________________________
> SAVA mailing list
> SAVA at mail.nrc.tsinghua.edu.cn
> http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava

---

From: bgreene at cisco.com (Barry Greene (bgreene))
Date: Wed, 5 Dec 2007 10:40:25 -0800

Reminder - goals for today. 

We have the BCP - 38 - which says what we need to accomplish.

We have lots of tools to implement BCP 38.

We have enough experience with this implementation to know that you
CANNOT have one solution that would work everywhere. 

So, to really get new IETF work, we need to look at what beyond BCP
38 we are going to accomplish.

---

From: fred at cisco.com (Fred Baker)
Date: Wed, 5 Dec 2007 13:35:07 -0800

for the record, the draft and presentation I will be discussing this  
afternoon covers all of these cases including unicast rpf.

I'm not sure I see the point of the discussion if we're going to  
hamstring its utility.

---

From: christian.vogt at nomadiclab.com (Christian Vogt)
Date: Wed, 05 Dec 2007 14:35:34 -0800

Folks,

please bring up your comments during the microphone discussion.  We will
base the discussion on the charter below for now, and evolve from there.

- Danny and Christian

---

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

Barry,

we need to make sure that our charter does not collide with activities
in RIPE's Anti-Spoofing task force [1].  While I agree that an analysis
of existing mechanism would be useful to identify the intended scope for
SAVI, documentation for its own benefit would certainly get into the
realm of the IP Anti-Spoofing task force.

[1] http://www.ripe.net/ripe/tf/anti-spoofing/index.html

Also, our scope is IP source address validation specifically.

- Christian