Hi Dan and Ben,
the updated text is below. I greatly appreciate your feedback.
NEW TEXT:
A STAMP
Session-Sender MAY generate a locally unique STAMP Session Identifier
(SSID). The SSID is a two-octet-long non-zero unsigned integer.
SSID generation policy is implementation-specific.
[I-D.gont-numeric-ids-generation] thoroughly analyzes common
algorithms for identifier generation and their vulnerabilities. For
example, an implementation can use algorithms described in
Section 7.1 of [I-D.gont-numeric-ids-generation]. An implementation
MUST NOT assign the same identifier to different STAMP test sessions.
Regards,
Greg
On Mon, Jul 20, 2020 at 7:01 PM Greg Mirsky <gregimirsky@xxxxxxxxx> wrote:
>
> Hi Ben,
> thank you for the suggestions. Would the Informational reference to
> draft-gont-numeric-ids-generation be reasonable?
>
> Regards,
> Greg
>
> On Mon, Jul 20, 2020 at 6:48 PM Benjamin Kaduk <kaduk@xxxxxxx> wrote:
> >
> > Thanks Dan.
> >
> > Greg, my recommendation would be to refer to the appopriate section of
> > https://tools.ietf.org/html/draft-gont-numeric-ids-generation-03 for the
> > needs in question. My understanding is that STAMP needs only unique (not
> > ordered) session IDs, and that furthermore, an occasional accidental
> > collision would not be catastrophic, in which case we can use the
> > "Uniqueness (soft failure)" characterization of Section 7.1 of the linked
> > document.
> >
> > -Ben
> >
> > On Sat, Jul 18, 2020 at 09:37:08AM +0300, Dan Romascanu wrote:
> > > Greg's understanding of my comment is correct.
> > >
> > > Regards,
> > >
> > > Dan
> > >
> > >
> > > On Sat, Jul 18, 2020 at 2:56 AM Greg Mirsky <gregimirsky@xxxxxxxxx> wrote:
> > >
> > > > Hi Ben,
> > > > thank you for the reference, very helpful. As you've noticed, this method
> > > > mentioned as an example. Would you suggest referencing another technique?
> > > > As I understood, Dan's comment was not specific to the sequential increment
> > > > allocation policy but to provide some guidance to an implementor.
> > > >
> > > > Regards,
> > > > Greg
> > > >
> > > > On Fri, Jul 17, 2020 at 3:39 PM Benjamin Kaduk <kaduk@xxxxxxx> wrote:
> > > >
> > > >> Hi again Greg :)
> > > >>
> > > >> Reading Dan's review reminded me of one other point (inline)...
> > > >>
> > > >> On Thu, Jul 02, 2020 at 12:22:04PM -0700, Greg Mirsky wrote:
> > > >> > Hi Dan,
> > > >> > thank you for your review, detailed questions, and helpful suggestions.
> > > >> > Please find my answers and notes below tagged GIM>>.
> > > >> >
> > > >> > Regards,
> > > >> > Greg
> > > >> >
> > > >> > On Mon, Jun 29, 2020 at 8:02 AM Dan Romascanu via Datatracker <
> > > >> > noreply@xxxxxxxx> wrote:
> > > >> >
> > > >> > > Reviewer: Dan Romascanu
> > > >> > > Review result: Ready with Issues
> > > >> > >
> > > >> > > I am the assigned Gen-ART reviewer for this draft. The General Area
> > > >> > > Review Team (Gen-ART) reviews all IETF documents being processed
> > > >> > > by the IESG for the IETF Chair. Please treat these comments just
> > > >> > > like any other last call comments.
> > > >> > >
> > > >> > > For more information, please see the FAQ at
> > > >> > >
> > > >> > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> > > >> > >
> > > >> > > Document: draft-ietf-ippm-stamp-option-tlv-06
> > > >> > > Reviewer: Dan Romascanu
> > > >> > > Review Date: 2020-06-29
> > > >> > > IETF LC End Date: 2020-07-06
> > > >> > > IESG Telechat date: Not scheduled for a telechat
> > > >> > >
> > > >> > > Summary: Ready with issues
> > > >> > >
> > > >> > > This is a clear, well-written document. There are a few minor issues
> > > >> that
> > > >> > > would
> > > >> > > benefit from clarifications and possible edits before approval.
> > > >> > >
> > > >> > > Major issues:
> > > >> > >
> > > >> > > Minor issues:
> > > >> > >
> > > >> > > 1. Section 3. Is there any recommended strategy to generate SSIDs? Are
> > > >> > > these
> > > >> > > supposed to be generated sequentially? Randomly? How soon is the 16
> > > >> -bit
> > > >> > > space
> > > >> > > supposed to wrap-up? Some clarification would be useful I believe.
> > > >> > >
> > > >> > GIM>> Because test sessions, in general, will be performed for different
> > > >> > periods of time, implementation will need to manage the pool of
> > > >> available
> > > >> > identifiers. I agree, the initial allocation may use sequential
> > > >> ascending
> > > >> > increment by one method, but at some point, it will be
> > > >> > "get-the-next-available number". I propose to update the text as
> > > >> follows:
> > > >> > OLD TEXT:
> > > >> > A STAMP
> > > >> > Session-Sender MAY generate a locally unique STAMP Session Identifier
> > > >> > (SSID). SSID is two octets long non-zero unsigned integer.
> > > >> > NEW TEXT:
> > > >> > A STAMP
> > > >> > Session-Sender MAY generate a locally unique STAMP Session Identifier
> > > >> > (SSID). SSID is two octets long non-zero unsigned integer. SSID
> > > >> > generation
> > > >> > policy is implementation-specific. For example, sequentially
> > > >> ascending
> > > >> > incremented by one method could be used for the initial allocation of
> > > >> > SSID.
> > > >> > Because of test sessions lasting different time an implementation
> > > >> that
> > > >> > uses
> > > >> > SSID MUST monitor the pool of available identifiers. An
> > > >> implementation
> > > >> > SHOULD NOT assign the same identifier to different STAMP test
> > > >> sessions.
> > > >>
> > > >> I would actually recommend against mentioning the "sequential increment"
> > > >> strategy. There's some justification for why in
> > > >> draft-gont-numeric-ids-sec-considerations (and more in the references),
> > > >> which I just completed my AD Evaluation of with intent to AD sponsor as a
> > > >> BCP.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Ben
> > > >>
> > > >
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
