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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: Dots <[e-mail]> On Behalf Of Warren Kumari via
> Datatracker
> Sent: Wednesday, February 5, 2020 11:01 PM
> To: The IESG <[e-mail]>
> Cc: Roman Danyliw <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> 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.
> 
> 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...

Thanks.

> 
> 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).

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
> DISCUSS point - I really really think that this bit should be either carefully
> revised, or, better yet, just struck...

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
> 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

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

Cheers,
-Tiru

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