Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-moskowitz-dots-gre-00.txt

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 7 Mar 2016 20:59:06 +0000

Hello!

Comments inline ...

> From: Dots [mailto:[email-masked]] On Behalf Of ??Dan Wing
> Sent: Monday, February 08, 2016 8:08 PM
> To: Robert Moskowitz <[email-masked]>
> Cc: Gilbert Clark <[email-masked]>; [email-masked]
> Subject: Re: [Dots] Why GRE - Re: Fwd: New Version Notification for draft-
> moskowitz-dots-gre-00.txt
> 
> Can we back up to protocol requirements?  I expect lots of protocols can
> already meet most requirements, but without agreement on the protocol
> requirements, we will keep talking past each other with solutions.

+1.  Side-stepping the specific merits of using GRE, the case to use it for DOTS in this draft at times relies on additional requirements/constraints not yet articulated in the requirements draft (draft-ietf-dots-requirements-00).  We should tease those requirements out as they are potentially applicable to all solutions drafts.

(Hat off ...)
IMO, we should explore them by identifying instances of these requirements/constraints (what's a new requirement vs. a solution that comes with GRE?), discussing them individually (is this a requirement relative to the use cases? do we need new use cases?) and considering how to use them as criteria (add them to the requirements document? Apply MUST, SHOULD, etc.) to evaluate all other candidate protocol drafts.  

From the discussion of this draft on the list to date, I believe that at least the following ideas need further discussion or consideration for inclusion in the requirements draft:

** Stateless security (section 3.3.1)
** Reducing fate sharing (section 3.3.2)
** UDP is commonly blocked so DOTS should engineer around it (section 4, bullet 2) vs. OP-001 in the requirements drafts
** Required communications patterns, e.g., peer-to-peer (section 4, bullet 5)
** Name (and other?) resolution (and other bindings?) need to be negotiated in advance (Section 6.1) -- mentioned in IETF 94 meeting notes
** Traversing NATs
** Need to be deployable on switches and other non-dedicated mitigation devices.

I'd also suggest addressing a few nits in this -00 draft eventually:

** Using the terminology defined in the requirements draft.  For example, instead of "DOTS messaging" (section 3.1) and "DOT communication" (section 4) use "DOTS signal".  It will also make it clear which elements of DOTS GRE is tackling.

** Harmonizing the security considerations with the use case/requirements drafts.  This draft notes that blocking DOTS traffic; or disabling DOTS servers or clients are the key concerns.  In the requirements/use case drafts, the threat model is agent impersonation, traffic injection and signal blocking.

Roman

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 08 Mar 2016 06:42:18 +0700

On 8 Mar 2016, at 3:59, Roman D. Danyliw wrote:

> ** UDP is commonly blocked so DOTS should engineer around it (section 
> 4, bullet 2)

It is non-infrequently filtered in endpoint networks - all this means is 
that we need an alternative for situations in which a stateless 
transport won't work.

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

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 9 Mar 2016 09:23:20 -0500

On 03/07/2016 06:42 PM, Roland Dobbins wrote:
> It is non-infrequently filtered in endpoint networks - all this means 
> is that we need an alternative for situations in which a stateless 
> transport won't work.

Please help me here, as I am having problems with your semantics. To me:

non-infrequently == frequently

And I don't think that is what you mean?

Also I am having problems with the second point. Do you mean 
specifically UDP as the stateless transport, or stateless in general 
whatever may exist (call it STP  :) ).

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 09 Mar 2016 22:55:50 +0700

> non-infrequently == frequently

It was a typo, I meant not-infrequently.

> And I don't think that is what you mean?

That is precisely what I mean.

> whatever may exist (call it STP  :) ).

We need both a stateful and a stateless transport option, as has been 
discussed a great deal on-list and in DOTS WG meetings.  UDP is the most 
viable stateless option, for many reasons.