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

[Maksim Proshin <[e-mail]>]

Hi Nagesh,


I still have the same concerns so please see my clatifications below inline.


BR, Maxim


________________________________
From: Nagesh shamnur <[e-mail]>
Sent: 13 November 2019 17:17
To: Maksim Proshin; [e-mail]
Cc: Ashutosh prakash
Subject: RE: [tsvwg] New Version Notification for draft-nagesh-sctp-auth-4895bis-00.txt


Dear Maksim,

                Thanks for reviewing the draft and sharing your perspective. Kindly find my reply inline.



Regards,

Nagesh S



From: Maksim Proshin [mailto:[e-mail]]
Sent: 13 November 2019 18:37
To: Nagesh shamnur <[e-mail]>; [e-mail]
Cc: Ashutosh prakash <[e-mail]>
Subject: RE: [tsvwg] New Version Notification for draft-nagesh-sctp-auth-4895bis-00.txt



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.

[Nagesh]: Major implementations such as lksctp on receiving side mandatorily expects this parameter to be present in the request which actually is not correct. Several attempts in the past to correct this issue in lksctp was rejected and the Michael Tuxen, has replied saying that this parameter should have been present in the request message at the first place which I am quoting here. Moreover, sending this parameter mandatorily would not break the interoperability with old implementations confirming to RFC 4895 only since the supported extension parameter is of type 0x8008 with upper 2 bits as 10. Receiving node will ignore supported extension parameter and continue processing without any error.

“Hi Vlad,



the EXTENSIONS parameter should have been there right from the

beginning....

”

https://sourceforge.net/p/lksctp/mailman/message/20743069/

[Maxim] First of all, I don't really like that you refer to only a part of Michael's response. In his response he also clearly responded that RFC4895 has no requirement on EXTENSIONS and thus lksctp doesn't follow the RFC. Your reasoning is based on a fact that this problem was not fixed in lksctp (even though the problem is known for years) which forces other implementations to also enable SCTP-AUTH through EXTENSIONS. Now you propose to fix the RFC instead. Is it a right approach?

Then in my view the only way to really improve the situation is to allow both mechanisms as some SCTP implementations already do it today. I want to avoid the situation when after the update some SCTP implementations will stop to accept the existing mechanism of RFC4895 which will result in exactly the same situation as you describe with lksctp. I'm sure it will take years untill all deployments are aligned with the new mechanism and during that time preiod there might be negotiation issues of SCTP-AUTH. Do you really want to bring it? I guess no, so the improvement should consider that any of the mechanisms must be accepted.


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?

[Nagesh]: This is added keeping extensibility in mind. Current RFC supports only SHA-1 and SHA-256, but in reality there are lot many variants of SHA which is available and being used SHA-224, SHA-256, SHA-384, SHA-512. Sender supports all these variants and what if receiver supports only SHA-256. With the new packet format, receiver will be better equipped to respond in the single message which is not supported rather than sending multiple error message which involves multiple RTTs.

[Maxim] I understand your improvement but I don't see your use case. Following RFC4895 SCTP will never report multiple such errors. Is it something that potentially will be inroduced in the future and you don't know the use case yet? If you know it, can you describe it exactly? Again, to introduce such change, we should be sure that it doesn't bring any issue. I don't know how all existing SCTP implementations would react on multiple Ids in the error cause.


The rest of your changes are clarifications or editorial changes in my view. Have I missed something?

[Nagesh]: The key issue which draft is trying to address is, anomaly with respect to AUTH negotiation procedure. When the client supports AUTH but server doesn’t support it, with existing implementation, client continues to send the data chunk with AUTH chunk and server continuously discards the packet resulting in not a single byte of data exchanged between the SCTP applications. Draft address this issue on how handle such a scenario.

I am also attaching the list of issues which I had earlier reported in the mailing list which covers all the issues which I am trying to address in this draft. I am attaching the link to it for your kind reference.

https://mailarchive.ietf.org/arch/msg/tsvwg/uBVvpLq8JfctCpPT1IoFtgH6eps

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