Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dots-architecture-15

[tirumal reddy <[e-mail]>]

On Mon, 27 Jan 2020 at 15:36, tirumal reddy <[e-mail]> wrote:

> Hi Paul,
>
> Thanks for the review. Please see inline
>
> On Thu, 23 Jan 2020 at 21:09, Paul Kyzivat <[e-mail]> wrote:
>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-dots-architecture-15
>> Reviewer: Paul Kyzivat
>> Review Date: 2020-01-23
>> IETF LC End Date: 2020-01-27
>> IESG Telechat date: ?
>>
>> Summary:
>>
>> This draft is on the right track but has open issues, described in the
>> review.
>>
>> General:
>>
>> This is a very well written document! Even though I lack any knowledge
>> of the subject domain I was generally able to understand it.
>>
>> I had trouble classifying some of my issues below. I wanted to make them
>> be questions. But in a review such as this it makes more sense to state
>> them as issues of clarity in the text, since the reader should ideally
>> not be left with questions.
>>
>> Issues:
>>
>> Major: 0
>> Minor: 5
>> Nits:  0
>>
>> 1) MINOR: Resource Ownership:
>>
>> The 2nd paragraph of section 2.2.2 stresses that it is important for a
>> DOTS Server to verify that the DOTS Client owns the resources over which
>> it is requesting mitigation.
>>
>> There seems to be quite a lot hiding behind that requirement. In
>> particular, how is the server supposed to be in a position to do that
>> verification? This seems to require that the server have access to
>> ownership information. While that may be easy in some cases (e.g., when
>> the server is operated by the ISP that assigned the resources to the
>> client), in other cases it could be hard. I'd like to see more
>> discussion of this.
>>
>
> The exact mechanism to validate the resources owned by the DOTS client
> domain is deployment-specific. I can add the following example mechanisms
> to address your comment:
>
>    The exact mechanism for the DOTS servers to validate that the resources are within the
>    scope of the DOTS client domain is deployment-specific.  For example,
>    if the DOTS client domain leverages the DDoS mitigation service of
>    its Internet Transit Provider (ITP), it knows the prefixes assigned
>    to the DOTS client domain.  If the DDoS Mitigation is offered by a
>    third party DDoS mitigation service provider, and if the resources
>    are not owned by the requesting domain, it can impose penalties for
>    violating the service level agreement.  Alternatively, the DDoS
>    mitigation service provider and the DOTS client domain can opt to use
>    the identifier validation challenges discussed in [RFC8555] and
>    [I-D.ietf-acme-ip] to identify whether the DOTS client domain
>    actually controls the resources. Note that the challenges for
>    validating control of resources must be performed when no attack
>    traffic is present.
>
>
I have modified the above text as follows for better clarity:

   The exact mechanism for the DOTS servers to validate that the
resources are within the
   scope of the DOTS client domain is deployment-specific.  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.  The DDoS
   mitigation service provider and the DOTS client domain can opt to use
   the identifier validation challenges discussed in [RFC8555] and
   [I-D.ietf-acme-ip] to identify whether the DOTS client domain
   actually controls the resources.  The challenges for validating
   control of resources must be performed when no attack traffic is
   present and works only for "dns" and "ip" identifier types.  Further,
   if the DOTS client lies about the resources owned by the DOTS client
   domain, the DDoS mitigation service provider can impose penalties for
   violating the service level agreement.

-Tiru



>> 2) MINOR: Scope and lifetime of sessions:
>>
>> Section 3.1 states that a session can be a signal channel session or a
>> data channel session or both. I'm confused about the relationships here.
>>
>> If a session can consist of both, how are they related? Is there some
>> state that ties them together?
>>
>> Can a channel survive the loss and reestablishment of a TCP connection?
>> Or does the creation of a new connection create a new channel?
>>
>> What is the act that creates a new channel, and what destroys one?
>>
>> I'd like to see some more text explaining this.
>>
>
> All above details are discussed in the DOTS signal and data channel
> protocol drafts (currently in the RFC editor queue), added the following
> like to address your comment:
>
>    The DOTS server couples the DOTS signal and data channel sessions using the DOTS
>    client identity. The DOTS session is further elaborated in the DOTS
>    signal channel protocol defined in [I-D.ietf-dots-signal-channel] and
>    the DOTS data channel protocol defined in
>    [I-D.ietf-dots-data-channel].
>
>
>
>>
>> 3) MINOR: Feedback for recursive mitigation:
>>
>> Section 3.2.3 says:
>>
>>     ... To maximize
>>     mitigation visibility to the DOTS client, however, the recursing
>>     domain SHOULD provide recursed mitigation feedback in signals
>>     reporting on mitigation status to the DOTS client.  For example, the
>>     recursing domain's mitigator should incorporate into mitigation
>>     status messages available metrics such as dropped packet or byte
>>     counts from the recursed mitigation.
>>
>> This seems to imply that feedback from So to Cn is routed to Mn for
>> merging with Mn's feedback. That seems to violate the architecture. Can
>> the feedback from So be routed by Gn back to Cc?
>>
>
> Yes, clarified text as follows:
>
>    For example, the recursing domain's DOTS server should incorporate into mitigation
>    status messages available metrics such as dropped packet or byte
>    counts from the recursed domain's DOTS server.
>
>
>
>>
>> Can this be clarified?
>>
>> 4) MINOR: Security of recursive mitigation:
>>
>> The last paragraph of section 3.2.3 says:
>>
>>     Deployment of recursive signaling may result in traffic redirection,
>>     examination and mitigation extending beyond the initial bilateral
>>     relationship between DOTS client and DOTS server.  As such, client
>>     control over the network path of mitigated traffic may be reduced.
>>     DOTS client operators should be aware of any privacy concerns, and
>>     work with DOTS server operators employing recursive signaling to
>>     ensure shared sensitive material is suitably protected.
>>
>> This sounds like hand waving. Am I right in thinking this is talking
>> about incorporating the details of recursion in the service level
>> agreement?
>>
>
> Yes, will add the following line:
>
>    Typically there is a contractual Service Level Agreement (SLA) negotiated among
>    the DOTS client domain, the recursed domain and the recursing domain
>    to meet the privacy requirements of the DOTS client domain.
>
>
>
>>
>> 5) MINOR: Normative references:
>>
>> I was surprised by the scarcity of normative references. I went looking
>> for MUSTs referencing RFCs and found three: RFC8612 (DOTS Requirements),
>> and RFCs 5389 and 7350 (STUN related). Please consider making these
>> normative references.
>>
>
> Done (Replaced RFC5389 with
> https://tools.ietf.org/html/draft-ietf-tram-stunbis-21).
>
> Cheers,
> -Tiru
>