Subject: [Dots] Warren Kumari's No Objection on draft-ietf-dots-architecture-16: (with COMMENT)

From: Warren Kumari via Datatracker <[email-masked]>
Date: Wed, 05 Feb 2020 09:31:01 -0800

Warren Kumari has entered the following ballot position for
draft-ietf-dots-architecture-16: 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.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

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

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

Firstly, thank you for a well written, and easy to understand document -- I
personally always find architecture type documents helpful...

I do have a few non-blocking comments:
1: "For example, if the DOTS client domain leverages the DDoS mitigation
service of its Internet Transit Provider (ITP), the ITP knows the prefixes
assigned to the DOTS client domain. However, if the DDoS Mitigation is offered
by a third party DDoS mitigation service provider, it does not know the
resources owned by the DOTS client domain." This is vastly oversimplifying the
real-world, to the point that it is harmful / propagates dangerous
misconceptions. ISPs may or may not know the prefixes assigned to their
customers - they really *should* know the prefixes that the client is choosing
to announce to them, but the client may have other prefixes which they only
announce through other transits (yes, in this case this ISP would only be
providing mitigations for prefixes announced to it, but this isn't clear). In
addition, if the DDoS mitigation is provides by a 3rd party, it could know what
resources are owned by the client -- in fact, it kind of has to if it is going
to agree to mitigate for those prefixes. Note that I *almost* made this a
DISCUSS point - I really really think that this bit should be either carefully
revised, or, better yet, just struck...

2: "Signal loss is not caused by links congested with attack traffic alone, and
as such mitigation requests triggered by signal channel degradation in either
direction may incur unnecessary costs, in network performance and operational
expense alike." The "operational expense" is vary vague - enabling DDoS
mitigations is almost definitely going to cause a user visible impact,
especially in the case where the  mitigator announces a BGP route to attract
traffic. Is this covered by 'operational expense'? This section also leaves out
the fact that there is likely a financial impact.

3: "The signal and data channels are loosely coupled, and may not terminate on
the same DOTS server." - s/may not/might not/. Every-time I'm sitting on a
plane and the safety briefing says that oxygen mask will fall from the ceiling
and that "the bag may not inflate" I have visions of IETFers (and similar
pedants!) sitting there and squeezing the bag to ensure that it doesn't... "the
bag *might* not inflate" is what is intended, and is also what you want :-P

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 6 Feb 2020 08:47:00 +0000

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of Warren Kumari via
> Datatracker
> Sent: Wednesday, February 5, 2020 11:01 PM
> To: The IESG <[email-masked]>
> Cc: Roman Danyliw <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: [Dots] Warren Kumari's No Objection on draft-ietf-dots-
> architecture-16: (with COMMENT)
> 
> CAUTION: External email. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> 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.)
> 
> 

Thanks.

> assigned to the DOTS client domain. However, if the DDoS Mitigation is
> offered by a third party DDoS mitigation service provider, it does not know
> the resources owned by the DOTS client domain." This is vastly
> oversimplifying the real-world, to the point that it is harmful / propagates
> dangerous misconceptions. ISPs may or may not know the prefixes assigned
> to their customers - they really *should* know the prefixes that the client is
> choosing to announce to them, but the client may have other prefixes which
> they only announce through other transits (yes, in this case this ISP would
> only be providing mitigations for prefixes announced to it, but this isn't clear).

Agreed (the intent of the example is to discuss PA addresses).

> In addition, if the DDoS mitigation is provides by a 3rd party, it could know
> what resources are owned by the client -- in fact, it kind of has to if it is going
> to agree to mitigate for those prefixes. 

The service level agreement may not include the prefixes used by the DOTS client domain (e.g., Enterprise network may switch ISPs, add new uplinks for multihoming, ISP renumbering etc.)

> Note that I *almost* made this a

The above text was recently added to address the comment from Gen-ART review, will modify the example as follows:

For example, if the DOTS client domain uses Provider-Aggregatable prefixes for its resources and 
leverages the DDoS mitigation service of the Internet Transit Provider (ITP), the ITP knows the prefixes assigned to the 
DOTS client domain because they are assigned by the ITP itself.

> 
> 2: "Signal loss is not caused by links congested with attack traffic alone, and as
> such mitigation requests triggered by signal channel degradation in either
> direction may incur unnecessary costs, in network performance and
> operational expense alike." The "operational expense" is vary vague -
> enabling DDoS mitigations is almost definitely going to cause a user visible
> impact, especially in the case where the  mitigator announces a BGP route to
> attract traffic. 

It depends on the DDoS mitigator capability (for example, scrubbing centers could be located across the world) or ISP could offer DDoS mitigation service and the user may not see any noticeable delay in the traffic when the mitigation is in progress. 
Further, content providers may use DDoS mitigation service all the time due to the frequency of attacks.

> Is this covered by 'operational expense'? 

Yes

>This section also
> leaves out the fact that there is likely a financial impact.

Updated line as follows for clarity:
Signal loss is not caused by links congested with attack traffic alone, and as such mitigation requests triggered
by signal channel degradation in either direction may incur unnecessary costs due to scrubbing traffic,
adversely impact network performance and operational expense alike.

> 
> 3: "The signal and data channels are loosely coupled, and may not terminate
> on the same DOTS server." - s/may not/might not/. Every-time I'm sitting on
> a plane and the safety briefing says that oxygen mask will fall from the ceiling

Barry raised the same comment, will fix in the next revision.

Cheers,
-Tiru

> 
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots