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

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:[e-mail]]
> Envoyé : vendredi 30 novembre 2018 11:58
> À : BOUCADAIR Mohamed TGI/OLN; Xialiang (Frank, Network Integration
> Technology Research Dept); Roman Danyliw; [e-mail]
> Objet : RE: WGLC on draft-ietf-dots-architecture-08
> 
> > -----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.
> 

[Med] It seems that you misunderstood the comments: I'm not suggesting to have this included in the arch draft.
Franck said "we don't explain the use cases and the benefits well enough in current drafts, or maybe I missed something". The expert above is to show that the expected behavior is already covered in the protocols I-Ds, but some changes are still required to the arch I-D.