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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 16 June 2011 21:28 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: savi@ietfa.amsl.com
Delivered-To: savi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BF411E8323 for <savi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.601
X-Spam-Level:
X-Spam-Status: No, score=-105.601 tagged_above=-999 required=5 tests=[AWL=0.998, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjcpBPu3AyQv for <savi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:28:47 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id A597911E8319 for <savi@ietf.org>; Thu, 16 Jun 2011 14:28:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 62D5D171C20; Thu, 16 Jun 2011 22:28:42 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308259721; bh=ZHkvgLQP/iWOxa TBOG2VXyW2LBBGgtHklEkd55FUYd4=; b=MaaHaJh0JGBK7URv6OHJ60d2diN0YA SL7Rzymrfp38GnSGMNKW4BMgentlsTA84AblZHPVIVN5Js7h0+Nf5ZMLixWeUYYT xcin8g+Sv7eCfAgDKmmr0RVqKzOMxyNFbQCfIqzF13umT8ylf6DMOIvYjP6DbiJF +kLv1OyUY3ujmFzlbh4c3u2AjMLb0IU0Vn9aTiaQDJ3Djf1hxPRyEHRThoazsXr9 FxoisQDkLLW+I/fkq90bdZe7tJkhAAFax0cvNjnhXQT5+iAVGtwZCwc5seSuivYO KhQAmWv8ff1x+fI3RULyrA4FyK6g9vIBNRiQlX31eZMVjH2Wj8itHdgw==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 9ty7M9E8wRWM; Thu, 16 Jun 2011 22:28:41 +0100 (IST)
Received: from [10.87.48.10] (unknown [86.42.183.124]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A067E171C19; Thu, 16 Jun 2011 22:28:38 +0100 (IST)
Message-ID: <4DFA7585.4060406@cs.tcd.ie>
Date: Thu, 16 Jun 2011 22:28:37 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Jean-Michel Combes <jeanmichel.combes@gmail.com>
References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> <4DE3A604.8080807@joelhalpern.com> <BANLkTiky5iejz2gnL=tgt4u+-52OZ-pQJA@mail.gmail.com>
In-Reply-To: <BANLkTiky5iejz2gnL=tgt4u+-52OZ-pQJA@mail.gmail.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: SAVI Mailing List <savi@ietf.org>, draft-ietf-savi-threat-scope@tools.ietf.org
Subject: Re: [savi] Status of draft-ietf-savi-threat-scope
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list for the SAVI working group at IETF <savi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/savi>, <mailto:savi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/savi>
List-Post: <mailto:savi@ietf.org>
List-Help: <mailto:savi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/savi>, <mailto:savi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jun 2011 21:28:51 -0000

Hi Jean-Michel,

Let's see if we can figure the other tricky bit of my discuss
as quickly as the other!

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.

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.

(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 <jmh@joelhalpern.com>om>:
> 
> [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.

> (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?

> 
> 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
>>> savi@ietf.org
>>> https://www.ietf.org/mailman/listinfo/savi
>>>
>> _______________________________________________
>> savi mailing list
>> savi@ietf.org
>> https://www.ietf.org/mailman/listinfo/savi
>>
> _______________________________________________
> savi mailing list
> savi@ietf.org
> https://www.ietf.org/mailman/listinfo/savi
>