Source Address Validation Improvement (SAVI) Threat Scope
Note: This ballot was opened for revision 05 and is now closed.
(Ralph Droms) Discuss
Discuss (2011-05-25 for -)
I will raise a meta-discussion issue before listing several specific Discuss points. This issue may be just the suppressed pedantic ex-professor side of my personality expressing itself. My issue is that the contents of this document are useful and not incorrect. However, in my opinion the document would be more useful, especially to someone who reads this document without a lot of background in the type of threats described, with some additional detail. I could be persuaded that I am being overly pedantic, in which case I will clear my Discuss and move my points to Comments. I will be happy to send text if the authors would find it helpful. 1. In section 1: At the IP Network Layer, or Internet Layer, there is typically no required transactional state when communicating with other hosts on the network. Hosts generating packets for transmission have the opportunity to spoof (forge) the source address of packets which they transmit. I think this paragraph needs more detail to connect the first sentence with the last sentence. 2. Next paragraph: Source address verification is necessary in order to detect and reject spoofed packets and contribute to the overall security of IP networks. In particular, source address verification techniques enable detection and rejection of spoofed packets, and also implicitly provide some assurances that the source address in an IP packet is legitimately assigned to the system that generated the packet. "Source address verification" can be used or is necessary? You haven't told us what source address verification is, yet. The second sentence in this paragraph doesn't seem to add any new information. What would be more helpful would be a sentence or two foreshadowing the details in section 3. Why are packets with spoofed addresses dangerous? 3. The attacks in section 3 fall, roughly, into two buckets: those that require spoofed source addresses and those that can use spoofed addresses to obfuscate the source of the attack. SAVI can eliminate the former but only deter, through threat of discovering the perpetrator, the latter. The difference is important to someone using this document to learn about how SAVI contributes to security in a network. Otherwise, a network administrator might expect to eliminate all of the listed attacks with SAVI. An improvement would be to explain the two types of attacks and indicate the type of the attacks in section 3. 4. I found the second sentence of the first paragraph of section 4 very hard to parse and not entirely consistent with the title of the section. While most of the solutions in section 4 have to do with the network topology, the first bullet: o The IP source address is appropriate for the lower layer address (they both identify the same system) has nothing to do with network topology. The second bullet: o The IP source address is appropriate for the device at the layer 2 switch port (the address was assigned to a, and perhaps the, system that uses that port) does use network topology, but seems specific to wired networks; in fact, later in section 4, wireless networks are mentioned as using different techniques. Might be better to write: o The IP source address is explicitly identified as appropriate for the physical topology; for example, the source address is appropriate for the layer 2 switch port through which the datagram was received 5. Section 4.1.1 changes in mid-section from checking the IP address against the Link Layer address to checking the IP address against the physical attachment point. Is Link Layer address checking ever implemented on switches or is it always IP address checking versus the physical attachment point? 6. I suggest augmenting section 4.1.3 with a mention of IPv6 prefix checking, where the PE can be populated with the customer prefix through monitoring DHCPv6 prefix delegation. Also, the enterprise case can be augmented with prefix filtering based on the prefixes known by the ISP to be assigned to the customer. 7. Sections 4.1.5 either needs more detail or pointers to references where more detail is available. In its current form, it has little or no content. The interesting parts of DOCSIS are the authentication and trust model, in which the ISP can control and trust the cable modem. 8. Section 4.1.6 has more detail than section 4.1.5, but assumes some experience with DSL deployments and architectures. Both of these sections would benefit from some explanation of the accountability model in which packets can be traced to an accountable entity, regardless of the specific address or prefix in the source address of a packet. 9. Section 188.8.131.52 might benefit from just a little more detail, or a pointer to more detail: switch uses IP address to port binding switch enforces restrictions that DHCP server traffic is only accepted from "upstream" switch monitors DHCP traffic to glean address-port bindings This technique works for both IPv4 and IPv6. And, the discussion of SLAAC brings up the issue of authenticated SAVI versus "ad hoc" SAVI. In the case of DHCP based SAVI, the switch can have authoritative information about the address/port binding, because it came from a reliable source (DHCP server). SLAAC-based SAVI can only identify claimed addresses, where the hose may not be authorized to use the claimed address. 10. Are the techniques mentioned in 4.2.4 really SAVI? 11. What is a "residual attack" and how does the text in section 4.2.5 describe a residual attack?
Comment (2011-05-25 for -)
1. Add DoS (yeah, I know DoS is pretty widely used already), "binding anchor" (and use "binding anchor" through the document), MITM, LAND, smurf attack, uRPF to section 2. Some of these also have first-use expansion, which might be OK ... this suggestion is just a Comment. 2. Suggestion: it would be more useful to incorporate any issues specific to IPv6 in the body of the document. 3. First sentence of section 4: The first requirement is to eliminate datagrams with spoofed IP addresses from the Internet. First requirement for what? I thought this document was exactly about "eliminat[ing] datagrams with spoofed IP addresses from the Internet." I suggest dropping the sentence. 4. At the end of section 4, the bullet list calls out "enterprise CPE Router" explicitly. Aren't residential CPE routers also a big opportunity? How are they different from enterprise CPE routers. In fact, perhaps "CPE" is not the best term? How about "Enterprise edge router" and add "subscriber home router"? 5. At the end of section 1, have the strength of your convictions: This document provides [...], and discusses [...]. 6. For consistency, in sections 3.2.1 and 4.1.1 s/MAC address/Layer 2 address/ 7. Is "source address verification" equivalent to "Source Address Validation Improvement (SAVI)"? If so, for consistency use one phrase or acronym throughout.
(Russ Housley) Discuss
Discuss (2011-05-24 for -)
The Gen-ART Review by David Black on 12-May-2011 lead to a discussion with one of the authors. At the end of the discussion, several changes to the document were agreed. However, those changes have not been made.
(Jari Arkko) Yes
The Gen-ART reviewer indicates that the earlier issues have been resolved, and I have myself performed a re-review comparing -10 to -05 that I had a long time ago sponsored... I'm glad that the document has now reached the situation where it can be approved.
(Stewart Bryant) Yes
Comment (2011-05-23 for -)
A useful document which I enjoyed reading
(Ted Lemon) Yes
Comment (2013-03-22 for -06)
I suggested the following changes to the authors, which they have agreed to: In section 184.108.40.206: OLD: When SLAAC is used for IPv address assignment, the switches can observe the SLAAC messages and use those to create the enforcement bindings. NEW: When SLAAC is used for IPv6 address assignment, the switches can observe the duplicate address detection messages and use those to create the enforcement bindings. In Section 8: OLD: Until every Internet-connected network implements source address validation at the ultimate network ingress, and assurances exist that intermediate devices are to never modify datagram source addresses, source addresses must not be used as an authentication mechanism. NEW: Even if every Internet-connected network implements source address validation at the ultimate network ingress, and assurances exist that intermediate devices are to never modify datagram source addresses, source addresses cannot be used as an authentication mechanism.
(Richard Barnes) No Objection
I support Stephen's DISCUSS on this document.
(Ron Bonica) No Objection
(Gonzalo Camarillo) No Objection
Benoit Claise No Objection
(Wesley Eddy) No Objection
Comment (2011-05-24 for -)
The document looks good, I just have a few comments that the authors might think about: Section 3.1.7 is titled "other blind spoofing attacks" but talks about non-blind attacks just as much. The example given of a host on-link with routers is non-blind, for instance. However, seciton 3.2 is where non-blind attacks are supposed to be discussed, so this part of 3.1.7 seems rather odd. Why isn't the relationship to SeND discussed in this document? VPN gateways have similar considerations as the Mobile IP HA in sectino 5.2.6, but VPN gateways don't appear to be discussed in 5.2.
(Adrian Farrel) No Objection
(Stephen Farrell) (was Discuss) No Objection
So two years later: Thanks for clearing my discuss points!
(Brian Haberman) No Objection
Comment (2013-04-09 for -07)
I have no issues with the publication of this document. The following are non-blocking points that I have derived from the document modulo the comments/issues raised by other ADs... * "At the IP Network Layer, or Internet Layer, there is typically no required transactional state when communicating..." just reads wrong to me. IP does not require transactional state, so why is "typically" thrown in there? Can you provide an example of where *IP* needs any state? * Section 3.2.1 describes a mechanism for performing on-link hijacking using ARP and then says "Similar vulnerabilities exist in IPv6 NDP". However, the ARP attack is effective mainly due to the use of broadcast messages. It would be good to take a few sentences to explain *how* the corresponding NDP attack would be carried out since broadcast messages are not used in IPv6 and the message validation & neighbor cache update rules defined in 4861. * Was there a reason why Section 4.2 does not describe some of the existing (albeit proprietary) solutions that have been widely deployed? For example, the Cisco Clean Access Agent is capable of doing some of this validation. Or was there a conscious decision to only focus on standardized solutions? * Section 220.127.116.11 says the following about IPv6 SLAAC-based addresses : "This enables the switches to ensure that only properly claimed IP addresses are used for data traffic". But, it can do more than that. If the switch is snooping NDP traffic, it can create MAC<->IPv6 mappings that allow the switch to drop packets that do not have the correct MAC/IP source address pairs. * Section 5.2.6 : Another possible option is that MIP Home Agents can act as an enforcement point prior to forwarding received traffic from mobile hosts.
(David Harrington) No Objection
Comment (2011-05-23 for -)
I found this document to be very informative about the problem space. I think this document could have been far more effective if the text didn't meander around the points it was trying to make; it could habve been far more succinct. Here are some suggestions that I think could improve the document. 1) I find the following ambiguous, "the operational staff needs to be able to track from the IP address sourcing the attack to the particular machine within the enterprise that is the source. " I think the intention is that "the IP address sourcing the attack" means the spoofed address, and "that is the source" means the actual sending machine, but I'm not sure. This can be read as "the staff needs to track from the source to the source." 2) This sentence doesn't parse properly, "This both that the information be useable ..." I think the sentence is missing "means" or "requires" or something. 3) The glossary should include references to the defining documents. 4) "or order to disrupt" -> "in order to disrupt" 5) 3.1.3 doesn't describe what a poison attack is. It also refers to "the same kinds of poisonings as above", but above never spoke of poisoning attacks. 6) the following seems a bit perverted logic - a malware attack is important because it is a justification for SAVI? "This attack is important both in terms of an attack vector that SAVI may help prevent, and also as a problem which SAVI can help track back to find infected systems. " Shouldn't you be arguing that savi is important for preventing these types of attacks? 7) section 3.2.2 "Another example of sighted attack" - this is the first mention of "sighted attack". Please use consistent terminology. 8) in section 3.2.2, "The use of spoofed addresses, while not necessary for this, can often provide additional information, and helps mask the traceability of the activity." would seem to be the conclusion of the paragraph, but this precedes the discussion of what the attack is. 9) in scetion 4, "the first requirement" isn't followed by any further requirements. and is this section going to describe the requirements or the solutions? 10) "The IP source address is appropriate for the lower layer address (they both identify the same system)". I find "is appropriate" too ambiguous, although the following parethetical text explains it. I suggest this would be better written as "the IP source address and the lower layer address both identify the same system." 11) "The IP source address is appropriate for the device at the layer 2 switch port" I find "is appropriate" too ambiguous. " (the address was assigned to a, and perhaps the, system that uses that port) " doesn't parse appropriately. I think this bullet needs a better description. 12) section 4.1.1 "Port identification prevents transmission of malicious datagrams" Is thistrue? or is port identification one method that can be used to help prevent transmission? 13) 4.1.3 "An obvious special case of the discussion is with an ISP PE router, " - what discussion? This section seems based on speculation about possible solutions, including contract negotiations. I think this would be much better if it actually focused on technical solutions for validating addresses for ISP edge routers. 14) 4.1.4 again discusses business agreements between two conpanies. Please focus on ***technical*** solutions at this topological location. 15) 4.1.4 "However, when it can be shown that spoofed addresses are present, the procedure can be applied. " what procedure? 16) 4.2.5 is entitled residual attacks, but there is no discussion of residual attacks in the paragraph. The hand-waving contained in the paragraph doesn't seem worth documenting. 17) why is 4.2.5, "residual attacks", included in section 4 "Current anti-spoofing solutions"? 18) 5.2.6 what does "proper member" mean? where is this defined? 19) 5.2.7 - doesn't this sum up the whole section 5? since it includes anything not covered in 5.1 or 5.2, shouldn't this be 5.3? 20) is 5.3 about topological challenges? it seems to meander on about additioonal capabilites, rather than discussing the topological challenge to SAVI.
(Joel Jaeggli) No Objection
(Barry Leiba) No Objection
Comment (2013-04-03 for -07)
I enjoyed reading this document: I found it well written, informative, and interesting. I have only a few non-blocking comments, all editorial, mostly at nit level. -- Section 3.1.1 -- Another form of blind attack is a RST probe [RFC0793]. Forgive me, please: this is a general peeve of mine, and I'm applying it here. OK, so I go to RFC 793. I search for "RST probe". Guess what: I don't find it. RFC 793 is 85 pages, and I have *no idea* where in RFC 793 you're trying to send me with that citation. If this needs a citation at all, it needs one that will help. This one doesn't help. Can you please do better (refer to a section number, or use a reference phrase that I *can* find in a search of the cited document)? [I'll leave off the discussion of whether it's pronounced "an R-S-T probe" or "a Reset probe". :-) ] -- Section 3.2.2 -- Use of "sighted attack" as a synonym for "non-blind attack" might not work so well with non-native English readers, and could also invite confusion with "sited attack" (which might refer to an attack that's tied to a particular network site). Probably best to avoid it, especially as this is the only place it's used. -- Section 4.2.3 -- However, establishing this binding is not trivial, and varying across both topologies type and address allocation mechanisms. There's a part-of-speech problem here. Maybe you want "varies", rather than "varying"? Or some other rewrite, because "topologies type" doesn't work either. -- Section 4.2.4 -- Another pet peeve of mine (I have quite a menagerie): the phrase "needless to say" is pretty much always silly. If it really doesn't need to be said, don't say it. But, in fact, what's *really* needless to say is "needless to say". Need I say more? -- Section 5.2 -- This paragraph is troubled: one very long sentence with severe commatosis (some extra, some misplaced, and some actually missing). May I presume to offer a re-write?: NEW From the perspective of network topology, consider hosts connected to switch ports that may have one or more IP addresses, and devices that forward packets from other network segments: it is much harder to enforce port-MAC-IP bindings on traffic from such hosts and devices. END And then think about the "much harder" bit: much harder than what? What's the antecedent here? Or is it sufficient just to say "hard" or "difficult"? -- Section 5.2.1 -- The most obvious example of devices that are problematic when attempting to implement port-MAC-IP bindings is that of routers. The "that of" is wrong, but, really, the sentence is upside-down (the subject is at the end). How about this?: NEW Routers are the most obvious examples of devices for which it is problematic to implement port-MAC-IP bindings. END -- Section 5.2.2 -- Another difficult paragraph, with a few grammatical problems. Maybe (also eliminating the Latin): NEW Validating traffic from Prefix-based and multi-address NATs is also problematic, for the same reasons as for routers. Because they may forward traffic from an array of addresses, validation requires advance knowledge of what IPs should be associated with a given port-MAC pair. END -- Section 5.2.3 -- While tractable, this creates some complexity for determining where enforcement logic can or should live. I don't think "tractable" is the word you want here: I think "tractable" has a connotation of ease of manipulation -- it refers to something that's *easily* done. The sense I get from what you're saying is that it can be done, but it's *not* easy. Perhaps "feasible" (or even "possible") works better here. Logically distinct hosts such as are provided by many varieties of virtualization logic result in a single physical host, connect to a single port on the Ethernet switch in the topology, actually having multiple internal virtual machines, each with IP and MAC addresses, and what is essentially (or sometimes literally) an internal LAN switch. There are missing commas in the beginning of this (before "such as" and before "result"), and then far too many comma-separated clauses in one too-long sentence. I suggest that you re-word this, and try to split it into two sentences. -- Section 7 -- No action here, but I have to give you the award for the longest "empty" IANA Considerations section ever.
(Pete Resnick) No Objection
(Dan Romascanu) No Objection
Comment (2011-05-25 for -)
I find the document comprehensive but I share DBH's observation that it's a little too verbose and could use some fixes in the details. Beyond what he found I have a few more observations. None is critical for this informational document, but cleaning up all these text unclarities in a new version would be recommended; 1. In the Glossary section NNI Router: Network to Network Interface Router. This router interface faces a similar system operated by another ISP or other large network. I think that the definition should read something like 'A router with interfaces facing a similar system ...' 2. Section 18.104.22.168 IEEE 802.1x is an authentication protocol that permits a network to determine the identity of a system seeking to join it and apply authorization rules to permit or deny the action. In and of themselves, such tools confirm only that the user is authorized to use the network, but do not enforce what IP address the user is allowed to use. It is worth noting that elements of 802.1x may well be useful as binding anchors for SAVI solutions. This is quite confusing. IEEE 802.1X is a port (in the sense of bridge or layer 2 switch) access control standard that controls the joining of devices to a layer 2 bridged network. The term 'tools' is not in place and there is nothing about the 'user' in the protocol itself but about the device - the standard uses the term 'supplicant' which is rather the device or the piece of software running on the device that presents credentials to an authenticator. 3. In section 5.2 'hosts connected to switch ports that may have one or more IP addresses' is probably rather 'hosts that may have one or more IP addresses connected to (layer 2) switch ports'
(Peter Saint-Andre) No Objection
Comment (2011-05-23 for -)
Please expand "DoS" on first use and add an informational reference to RFC 4732.
(Robert Sparks) No Objection
(Martin Stiemerling) No Objection
(Sean Turner) No Objection
Well written! I'm putting this first one in as a comment based on the 1st sentence in the security considerations where you say you're not doing a comprehensive threat analysis: 1) It'd be really good to characterize the attacker somewhere early in the document. s4.1.7 indicates that it's not clear that providing spoofing protection among the devices within a "residence" is needed because of a lack of threat. If it was a business residence (e.g., hotspot or whatever in a coffee shop) does this still hold true? 2) And now for some nits: s1: traffic To do/traffic. To do s3.1.3: r/poisoning attacks are attacks aimed at/poisoning attacks are aimed at s3.2.2: Isn't Third Party Recon really traffic analysis? s4: r/For example, With these/For example, with these s4.3.2: r/for IPv address/for IPv6 address These are based on Dan's comments on -05 (I think that's the right version). He's right that 802.1x is about supplicants/devices. yeah users use them, but ... s22.214.171.124: r/user/device or supplicant which is term they use s126.96.36.199: r/tools confirm/this mechanism confirms s188.8.131.52: r/use the network/access the network s184.108.40.206: r/the user/the device/supplicant We should really have a security consideration about whether smurf attacks are worse than the zombie apocalypse and what we should do to mitigate our risk if they happened at the same time.