Re: [tsvwg] New Version Notification for draft-nagesh-sctp-auth-4895bis-00.txt

[Maksim Proshin <[e-mail]>]

Hi Nagesh,
I went through your draft and have a few comments.
As far as I understood there are only two technical issues that you want to address in the bis document:

1.       Negotiation procedure.
You’re right saying that some SCTP implementations rely on RFC 5061 instead of the negotiation mechanism prescribed by RFC 4895. Considering that RFC 4895 was published earlier than RFC 5061 and it clearly describes how the AUTH extension should be negotiated, I would say that this is an implementation bug in those SCTPs rather than the specification bug.
Moreover, I think that your proposal with “The supported Extensions parameter as defined in RFC 5061 section 4.2.7 MUST be exchanged” is even worse as it may lead to interoperability issues with old implementations which follow RFC 4895 only. If you really want to improve it, I would clarify that both mechanisms may be used to enable the extension. This is how some implementations do it today. Anyway, not sure that such improvement would require the bis document. In my view an errata should be enough here.

2.       Unsupported HMAC Identifier Error Cause.
I don’t see the use case where it could be used. The RFC clearly specifies that ERROR with such cause should be sent in response to the AUTH chunk which includes only one HMAC id. There is also MUST in the negotiation procedure which secures that at least one HMAC id will be supported. In which case there is a need to report multiple errors?
I also wonder how existing implementations will react on multiple unsupported ids as they expect just one id today, so it’s also a potential issue. If there is really such case, I would send multiple ERRORs back which is then aligned with RFC 4895. Have you checked it with lksctp or any other implementations? Why do you think it’s so important to address this improvement and especially as the bis?
The rest of your changes are clarifications or editorial changes in my view. Have I missed something?
The only real problem that I see today in RFC 4895 is “The HMAC algorithm based on SHA-1 MUST be supported…”. That algorithm is not recommended anymore and I would remove all MUSTs towards it. However, I would publish an errata on this instead of the bis.
BR, Maxim
---------- Forwarded message ---------
From: Nagesh shamnur <[e-mail]<mailto:[e-mail]>>
Date: Mon, Nov 4, 2019 at 4:03 PM
Subject: Re: [tsvwg] New Version Notification for draft-nagesh-sctp-auth-4895bis-00.txt
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: Ashutosh prakash <[e-mail]<mailto:[e-mail]>>

Dear TSVWG members,
                With this draft I want to highlight one key issue with AUTH 4895 RFC which doesn’t address the scenario in which one of the communicating peer doesn’t support AUTH feature. Apart from this key issue to also addresses many other issues (both technical and editorial). I would like to present the same in upcoming IETF 106 Singapore meeting.  Request members to review the same and provide me with your valuable comments.

Regards,
Nagesh S

From: Nagesh shamnur
Sent: 23 July 2019 11:58
To: '[e-mail]<mailto:[e-mail]>' <[e-mail]<mailto:[e-mail]>>
Cc: Ashutosh prakash <[e-mail]<mailto:[e-mail]>>
Subject: Fwd: New Version Notification for draft-nagesh-sctp-auth-4895bis-00.txt

Dear Chairs & Members,
                As per the points which I had posted earlier on mailing list regarding the issues/enhancements that needs to be done to SCTP Auth RFC 4895, I have put across all of them in the draft and is available as per the announcement mail below. Request all to provide review and provide your valuable comments and feedback.

Regards,
Nagesh S


---------- Forwarded message ---------
From: <[e-mail]<mailto:[e-mail]>>
Date: Mon, 22 Jul 2019 at 15:14
Subject: New Version Notification for draft-nagesh-sctp-auth-4895bis-00.txt
To: Nagesh Shamnur <[e-mail]<mailto:[e-mail]>>



A new version of I-D, draft-nagesh-sctp-auth-4895bis-00.txt
has been successfully submitted by Nagesh Shamnur and posted to the
IETF repository.

Name:           draft-nagesh-sctp-auth-4895bis
Revision:       00
Title:          Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) bis
Document date:  2019-07-21
Group:          Individual Submission
Pages:          20
URL:            https://www.ietf.org/internet-drafts/draft-nagesh-sctp-auth-4895bis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-nagesh-sctp-auth-4895bis/
Htmlized:       https://tools.ietf.org/html/draft-nagesh-sctp-auth-4895bis-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-nagesh-sctp-auth-4895bis


Abstract:
   This document obsoletes RFC4895 if approved.  This document describes
   a new chunk type, several parameters, and procedures for the Stream
   Control Transmission Protocol (SCTP).  This new chunk type can be
   used to authenticate SCTP chunks by using shared keys between the
   sender and receiver.  The new parameters are used to establish the
   shared keys.

   This document describes the limitations with the current SCTP AUTH
   RFC4895 and thus enhances the document to resolve such ambiguities
   and thus strengthen the overall AUTH procedure.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat