Re: [Dots] WGLC on draft-ietf-dots-architecture-08

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

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Friday, November 30, 2018 12:37 PM
> To: Xialiang (Frank, Network Integration Technology Research Dept)
> <[e-mail]>; Konda, Tirumaleswar Reddy
> <[e-mail]>; Roman Danyliw <[e-mail]>;
> [e-mail]
> Subject: RE: WGLC on draft-ietf-dots-architecture-08
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is safe.
> 
> Hi Frank,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Xialiang (Frank, Network Integration Technology Research Dept)
> > [mailto:[e-mail]]
> > Envoyé : vendredi 30 novembre 2018 01:44 À : Konda, Tirumaleswar
> > Reddy; BOUCADAIR Mohamed TGI/OLN; Roman Danyliw; [e-mail]
> Objet :
> > 答复: WGLC on draft-ietf-dots-architecture-08
> >
> > Hi Tiru and Med,
> > Please see inline:
> >
> > -----邮件原件-----
> > 发件人: Dots [mailto:[e-mail]] 代表 Konda, Tirumaleswar
> Reddy
> > 发送时间: 2018年11月30日 0:03
> > 收件人: [e-mail]; Roman Danyliw <[e-mail]>;
> > [e-mail]
> > 主题: Re: [Dots] WGLC on draft-ietf-dots-architecture-08
> >
> > > -----Original Message-----
> > > From: [e-mail]
> <[e-mail]>
> > > Sent: Thursday, November 29, 2018 7:35 PM
> > > To: Konda, Tirumaleswar Reddy
> <[e-mail]>;
> > > Roman Danyliw <[e-mail]>; [e-mail]
> > > Subject: RE: WGLC on draft-ietf-dots-architecture-08
> > >
> > > This email originated from outside of the organization. Do not click
> > > links or open attachments unless you recognize the sender and know
> > > the
> > content is safe.
> > >
> > > Tiru,
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Konda, Tirumaleswar Reddy
> > > > [mailto:[e-mail]]
> > > > Envoyé : jeudi 29 novembre 2018 14:25 À : BOUCADAIR Mohamed
> > > > TGI/OLN; Roman Danyliw; [e-mail] Objet :
> > > > RE: WGLC on draft-ietf-dots-architecture-08
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Dots <[e-mail]> On Behalf Of
> > > > > [e-mail]
> > > > > Sent: Thursday, November 29, 2018 2:01 PM
> > > > > To: Roman Danyliw <[e-mail]>; [e-mail]
> > > > > Subject: Re: [Dots] WGLC on draft-ietf-dots-architecture-08
> > > > >
> > > > >
> > > > >
> > > > > Hi Roman, all,
> > > > >
> > > > > I support this draft to be sent to the IESG for publication.
> > > > >
> > > > > Some easy-to-fix comment, though:
> > > > >
> > > > > (1) The document cites [I-D.ietf-dots-requirements] in may
> > > > > occurrences. I suggest these citations to be more specific, that
> > > > > is to point the specific
> > > > REQ# or
> > > > > the section. Doing so would help readers not familiar with DOTS
> > > > > documents
> > > > to
> > > > > easily link the various pieces.
> > > > >
> > > > > (2) I used to point people to the DOTS architecture I-D when I
> > > > > receive comments/questions about the notion of "DOTS session"
> > > > > and to the Requirements I-D for clarification about DOTS
> > > > > channels. It seems that some clarifications are needed in the
> > > > > architecture I-D to explain for readers
> > > > not
> > > > > familiar with all DOTS documents, for example:
> > > > > - the link with the underlying transport sessions/connections
> > > > > and security associations.
> > > > > - mitigations are not bound to a DOTS session but to a DOTS
> > client/domain.
> > [Frank]: is there some specific examples to clarify this point I feel
> > we don't explain the use cases and the benefits well enough in current
> > drafts, or maybe I missed something.
> >
> 
> [Med] Adding the clarification I proposed into the architecture I-D would fix this,
> IMHO.
> 
> FWIW, we do have text for this in the protocol I-Ds, e.g.,
> 
> ==
>    In both DOTS signal and data channel sessions, the DOTS client MUST
>    authenticate itself to the DOTS server (Section 8).  The DOTS server
>    MAY use the algorithm presented in Section 7 of [RFC7589] to derive
>    the DOTS client identity or username from the client certificate.
>    The DOTS client identity allows the DOTS server to accept mitigation
>    requests with scopes that the DOTS client is authorized to manage.
> 
>    The DOTS server couples the DOTS signal and data channel sessions
>    using the DOTS client identity and optionally the 'cdid' parameter
>    value, so the DOTS server can validate whether the aliases conveyed
>    in the mitigation request were indeed created by the same DOTS client
>    using the DOTS data channel session.  If the aliases were not created
>    by the DOTS client, the DOTS server MUST return 4.00 (Bad Request) in
>    the response.
> 
>    The DOTS server couples the DOTS signal channel sessions using the
>    DOTS client identity and optionally the 'cdid' parameter value, and
>    the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to
>    detect duplicate mitigation requests.  If the mitigation request
>    contains the 'alias-name' and other parameters identifying the target
>    resources (such as 'target-prefix', 'target-port-range', 'target-
>    fqdn', or 'target-uri'), the DOTS server appends the parameter values
>    in 'alias-name' with the corresponding parameter values in 'target-
>    prefix', 'target-port-range', 'target-fqdn', or 'target-uri'.

Most of the details in the above paragraphs are protocol specific and discussed in the signal channel draft, no need to re-iterate in the architecture draft.

-Tiru

> ==
> 
> 
> > > > >
> > > > > (3) The signal channel I-D uses "DOTS signal channel session",
> > > > > "DOTS signal channel sessions" and "DOTS data channel session"
> > > > > to refer to specific DOTS sessions. I'd like to have these terms
> > > > > introduced also in the
> > > arch I-D.
> > > > >
> > > > > BTW, the signal channel uses in few occurrences "DOTS session";
> > > > > those can
> > > > be
> > > > > changed to "DOTS signal channel session". There is no occurrence
> > > > > of "DOTS session" in the data channel I-D.
> > > >
> > > > I don't see a need to modify the "DOTS session" discussed in the
> > > > signal channel draft,
> > > > https://tools.ietf.org/html/draft-ietf-dots-architecture-
> > > > 07#section-3.1 defines the term "DOTS session".
> > >
> > > [Med] I used to had the same opinion till recently. The comments I'm
> > > getting from people is that the articulation between the various
> > > terms is
> > not that clear.
> > > We collectively need to double check this and make required changes,
> > > including simplifying the terminology. We are using the following
> > > terms in the various I-Ds:
> > >
> > > * DOTS session
> > > * DOTS signal channel
> > > * DOTS data channel
> > > * DOTS signal channel session
> > > * DOTS data channel session
> > > * established signal channel
> > > * established data channel
> > [Frank]: do we still use the terminology of "DOTS signal channel" and
> > "DOTS data channel" somewhere? They are the draft title. And if they
> > still exist, what is the relation between the channels and the sessions?
> >
> 
> [Med] The notion of "channel" is already defined in the Requirements I-D. I do
> think that one is clear.
> 
> The architecture I-D defines the notion of "DOTS session", but some changes
> are still needed. The changes discussed in this thread will help clarifying what is
> the relationship between a channel and the session or set of sessions bound to
> it.
> 
> [snip]
> >
> > >
> > > >
> > > > The DOTS signal data channel session is a mutually authenticated
> > > > DOTS session between DOTS agents.
> > > >
> > >
> > > [Med] I guess you meant s/signal data channel/signal channel.
> >
> > I don't see the need for the above line, if we add the following line:
> >  A DOTS signal channel session is associated with a single transport
> > connection (e.g. TCP or UDP session) and an ephemeral security
> > association (e.g. a TLS or DTLS session).
> >
> > > Putting that
> > > aside, and more importantly, a reader will then have troubles to
> > > parse the
> > > following:
> > >
> > > "Conversely, a
> > >    DOTS session cannot exist without an established signal channel: when
> > >    an established signal channel is terminated for any reason, the DOTS
> > >    session is also said to be terminated."
> >
> > Removing the above line should avoid the confusion.
> >
> > -Tiru
> >
> > >
> > >
> > > > DOTS data channel draft is not using the term "DOTS data channel
> > > > session", we can fix the signal channel draft to use "DOTS data
> > > > channel" instead of "DOTS data channel session".
> > [Frank]: why can we use the term " DOTS data channel session" to make
> > it consistent with "DOTS signal channel session"?
> >
> 
> [Med] Perhaps I missed your point, but the signal channel is already using
> "DOTS data channel session".