[savi] Status of draft-ietf-savi-threat-scope

[Jari Arkko <[e-mail]>]

This draft was in IESG review last week. Please see below for the 
comments that were raised. I would like the authors to correct these 
issues and/or respond to the Discuss holders, as appropriate. There are 
many detailed things, but the key takeaways that I took from my IESG 
colleagues were the following:

* Changes agreed after Gen-ART discussion need to be incorporated in a 
new version of the document (Russ' Discuss)

* Many of the issues around precise definitions and additional 
information brought up by Ralph's Discuss seemed correct. Please ensure 
that you adopt these in a new version as well.

* I think you need to fix many of the details pointed to in Stephen's 
Discuss, and explain that this document is not the one that will 
describe what the residual threats are after SAVI is implemented. (That 
would be the job of the individual SAVI mechanism documents).

Jari

>
>     Dan Romascanu
>
> *Comment (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 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'
>
>
>     David Harrington
>
> *Comment (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.
>
>
>     Peter Saint-Andre
>
> *Comment (2011-05-23)*
>
> Please expand "DoS" on first use and add an informational reference to RFC 4732.
>
>
>     Russ Housley
>
> *Discuss (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.
>
>
>     Stewart Bryant
>
> *Comment (2011-05-23)*
>
> A useful document which I enjoyed reading
>   
>
>
>     Wesley Eddy
>
> *Comment (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.
>
>
>     Ralph Droms
>
> *Discuss (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
>    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?
>   
>
> *Comment (2011-05-25)*
>
> 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.
>
>
>     Stephen Farrell
>
> *Discuss (2011-05-26)*
>
> (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.
>   
>
> *Comment (2011-05-26)*
>
> (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.