Note: This ballot was opened for revision 05 and is now closed.
Summary: Has enough positions to pass.
I enjoyed reading this document: I found it well written, informative, and
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
-- 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
-- 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
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.
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?:
Routers are the most obvious examples of devices for which it is
problematic to implement port-MAC-IP bindings.
-- Section 5.2.2 --
Another difficult paragraph, with a few grammatical problems. Maybe (also
eliminating the Latin):
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.
-- Section 5.2.3 --
While tractable, this creates some
complexity for determining where enforcement logic can or should
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
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
-- 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 22.214.171.124 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.
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.
I support Stephen's DISCUSS on this document.
So two years later: Thanks for clearing my discuss points!
I suggested the following changes to the authors, which they have agreed to:
In section 126.96.36.199:
When SLAAC is used for IPv address assignment, the switches can
observe the SLAAC messages and use those to create the enforcement
When SLAAC is used for IPv6 address assignment, the switches can
observe the duplicate address detection messages and use those to create the
In Section 8:
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.
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.
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
I think that the definition should read something like 'A router with
interfaces facing a similar system ...'
2. Section 188.8.131.52
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 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
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
"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
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
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
9. Section 184.108.40.206 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?
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.
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.
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
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
... s220.127.116.11: r/user/device or supplicant which is term they use s18.104.22.168:
r/tools confirm/this mechanism confirms s22.214.171.124: r/use the network/access the
network s126.96.36.199: 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.
A useful document which I enjoyed reading
The document looks good, I just have a few comments that the authors might
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.