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

From: Jean-Michel Combes <[email-masked]>
Date: Wed, 8 Jun 2011 19:28:31 +0200

Hi,

At first sorry for the delayed reply.

Please, see my comments inline.

2011/5/30 Jari Arkko <[email-masked]>:
> Joel,
>
>> As I have said, i am happy to make most of the changes.
>> However, there are two changes requested by Ralph that change the scope in
>> a way that I do not feel I (or you) can call for.
>> I have been awaiting the Chair's review on these two substantive issues:
>>
>> 1) The issue of analysis of the effect of SAVI, and what threats remain
>> after SAVI was requested by Stephen.  I pointed out that this is not in
>> scope for the document, and he said that he wanted it anyway.  I punted to
>> you and the chairs.  I believe it would take WG agreement, AD agreement on
>> scope change, and chair direction, before I can make that change.
>
> My opinion is that this document should NOT do that analysis or attempt to
> find out precisely what residual threats are after some set of SAVI tools
> have been implemented in a network. I think we touched upon it in the call,
> but I  can talk to Stephen about it.

I agree with Jari:
(1) IMHO, this would be like to put the cart before the horse :)
(2) to doing such an analysis you need a clear specification of a SAVI
mechanism which is outside the scope of this document. BTW, during my
review of FCFS SAVI for the ID Write-Up document, text about residual
threats was added inside the Security Considerations section. I will
carefully check that the DHCP SAVI, SEND SAVI and the Mix Scenario
documents take into account this issue before requesting AD/IESG
review.

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.
>
> OK. Its certainly bit of a borderline as a discuss. He wants more precise
> description and in some cases more text. From my read many of the points
> that he makes seemed reasonable. If I was the author I would go through his
> specific requests and see which ones made sense (while remembering the
> feedback you've gotten from other folks).
>
> You do not have to implement verbatim everything that the IESG reviewers ask
> for. Please fight back if the requests do not make sense. I thought I was
> asking for that, actually.
>
> Jari
>
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: Jean-Michel Combes <[email-masked]>
Date: Wed, 8 Jun 2011 20:21:45 +0200

Hi,

2011/5/30 Joel M. Halpern <[email-masked]>:

[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.
(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.
(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.

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.

Best regards.

JMC.

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Jun 2011 13:23:59 +0100

Hi Jean-Michel,

> documents take into account this issue before requesting AD/IESG

So my question then is where will I go to find a description of
the residual threat for SAVI generally? Right now, it looks like
there's going to be no place for that.

The problem I see with that not being available is the following.

Each SAVI mechanism (FCFS etc.) is going to catch certain forms
of spoofing but inevitably leave others available and as you
say those mechanism-specific residual threats will need to be
documented in each SAVI spec.

But I think there are dangers inherent in deploying a network
with multiple SAVI mechanisms because of this - the issue being
that an innocent party might be blamed for some action on the
basis that a combination of SAVI mechanisms makes it "impossible"
that the action actually involved spoofing.

That kind of thing has happened in DRM-related cases so I
think its important that the residual threat when all the various
SAVI mechanisms are defined be properly documented somewhere.

In addition I would assume that vendors are likely to implement
more than one SAVI mechanism in some of their products, so
customers for those products should also be interested in the
residual threat for combinations of SAVI mechanisms.

And I think that only the SAVI WG will have the expertise
required to do that.

Would it make sense to try get someone to write a document
just on that towards the end of the process? (Assuming you
could get a volunteer? I can try see if some security area
type person would be willing to help as well if you like.)

Cheers,
Stephen.

---

From: Jean-Michel Combes <[email-masked]>
Date: Wed, 15 Jun 2011 16:11:16 +0200

Hi Stephen,

I totally agree with you about the fact that deploying different SAVI
solutions on a same architecture may have as consequences extra
residual threats.
That's why, from my point of view, the right place for such an
analysis was the MIX SAVI document
(http://tools.ietf.org/html/draft-ietf-savi-mix-00).

Cheers.

JMC.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Jun 2011 15:25:50 +0100

Hi Jean-Michel,

> (http://tools.ietf.org/html/draft-ietf-savi-mix-00).

So if you're saying that that document will eventually contain
the residual threat analysis for all the others then I'm fine
with that. Sorry for not spotting it, but I guess I can use
the missing security considerations section in the -00 as my
lame excuse:-)

If that's the plan I'm happy to clear that part of the discuss.

Cheers,
S.

---

From: Jean-Michel Combes <[email-masked]>
Date: Wed, 15 Jun 2011 16:46:22 +0200

Hi again,

> the missing security considerations section in the -00 as my

:)

> If that's the plan I'm happy to clear that part of the discuss.

Yes that's the plan and this is clearly identified in my TODO list for
the review of this document.

Cheers.

JMC.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Jun 2011 16:34:53 +0100

> the review of this document.

Grand. I've cleared the two relevant discuss points (2 & 17). I
copied that text down to the end of the comments to help keep
track as we kill off the other discuss and comment points.

Thanks,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Jun 2011 22:28:37 +0100

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.

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

> was.". This is the only occurrence I saw about a trigger that should

Traceability implies a lot to me. It has serious privacy consequences.
See above.

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

> about logging references, so, from my point of view, there is already

But not, I think, IETF consensus.

Cheers,
S.

---

From: Jean-Michel Combes <[email-masked]>
Date: Mon, 20 Jun 2011 17:25:50 +0200

Hi Stephen,

> Let's see if we can figure the other tricky bit of my discuss

OK.

> we can figure it out independent of FCFS that should be better.

Agree.

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

> agreement, but I'm just going on the archive.

Yes, this was a silent agreement.

> is what BCP 38 calls for?

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

Cheers.

JMC.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Jun 2011 17:01:00 +0100

> Would it be fine for you?

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

Thanks for considering this,
Regards,
Stephen.

---

From: Jean-Michel Combes <[email-masked]>
Date: Mon, 20 Jun 2011 19:55:59 +0200

Stephen, fine! I will check carefully this point during my future reviews.

Now, coming back on the Threats document, do you think some text is
not compliant with your requirement?

Thanks in advance.

Best regards.

JMC.

[snip]

[snip]

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Jun 2011 19:12:18 +0100

Hiya,

> Stephen, fine! I will check carefully this point during my future reviews.

Lovely.

> not compliant with your requirement?

I think my discuss points 3, 18 and 21 for this document are the
relevant ones. With our current understanding they should be
easy fixes.

Cheers,
S.