Subject: Re: [Gen-art] Gen-ART review of draft-ietf-dime-e2e-sec-req-04.txt

From: Jari Arkko <[email-masked]>
Date: Thu, 2 Jun 2016 16:24:28 +0300

Thanks for your review, and good questions, Christer. Authors, I have not seen a response or a new version. What’s up?

Jari

On 07 May 2016, at 17:48, Christer Holmberg <[email-masked]> wrote:

> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
> 
> Document:                                     draft-ietf-dime-e2e-sec-req-04
> Reviewer:                                        Christer Holmberg
> Review Date:                                7 May 2016
> IETF LC End Date:                        12 April 2016
> IETF Telechat Date:                    N/A
> Summary:                                      The document is well written, and almost ready for publication is informational RFC. However, I have a few editorial issues, related to the Introduction, that I ask the authors to address.
> Major Issues:                                None
> Minor Issues:                                None
> Editorial Issues:
> 
> Q_ABSTRACT_1:
> 
> The text says that the draft “discusses” requirements. In my opinion it should say “defines” or “specifies”.
> 
> 
> Q_INTRODUCTION_1:
> 
> Please add references for TLS (for TCP) and DTLS (for SCTP).
> 
> 
> Q_INTRODUCTION_2:
> 
> The text says: “…or alternative security mechanisms independent of Diameter (e.g., IPsec) is used.”
> 
> 2A: I guess it should be “are used”?
> 
> 2B: I am not sure I understand what “independent of Diameter” means.
> 
> 
> Q_INTRODUCTION_3:
> 
> The text talks about security between non-neighbour nodes, while the draft name includes “e2e”. However, when reading Section 4, non-neighbour does not necessarily mean end-to-end. I think it would be good to explicitly clarify that in the Introduction.
> 
> 
> Q_INTRODUCTION_4:
> 
> The text says: “This document collects requirements for developing a solution to protect Diameter AVPs.”
> 
> 2A: It needs to be clear that it’s about protecting AVPs between non-neighbour nodes.
> 
> 2B: Instead of “collect”, please use the same terminology as in the Abstract.
> 
> 
> Q_INTRODUCTION_5:
> 
>               Please enhance AVP on first occurrence. Currently it’s not done until Section 3.
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Jouni <[email-masked]>
Date: Thu, 2 Jun 2016 06:49:14 -0700

Hi,

Right. My fault, I just missed the mail from Christer. I’ll get back to it asap.

- Jouni

> On 02 Jun 2016, at 06:24, Jari Arkko <[email-masked]> wrote:
>

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 2 Jun 2016 07:58:07 -0700

Thanks Christer,

And sorry for not responding earlier.. See my comments inline.

5/7/2016, 7:48 AM, Christer Holmberg kirjoitti:
>
>
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>
>
>
> Review Date:                                7 May2016
> Summary:                                      The document is well
> written, and almost ready for publication is informational RFC. However,
> I have a few editorial issues, related to the Introduction, that I ask
> the authors to address.
>
> Major Issues:                                None
>
> Minor Issues:                                None
>
> Editorial Issues:
>
>
>
> Q_ABSTRACT_1:
>
>
>

Ack. "specifies" sounds as a good choice.

> Please add references for TLS (for TCP) and DTLS (for SCTP).

Ack.

> 2A: I guess it should be “are used”?

Yes.. the whole sentence IMO reads badly, so I have some overall 
rewording proposals.

OLD:
    The Diameter base protocol specification [2] offers security
    protection between neighboring Diameter peers and mandates that peer
    connections must be protected by TLS (for TCP), DTLS (for SCTP) or
    alternative security mechanisms independent of Diameter (e.g., IPsec)
    is used.

NEW:
    The Diameter base protocol specification [RFC6733] defineds security
    protection between neighboring Diameter peers. The Diameter
    mandates that peer connections must be protected by TLS [RFC5246]
    (for TCP), DTLS [RFC6083] (for SCTP) or using security mechanisms
    that are independent of Diameter such as IPsec [RFC4301].

> 2B: I am not sure I understand what “independent of Diameter” means.

It is actually quite direct quotation from base protocol RFC6733 text. 
Basically meaning when using (D)TLS the Diameter node itself has to 
implement/terminate the security, while with IPsec it does not 
necessarily need to do anything (e.g., when site-to-site IPsec is in 
place).

>
> Q_INTRODUCTION_3:
>
> The text talks about security between non-neighbour nodes, while the
> draft name includes “e2e”. However, when reading Section 4,
> non-neighbour does not necessarily mean end-to-end. I think it would be
> good to explicitly clarify that in the Introduction.
>

Ok. This terminology issue was brought up also in two other review 
afair. I would actually propose rewording the document name, since that 
seems to be the only place where "e2e" is really misplaced and the 
document name is goofy in any case.

OLD:
Diameter AVP Level Security End-to-End Security: Scenarios and
                               Requirements
NEW:
AVP Level Security for Non-neighboring Diameter Nodes: Scenarios and
                               Requirements

and also..

OLD:
Diameter End-to-End Security

NEW:
Diameter AVP Level Security

> 2A: It needs to be clear that it’s about protecting AVPs between

Ok.

> 2B: Instead of “collect”, please use the same terminology as in the

Ok. That will be 'specifies' then.

>               Please enhance AVP on first occurrence. Currently it’s not

Ack.

Thanks,
	Jouni

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Jun 2016 07:51:49 +0000

Hi Jouni,

I am happy with your clarifications and change suggestions.

Thanks!

Regards,

Christer

On 02/06/16 17:58, "Jouni Korhonen" <[email-masked]> wrote:

>> The text says that the draft ³discusses² requirements. In my opinion it
>> should say ³defines² or ³specifies².
>
>> The text says: ³Šor alternative security mechanisms independent of
>> Diameter (e.g., IPsec) is used.²
>>
>> 2A: I guess it should be ³are used²?
>>
>
>> 2B: I am not sure I understand what ³independent of Diameter² means.
>>
>
>> draft name includes ³e2e². However, when reading Section 4,
>> The text says: ³This document collects requirements for developing a
>> solution to protect Diameter AVPs.²
>>
>> 2A: It needs to be clear that it¹s about protecting AVPs between
>> non-neighbour nodes.
>>
>
>Ok.
>
>> 2B: Instead of ³collect², please use the same terminology as in the
>> Abstract.
>
>>               Please enhance AVP on first occurrence. Currently it¹s not
>> done until Section 3.
>>
>
>Ack.
>
>Thanks,
>	Jouni
>
>>