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

[Jean-Michel Combes <[e-mail]>]

Hi Stephen,

2011/6/16 Stephen Farrell <[e-mail]>:
>
> Hi Jean-Michel,
>
> Let's see if we can figure the other tricky bit of my discuss
> as quickly as the other!

OK.

>
> Although I raised the same issue in my discuss on FCFS, I
> think dealing with it on this document is better since I reckon
> the same thing is likely to occur with all SAVI docs, so if
> we can figure it out independent of FCFS that should be better.

Agree.

>
> So this is about logging. To be clear - I have no problem if
> SAVI mechanisms log some information when a spoofing event of
> some sort has been prevented/detected, my problem lies in
> SAVI logging binding anchor information for the 90-something
> percent of cases where there is no spoofing at all.
>
> I do not think that such ubiquitous logging is in scope
> of the WG charter which states that SAVI is about preventing
> spoofing and that "Tracking other protocols is not within
> the scope of the WG."
>
> Separately, there is rfc 2804. As far as I know that is the
> most relevant IETF consensus position here. And that was
> arrived at after an extended and wide ranging debate (one
> of the IETF's finer moments IMO, but that's beside the
> point).
>
> Of course that wasn't precisely addressing the same issue,
> but I think its close enough. Given the various combinations
> of privacy and data retention laws in various jurisdictions,
> and the fact that ubiquitous logging would put SAVI into
> the ballpark of wiretapping functionality, it seems to me
> that the same conclusion should apply when considering whether
> SAVI mechanisms ought to log information for every binding
> anchor.
>
> I'm not sure whether or not WG participants considered this
> in relation to the logging issue or not.
>
> I would also suspect that achieving a freshly minted IETF
> consensus on this particular point might be as time
> consuming as the raven process. (Might not be a bad thing
> though to get an IETF consensus on that if we really
> needed to do it.)
>
> So I think that given that the charter and rfc 2804 have
> IETF consensus that would trump even a quite strong WG
> consensus on this topic. Hence my discuss.
>

What can be done in the different SAVI documents, is to restrict
logging only when an incident has been detected (i.e. use of an IP
address not allowed on a binding anchor).

Would it be fine for you?

> (As an aside, if some spoofing can still occur for any
> combination of SAVI mechanisms such ubiquitous logging makes
> me even more nervous - that'd be like a wiretap technology
> that sometimes records the wrong call or something.)
>
> A few more minor points below.
>
> On 08/06/11 19:21, Jean-Michel Combes wrote:
>> Hi,
>>
>> 2011/5/30 Joel M. Halpern <[e-mail]>:
>>
>> [snip]
>>
>>>
>>> 2) As you have been copied on, Stephen and I have been discussing the
>>> question of the references to logging, and the fact that it is likely to be
>>> used, and its utility is strengthened by the use of SAVI.  This has been
>>> assumed to be significant by the working group.  The charter however agrees
>>> with Stephen.  Before I can make a change of that scope, it needs WG
>>> concurrence, as judged by the chair.
>>
>> (1) From a previous discussion on the ML (cf.
>> http://www.ietf.org/mail-archive/web/savi/current/msg01573.html), it
>> seems that logging is something expected by people wanting to deploy
>> SAVI, what I must admit I understand when we know that most of the
>> security tools have such a feature.
>
> So that's a thread with Joel, you and another person contributing.
> Joel now seems to agree that logging like this is problematic
> given the WG charter and you're calling the consensus, so I guess
> that's not quite an overwhelmingly strong WG consensus:-)
> No one did object granted, and there may be a lot of silent
> agreement, but I'm just going on the archive.
>

Yes, this was a silent agreement.

>> (2) From the Threats document: "A second class of benefit is related
>> to the traceability described above. When a security incident is
>> detected, either within a site, or externally (and traced to the site)
>> it can be critical to determine what the actual source of the incident
>> was.". This is the only occurrence I saw about a trigger that should
>> initiate a logging.
>
> Traceability implies a lot to me. It has serious privacy consequences.
> See above.
>
>> (3) From BCP 38: "Network administrators should log information on
>> packets which are dropped. This then provides a basis for monitoring
>> any suspicious activity.". So, IMHO, the Threats document only
>> provides the same type of advice.
>
> If SAVI only mandates logging related to spoofs then that'd be
> ok and consistent with BCP38. Are you arguing that logging everything
> is what BCP 38 calls for?
>

No no: from my point of view, BCP 38 only recommends to log when
incidents occur.

Cheers.

JMC.

>>
>> So, regarding the Threats documents, I must admit I don't see what is the issue.
>>
>>>
>>> It is the chair's task, as shepherd, to take these questions to the WG.  I
>>> will try to get the other comments dealt with.
>>
>> During the discussion on the ML about this topic there was no concern
>> about logging references, so, from my point of view, there is already
>> a WG consensus.
>
> But not, I think, IETF consensus.
>
> Cheers,
> S.
>
>>
>> Best regards.
>>
>> JMC.
>>
>>>
>>> I am not sure whether Ralph's request for "more details" is arelaly a
>>> discuss, or a suggestion to ask him for and consider more text.  I am
>>> certainly willing to talk with him about it.  But I would need to temper any
>>> such evaluation with the fact that folks asked us to CUT substantial
>>> portions of text in the last review.
>>> I have held off on that discussion because I wanted resolution on the other
>>> issues.  I will contact Ralph this week.  It was only on Sunday that I
>>> reached an understanding of what Stephen was asking for in point 2 above.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 5/30/2011 3:03 AM, Jari Arkko wrote:
>>>>
>>>> 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.
>>>>
>>>> _______________________________________________
>>>> savi mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/savi
>>>>
>>> _______________________________________________
>>> savi mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/savi
>>>
>> _______________________________________________
>> savi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/savi
>>
>