Subject: [Dots] Martin Stiemerling's No Objection on charter-ietf-dots-00-01: (with COMMENT)

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 10 Jun 2015 12:54:08 -0700

Martin Stiemerling has entered the following ballot position for
charter-ietf-dots-00-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-dots/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support the chartering, but I have a question about this paragraph:

"These elements may be communicating inter-domain or intra-domain over
links that may be congested by attack traffic resulting in hostile
conditions for connection oriented approaches and more generalized
signaling and telemetry solutions."

Is this text trying to make a statement that, for instance,  TCP cannot
be used for transporting threat signaling?  As this text says "hostile
conditions for connection oriented". And if so, what would be the
intended alternative, if any?

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 10 Jun 2015 22:12:39 +0200

Hello Martin,

attempting to answer this from my own personal view:

my understanding is that we need to recognise that such NEs may very 
well be under attack themselves and we as a WG need to investigate and 
consider which communication protocol would be best suited to function 
under such difficult conditions of "under attack". I do not believe the 
WG is at this stage discounting any one specific protocol or has decided 
already for one protocol choice. But that we rather say we need to 
investigate and see what protocol is a good method for communicating in 
these challenging environments.

I hope that helps to answer your question.

Best regards, Tobias

On 10/06/15 21:54, Martin Stiemerling wrote:
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 10 Jun 2015 22:43:15 +0200

Hi Tobias,

> I hope that helps to answer your question.

That answers my question, but I guess that this fact has to be 
documented in the charter much more explicitly.

My next question would be:
Is there the assumption that the DOTS signaling is travelling the 
reverse path of the DoS attack? Or is the DOTS signaling ok travelling a 
different path from one NE under attack the an upstream NE under attack, 
thus avoiding the potential congested downsteam path?

Thanks/Danke schön!

   Martin

---

From: "Teague, Nik" <[email-masked]>
Date: Wed, 10 Jun 2015 20:52:51 +0000

Martin hi,

I think Tobias expressed it very well in his response.

My experience has been that even if an participating element is not,
itself, being attacked that a link/circuit in the path may be congested
due to the attack and that this can impact the stability of connection
oriented protocols.  I support Tobias’s statement that the WG is not yet
ready to rule out any protocols but that the choice of signal transport
needs to fit within the attack environment.

I don’t think, though, that the WG should operate under the assumption
that there will always be an out of band or alternate path nor should it
assume that the path will always be congested.  The WG would consider both
possibilities and determine the best solution.

Thanks,

-Nik

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 10 Jun 2015 22:54:08 +0200

Hi Martin,

again only answering as an individual.

> documented in the charter much more explicitly.

IMHO the charter's current text and openness on the question of specific 
protocol and that we start looking at requirements should be sufficient 
to allow us to look for and choose the best protocol options.
I note that I might be biased as I attended the BOF and obviously see 
the charter in the context of the BOF meeting. Still I feel the current 
text is sufficient on this. Having said that, I have no objections on 
adding text to further clarify this explanation of openness if you feel 
that it is not clear enough.

> reverse path of the DoS attack? Or is the DOTS signaling ok travelling 
> a different path from one NE under attack the an upstream NE under 
> attack, thus avoiding the potential congested downsteam path?

IMHO: No, the assumption is not that it is (necessarily) the reverse 
path. However, be advised that a whole cluster of NEs might be 
experiencing an attack and we need to consider how to communicate that 
information across the nodes under stress.

Best regards, Tobias

---

From: Andrew Mortensen <[email-masked]>
Date: Wed, 10 Jun 2015 17:16:03 -0400

> On Jun 10, 2015, at 4:54 PM, Tobias Gondrom <[email-masked]> wrote:
> 
> Hi Martin, 
> 
>> That answers my question, but I guess that this fact has to be documented in the charter much more explicitly. 
> 
> IMHO the charter's current text and openness on the question of specific protocol and that we start looking at requirements should be sufficient to allow us to look for and choose the best protocol options. 
> I note that I might be biased as I attended the BOF and obviously see the charter in the context of the BOF meeting. Still I feel the current text is sufficient on this. Having said that, I have no objections on adding text to further clarify this explanation of openness if you feel that it is not clear enough. 

My understanding is somewhat different. While the WG hasn’t eliminated any transport options at this stage, emphasizing the need for “robustness” under "hostile” conditions for "connection oriented protocols” looks to me like periphrasis for “TCP will be a poor choice for the signaling transport under attack conditions.” That this language met approval from the WG suggests a general, albeit tacit, agreement on that point.

If that’s not the case, we should make it explicit in the charter.

>> Is there the assumption that the DOTS signaling is travelling the reverse path of the DoS attack? Or is the DOTS signaling ok travelling a different path from one NE under attack the an upstream NE under attack, thus avoiding the potential congested downsteam path? 
> 
> IMHO: No, the assumption is not that it is (necessarily) the reverse path. However, be advised that a whole cluster of NEs might be experiencing an attack and we need to consider how to communicate that information across the nodes under stress.

Again my understanding differs. I do not believe that the signaling element can rely on the availability of a separate path to the upstream element, and must be able to signal over the congested link. Hence the emphasis on need for protocol robustness under hostile conditions.

andrew

---

From: "Teague, Nik" <[email-masked]>
Date: Wed, 10 Jun 2015 22:05:00 +0000

Martin hi,

Thanks for your comments.

The charter states within deliverables:

"* Document or Documents describing the problem space, use cases, protocol
requirements and other qualifying information as the WG sees fit.
* Document or Documents specifying protocols and associated data models to
address the stated goals of the WG."

Is this sufficient to cover your concerns or do you think we need more?
We could add transport selection into this if you would rather it were
present.

Thanks,

-Nik

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 11 Jun 2015 11:17:37 +0700

On 11 Jun 2015, at 3:52, Teague, Nik wrote:

> oriented protocols.

I concur with this general stance, but with a caveat.

There are significant problems on many production networks with regards 
to connectionless transports making it through stateful firewalls, NATs, 
ACLs, etc.  These barriers are unlikely to be resolved in the 
foreseeable future (sadly, it seems they're likely to become more common 
over time).

Therefore, even though a connectionless transport is preferred for all 
the reasons previously noted, the application-layer protocol(s) the WG 
is working towards should also be compatible with a widely-supported 
connection-oriented transport, as well.

Otherwise, there will be significant adoption problems on many 
production networks, particularly enterprise endpoint networks.

> I support Tobias’s statement that the WG is not yet ready to rule 
> out any protocols but that the choice of signal transport needs to fit 
> within the attack environment.

Concur, with the caveat of protocol(s), and that complications such as 
the aforementioned stateful firewalls, NATs, ACLs, etc. are often part 
of either the attack environment, the signal path necessary to invoke 
mitigation, or both.

> possibilities and determine the best solution.

Concur.  OOB for this sort of thing is preferred, but unfortunately, 
that will likely always be a minority deployment scenario.  The WG 
should definitely encourage the use of an OOB signaling path where 
possible, but must make the assumption that OOB is not and is not likely 
to be a prevalent deployment model in the foreseeable future.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 11 Jun 2015 11:20:25 +0700

On 11 Jun 2015, at 11:17, Roland Dobbins wrote:

> Concur, with the caveat of protocol(s),

This should read 'transport(s)', apologies for the confusion.

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 11 Jun 2015 17:38:08 +0700

> If that’s not the case, we should make it explicit in the charter.

Per previous comments on the operational challenges of stateful 
firewall, NAT, and ACL traversal faced by connectionless protocols, I 
concur that both a general preference for connectionless transport as 
well as recognition of the need for a widely-supported 
connection-oriented transport option explicit in the charter.

---

From: "Teague, Nik" <[email-masked]>
Date: Thu, 11 Jun 2015 11:11:59 +0000

Hi,

Are we suggesting we define the protocol characteristics in the charter or
should be we call out that transport protocol pursuant to the operating
conditions will require examination and that this should be explicit in
the charter?

Thanks,

-Nik

---

From: "Teague, Nik" <[email-masked]>
Date: Thu, 11 Jun 2015 12:23:46 +0000

Hi,

I noticed comments on the ballot that don’t seem to have made it to the
list -

Joel commented:

"Comment (2015-06-11 for -00-01)
One consistent issue that I have found with pushing  telemery and then
mitigation upstream is the loss of visibility into the attack. so while
downstream customers may be senders of information at some point they also
need
any telemetry generated upstream.”

We discussed this during the ietf92 BoF and it is called out in the
charter - 

“Feedback between participating elements is required for increased
awareness
supporting effective decision making.”

We strongly think that telemetry back to the originator is important in
this effort.

Terry commented:

"Comment (2015-06-10 for -00-01)
The first thing that grabbed me was impact of DOTS on a system/network
that is
under attack. I think Martin has raised it well, so I won't belabour the
point.

I wonder if this, in the nature of the work, is going to be of a far more
experimental nature than it is a standards track body of work? I can
foresee
_multiple_ iterations (presuming the proponents move passed talking about
the
problem) over implementation and design principles. As a WG outputting
experimental documents it will mean that they will have an interesting time
modifying existing RFCs within the WG, but will be able to still
collaborate
with other WGs as necessary.”

Elements of DOTS like functionality are present today in a number of
existing hybrid DDoS mitigation solutions but these are often vertically
locked to vendor x or y at the various tiers.  These solutions often use
small UDP exports (proprietary or syslog or w/e) for the signaling portion
with the goal of keeping impact to a minimum for the originator who’s
networks may be already highly stressed.  The composition and signaled
intent of the proposed WG appears conducive to making DOTS a reality.

Thanks,

-Nik

---

From: Andrew Mortensen <[email-masked]>
Date: Thu, 11 Jun 2015 09:19:40 -0400

> On Jun 11, 2015, at 7:11 AM, Teague, Nik <[email-masked]> wrote:
> 
> Hi,
> 

I’m in favor of calling out the need for transport evaluation in the charter. Making transport choices in the charter seems misguided in the wake of the discussion following Martin’s comments.

andrew

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 11 Jun 2015 20:34:44 +0700

On 11 Jun 2015, at 20:19, Andrew Mortensen wrote:

> I’m in favor of calling out the need for transport evaluation in the 
> charter.

I concur.  This is a good approach, IMHO.

---

From: "Teague, Nik" <[email-masked]>
Date: Thu, 11 Jun 2015 13:53:31 +0000

Hi,

Benoit commented:

---
"Block (2015-06-11 for -00-01)
More of DISCUSS-DISCUSS for the telechat than a BLOCK.

"Document or Documents describing the problem space, use cases, protocol
requirements and other qualifying information as the WG sees fit."

I would strongly encourage the group to focus first on the intra-domain:
this
is already a huge problem. The inter-domain use cases will lead to
different
set of requirements (sending telemetry info across domains, potential
synchronization of the collecting infrastructure). Sharing IPFIX data
between
domains is not a reality today, and and when I see "Feedback between
participating elements is required for increased awareness supporting
effective
decision making.", it remains to be seen if elements from different domains
will communicate... Don't make the scope too big.

Comment (2015-06-11 for -00-01)
Btw, any link with BGP Flow Spec to block the attack?”
----

Re: "Sharing IPFIX data between domains is not a reality today”

IPFIX/Netflow is readily exported inter-domain by a number of operators to
DDoS mitigation service providers and is often the primary monitoring data
source for these operations.  At the present time its pretty much a
requirement for such a provider to be able to effectively monitor and
alarm against customer traffic.  Similarly I notice a number of cloud
providers popping up to handle flow analysis.

Re: "Btw, any link with BGP Flow Spec to block the attack?"

DOTS should in my mind be concerned with signaling the threat - the
countermeasure may be determined by the threat being communicated but in
the first iteration triggering a countermeasure is probably outside
initial scope and should be handled by a consumer process.

Thanks,

-Nik

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 11 Jun 2015 16:24:03 +0200

Hi all,

I believe that I have now understood the setting, after the email 
discussions.

I would propose to say:
OLD
"These elements may be communicating inter-domain or intra-domain over
links that may be congested by attack traffic resulting in hostile
conditions for connection oriented approaches and more generalized"
NEW
"These elements may be communicating inter-domain or intra-domain over
links that may be congested by attack traffic resulting in potentially
hostile conditions for any type of upstream signaling, in particular 
transport protocols that yield to congestion, and more generalized "

This is capturing more the situation we have right now that there is the 
assumption that protocols, such as TCP, might not the right answer 
without ruling them out. Further, a congested link will be troublesome 
to any type of transport/signaling crossing this link, as the link is 
anyway out of free resources (or close to), though signaling and attack 
traffic might travel the opposite direction.

Further, I would add a paragraph along these lines, after the paragraph 
starting with "The WG will, where appropriate, reuse or extend existing 
standard":

"The WG will document requirements for the transport protocol to be used 
for the signaling of DOTS and consult with the Transport Area about the 
requirements and, if applicable, any new development of a encapsulation 
scheme for DOTS."

This is to ensure that early in the process, DOTS and the Transport Area 
will talk to each other in order to double check your requirements and 
what is possible in a (congested downstream) network environment.

Let me know your feedback.

   Martin

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 11 Jun 2015 10:28:30 -0400

On Thu, Jun 11, 2015 at 10:24 AM, Martin Stiemerling <[email-masked]>
wrote:

> assumption that protocols, such as TCP, might not the right answer without
> ruling them out. Further, a congested link will be troublesome to any type
> of transport/signaling crossing this link, as the link is anyway out of
> free resources (or close to), though signaling and attack traffic might
> travel the opposite direction.
>
> will talk to each other in order to double check your requirements and what
> is possible in a (congested downstream) network environment.
>

The suggestions look reasonable to me, but I'd like to hear some proponents
chime in before making an update.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Teague, Nik" <[email-masked]>
Date: Thu, 11 Jun 2015 14:30:43 +0000

Hi,

I’m fine with the clarification and the agreement to specifically call out
working with the Transport Area.

I’ll get an updated charter out asap.

Thanks,

-Nik

On 11/06/2015 15:28, "Kathleen Moriarty"
<[email-masked]> wrote:

>
>
>On Thu, Jun 11, 2015 at 10:24 AM, Martin Stiemerling
><[email-masked]> wrote:
>
>Hi all,
>
>without ruling them out. Further, a congested link will be troublesome to
>any type of transport/signaling crossing this
> link, as the link is anyway out of free resources (or close to), though
>signaling and attack traffic might travel the opposite direction.
>
>The suggestions look reasonable to me, but I'd like to hear some
>proponents chime in before making an update.
>
>
>Thank you,
>Kathleen 
>
>
>  Martin
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 11 Jun 2015 10:33:35 -0400

> I’ll get an updated charter out asap.

If Martin's text is good, I can just make the update as the old/new makes
it easy.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Teague, Nik" <[email-masked]>
Date: Thu, 11 Jun 2015 14:35:21 +0000

Hi,

Yes I think the text is good.

Thanks!

-Nik

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 11 Jun 2015 10:52:28 -0400

Martin,

The updates have been made.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 11 Jun 2015 17:14:02 +0200

Thanks & I have cleared.

The text after the OLD/NEW change has a formatting issue in the tracker.

   Martin

Am 11.06.15 um 16:52 schrieb Kathleen Moriarty:
> On Thu, Jun 11, 2015 at 10:35 AM, Teague, Nik <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>      >
>      >
>      >On Thu, Jun 11, 2015 at 10:30 AM, Teague, Nik
>      ><[email-masked] <mailto:[email-masked]>> wrote:
>      >
>      >Hi,
>      >
>      ><[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>      >>
>      >>
>      >><[email-masked] <mailto:[email-masked]>> wrote:
>      >>
>      >>Hi all,
>      >>
>      >>Roland Dobbins <[email-masked] <mailto:[email-masked]>>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>--
>      >>
>      >>Best regards,
>      >>Kathleen
>      >>
>      >>
>      >>
>      >>
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >--
>      >
>      >Best regards,
>      >Kathleen
>      >
>      >
>      >
>      >
>
>
>
>
> --
>
> Best regards,
> Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 11 Jun 2015 11:19:52 -0400

Thank you for catching the text problems, that has been fixed.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 11 Jun 2015 10:24:17 -0500

Hi, Kathleen,

> On Thu, Jun 11, 2015 at 11:14 AM, Martin Stiemerling <[email-masked]>
Just to tie up any loose ends, I was only a No Objection because Martin
already had a Discuss on that point, but the new text works for me as well.

So, now I Really Don't Object.

Thank,

Spencer

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 11 Jun 2015 11:28:19 -0400

Thanks, Spencer!

-- 

Best regards,
Kathleen

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 11 Jun 2015 19:25:53 +0200

I agree. Works for me.
Best, Tobias

On 11/06/15 16:28, Kathleen Moriarty wrote:
>     hostile conditions for any type of upstream signaling, in
>     particular transport protocols that yield to congestion, and more
>     generalized "
>
>     This is capturing more the situation we have right now that there
>     is the assumption that protocols, such as TCP, might not the right
>     answer without ruling them out. Further, a congested link will be
>     troublesome to any type of transport/signaling crossing this link,
>     as the link is anyway out of free resources (or close to), though
>     Further, I would add a paragraph along these lines, after the
>     paragraph starting with "The WG will, where appropriate, reuse or
>     extend existing standard":
>
>     "The WG will document requirements for the transport protocol to
>     be used for the signaling of DOTS and consult with the Transport
>     Area about the requirements and, if applicable, any new
>     development of a encapsulation scheme for DOTS."
>
>     This is to ensure that early in the process, DOTS and the
>     Transport Area will talk to each other in order to double check
>     your requirements and what is possible in a (congested downstream)
>     network environment.
>