Subject: [SAVA] FW: I-D ACTION:draft-wu-sava-solution-firsthop-eap-00.txt

From: bgreene at cisco.com (Barry Greene (bgreene))
Date: Mon, 23 Jul 2007 14:00:50 -0700

This work is directly replicating work already completed with:

1. Cable Source Verify (DHCP Lease Query)
http://www.cisco.com/en/US/tech/tk86/tk803/technologies_tech_note09186
a00800a7828.shtml

2. IP Source Guard
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configu
ration_guide_chapter09186a008022f26c.html#wp1083306

The Source Address Management Server (SAMS) and Interface to the
Authentication Server (IAS) are both equal to a DHCP or AAA/Radius
server. 

Both of these technologies are deployed in really huge Cable and
ETTX/MetroE providers. 

So, what is new? Why was there _no_ due diligence done?

DHCP Lease Query work is already in RFC4388 as a proposed standard
(ftp://ftp.rfc-editor.org/in-notes/rfc4388.txt) and is also part if
DOCSIS 3.0.

My biggest problem with the SAVA work and IETF is the 'driver's'
theme of ignoring all other academic and operational work in this
sphere. 

- -----Original Message-----
From: Internet-Drafts at ietf.org [mailto:Internet-Drafts at ietf.org] 
Sent: Monday, July 23, 2007 10:15 AM
To: i-d-announce at ietf.org
Subject: I-D ACTION:draft-wu-sava-solution-firsthop-eap-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: A First-Hop Source Address Validation Solution
for SAVA
	Author(s)	: J. Wu, et al.
	Filename	: draft-wu-sava-solution-firsthop-eap-00.txt
	Pages		: 9
	Date		: 2007-7-23
	
   This document describes a solution for preventing source address
   spoofing in the first hop, local subnet of the Internet.  The main
   idea of the solution is to get a dynamic binding between IP
address
   and access switch port.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wu-sava-solution-firsthop-ea
p-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body
of 
the message. 
You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-wu-sava-solution-firsthop-eap-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv at ietf.org.
In the body type:
	"FILE
/internet-drafts/draft-wu-sava-solution-firsthop-eap-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ATT2307521.TXT
Type: application/octet-stream
Size: 249 bytes
Desc: ATT2307521.TXT
Url : http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070723/80f8cecc/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-wu-sava-solution-firsthop-eap-00.URL
Type: application/octet-stream
Size: 103 bytes
Desc: draft-wu-sava-solution-firsthop-eap-00.URL
Url : http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070723/80f8cecc/attachment-0001.obj 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT2307522.txt
Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070723/80f8cecc/attachment.txt

---

From: miw at juniper.net (Mark Williams)
Date: Tue, 24 Jul 2007 08:16:35 +0800

*sigh*

Present a framework without the solutions filled in and you get accused 
of presenting a problem without solutions. Colour in the boxes with an 
existing solution and you get accused of re-inventing the wheel or 
copying somebody else's work.

In my presentation to the INT open meeting this afternoon, I was at some 
pains to point out that there were already many technologies out there 
that probably conform to the framework and that most of the work for the 
first hop validation in SAVA will be documentation/survey of existing 
methods for SAVA. If it turns out that there is no actual need for new 
protocols and/or mechanisms at this level then that is a good thing.

There will need to be many methods, because organisations dole out 
addresses and do authentication and access control in different ways. 
The draft actually mentions one implementation that uses EAP/802.1x and 
RADIUS. RFC4388 solves the main problem with DHCP snooping (state loss 
in the snooper causes security loss) which is a good thing. But the 
draft in question did not actually propose DHCP snooping other than to 
say it was an alternative candidate so accusations of "direct 
replication" are quite far from the mark here.

cheers,

Mark          

Barry Greene (bgreene) wrote:
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
>
> iQA/AwUBRqUXAr/UEA/xivvmEQL8AQCfYy/mUI4AWdVN6k+B4XyY3ZWWxmIAnRNP
> ZuBiJtVNx3ARAh58hpStyKpk
> =Uyrx
> -----END PGP SIGNATURE-----
>   
>

-- 
"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

---

From: jari.arkko at piuha.net (Jari Arkko)
Date: Mon, 23 Jul 2007 19:32:25 -0500

I can confirm that the existence of solutions is well-known
by everyone who has been involved in this discussion. If
pointers were missing in some document, that is  an oversight,
not an attempt to claim originality or avoid giving credit
where it is due.

The question I would pose is: if vendors have solutions in
this space, is there need or interest in documenting
some of them in an IETF standard? I.e.,

- are the solutions relevant for the users?
- do we think we could find consensus in the IETF that
  they should indeed be standard solutions?
- is there willingness from the vendors and others
  to spend effort in doing this?

Jari

---

From: bgreene at cisco.com (Barry Greene (bgreene))
Date: Mon, 23 Jul 2007 18:09:09 -0700

> this space, is there need or interest in documenting some of 
> them in an IETF standard? I.e.,
> 

There are source address validation techniques used by a wide range
of networks today. Are they relevant? Yes. 

What the SAVA work has never demonstrated a willingness to tackle is
a complete survey of the work that is done today. In fact, I think
SAVA is pulling resources away from the work we started on this in
RIPE. 

In other word, I think SAVA is becoming a distraction to the work
flow that was already in progress before SAVA started.

>   they should indeed be standard solutions?

Been there - done that. We have BCPs. We have the DHCP Lease Query
work. We have the Diameter work. 

In other words, work never stopped on source address validation
techniques and approaches in the IETF. 

>   to spend effort in doing this?

Good question. I wonder on that one. Speaking for my experience in
Cisco, we've opened many of the techniques so that any vendor can
code and deploy them. Most of the time operator pressure needs to be
applied to get our peers to code the work.

---

From: jari.arkko at piuha.net (Jari Arkko)
Date: Mon, 23 Jul 2007 20:54:57 -0500

Barry,

> applied to get our peers to code the work.

So, the incentives for you or other vendors to do something
relate to either (a) improving the solutions or their completeness
is some manner or (b) true interest in having a standard
solution as opposed to marketing a vendor-specific solution
or being happy with an industry standard. The latter
relates typically to customer push to do something,
or need to interoperate.

With regards to the first item, are the currently solutions
complete? Can they handle IPv6 as well as IPv4? Are all
the components in place, either in vendor docs or in some
of the IETF components that you mentioned? AAA/DHCP/IPv4/
IPv6/stateless autoconfig, etc?

Jari