Subject: [Ice] AD Evaluation of draft-ietf-ice-rfc5245bis-15

From: Ben Campbell <[email-masked]>
Date: Mon, 8 Jan 2018 21:45:01 -0600

(Apologies for the repeat. I messed up the “[email-masked]” address the first time. )

Hi,

This is my AD Evaluation of draft-ietf-ice-rfc5245bis-15. Most of my comments are editorial, but there are enough of them I think we will need another revision prior to IETF LC.

I recognize some of my comments address text that did not change from 5245. I tried to minimize that, but this is enough of a rewrite that it’s hard to completely isolate just the updated text. I suspect that last call reviewers and members of the IESG will also find that hard in places.)

Thanks!

Ben.
————————

Substantive Comments:

- 2.1, 2nd to last: Does ICE really prioritize a path with fewer NATs over a path with more NATs, or is it more a matter of selecting a path with no NATs over a path with “some” NATs? (If the former, how does it figure out how many NATs are between an agent and it’s servers and peers? Is this just a matter of timing?)

- 7.2.5.2.3 and 7.2.5.2.4: Why are these SHOULDs not MUSTs? Do you envision circumstances where it might make sense _not_ to set the state to Failed?

-17, first paragraph: “ If these
  potential attacks can not be mitigated, the implementation may want
  to institute controls for which addresses are revealed to the
  negotiation and/or probing process.  Such controls need to be
  specified as part of the ICE usage.”

This seems ambiguous. Is it the implementation’s decision to institute such controls, or is each ICE usage spec expected to make a decision that applies to all implementations of that usage?

Should “secure signaling techniques” distinguish between HBH and E2E techniques, in light of the later discussion about insider attacks?

-17,1, false peer reflexive candidate: Should this mention SRTP (or DTLS-SRTP)  as a mitigating countermeasure?

Editorial Comments and Nits:

Is there a reason that the Security Considerations and IANA considerations are not in the conventional locations (i.e. the last two sections before the references)? (I see that is also true in 5245, so this is mostly curiosity.)

-1, last paragraph: Would it make sense to change “exchanged via mechanisms” (which seems a tautology) to “exchanged via various mechanisms”,  “exchanged by application-specific mechanisms”, or something similar?

— Didn't 5245 already deprecate RFC 4091 and 4092? That is, _this_ document does not do that.

-2.1, first paragraph: "Naturally, one viable candidate has a transport address obtained directly from a
  local interface”

Shouldn’t that say “one or more viable candidates have….”? or “At least one…”?

-2.1, 4th paragraph from end: It would be helpful to describe what “valid pair” means earlier in the document.

-2.3, figure 4: The figure still says “flag”, while the text has been changed in several place to speak of the nominated “attribute”. Please use one or the other consistently.

-4: There are at least a few uses of lower case “must” and “should” that do not appear to have been intended as keywords. If that is the intent, please update this to use the boilerplate from 8174.  (The 2119 boilerplate is ambiguous on whether lower case instances count as keywords.)

s/“… defined in the STUN…” / “… defined in STUN… “ or “… defined in the STUN protocol …”

-5, last paragraph: The figure does not actually mention “default candidate selection”.

-5.1.1, last paragraph, last sentence: Is the MAY applicable just to the responding agent, or both agents?

-5.1.1.2, first paragraph : “Those requirements are at SHOULD strength…”
I suggest putting “SHOULD” in quotes when talking about a requirement stated elsewhere. (Even if that “elsewhere” is in the same sentence :-)  )

-5.1.1.3, first paragraph: "Two candidates MUST have the same foundation when all of the following are true”
That seems like a statement of fact. (Same for the last paragraph talking about different foundations.)

- 5.1.2.1: Missing article before “IP Address for which the candidate…”
(This section also seems to have a lot of 2119 keywords that are really statements of fact or definition. But I recognize those come from the original 5245 text.)

-6.1.2, 2nd sentence: “ To form a check list, an ICE agent (initiating and responding) forms candidate pairs"
Consider : “To form check lists, initiating and responding ICE agents form candidate pairs…”

-7.2.5.2.1: “MUST be equal the destination IP address”

Consider “MUST equal” or “MUST be equal to”

-12.3: “ As discussed below, ICE agents are encouraged to re-adjust jitter buffers…”
Please cite the specific section(s).

- 17, last 3 paragraphs: With the expansion of the security considerations, this list does not include all the countermeasures mentioned in the later sections.

-17.2, last bullet: Why call out viruses specifically? It seems like there are a lot of ways a server might be compromised that do not involve viruses per se. (Same in 17.3).

-17.4.1: Since the description of the voice hammer attack has been removed, can you cite something that does describe it? (Appendix A still refers to section 17 to describe the voice hammer attack.)

-17.4.1, 2nd paragraph: s/they’ll/“they will”

-22: Did you consider making this section an appendix?

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Jan 2018 12:58:03 +0000

Hi Ben,

Thank You for the review! Please see inline.

>Substantive Comments:
>
>- 2.1, 2nd to last: Does ICE really prioritize a path with fewer NATs
>over a path with more NATs, or is it more a matter of selecting a path
>with no NATs over a path with ³some² NATs? (If the former, how does it
>figure out how many NATs are between an agent and it¹s servers and peers?
>Is this just a matter of timing?)

ICE agents can¹t determine how many NATs there are.

I suggest to say:

   "In general, the priority algorithm is designed so that candidates of
    similar type get similar priorities and so that more direct routes
    (that is, routes without data relays or NATs) are preferred over
indirect routes
    (routes with data relays or NATs)."

----

>- 7.2.5.2.3 and 7.2.5.2.4: Why are these SHOULDs not MUSTs? Do you
>envision circumstances where it might make sense _not_ to set the state
>to Failed?

I can¹t think of any such cases.

I suggest to s/SHOULD/MUST.

----

>-17, first paragraph: ³ If these
>  specified as part of the ICE usage.²
>
>This seems ambiguous. Is it the implementation¹s decision to institute
>such controls, or is each ICE usage spec expected to make a decision that
>applies to all implementations of that usage?

I think we could allow both ICE usage-specified and
implementation-specific mechanisms. Maybe re-write as following:

      "If these potential attacks can not be mitigates, ICE usages can
define mechanisms for controlling which addresses are revealed
       to the negotiation and/or probing process. Individual
implementations may also have implementation-specific rules for
controlling 
       which addresses are revealed."

>Should ³secure signaling techniques² distinguish between HBH and E2E
>techniques, in light of the later discussion about insider attacks?

Later down in the reply I suggest to remove the bullet list.

---

>-17,1, false peer reflexive candidate: Should this mention SRTP (or
>DTLS-SRTP)  as a mitigating countermeasure?

The list itself does not describe the countermeasures. SRTP is mentioned
in the last paragraph of the section.

====

>Is there a reason that the Security Considerations and IANA
>considerations are not in the conventional locations (i.e. the last two
>sections before the references)? (I see that is also true in 5245, so
>this is mostly curiosity.)

No reason.

I suggest to move the sections.

---

>-1, last paragraph: Would it make sense to change ³exchanged via
>mechanisms² (which seems a tautology) to ³exchanged via various
>mechanisms²,  ³exchanged by application-specific mechanisms², or
>something similar?

The document introduces the ³ICE usage² concept, so I suggest to say
³exchanged with ICE usage-specific mechanisms².

---

>‹ Didn't 5245 already deprecate RFC 4091 and 4092? That is, _this_
>document does not do that.

I suggest to remove the sentence, and the RFC references.

---

>  local interface²
>Shouldn¹t that say ³one or more viable candidates haveŠ.²? or ³At least
>oneŠ²?

I suggest to say ³At least one².

---

>-2.1, 4th paragraph from end: It would be helpful to describe what ³valid
>pair² means earlier in the document.

I assume you mean section 2.2?

I suggest to following modification:

    "The agent works through the check list by sending a STUN request for
     the next candidate pair on the list periodically.  These are called
     ordinary checks. When a STUN transaction succeeds, one or more
     candidate pairs will become so called valid pairs, and will be added
     to a candidate pair list called the valid list.

     As an optimization, as soon as R gets L's check message, R schedules
     a connectivity check message to be sent to L on the same candidate
     pair. This is called a triggered check, and accelerates the process
     of finding valid pairs."

I would not like to add more details to section 2 (I think it¹s too
detailed already), but I suggest to add
the following to section 4:

    "Valid Pair: A candidate pair whose local candidate equals the mapped
address of the connectivity check response,
     and whose remote candidate equals the destination address to which
the connectivity check request was sent."

Related to this, I note that the document uses both ³valid pair² and
³valid candidate pair² terminology. Perhaps it¹s enough to say ³valid
pair² everywhere.

Related to this, there is a bug in section 2.3. The text shall say:

    "For each component of a data stream, the controlling agent nominates
a valid pair from
     the valid list to be used for data."

---

>-2.3, figure 4: The figure still says ³flag², while the text has been
>changed in several place to speak of the nominated ³attribute². Please
>use one or the other consistently.

I will s/flag/attribute in the figure. Elsewhere the usage of ³flag² is
correct.

---

>-4: There are at least a few uses of lower case ³must² and ³should² that
>do not appear to have been intended as keywords. If that is the intent,
>please update this to use the boilerplate from 8174.  (The 2119
>boilerplate is ambiguous on whether lower case instances count as
>keywords.)

I suggest we keep the 2119 boilerplate, but I will go through the lower
case instances and see whether they should be capitalized.

---

>s/³Š defined in the STUNŠ² / ³Š defined in STUNŠ ³ or ³Š defined in the
>STUN protocol Š²

In order to be aligned with the rest of the document, I suggest to simply
say ³defined in [RFC5389]².

---

>-5, last paragraph: The figure does not actually mention ³default
>candidate selection².

I suggest to remove that part, and say:

"As shown, the agents involved in the candidate exchange perform (1)
   candidate gathering, (2) candidate prioritization, (3) redundant
   candidate elimination and (4) sending of the candidates to the peer."

As shown, I also removed the last sentence regarding lite implementations.
I don¹t think it is needed, since the picture is a high-level overview.

---

>responding agent, or both agents?

I suggest to remove the last sentence. The text already says that the
gathering can start before the user is alerted.

---

>-5.1.1.2, first paragraph : ³Those requirements are at SHOULD strengthŠ²
>I suggest putting ³SHOULD² in quotes when talking about a requirement
>stated elsewhere. (Even if that ³elsewhere² is in the same sentence :-)  )

I suggest to remove the sentence, and begin the following sentence with:

"However, use of STUN and TURN servers may be unnecessary inŠ"

---

>-5.1.1.3, first paragraph: "Two candidates MUST have the same foundation
>when all of the following are true²

I suggest to remove ³MUST².

---

>- 5.1.2.1: Missing article before ³IP Address for which the candidateŠ²
>(This section also seems to have a lot of 2119 keywords that are really
>statements of fact or definition. But I recognize those come from the
>original 5245 text.)

I suggest to say ³the IP Address².

I suggest to keep the 2119 keywords.

---

>-6.1.2, 2nd sentence: ³ To form a check list, an ICE agent (initiating
>and responding) forms candidate pairs"
>Consider : ³To form check lists, initiating and responding ICE agents
>form candidate pairsŠ²

I will fix as suggested.

---

>-7.2.5.2.1: ³MUST be equal the destination IP address²
>
>Consider ³MUST equal² or ³MUST be equal to²

I will change to ³MUST be equal to².

---

>-12.3: ³ As discussed below, ICE agents are encouraged to re-adjust
>jitter buffersŠ²

I actually suggest to remove section 12.3. It is about receiving data, and
the content is covered in section 13.

I also suggest to change section 12.3 to 12.2.1, as the text is only about
sending media.

I also suggest to change section 13 to 12.3. It was always intended to be
a subsection to section 12.

---

>- 17, last 3 paragraphs: With the expansion of the security
>considerations, this list does not include all the countermeasures
>mentioned in the later sections.

I suggest to remove the list, and say:

    "There are several types of attacks possible in an ICE system.  This
     section considers these attacks and their countermeasures."

---

>-17.2, last bullet: Why call out viruses specifically? It seems like
>there are a lot of ways a server might be compromised that do not involve
>viruses per se. (Same in 17.3).

 My only answer is that this is text from RFC 5245.

I can remove ³virus², and simply say:

"An attacker can compromise a STUN server, and cause it to send responses
with incorrect mapped addresses.² (17.2)

Šand:

"However, TURN servers are susceptible to DNS attacks for purposes of
turning it into a zombie or rogue server."

---

>-17.4.1: Since the description of the voice hammer attack has been
>removed, can you cite something that does describe it? (Appendix A still
>refers to section 17 to describe the voice hammer attack.)

I didn¹t really find a good citation, but maybe something like:

"The STUN amplification attack is similar to a voice hammer attack, where
the attacker causes other agents to direct media traffic towards the
attack target."

I also realised that the following text needs to be removed from Appendix
A:

"in particular, the voice hammer attack described in Section 17 is
   prevented only for full implementations, not lite."

---

>-17.4.1, 2nd paragraph: s/they¹ll/³they will²

I will fix as suggested.

---

>-22: Did you consider making this section an appendix?

I don¹t remember. I have no problem doing that, if you think an appendix
would be better.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 9 Jan 2018 11:24:46 -0600

> On Jan 9, 2018, at 6:58 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Ben,
> 
>    (routes with data relays or NATs).”
> 

WFM

> I suggest to s/SHOULD/MUST.

Okay. (Shepherd: Please note that this would be a normative change that should be pointed out to the WG.)

>       which addresses are revealed.”

WFM.

> Later down in the reply I suggest to remove the bullet list.

Okay, does it make sense to discuss HBH vs E2E protections in the section about insider attacks?

> in the last paragraph of the section.

Ah, okay.

> I suggest to move the sections.

Okay. (I’m also okay leaving it as is unless someone objects in IETF LC).

> ³exchanged with ICE usage-specific mechanisms².

Okay.

> I suggest to remove the sentence, and the RFC references.

I’m okay with that, but it might be helpful to merely adjust the wording to say that 5245 deprecated them.

> I suggest to say ³At least one².

Okay.

> I assume you mean section 2.2?

Sorry, yes.

>     of finding valid pairs.”

WFM

> the connectivity check request was sent.”

Also WFM.

>     the valid list to be used for data.”

I’m okay either way. (While I usually prefer consistency, I imagine that people can figure this one out.)

> I will s/flag/attribute in the figure. Elsewhere the usage of ³flag² is

Okay

> case instances and see whether they should be capitalized.

Okay, although if you keep 2119, it might be better to change any that should remain non-capitalized to non-colliding terms.

> say ³defined in [RFC5389]².

Okay

> I don¹t think it is needed, since the picture is a high-level overview.

Okay.

> gathering can start before the user is alerted.

Okay.

> "However, use of STUN and TURN servers may be unnecessary inŠ”

Okay.

> I suggest to remove ³MUST².

Okay.

> I suggest to keep the 2119 keywords.

Okay.

>> Consider : ³To form check lists, initiating and responding ICE agents

Okay.

> I will change to ³MUST be equal to².

Okay.

> a subsection to section 12.

No objection, but that goes beyond the scope of my comment :-)

(Normally I discourage lots of reorganization in bis drafts because it makes them harder to review against the original. But this is already enough of a re-write that this change would make little incremental difference.)

>     section considers these attacks and their countermeasures.”

Okay.

> turning it into a zombie or rogue server.”

Okay. On reflection,  I’m also okay leaving things as is in deference to 5245.

> attack target.”

WFM. Perhaps put “voice hammer” in quotes?

>   prevented only for full implementations, not lite.”

Okay.

>> -17.4.1, 2nd paragraph: s/they¹ll/³they will²

Okay.

> I don¹t remember. I have no problem doing that, if you think an appendix

On reflection, don’t worry about it.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jan 2018 11:45:57 +0000

Hi,

>Okay, does it make sense to discuss HBH vs E2E protections in the section

I don’t know. Do we have the right people? Would we get any useful input?

My suggestion would be to wait for the SECDIR- and SEC AD reviews etc, and
see what/if they say.

====

>Okay. (I’m also okay leaving it as is unless someone objects in IETF LC).

I already moved them in the pull request :)

---

>to say that 5245 deprecated them.

Ok. So, I suggest:

   "Because ICE exchanges a multiplicity of IP addresses and ports for
each media
    stream, it also allows for address selection for multihomed and dual-
    stack hosts. For this reason RFC 5245 [RFC5245] deprecated RFC 4091
[RFC4091] and
    [RFC4092]."

---

>people can figure this one out.)

This is one of the things I always check when I do GenArt reviews :)

I had a look, and there weren’t too many instances of “valid candidate
pair”, so I changed them to “valid pair” in order to align.

I implemented the changes in the PR.

---

>Okay, although if you keep 2119, it might be better to change any that
>should remain non-capitalized to non-colliding terms.

I had a look. In most cases I could change to a non-colliding terms, and
in 1-2 cases I changed to upper case.

I implemented the changes in the PR.

—

>(Normally I discourage lots of reorganization in bis drafts because it
>makes them harder to review against the original. But this is already
>enough of a re-write that this change would make little incremental
>difference.)

Also note that “Receiving media” (section 13 in bis) was a subsection in
RFC 5245, so the 13->12.3 change will actually align the bis with the RFC
:)

—

>Okay. On reflection,  I’m also okay leaving things as is in deference to

I already removed it in the PR, so if you are ok with that I won’t put it
back :)

---

>WFM. Perhaps put “voice hammer” in quotes?

I will fix that.

---

>On reflection, don’t worry about it.

Ok, I’ll keep it.

Updated PR:

https://github.com/ice-wg/rfc5245bis/pull/55

Regards,

Christer

---

From: Ari Keränen <[email-masked]>
Date: Wed, 10 Jan 2018 16:10:38 +0000

> On 9 Jan 2018, at 14.58, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Ben,
> 

ICE makes a difference between no NATs, one agent behind a NAT, and both agents (or more specifically their interfaces being checked) behind NATs. And a path with only one agent behind a NAT would be "fewer NATs" than both behind NATs. Admittedly there could be a cascade of 3 NATs in front of one of the agents and they would be "counted" as a single NAT.

That said, I think the text you suggested is also correct. And probably less confusing too.

Cheers,
Ari

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Jan 2018 10:22:23 -0600

> On Jan 10, 2018, at 5:45 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
>>> 

I wasn’t asking for a detailed discussion—maybe just a 1 sentence acknowledgement that things like SIPS do not by themselves prevent an insider or a compromised proxy/b2bua from eavesdropping on and/or tampering with the candidate exchange.

> My suggestion would be to wait for the SECDIR- and SEC AD reviews etc, and

I’m okay with that.

[The rest of your responses look fine.]

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Jan 2018 10:36:07 -0600

I meant to mention that the github DIFF looks good to me as far as I can tell. I agree with Ari’s comments. However, moving sections around makes the diff hard to follow for those sections, so I reserve the right to find something I missed when it is submitted as a draft :-)

Since there is at least one normative change (SHOULD to MUST), please call that out in a separate message to the wg.  That doesn’t need to block IETF LC; if anyone objects they can do it as part of the LC.

Thanks!

Ben.

> On Jan 10, 2018, at 10:22 AM, Ben Campbell <[email-masked]> wrote:
> 
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jan 2018 18:34:33 +0000

Hi,

>>> over a path with more NATs, or is it more a matter of selecting a 
>>> path with no NATs over a path with ³some² NATs? (If the former, how 
>>> does it figure out how many NATs are between an agent and it¹s servers and peers?
>>   indirect routes (routes with data relays or NATs)."
>
> ICE makes a difference between no NATs, one agent behind a NAT, and both agents (or more specifically their interfaces being checked) behind NATs. 
> And a path with only one agent behind a NAT would be "fewer NATs" than both behind NATs. Admittedly there could be a cascade of 3 NATs in front of one of the agents 
> and they would be "counted" as a single NAT.

Correct, that's what I meant.

> That said, I think the text you suggested is also correct. And probably less confusing too.

Making ICE less confusing has been my mission :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jan 2018 19:47:33 +0000

Hi,

I have updated the PR, based on the comments from Ari.

Unless you object, I intend to submit a new version of the draft tomorrow morning :)

Regards,

Christer

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: 10 January 2018 18:22
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: AD Evaluation of draft-ietf-ice-rfc5245bis-15

>>>> Should ³secure signaling techniques² distinguish between HBH and 
>>>> E2E techniques, in light of the later discussion about insider attacks?
>>> 

> 
> My suggestion would be to wait for the SECDIR- and SEC AD reviews etc, 
> and see what/if they say.

I’m okay with that.

Thanks!

Ben.

>>>> considerations are not in the conventional locations (i.e. the last 
>>>> two sections before the references)? (I see that is also true in 
>>>> 5245, so this is mostly curiosity.)
>>> 
>>> No reason.
>>> 
>> I’m okay with that, but it might be helpful to merely adjust the 
>> wording to say that 5245 deprecated them.
> 
> Ok. So, I suggest:
> 
>>>> -2.1, 4th paragraph from end: It would be helpful to describe what 
>>>> ³valid pair² means earlier in the document.
>>> 
>>> detailed already), but I suggest to add the following to section 4:
>>> 
>>>   "Valid Pair: A candidate pair whose local candidate equals the 
>>> mapped address of the connectivity check response,
>>>    and whose remote candidate equals the destination address to 
>>> which the connectivity check request was sent.”
>> 
>> Also WFM.
>> 
>>> 
>>> 
>>> ³valid candidate pair² terminology. Perhaps it¹s enough to say 
>>> ³valid pair² everywhere.
>>> 
>>>   "For each component of a data stream, the controlling agent 
>>> nominates a valid pair from
>>>> -4: There are at least a few uses of lower case ³must² and ³should² 
>>>> that do not appear to have been intended as keywords. If that is 
>>>> the intent, please update this to use the boilerplate from 8174.  
>>>> (The 2119 boilerplate is ambiguous on whether lower case instances 
>>>> count as
>>>> keywords.)
>>> 
>>> 
>>> I suggest we keep the 2119 boilerplate, but I will go through the 
>>> lower case instances and see whether they should be capitalized.
>> 
>> Okay, although if you keep 2119, it might be better to change any 
>> that should remain non-capitalized to non-colliding terms.
> 
> I had a look. In most cases I could change to a non-colliding terms, 
> and in 1-2 cases I changed to upper case.
> 
>>>> jitter buffersŠ² Please cite the specific section(s).
>>> 
>>> I actually suggest to remove section 12.3. It is about receiving 
>>> data, and the content is covered in section 13.
>>> 
>>> I also suggest to change section 12.3 to 12.2.1, as the text is only 
>>> about sending media.
>>> 
>>> I also suggest to change section 13 to 12.3. It was always intended 
>>> to be a subsection to section 12.
>> 
>> (Normally I discourage lots of reorganization in bis drafts because 
>> it makes them harder to review against the original. But this is 
>> already enough of a re-write that this change would make little 
>> incremental
>> difference.)
> 
> Also note that “Receiving media” (section 13 in bis) was a subsection 
> in RFC 5245, so the 13->12.3 change will actually align the bis with 
> the RFC
> :)
> 
> —
> 
>>> 
>>>> -17.2, last bullet: Why call out viruses specifically? It seems 
>>>> like there are a lot of ways a server might be compromised that do 
>>>> not involve viruses per se. (Same in 17.3).
>>> 
>>> "An attacker can compromise a STUN server, and cause it to send 
>>> responses with incorrect mapped addresses.² (17.2)
>>> 
>>> 
>>> Šand:
>>> 
>>> "However, TURN servers are susceptible to DNS attacks for purposes 
>>> of turning it into a zombie or rogue server.”
>> 
> I already removed it in the PR, so if you are ok with that I won’t put 
> it back :)
> 
> ---
> 
>>> 
>>>> removed, can you cite something that does describe it? (Appendix A 
>>>> still refers to section 17 to describe the voice hammer attack.)
>>> 
>>> "The STUN amplification attack is similar to a voice hammer attack, 
>>> where the attacker causes other agents to direct media traffic 
>>> towards the attack target.”
>>> 
>> 
>>> I don¹t remember. I have no problem doing that, if you think an 
>>> appendix would be better.
>>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Jan 2018 14:37:49 -0600

By all means, please do so :-)

> On Jan 10, 2018, at 1:47 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>