Source Address Validation Improvement (SAVI) Threat Scope
draft-ietf-savi-threat-scope-08

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.

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 4.2.3.2 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.

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 4.2.3.3

   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'

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.

Please expand "DoS" on first use and add an informational reference to RFC 4732.

I support Stephen's DISCUSS on this document.

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 ...
s4.2.3.3: r/user/device or supplicant which is term they use
s4.2.3.3: r/tools confirm/this mechanism confirms
s4.2.3.3: r/use the network/access the network
s4.2.3.3: 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.

So two years later: Thanks for clearing my discuss points!

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.