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

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
I had a huge discuss on this back in 2011. Since I've lost
most of the state, (apologies for that), I've re-reviewed
this starting from my old discuss points and the delta from
-05 to -07. If there are things that were resolved via mail
2 years ago, please do point me at the mail so we can clear
those points quickly. (The discuss is alreayd only about
half as long, so we are getting there:-)

A note on discuss-worthiness of these points: I think that
SAVI has clear downsides in terms of its potential for
worsening privacy problems, so I think its important that
this document very accurately characterise what SAVI can
and cannot do, since otherwise SAVI standards documents are
liable to stray too far towards privacy intrusive features
even if those may not be very effective in countering
threats resulting from source address spoofing.

(1) Intro, 3rd para: What is the evidence that "Source
address verification is necessary in order to detect and
reject spoofed packets"? I'm asking why this is
"necessary" as opposed to sufficient. I'd suggest "Source
address validation allows for detection and rejection..."

(2) p4, 1st para: Where in the SAVI charter is "local
traceability" in scope? The concern is that SAVI mechanisms
could be (and probably will be) used for tracking users,
but tracking users is not in scope for the WG and touches
on RFC 2804. I'd suggest just deleting the phrase or
maybe defining it so its limited to tracing attacks.

(3) Spoofing is defined on p5 to cover both IP and MAC
address spoofing.  SAVI does not address the latter I
believe (right?). If so, then I think best is to limit
the term when used here to refer to IP address spoofing
and exclude MAC address spoofing. If you don't do that,
then I suspect many of your uses of the term won't be
correct.

(4) Does the ARP example in 3.2.1 really involve a spoofed
IP source? I think this isn't correct - if an IP address is
spoofed here its not a "source IP address" meaning that
field in an IP packet but the spoofing rather occurs a
field within the payload of the ARP message. (Or am I
mis-remembering?) So if SAVI devices were to help here,
they'd need to also be watching specifically for this kind
of threat to be countered, which seems odd - will SAVI also
watch to check if SIP messages used spoofed IP addresses in
their payloads?  I'm also not sure this fits with your
definition of spoofing. Clarifying that this kind of attack
isn't countered by SAVI would be good. More generally, it'd
be good to say somewhere which parts of sections 3 and 4
are really things where SAVI can help.

(5) cleared

(6) cleared

(7) cleared

(8) cleared

(9) Section 6: "If address usage can be tied to the kinds
of anchors described earlier, then it is possible to
respond to security incidents." SAVI is not needed for
responding to all incidents. Maybe say SAVI can help and
not say that its absolutely needed.

(10) cleared

(11) If binding anchors are personally identifying or
stable over time or location then recording those create
new possibilities for tracking the user or host associated
with the binding anchor. That needs to be noted, but is not
(I mean the persistence issue). I think you need to add
guidance that introducing SAVI creates this kind of threat,
but that frequently deleting bindings might be a good
mitigation, or this might be a reason to want to have some
form of more dynamic binding anchor.

[Ballot discuss]
I had a huge discuss on this back in 2011. Since I've lost
most of the state, (apologies for that), I've re-reviewed
this starting from my old discuss points and the delta from
-05 to -07. If there are things that were resolved via mail
2 years ago, please do point me at the mail so we can clear
those points quickly. (The discuss is alreayd only about
half as long, so we are getting there:-)

A note on discuss-worthiness of these points: I think that
SAVI has clear downsides in terms of its potential for
worsening privacy problems, so I think its important that
this document very accurately characterise what SAVI can
and cannot do, since otherwise SAVI standards documents are
liable to stray too far towards privacy intrusive features
even if those may not be very effective in countering
threats resulting from source address spoofing.

(1) Intro, 3rd para: What is the evidence that "Source
address verification is necessary in order to detect and
reject spoofed packets"? I'm asking why this is
"necessary" as opposed to sufficient. I'd suggest "Source
address validation allows for detection and rejection..."

(2) p4, 1st para: Where in the SAVI charter is "local
traceability" in scope? The concern is that SAVI mechanisms
could be (and probably will be) used for tracking users,
but tracking users is not in scope for the WG and touches
on RFC 2804. I'd suggest just deleting the phrase or
maybe defining it so its limited to tracing attacks.

(3) Spoofing is defined on p5 to cover both IP and MAC
address spoofing.  SAVI does not address the latter I
believe (right?). If so, then I think best is to limit
the term when used here to refer to IP address spoofing
and exclude MAC address spoofing. If you don't do that,
then I suspect many of your uses of the term won't be
correct.

(4) Does the ARP example in 3.2.1 really involve a spoofed
IP source? I think this isn't correct - if an IP address is
spoofed here its not a "source IP address" meaning that
field in an IP packet but the spoofing rather occurs a
field within the payload of the ARP message. (Or am I
mis-remembering?) So if SAVI devices were to help here,
they'd need to also be watching specifically for this kind
of threat to be countered, which seems odd - will SAVI also
watch to check if SIP messages used spoofed IP addresses in
their payloads?  I'm also not sure this fits with your
definition of spoofing. Clarifying that this kind of attack
isn't countered by SAVI would be good. More generally, it'd
be good to say somewhere which parts of sections 3 and 4
are really things where SAVI can help.

(5) cleared

(6) 4.2.3.2 says that "filtering policies" mean DHCP
replies can be authoritative. I think that has to depend
on the port at which the DHCP reply is first seen, since
anyone can (try) send out DHCP replies.

(7) cleared

(8) cleared

(9) Section 6: "If address usage can be tied to the kinds
of anchors described earlier, then it is possible to
respond to security incidents." SAVI is not needed for
responding to all incidents. Maybe say SAVI can help and
not say that its absolutely needed.

(10) If no set of deployed SAVI instances can prevent all
spoofing from a given network then an attacker could probe
the network to find out what spoofing works from where they
are at, and then use that approach. Success in spoofing
would then likely have more consequences for an innocent
spoofed party. This seems like a new threat caused by SAVI
itself that needs to be noted.

(11) If binding anchors are personally identifying or
stable over time or location then recording those create
new possibilities for tracking the user or host associated
with the binding anchor. That needs to be noted, but is not
(I mean the persistence issue). I think you need to add
guidance that introducing SAVI creates this kind of threat,
but that frequently deleting bindings might be a good
mitigation, or this might be a reason to want to have some
form of more dynamic binding anchor.

[Ballot comment]
3.1.1: Expand "LAND"

-- formerly discuss points now coments...

(5) 4.2.3: What does "unchangeable or authenticated MAC
address" mean in 4.2.3? Practically, MAC addresses are
neither of those. Some MACs can be registered e.g. with a
DHCP server but I think that's different from
authentication - all that's done there is the DHCP server
will accept any of the MACs it knows about and reject
ones it doesn't know, which is not the same as
authenticating a MAC address. (Just cleared)

(7)  Section 6 seems to be overstated and problematic in a
few ways. First, where is traceability in scope for the
SAVI charter? If you want to define traceability as being
the abillity to help trace attacks but not the ability to
track users over time, then that might help. (Handle
this as part of discuss point 2)

(8) 1st para of section 6 admits the imperfection of SAVI
yet the 2nd last para claims benefits that seem to be based
on the perfection of SAVI. That seems like a contradiction.
BTW, as a comment
it'd be good to delete the phrase "or at least to track even those
attacks back to their source." Given SAVI only applies to LANs
SAVI is only really helping at the end of the tracking back
process.

[Ballot discuss]

I had a huge discuss on this back in 2011. Since I've lost
most of the state, (apologies for that), I've re-reviewed
this starting from my old discuss points and the delta from
-05 to -07. If there are things that were resolved via mail
2 years ago, please do point me at the mail so we can clear
those points quickly. (The discuss is alreayd only about
half as long, so we are getting there:-)

A note on discuss-worthiness of these points: I think that
SAVI has clear downsides in terms of its potential for
worsening privacy problems, so I think its important that
this document very accurately characterise what SAVI can
and cannot do, since otherwise SAVI standards documents are
liable to stray too far towards privacy intrusive features
even if those may not be very effective in countering
threats resulting from source address spoofing.

(1) Intro, 3rd para: What is the evidence that "Source
address verification is necessary in order to detect and
reject spoofed packets"? I'm asking why this is
"necessary" as opposed to sufficient. I'd suggest "Source
address validation allows for detection and rejection..."

(2) p4, 1st para: Where in the SAVI charter is "local
traceability" in scope? The concern is that SAVI mechanisms
could be (and probably will be) used for tracking users,
but tracking users is not in scope for the WG and touches
on RFC 2804. I'd suggest just deleting the phrase or
maybe defining it so its limited to tracing attacks.

(3) Spoofing is defined on p5 to cover both IP and MAC
address spoofing.  SAVI does not address the latter I
believe (right?). If so, then I think best is to limit
the term when used here to refer to IP address spoofing
and exclude MAC address spoofing. If you don't do that,
then I suspect many of your uses of the term won't be
correct.

(4) Does the ARP example in 3.2.1 really involve a spoofed
IP source? I think this isn't correct - if an IP address is
spoofed here its not a "source IP address" meaning that
field in an IP packet but the spoofing rather occurs a
field within the payload of the ARP message. (Or am I
mis-remembering?) So if SAVI devices were to help here,
they'd need to also be watching specifically for this kind
of threat to be countered, which seems odd - will SAVI also
watch to check if SIP messages used spoofed IP addresses in
their payloads?  I'm also not sure this fits with your
definition of spoofing. Clarifying that this kind of attack
isn't countered by SAVI would be good. More generally, it'd
be good to say somewhere which parts of sections 3 and 4
are really things where SAVI can help.

(5) 4.2.3: What does "unchangeable or authenticated MAC
address" mean in 4.2.3? Practically, MAC addresses are
neither of those. Some MACs can be registered e.g. with a
DHCP server but I think that's different from
authentication - all that's done there is the DHCP server
will accept any of the MACs it knows about and reject
ones it doesn't know, which is not the same as
authenticating a MAC address.

(6) 4.2.3.2 says that "filtering policies" mean DHCP
replies can be authoritative. I think that has to depend
on the port at which the DHCP reply is first seen, since
anyone can (try) send out DHCP replies.

(7) Section 6 seems to be overstated and problematic in a
few ways. First, where is traceability in scope for the
SAVI charter? If you want to define traceability as being
the abillity to help trace attacks but not the ability to
track users over time, then that might help.

(8) 1st para of section 6 admits the imperfection of SAVI
yet the 2nd last para claims benefits that seem to be based
on the perfection of SAVI. That seems like a contradiction.

(9) Section 6: "If address usage can be tied to the kinds
of anchors described earlier, then it is possible to
respond to security incidents." SAVI is not needed for
responding to all incidents. Maybe say SAVI can help and
not say that its absolutely needed.

(10) If no set of deployed SAVI instances can prevent all
spoofing from a given network then an attacker could probe
the network to find out what spoofing works from where they
are at, and then use that approach. Success in spoofing
would then likely have more consequences for an innocent
spoofed party. This seems like a new threat caused by SAVI
itself that needs to be noted.

(11) If binding anchors are personally identifying or
stable over time or location then recording those create
new possibilities for tracking the user or host associated
with the binding anchor. That needs to be noted, but is not
(I mean the persistence issue). I think you need to add
guidance that introducing SAVI creates this kind of threat,
but that frequently deleting bindings might be a good
mitigation, or this might be a reason to want to have some
form of more dynamic binding anchor.

[Ballot comment]
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.

[Ballot comment]
I suggested the following changes to the authors, which they have agreed to:

In section 4.2.3.2:

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.

Actually, this document didn't go back to the working group, and the changes are only in response to IESG review, so I don't think it needs a new last call.

This document looks solid, and is ready for last call.  The document has been through IESG review once before and has been substantially edited to address concerns raised during that review.

I suggested the following changes to the authors, which they have agreed to:

In section 4.2.3.2:

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

[Ballot discuss]
I'm modifying a part (#3) of this discuss as a result of Jari clarifying
that I had been misinterpreting the charter text that said "Tracking other
protocols is not within the scope of the WG." I interpreted that to
mean "Tracking other protocols using SAVI data is not within the
scope of the WG" but as Jari makes clear the intent was actually
"Tracking other protocols to generate SAVI data is not within the
scope of the WG." This means that my discuss point about local
traceability being out of scope is weakened somewhat, but the
question does however remain since that is not actually called out
as being within scope.

I've also renumbered the points below to get rid of a duplicated
#3 - what was the 1st #2 is now #1a.

(1) What's the difference between "validation" (abstract) and
"verification" (overview, 3rd para) as used here?  If there is
none, then just use one. If this is a difference, then where are
these defined?  I think in either case, some definition is needed.

(1a) What is the evidence that "Source address verification is
necessary in order to detect and reject spoofed packets"? I'm
asking why this is "necessary"as opposed to sufficient (if it is
sufficient - see (2) above).

(2) This presumably needs some form of qualification if not all
packets with spoofed source addresses can be spotted: "source
address verification techniques enable detection and rejection of
spoofed packets." I'm not sure if "some spoofed packets" would be a
good thing to say there but it does seem to be the case - a better
qualification (or a forward reference to where that is described)
would represent truth-in-advertising.

(3) Where in the charter is "local traceability" in scope?

(4) "For example, when an enterprise receives a report of an attack
originating within that enterprise, 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
don't think that's true in general - "needs" is wrong since there
can be other ways to find a zombie.

(5) Spoofing is defined to cover both IP and MAC address spoofing.
SAVI does not address the latter I believe (right?). If so, then I
think you need to separate these as otherwise confusion between
them might lead to incorrect conclusions being stated. Spoofing is
also defined as "forging" but that is not defined and could be
considered to be synonymous with "spoofing" here which would make
this a circular definition. I think the definition of spoofing
needs to be more precise basically.

(6) 3.1: " The result is that they have no access to legitimate
source and target systems." I think that's wrong - are you trying
to say that "The attacker in this case should have no legitimate
access to source and target systems."

(7) Does the ARP example in 3.2.1 really involve a spoofed IP
source?  If not, then you should note that its not in scope for
SAVI. If it is, then say why its in scope.

(8) I'd be interested in knowing if SAVI can help with 3.2.2 - if
not then saying so would be right. If so, then saying when SAVI
might help would be good.

(9) If "The first requirement is to eliminate datagrams with
spoofed IP addresses from the Internet." then SAVI would seem to be
facing an impossible problem. The "can eliminate such datagrams"
part also seems overstated - where's the evidence that that's true?
s/eliminate/reduce/ would seem to be more correct.

(10) Saying that "Internet devices can...confirm...that the IP
address is appropriate for the lower layer address" is not true of
all "Internet devices" only for some near the source, so that's
also overstated and needs to be qualified. (It is later to be fair
but the statement itself is wrong.)

(11) I don't know the answer here, so this is just a question -
what is the likelihood the uRPF check works well? (I didn't find
the string uRPF in RFC 3704, so I'm not sure, but I didn't really
read 3704;-) I guess the real question is whether a failure in uRPF
might break anything for a non-spoofing host and whether a spoofing
host could make it so that uRPF checks allow the packet with a
spoofed address through (from e.g. the same subnet, or for certain
guessable source addresses). I ask (in part) since 4.2.2 says that
uRPF is a crude mechanism.

(12) I'm not sure whether 4.1.3 and 4.1.4 are in or out of scope
for SAVI.  Can you make that clear?

(13) What does "unforgeable" mean in 4.2.3? Perhaps you need to
define that term as well? It may be that the meaning differs for
e.g. MAC addresses and other credentials (noting that passwords can
be guessed or shared of course).

(14) In 4.2.3 where is the evidence that "a large portion of the
...threat space...can be marginalized" - I think that needs some
qualification.

(15) 4.2.3.2 says that DHCP and sniffing "can...auotmatically
provide sufficient binding information" - is there evidence for
that somewhere?  Be good to reference it.

(16) 802.1X determines the identity of a user, not a system I
think.

(18) Section 6 (at least) should also recognise that there are
privacy considerations that apply and that more-or-less directly
run counter to the ability to trace the source of problems.

(19) Section 8 should note that circumstantial evidence linking a
person to an IP address can be dangerous for the person. There have
been cases where such tracking has mis-identified people
responsible for some act. (I don't have a reference to hand sorry.)

(20) If no set of deployed SAVI instances can prevent all spoofing
from a given network then an attacker could probe the network to
find out what spoofing works from where they are at, and then use
that. Success in spoofing would then likely have more consequences
for an innocent spoofed party. This would be a new threat caused by
SAVI itself.

(21) If binding anchors are personally identifying or stable over
time or location then recording those creates new threats for tracking
the user or host associated with the binding anchor. That needs to
be noted.

[Ballot comment]
(1) 2nd para of overview says that there is "typically no required
transactional state when communicating with other hosts on the
network." I think it'd be good to say why that's the case, via a
reference to something.  (Not sure what reference is best exactly.)

(2) What is a "better Internet participant"? It sounds like a scary
thing.

(3) s/This both that the information be useable/This requires both
that the information be useable/

(4) I expected to see some CVE references in section 3 but didn't
see any. I'd encourage adding some of those for each of the threats
covered since that should help motivate the work and would
demonstrate that there are real threats to mitigate. (E.g. a quick
search on "CVE spoofed source" throws up a bunch.) To take one
example, 3.1.4 could do with such a reference.

(5) Expand "LAND"

(6) The DNS attack described around the top of page 9 isn't
relevant to SAVI, right? Maybe the smurf attack is enough there.

(7) Do 3.1.6 and 3.1.7 really fit in 3.1?

(8) Do *all* CMTS employ DOCSIS? 4.1.5 says that they do.

(9) Even IPsec doesn't unquestionably verify source address if
load-balancing is in place with private key sharing.

----- Text below is cut'n'paste from what was DISCUSS text just to help keep track

(2) I expected this document to also analyse source-address
spoofing threats after SAVI mechanisms are deployed. If some simple
form(s) of source address spoofing will work regardless of which
SAVI mechanism(s) are in place then one would have to wonder if
SAVI is worth deploying or not. If this is not the right document
to cover that then what is? The fact that the SAVI mechanisms will
each be in separate documents would seem to mean that this question
won't otherwise be answered by the WG, and I think we do need an
answer somewhere.  (The security considerations of the SAVI
framework is currently one paragraph so that's not the place, at
least not now.) Its probably worth noting that this issue is behind
a number of cases below where I ask for evidence to justify what
appear to be overly broad claims made.

    = The residual threats for SAVI generally will be considered
        in draft-ietf-savi-mix later on

(17) I think 4.2.5 needs to better characterise the "residual
threat" (not "residual attack") - for each of the various forms of
SAVI. I had hoped this document would say what spoofing
possibilities remain.  Providing just one example doesn't seem
sufficient.

    = Same as for discuss point (2) above.

[Ballot discuss]
(1) What's the difference between "validation" (abstract) and
"verification" (overview, 3rd para) as used here?  If there is
none, then just use one. If this is a difference, then where are
these defined?  I think in either case, some definition is needed.

(3) What is the evidence that "Source address verification is
necessary in order to detect and reject spoofed packets"? I'm
asking why this is "necessary"as opposed to sufficient (if it is
sufficient - see (2) above).

(2) This presumably needs some form of qualification if not all
packets with spoofed source addresses can be spotted: "source
address verification techniques enable detection and rejection of
spoofed packets." I'm not sure if "some spoofed packets" would be a
good thing to say there but it does seem to be the case - a better
qualification (or a forward reference to where that is described)
would represent truth-in-advertising.

(3) Where in the charter is "local traceability" in scope? The
charter does say that "tracking other protocols is not in scope" so
local traceability needs to be defined as something limited
to/scoped to spoofed source addresses.

(4) "For example, when an enterprise receives a report of an attack
originating within that enterprise, 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
don't think that's true in general - "needs" is wrong since there
can be other ways to find a zombie.

(5) Spoofing is defined to cover both IP and MAC address spoofing.
SAVI does not address the latter I believe (right?). If so, then I
think you need to separate these as otherwise confusion between
them might lead to incorrect conclusions being stated. Spoofing is
also defined as "forging" but that is not defined and could be
considered to be synonymous with "spoofing" here which would make
this a circular definition. I think the definition of spoofing
needs to be more precise basically.

(6) 3.1: " The result is that they have no access to legitimate
source and target systems." I think that's wrong - are you trying
to say that "The attacker in this case should have no legitimate
access to source and target systems."

(7) Does the ARP example in 3.2.1 really involve a spoofed IP
source?  If not, then you should note that its not in scope for
SAVI. If it is, then say why its in scope.

(8) I'd be interested in knowing if SAVI can help with 3.2.2 - if
not then saying so would be right. If so, then saying when SAVI
might help would be good.

(9) If "The first requirement is to eliminate datagrams with
spoofed IP addresses from the Internet." then SAVI would seem to be
facing an impossible problem. The "can eliminate such datagrams"
part also seems overstated - where's the evidence that that's true?
s/eliminate/reduce/ would seem to be more correct.

(10) Saying that "Internet devices can...confirm...that the IP
address is appropriate for the lower layer address" is not true of
all "Internet devices" only for some near the source, so that's
also overstated and needs to be qualified. (It is later to be fair
but the statement itself is wrong.)

(11) I don't know the answer here, so this is just a question -
what is the likelihood the uRPF check works well? (I didn't find
the string uRPF in RFC 3704, so I'm not sure, but I didn't really
read 3704;-) I guess the real question is whether a failure in uRPF
might break anything for a non-spoofing host and whether a spoofing
host could make it so that uRPF checks allow the packet with a
spoofed address through (from e.g. the same subnet, or for certain
guessable source addresses). I ask (in part) since 4.2.2 says that
uRPF is a crude mechanism.

(12) I'm not sure whether 4.1.3 and 4.1.4 are in or out of scope
for SAVI.  Can you make that clear?

(13) What does "unforgeable" mean in 4.2.3? Perhaps you need to
define that term as well? It may be that the meaning differs for
e.g. MAC addresses and other credentials (noting that passwords can
be guessed or shared of course).

(14) In 4.2.3 where is the evidence that "a large portion of the
...threat space...can be marginalized" - I think that needs some
qualification.

(15) 4.2.3.2 says that DHCP and sniffing "can...auotmatically
provide sufficient binding information" - is there evidence for
that somewhere?  Be good to reference it.

(16) 802.1X determines the identity of a user, not a system I
think.

(18) Section 6 (at least) should also recognise that there are
privacy considerations that apply and that more-or-less directly
run counter to the ability to trace the source of problems.

(19) Section 8 should note that circumstantial evidence linking a
person to an IP address can be dangerous for the person. There have
been cases where such tracking has mis-identified people
responsible for some act. (I don't have a reference to hand sorry.)

(20) If no set of deployed SAVI instances can prevent all spoofing
from a given network then an attacker could probe the network to
find out what spoofing works from where they are at, and then use
that. Success in spoofing would then likely have more consequences
for an innocent spoofed party. This would be a new threat caused by
SAVI itself.

(21) If binding anchors are personally identifying or stable over
time or location then recording those creates new threats for tracking
the user or host associated with the binding anchor. That needs to
be noted.

[Ballot comment]
(1) 2nd para of overview says that there is "typically no required
transactional state when communicating with other hosts on the
network." I think it'd be good to say why that's the case, via a
reference to something.  (Not sure what reference is best exactly.)

(2) What is a "better Internet participant"? It sounds like a scary
thing.

(3) s/This both that the information be useable/This requires both
that the information be useable/

(4) I expected to see some CVE references in section 3 but didn't
see any. I'd encourage adding some of those for each of the threats
covered since that should help motivate the work and would
demonstrate that there are real threats to mitigate. (E.g. a quick
search on "CVE spoofed source" throws up a bunch.) To take one
example, 3.1.4 could do with such a reference.

(5) Expand "LAND"

(6) The DNS attack described around the top of page 9 isn't
relevant to SAVI, right? Maybe the smurf attack is enough there.

(7) Do 3.1.6 and 3.1.7 really fit in 3.1?

(8) Do *all* CMTS employ DOCSIS? 4.1.5 says that they do.

(9) Even IPsec doesn't unquestionably verify source address if
load-balancing is in place with private key sharing.

[Ballot discuss]
(1) What's the difference between "validation" (abstract) and
"verification" (overview, 3rd para) as used here?  If there is
none, then just use one. If this is a difference, then where are
these defined?  I think in either case, some definition is needed.

(2) I expected this document to also analyse source-address
spoofing threats after SAVI mechanisms are deployed. If some simple
form(s) of source address spoofing will work regardless of which
SAVI mechanism(s) are in place then one would have to wonder if
SAVI is worth deploying or not. If this is not the right document
to cover that then what is? The fact that the SAVI mechanisms will
each be in separate documents would seem to mean that this question
won't otherwise be answered by the WG, and I think we do need an
answer somewhere.  (The security considerations of the SAVI
framework is currently one paragraph so that's not the place, at
least not now.) Its probably worth noting that this issue is behind
a number of cases below where I ask for evidence to justify what
appear to be overly broad claims made.

(3) What is the evidence that "Source address verification is
necessary in order to detect and reject spoofed packets"? I'm
asking why this is "necessary"as opposed to sufficient (if it is
sufficient - see (2) above).

(2) This presumably needs some form of qualification if not all
packets with spoofed source addresses can be spotted: "source
address verification techniques enable detection and rejection of
spoofed packets." I'm not sure if "some spoofed packets" would be a
good thing to say there but it does seem to be the case - a better
qualification (or a forward reference to where that is described)
would represent truth-in-advertising.

(3) Where in the charter is "local traceability" in scope? The
charter does say that "tracking other protocols is not in scope" so
local traceability needs to be defined as something limited
to/scoped to spoofed source addresses.

(4) "For example, when an enterprise receives a report of an attack
originating within that enterprise, 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
don't think that's true in general - "needs" is wrong since there
can be other ways to find a zombie.

(5) Spoofing is defined to cover both IP and MAC address spoofing.
SAVI does not address the latter I believe (right?). If so, then I
think you need to separate these as otherwise confusion between
them might lead to incorrect conclusions being stated. Spoofing is
also defined as "forging" but that is not defined and could be
considered to be synonymous with "spoofing" here which would make
this a circular definition. I think the definition of spoofing
needs to be more precise basically.

(6) 3.1: " The result is that they have no access to legitimate
source and target systems." I think that's wrong - are you trying
to say that "The attacker in this case should have no legitimate
access to source and target systems."

(7) Does the ARP example in 3.2.1 really involve a spoofed IP
source?  If not, then you should note that its not in scope for
SAVI. If it is, then say why its in scope.

(8) I'd be interested in knowing if SAVI can help with 3.2.2 - if
not then saying so would be right. If so, then saying when SAVI
might help would be good.

(9) If "The first requirement is to eliminate datagrams with
spoofed IP addresses from the Internet." then SAVI would seem to be
facing an impossible problem. The "can eliminate such datagrams"
part also seems overstated - where's the evidence that that's true?
s/eliminate/reduce/ would seem to be more correct.

(10) Saying that "Internet devices can...confirm...that the IP
address is appropriate for the lower layer address" is not true of
all "Internet devices" only for some near the source, so that's
also overstated and needs to be qualified. (It is later to be fair
but the statement itself is wrong.)

(11) I don't know the answer here, so this is just a question -
what is the likelihood the uRPF check works well? (I didn't find
the string uRPF in RFC 3704, so I'm not sure, but I didn't really
read 3704;-) I guess the real question is whether a failure in uRPF
might break anything for a non-spoofing host and whether a spoofing
host could make it so that uRPF checks allow the packet with a
spoofed address through (from e.g. the same subnet, or for certain
guessable source addresses). I ask (in part) since 4.2.2 says that
uRPF is a crude mechanism.

(12) I'm not sure whether 4.1.3 and 4.1.4 are in or out of scope
for SAVI.  Can you make that clear?

(13) What does "unforgeable" mean in 4.2.3? Perhaps you need to
define that term as well? It may be that the meaning differs for
e.g. MAC addresses and other credentials (noting that passwords can
be guessed or shared of course).

(14) In 4.2.3 where is the evidence that "a large portion of the
...threat space...can be marginalized" - I think that needs some
qualification.

(15) 4.2.3.2 says that DHCP and sniffing "can...auotmatically
provide sufficient binding information" - is there evidence for
that somewhere?  Be good to reference it.

(16) 802.1X determines the identity of a user, not a system I
think.

(17) I think 4.2.5 needs to better characterise the "residual
threat" (not "residual attack") - for each of the various forms of
SAVI. I had hoped this document would say what spoofing
possibilities remain.  Providing just one example doesn't seem
sufficient.

(18) Section 6 (at least) should also recognise that there are
privacy considerations that apply and that more-or-less directly
run counter to the ability to trace the source of problems.

(19) Section 8 should note that circumstantial evidence linking a
person to an IP address can be dangerous for the person. There have
been cases where such tracking has mis-identified people
responsible for some act. (I don't have a reference to hand sorry.)

(20) If no set of deployed SAVI instances can prevent all spoofing
from a given network then an attacker could probe the network to
find out what spoofing works from where they are at, and then use
that. Success in spoofing would then likely have more consequences
for an innocent spoofed party. This would be a new threat caused by
SAVI itself.

(21) If binding anchors are personally identifying or stable over
time or location then recording those creates new threats for tracking
the user or host associated with the binding anchor. That needs to
be noted.

[Ballot comment]
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.

[Ballot discuss]
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 4.2.3.2 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?

[Ballot comment]
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'

[Ballot comment]
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 incorrect. 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'

[Ballot discuss]
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.

[Ballot comment]
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.

[Ballot comment]
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.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (SAVI Threat Scope) to Informational RFC


The IESG has received a request from the Source Address Validation
Improvements WG (savi) to consider the following document:
- 'SAVI Threat Scope'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-05-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-savi-threat-scope/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-savi-threat-scope/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this version of the document and, in
particular, does he or she believe this version is ready for
forwarding to the IESG for publication?

Jean-Michel Combes (jeanmichel.combes@gmail.com) is the Document
Shepherd, savi WG co-chair. He has done a review on the document and
believes it is ready to be forwarded to IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have any
concerns about the depth or breadth of the reviews that have been
performed?

The document has had adequate reviews by key WG members.The document
shepherd does not have any concerns regarding the depth or breadth of
the reviews received.

(1.c) Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective, e.g., security,
operational complexity, someone familiar with AAA,
internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or issues
with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there
really is a need for it. In any event, if the WG has discussed those
issues and has indicated that it still wishes to advance the document,
detail those concerns here. Has an IPR disclosure related to this
document been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on this
issue.

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is savi WG consensus behind the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is entered into the ID
Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See the Internet-Drafts Checklist and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media type
and URI type reviews?

The document shepherd has personally verified that the document
satisfies all ID nits. The document does not need MIB doctor review.
The document does not contain any media and URI types.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are not
ready for advancement or are otherwise in an unclear state? If such
normative references exist, what is the strategy for their completion?
Are there normative references that are downward references, as
described in [RFC3967]? If so, list these downward references to
support the Area Director in the Last Call procedure for them
[RFC3967].

References are split into normative and informative sections.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the IANA
registries clearly identified? If the document creates a new registry,
does it define the proposed initial contents of the registry and an
allocation procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed
Expert during the IESG Evaluation?

This document has an IANA considerations section and no IANA
considerations that needs to be taken care of.

(1.j) Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF rules,
MIB definitions, etc., validate correctly in an automated checker?

There are no such sections.

(1.k) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up? Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
Source Address Validation Improvement (SAVI) effort aims to complement
ingress filtering with finer-grained, standardized IP source address
validation. This document describes threats enabled by IP source
address spoofing both in the global and finer-grained context,
describes currently available solutions and challenges, and provides a
starting point analysis for finer-grained (host granularity)
anti-spoofing work.

Working Group Summary
The normal WG process was followed. The document as it is now,
reflects WG consensus.

Document Quality
The document was thoroughly reviewed by Pekka Savola, Marcelo Bagnulo,
Eric Vyncke, Jari Arkko and Jean-Michel Combes.