Skip to main content

Source Address Validation Improvement (SAVI) Threat Scope



No Objection

(Adrian Farrel)
(Benoît Claise)
(Gonzalo Camarillo)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Robert Sparks)
(Ron Bonica)

Note: This ballot was opened for revision 05 and is now closed.

Ralph Droms Former IESG member
Discuss [Treat as non-blocking comment] (2011-05-25)
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
a packet.

9. Section 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?
Russ Housley Former IESG member
Discuss [Treat as non-blocking comment] (2011-05-24)
  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 Former IESG member
Yes (2013-04-11)
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 Former IESG member
Yes (2011-05-23)
A useful document which I enjoyed reading
Ted Lemon Former IESG member
Yes (2013-03-22 for -06)
I suggested the following changes to the authors, which they have agreed to: 

In section 

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 
enforcement bindings. 

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.
Adrian Farrel Former IESG member
No Objection
No Objection ()

Barry Leiba Former IESG member
No Objection
No Objection (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?:

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

-- Section 7 --
No action here, but I have to give you the award for the longest "empty" IANA Considerations section ever.
Benoît Claise Former IESG member
No Objection
No Objection ()

Brian Haberman Former IESG member
No Objection
No Objection (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 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.
Dan Romascanu Former IESG member
No Objection
No Objection (2011-05-25)
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

   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'
David Harrington Former IESG member
No Objection
No Objection (2011-05-23)
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.
Gonzalo Camarillo Former IESG member
No Objection
No Objection ()

Joel Jaeggli Former IESG member
No Objection
No Objection ()

Martin Stiemerling Former IESG member
No Objection
No Objection (for -07)

Pete Resnick Former IESG member
No Objection
No Objection ()

Peter Saint-Andre Former IESG member
No Objection
No Objection (2011-05-23)
Please expand "DoS" on first use and add an informational reference to RFC 4732.
Richard Barnes Former IESG member
No Objection
No Objection (2013-04-09)
I support Stephen's DISCUSS on this document.
Robert Sparks Former IESG member
No Objection
No Objection ()

Ron Bonica Former IESG member
No Objection
No Objection ()

Sean Turner Former IESG member
No Objection
No Objection (2013-04-11)
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.
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2013-04-11)
So two years later: Thanks for clearing my discuss points!
Wesley Eddy Former IESG member
No Objection
No Objection (2011-05-24)
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.