From christian.vogt at nomadiclab.com Mon Apr 14 02:20:40 2008 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Sun, 13 Apr 2008 21:20:40 +0300 Subject: [SAVA] Conclusions from SAVI Workshop at IETF 71 Message-ID: <35F106BE-F3A4-473F-AC03-FC9F8DBB7FA6@nomadiclab.com> Dear folks, during our workshop at IETF 71 in Philadelphia, we concluded on three steps to be taken in order to convince IESG and IAB that establishing a SAVI working group is a good idea: (1) Finalize proposed working group charter We agreed on revising the requirements stated in the current charter version. The current charter version is very ambitious. Although we should strive to meet the requirements it lists, leaving them in the charter would mean that we have to meet them. That may in some cases be hard, in others even unfeasible. (2) Finalize problem analysis We agreed on adding rationale for the establishment of SAVI to the problem analysis by Fred and Danny. The current version includes an excellent overview of threats that IP source address spoofing can cause. It also has a great summary of existing IP source address validation techniques. What it is currently missing is a statement of where the existing techniques fall short, and why we need SAVI. (3) Decide on desired trade-off between security and simplicity of to-be-developed SAVI solution The IP Source Guard that we have so far considered as a potential solution approach is very lightweight. It doesn't break anything and can hence be enabled by default. But it is not bullet-proof. In particular, it assumes that a malicious host won't spoof address configuration traffic, such as Neighbor Discovery or DHCP messages. I would like to confirm on this list that SAVI should take a similar lightweight approach as the IP Source Guard. Please send comments. Personally, I strongly favor the lightweight approach. More heavyweight approaches quickly lead to complexity, which doesn't contribute to convincing operators that they should switch the SAVI feature on. I will follow up with a revision of the charter proposal, and suggest rationale text for the problem analysis. Kind regards, - Christian From christian.vogt at nomadiclab.com Mon Apr 14 02:27:55 2008 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Sun, 13 Apr 2008 21:27:55 +0300 Subject: [SAVA] Rationale for Creating SAVI Working Group Message-ID: Folks, attached is text that explains the shortfalls of existing IP source address validation techniques and, based on this, provides rationale for creating a new SAVI working group. I suggest this text for inclusion in Fred's and Danny's problem analysis. - Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: Existing Techniques for IP Source Address Validation Type: application/octet-stream Size: 3191 bytes Desc: not available Url : http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20080413/856a160b/attachment.obj From christian.vogt at nomadiclab.com Wed Apr 16 03:35:06 2008 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Tue, 15 Apr 2008 22:35:06 +0300 Subject: [SAVA] SAVI Charter Revision after Philadelphia Message-ID: <861C085E-F75E-4830-982A-40305B53AB0B@nomadiclab.com> Folks, I revised the charter as announced in my email from April 13. You find the new version attached; please take a look. Change log: - Softened requirements regarding support for mobile hosts, hosts with multiple interfaces, and hosts with multiple IP addresses on an interface (2nd-to-last bullet). - Updated milestones. Comments are welcome. - Christian -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 2008-04-12.txt Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20080415/9d10e17e/attachment.txt From jari.arkko at piuha.net Wed Apr 30 03:53:58 2008 From: jari.arkko at piuha.net (Jari Arkko) Date: Tue, 29 Apr 2008 22:53:58 +0300 Subject: [SAVA] proposed charter Message-ID: <48177CD6.9080807@piuha.net> All, Here's a proposed charter for the SAVI WG. It has been sent for IESG and IAB review. If and when this is successful, there will be public IETF review. If people on this list have comments on the charter, please let me know by next week's Wednesday. We've been waiting with SAVI in order to address two issues: (1) documentation of threats and how SAVI would improve things over what we can already do with BCP 38 & friends, and (2) dealing with a bigger set of situations (multiple MAC addresses, multiple addresses, mobility, multihoming, ...) than the vendor solutions. For the first issue, the beginning of the new charter tries to explain that SAVI is really just about making BCP 38-like filtering possible in more circumstances than it now is. For instance, if you interface to my customer is a PPP link, I can do it today. But if all my customers are attached my Ethernet switch, I have a much harder time doing ingress filtering. Secondly, Danny has written a new draft (http://tools.ietf.org/html/draft-mcpherson-savi-threat-scope). While clearly a -00, I think it says what we need to say about issue 1 at this stage. In particular, as long as we are not doing the IPv4 checking on a 32 bit boundary and on all kinds of link types, we can see some potential improvements. The other issue is harder. Christian and I did some work together to try to understand what can and cannot be done in this space. We've also had a discussion about this with a few interested parties. There are many interesting ideas on what we could do, and almost everything that we want to handle can be handled. Certainly much more than some of the existing designs. However, we suspect there are fundamental limits -- anycast address usage, for instance, would look very similar to a spoofing attack. As a result, the best that we may be able to do in such situations is to log suspected spoofing attempts. Or require explicit configuration to enable blocking of spoofed packets in environments where this is possible. My belief is that this is sufficient to make an improvement in the Internet -- and I believe there is market demand for this. The charter takes the approach that it lists the situations we want to be able to handle, explains which of them are likely hard, and lets the actual design & tradeoffs be done by the WG. Thoughts, comments, suggestions? ---- Source Address Validation Improvements (SAVI) While ingress filtering [RFC 2827, BCP 38] provides a way to validate IP source addresses at an aggregated level, there is not yet a standardized mechanism for IP source address validation at a finer granularity. Having a finer granularity would be helpful in a number of situations, including filtering traffic from customer interfaces implemented as ports in a switch, general improvements in filtering accuracy in enterprise networks, etc. Depending on the situation, there may be a requirement for blocking spoofed packets or merely logging packets that appear to be spoofed. Partial solutions exist to prevent nodes from spoofing the IP source address of another node in the same IP link (e.g., the "IP source guard"), but are proprietary. The purpose of the proposed "Source Address Validation Improvements" working group is to standardize mechanisms that prevent nodes attached to the same IP link from spoofing each other's IP addresses. The scope of the WG is as follows: - The working group considers only solutions implemented on systems located on the same IP link as a to-be-verified node. The goal of the working group is the LAN environment and solutions running in an Ethernet switch. - Both IPv4 and IPv6 need to be covered. - All address assignment mechanisms need to be supported, including stateless, stateful, and manual configuration; as well as privacy and cryptographically generated addresses. - Solutions are based on observing existing protocols and not introducing new protocols. Examples of protocols that can be useful are ARP, Neighbor Discovery, DHCP, and DHCP Prefix Delegation protocols. Observing addresses in IP headers of other protocols can also be useful. The gathered information is used to determine what source addresses in packets are appropriate. - Tracking other protocols, such as routing protocols, is not within the scope of the WG. - No changes to hosts are allowed. - The WG is prohibited from creating its own protocols or extensions of current protocols. These limitations in the scope may be relaxed through later rechartering. For instance, solutions tailored for PPP links and specific environments such as DSL may be added later, or solutions involving co-operation of the nodes on the link may be developed once the baseline solutions have been completed. In order to reach a result that is widely usable and unlikely to disturb existing network practices, the working group needs to take into account - nodes that use static addresses, - nodes with multiple IP addresses on the same interface, - nodes that use multiple link-layer addresses on the same interface, - attachment of another switch at a switch port, - presence of routers, NATs, and other similar devices on the same link, - use of SEcure Neighbor Discovery in some networks, - nodes that have multiple interfaces to the same link, - nodes that move to another port on the same link, and - hosts with anycast addresses. However, should such wide applicability turn out to be impossible, the working group will document the limitations of the solutions in due manner. In particular, it is likely that anycast addressing and nodes that employ multiple interfaces for load balancing at link layer are indistinguishable from an actual spoofing attack. There may also be a difference in the applicability between blocking and merely logging spoofed packets. In any case, the solutions may require to be explicitly turned on for each network or interface where they are applicable. For background information, the working group will also develop a threats analysis document that describes what threats the solutions from the WG protect against. This document also contrasts SAVI to existing solutions. Milestones: Jun 08 WG approval Jul 08 First WG draft on threats document Oct 08 First WG draft on IPv4 solution Oct 08 First WG draft on IPv6 solution Oct 08 Submit document on threats to IESG for Informational RFC Mar 09 Submit IPv4 solution to IESG for Proposed Standard May 09 Submit IPv6 solution to IESG for Proposed Standard