Re: [AVTCORE] Éric Vyncke's Discuss on draft-ietf-avtcore-rtp-scip-05: (with DISCUSS and COMMENT)

["[e-mail]" <[e-mail]>]

Eric,

Thank you for reviewing the document.  After consulting with others in the IETF, they state the following:

The IETF has routinely published documents encapsulating security protocols it did not develop without reviewing them.  For example, RFC 4186 documents EAP-SIM, RFC 4187 documents EAP-AKA, etc.  Both of those documents include a "Security claims" section (e.g., a statement of the security services provided, as required by RFC 3748), without a proof of the actual security of those services (which had well known issues, in the case of SIM in particular).


Regards,
Dan Hanson
General Dynamics Mission Systems

This message and/or attachments may include information subject to GD Corporate Policies 07-103 and 07-105 and is intended to be accessed only by authorized recipients.  Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties.  Recipients should refer to the policies or contract to determine proper handling.  Unauthorized review, use, disclosure or distribution is prohibited.  If you are not an intended recipient, please contact the sender and destroy all copies of the original message.

From: Eric Vyncke (evyncke) <[e-mail]>
Sent: Tuesday, December 5, 2023 10:12 AM
To: Hanson, Daniel C <[e-mail]>; [e-mail] <Dan.Hanson=[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Faller, Michael F <[e-mail]>; Maver, Keith M <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-avtcore-rtp-scip-05: (with DISCUSS and COMMENT)

External E-mail --- CAUTION: This email originated from outside GDMS. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Dan,

Finally, NATO has provided the IESG with a copy of the SCIP-210.

OTOH, the main point of my DISCUSS is about the claim in section 3 (background). There has been no security review by the IETF of SCIP-210, so how can an IETF standard track document claim:

"These capabilities include end-to-end security at the application layer, authentication of user identity, the ability to apply different security levels for each secure session, and secure communication over any end-to-end data connection."<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip-06#section-3-1>

I suggest removing this sentence from the I-D, it won't change the actual purpose of the I-D and I could then clear my current blocking DISCUSS.

Regards

-éric

From: [e-mail] <[e-mail]>
Date: Wednesday, 9 August 2023 at 16:14
To: Eric Vyncke (evyncke) <[e-mail]>, [e-mail] <Dan.Hanson=[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: RE: Éric Vyncke's Discuss on draft-ietf-avtcore-rtp-scip-05: (with DISCUSS and COMMENT)
Eric,

NATO may be a little slow to respond since probably many of the staff is on European summer holiday.  In the meantime, you can get an older version of SCIP-210 at https://www.iad.gov/SecurePhone/index.cfm.  Click SCIP Specification on the left side of the page, then scroll down to SCIP-210 Rev 3.6 which is the next to last item in the list.

SCIP-210 and supporting documents define SCIP (Secure Interoperable Communications Protocol) and demonstrates the statement "These capabilities include end-to-end security at the application layer, authentication of user identity, ..."


Regards,
Dan Hanson
General Dynamics Mission Systems

This message and/or attachments may include information subject to GD Corporate Policies 07-103 and 07-105 and is intended to be accessed only by authorized recipients.  Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties.  Recipients should refer to the policies or contract to determine proper handling.  Unauthorized review, use, disclosure or distribution is prohibited.  If you are not an intended recipient, please contact the sender and destroy all copies of the original message.

-----Original Message-----
From: Eric Vyncke (evyncke) <[e-mail]>
Sent: Tuesday, August 8, 2023 7:33 AM
To: [e-mail] <Dan.Hanson=[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Éric Vyncke's Discuss on draft-ietf-avtcore-rtp-scip-05: (with DISCUSS and COMMENT)

----
External E-mail --- CAUTION: This email originated from outside GDMS. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hello Dan,

Thank you for your prompt reply.

FYI, I have requested the SCIP standard, but I am still waiting for it.

Anyway, my blocking issue is different from Lars' one, but more on the assertion/claim in this I-D on the IETF stream: `These capabilities include end-to-end security at the application layer, authentication of user identity,`. First, it brings nothing to the actual purpose of the I-D, but more important nobody in the IETF community has analyzed the security properties of SCIP. I.e., suggest to simply remove this claim from the text.

See below for EV>

Hope this helps

-éric


?On 04/08/2023, 17:41, "iesg on behalf of [e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]> on behalf of Dan.Hanson=[e-mail] <mailto:[e-mail]>> wrote:


Éric,


Thank you for reviewing this document. Responses are inline below prefixed with [DH].




Dan Hanson
General Dynamics Mission Systems


This message and/or attachments may include information subject to GD Corporate Policies 07-103 and 07-105 and is intended to be accessed only by authorized recipients. Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties. Recipients should refer to the policies or contract to determine proper handling. Unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender and destroy all copies of the original message.


-----Original Message-----
From: Éric Vyncke via Datatracker <[e-mail] <mailto:[e-mail]>>
Sent: Friday, August 4, 2023 9:21 AM
To: The IESG <[e-mail] <mailto:[e-mail]>>
Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
Subject: Éric Vyncke's Discuss on draft-ietf-avtcore-rtp-scip-05: (with DISCUSS and COMMENT)


----
External E-mail --- CAUTION: This email originated from outside GDMS. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Éric Vyncke has entered the following ballot position for
draft-ietf-avtcore-rtp-scip-05: Discuss


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/about/groups/iesg/statements/handling-ballot-positions/ <https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/>
for more information about how to handle DISCUSS and COMMENT positions.




The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-scip/ <https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-scip/>






----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------




# Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05


Thank you for the work put into this document.


Please find below one blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.


Special thanks to Bernard Aboba for the shepherd's detailed write-up including
the WG consensus ***but it lacks*** the justification of the intended status,
this is related to my DISCUSS below.


I hope that this review helps to improve the document,


Regards,


-éric


# DISCUSS


As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/ <https://www.ietf.org/blog/handling-iesg-ballot-positions/>, a
DISCUSS ballot is a request to have a discussion on the following topics:


## Section 2


I am afraid that without free and public access to the IETF community (whether
informational or normative) to the SCIP protocol itself, the IETF stream cannot
publish any document (even informational or experimental) with the following
assertion/claim `These capabilities include end-to-end security at the
application layer, authentication of user identity,`. Suggest removing any such
claim from the text.


[DH] The most recent version of SCIP-210 can be requested via email from NATO at [e-mail] <mailto:[e-mail]> (this is email specified in Section 8 of the I-D). An older version is publicly available at https://www.iad.gov/SecurePhone/index.cfm. Section <https://www.iad.gov/SecurePhone/index.cfm.&nbsp;&nbsp;Section> 8 will be updated to explicitly state that requests for the SCIP-210 specification can be made via email.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------




# COMMENTS


## Abstract


Is there a reason why is SDP expanded and not RTP ?


[DH] The expansion of SDP can be removed.




## Section 1


Unsure whether the following text has a place into an IETF RFC `This document
provides a reference for network security policymakers, network equipment OEMs,
procurement personnel, and government agency and commercial industry
representatives.`. Suggest to remove it.


[DH] The intent was to emphasize that this I-D is focused on network devices and the information provided here-in identifies the SCIP media subtype as a valid codec to be allowed to traverse network devices. We are asking:
1. network device manufacturers include 'scip' as a known codec in their equipment
2. network security policymakers allow 'scip' to traverse their networks
3. procurement personnel be able to identify which network devices implement 'scip' when bidding for equipment

EV> the above was a suggestion, feel free to ignore

I wonder to wonder whether the USA has left NATO ? The text `SCIP is presently
implemented in United States and NATO` seems to indicate that the USA are not
included in NATO.


[DH] SCIP was first only implemented in the USA, then it was later provided to NATO. We deliberately made this distinction.

EV> suggest to rephrase as "SCIP was first implemented in the USA then in NATO member states" or something similar to capture the time line.

## Section 1.2


The DTX acronym is expanded twice and never used. Suggest to remove it.


[DH] The DTX acronym will be removed from the acronym list and from the text in section 3.1.


## Section 2


Per `Secure Communication Interoperability Protocol (SCIP) allows the
negotiation of several voice, data, and video applications`, it appears that
SCIP can also be used for *data*, but this document is only about video/audio.
I.e., some text should explain to the reader what happens to the data.


[DH] SCIP-210 defines proprietary encrypted 'data' protocols. Perhaps 'data' could be removed from this I-D to avoid confusion.

EV> this would be nice indeed

Please explain what is a STANAG or provide an informational reference to STANAG
5068.


[DH] STANAG = Standardization Agreements. "... a normative document that records an agreement among several or all NATO member states - ratified at the authorized national level - to implement a standard, in whole or in part, with or without reservation." Information about STANAG 5068 can found at: https://nso.nato.int/nso/nsdd/main/standards/stanag-details/7712/EN <https://nso.nato.int/nso/nsdd/main/standards/stanag-details/7712/EN> but the document cannot be downloaded from that site. We mentioned STANAG 5068 in the background section to emphasize the acceptance of SCIP by NATO, but it was not intended as a reference document for the I-D..

EV> lease expand STANAG at least

The reader will welcome explanations about the numbers in `scip/8000 and
scip/90000` (e.g., by a reference to section 5)


[DH] The text will be changed to "... audio/scip and video/scip, respectively, ..."


## Section 3.1


Should there be informative references for MELPe, G.729D ?


[DH] MELPe (RFC 8130) is listed in the informative references. G.729D (RFC 3551) is listed in the normative references. The citation links are made later in the document; they will be moved up to the first occurrence of those terms.


Is this subsection useful ? This document is about RTP payload and this
subsection is more fit for the SCIP endpoints themselves. But, I am neither a
transport nor an application expert, so, feel free to keep this subsection.


# NITS


The official name of the UNO member state is "United States of America" and not
simply "United States".


[DH] We used "United States" for brevity since it is unambiguous.

EV> unsure whether it is really unambiguous, suggest to use "USA" then.