Subject: Re: [Dots] DOTS requirements (-01) feedback

From: Andrew Mortensen <[email-masked]>
Date: Fri, 8 Jul 2016 00:36:59 -0400

Thanks, Flemming. Comments inline.

> On Jun 29, 2016, at 10:38 AM, Flemming Andreasen <[email-masked]> wrote:
> 
> 1. DDoS (in DOTS) is not just about network devices and bandwidth but about resource constrained devices with network connectivity in general. We should make that clear throughout, because it affects our overall scope and data model.

What exactly do you have in mind when you talk about resource constrained devices? “Constrained” seems to have a strong association with IoT within the IETF.

> 1a) A specific example shows up in requirement OP-006, where we talk about addresses and prefixes, while on the other hand it does recognize that attacked resources may be identified by higher-level naming schemes, like SIP-URIs, E.164 numbers etc. It's not clear to me all of this is fully vetted and that we in fact always have an address or prefix indication - more discussion on this whole area is needed.

You’re right: OP-006 is self-contradictory in that it seems to define scope in terms of addresses and prefixes, while then giving as examples resource identifiers that are neither.

> 1b) Another example is DATA-003 which again is address focused. That may be enough, but we should discuss further (e.g. allow for extensibility to enable user-based whitelists)

What form do you anticipate user-based whitelists taking?

> 2. Need to get rid of relays and replace with DOTS Gateway. More importantly though, we need to consider what requirements we have on DOTS Gateways (if any).

Relay references have been removed from the upcoming revision. I’ve replaced them with a stub treatment of gateways to spur discussion of the gateway requirements.

> 3. Inter- and intra-domain shows up, however it's not really clear what we mean by that. Maybe this is something the architecture draft should clarify, because the requirements draft does seem to assume some level of familiarity with the overall architecture.

Agreed.

> 4. OP-008 talks about conflicting requests to DOTS servers. It's not clear if this requires DOTS servers to coordinate with each other, and if so, if that applies across administrative boundaries as well. Related to that last point, DOTS clients may have relationships with different provides (each of which will have DOTS servers), and there doesn't seem to be clarity on the requirements associated with that.

This was originally meant to cover the specific case of a DOTS client requesting e.g. a new mitigation with a scope overlapping with an existing mitigation. It sounds like a separate requirement should be added to discuss multi-homed DOTS client relationships with providers.

> 5. OP-009: Need to clarify how this caching works and in particular how it relates to DNS TTL values.

I came away from the Buenos Aires meeting with the impression that the WG had rejected this requirement, and I was prepared to remove it.

> 6. DATA-001 talks about "transactional" transport, however it's not clear what the transaction is actually for. Presumably it's for some higher-level construct in the "to-be-defined" data model, but it's not clear here. I'm also not clear on whether we really need that or standard e2e reliable message delivery wouldn't suffice.

Agreed, reliable messaging is adequate.

> 7. We need a section with requirements for the overall data model.
> 
> 8. The congestion control section states the transmission rate will be negligible and hence link congestion is not a concern. I think we need explicit requirements around that because I'm guessing we will ultimately need to have some form of congestion control in place.

Yes, I’m working on replacing it with something less naive.

andrew

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 8 Jul 2016 15:21:31 -0400

> What exactly do you have in mind when you talk about resource constrained devices? “Constrained” seems to have a strong association with IoT within the IETF.
Good point. I basically meant any device with a finite set of resources 
(and with the present state of technology, it would seem most devices 
fall in that category :-)

> What form do you anticipate user-based whitelists taking?
Identity, token, etc. would probably have been better choices of words. 
Basically, if you have some form of credential (non-address based), you 
could be white-listed.

> I came away from the Buenos Aires meeting with the impression that the WG had rejected this requirement, and I was prepared to remove it.
Ok - I don't recall, but that works for me too.
> Yes, I’m working on replacing it with something less naive.
Sounds good.

Thanks

-- Flemming

> andrew.