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

[Stephen Farrell <[e-mail]>]

On 20/06/11 16:25, Jean-Michel Combes wrote:
> 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?

Only logging when an incident has been detected sounds
perfect to me.

Thanks for considering this,
Regards,
Stephen.


> 
>> (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
>>>
>>
> _______________________________________________
> savi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/savi
>