Re: [sacm] Eric Rescorla's No Objection on draft-ietf-sacm-nea-swima-patnc-02: (with COMMENT)

[Eric Rescorla <[e-mail]>]

On Tue, Feb 20, 2018 at 6:21 AM, Schmidt, Charles M. <[e-mail]>
wrote:

> Hello Eric,
>
> Thank you very much for the comments. I have only two follow-up questions:
>
> >    An EID is a 4-byte unsigned integer that the SWIMA-PC assigns
> >    sequentially to each observed event (whether detected in real-time or
> > What byte order?
>
> Section 5.3 (Message Diagram Syntax) states that "Multi-octet fields
> representing numeric values MUST be sent in network (big-endian) byte
> order." I have tweaked this to simply say "All fields representing numeric
> values MUST be sent in network (big-endian) byte order". Is this sufficient
> or do feel that this should be reiterated in the individual field
> descriptions? (I did go through and make sure that every integer is
> explicitly "unsigned", per your other comment.)
>
>
Yeah, I make notes as I go and then left this one because I think that
might be confusing as people read in order.

I'm not sure what the best approach is, TBH. Maybe say it up front too?


>    event records MUST only contain events with EIDs that all come from
> >    the current Epoch.
> > How does the SWIMA-PC garbage collect? It seems like the answer is it can
> > just change epochs?
>
> You are correct. The second paragraph of section 3.7.1 (Event Identifiers)
> states that "In the case where a SWIMA-PC needs to reset its EID counter,
> either because it has exhausted all available EID values or because the
> SWIMA-PC's event log becomes corrupted, then a new EID Epoch MUST be
> selected." Apart from that passing mention, I don't believe the document
> makes any comment. Do you feel additional emphasis on this topic is
> necessary?
>

It confused me a bit. Perhaps you might say "or has exhausted the space
allowed for event storage"




>
> Finally, an aesthetic check on repeated fields. I have attempted the
> following:
> --------------
>                         1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Flags        |                Event Count                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Request ID Copy / Subscription ID                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       EID Epoch                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Last EID                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |               Last Consulted EID                              |
>    =================================================================
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                          EID                                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       Timestamp
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                            Timestamp
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                            Timestamp
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                            Timestamp
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                            Timestamp                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                   Record Identifier                           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |           Data Model Type PEN                 |Data Model Type|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Source Id Num |  Action       |   Software Identifier Length  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |              Software Identifier (variable length)            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Software Locator Length     |Software Locator (variable len)|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>               Figure 8: Software Identifier Events Attribute
>
>    Everything after the line of double bars (======) is repeated a
>    number of times equal to Event Count.
> -------------
>
> Do you feel that this clarifies the repeated fields in the diagram? The
> alternative would be to do something like:
>
>                         1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Flags        |                Event Count                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Request ID Copy / Subscription ID                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       EID Epoch                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Last EID                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |               Last Consulted EID                              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                            |
>    |    SUB-BLOCK (Event Count times)                   |
>    |                                                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Figure n: Main message
>
>                         1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                          EID                                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       Timestamp
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                            Timestamp
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                            Timestamp
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                            Timestamp
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                            Timestamp                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                   Record Identifier                           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |           Data Model Type PEN                 |Data Model Type|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Source Id Num |  Action       |   Software Identifier Length  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |              Software Identifier (variable length)            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Software Locator Length     |Software Locator (variable len)|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Figure M: Sub-block
>
> I'm interested in your thoughts as to which of these better clarifies the
> nature of the repeated fields.
>

I think the second is better, but as you say it's aesthetic.

FWIW, I usually do these big blockaf (e.g., timestamp) s by eliding the
horizontal bars rather than the vertical ones, but again, it's taste.

Best,
-Ekr



>
> Thanks again for your help.
>
> Charles
>
> > -----Original Message-----
> > From: Eric Rescorla [mailto:[e-mail]]
> > Sent: Monday, February 19, 2018 10:55 AM
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail]; Karen
> > O'Donoghue <[e-mail]>; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: Eric Rescorla's No Objection on draft-ietf-sacm-nea-swima-
> patnc-02:
> > (with COMMENT)
> >
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-sacm-nea-swima-patnc-02: No Objection
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > More detail in context at: https://mozphab-
> > ietf.devsvcdev.mozaws.net/D3336
> >
> > IMPORTANT
> > I consider the following comment important, though I have chosen to make
> > it a comment rather than a discuss.
> >
> >    Software records on an endpoint are generally not considered to be
> >    sensitive, although there can be exceptions to this generalization as
> >    noted in the section on Privacy Considerations.  In general, an
> >
> > I'm not sure where "generally" comes from. I consider it
> > sensitive and we know that people have been jailed for running certain
> > software.  Even the rest of this section provides strong evidence that
> > this is sensitive. So I think you should remove this claim and rewrite
> > this paragraph to acknowledge that this is sensitive information
> >
> > MINOR
> >    The primary use of exchanging software inventory information over the
> >    PA-TNC interface is to enable a challenger (e.g.  NEA Server) to
> >    obtain inventory evidence about some system in a way that conforms to
> > Nit: e.g.,
> >
> >    endpoint is providing false information, either through malice or
> >    error, but instead focuses on correctly and reliably providing the
> >    reported Software Inventory Evidence Collection to the NEA Server.
> > This seems like a pretty significant narrowing of the use cases. Can you
> > explain what use cases this is useful for if the machine can lie?
> >
> >    A Record Identifier is a 4-byte integer generated by the SWIMA-PC
> >    that is uniquely associated with a specific record within the
> > In what byte order? Signed or unsigned? If it's actually an integer this
> is
> > important.
> >
> >    that SWIMA-PV), the SWIMA-PC MUST assign that source a Source
> >    Identification Number, which is an 8-bit unsigned integer.  Each item
> >    reported includes the Source Identification Number that provided that
> > What happens if you have 256 sources? Must these be sequential?
> >
> >    record that is no longer available, the SWIMA-PC SHOULD return a
> >    0-length record.
> > Is this different from what happens if you are requested to send
> something
> > that
> > never existed? If so, is this a recipe for unlimited growth.
> >
> >    An EID is a 4-byte unsigned integer that the SWIMA-PC assigns
> >    sequentially to each observed event (whether detected in real-time or
> > What byte order?
> >
> >    very first recorded event in a SWIMA-PC's records within an EID Epoch
> >    MUST be assigned a value of 1 or greater.  Note that EID and EID
> >    Epoch values are assigned by the SWIMA-PC without regard to whether
> > Why "or greater" this is the only place you allow a gap.
> >
> >    event records MUST only contain events with EIDs that all come from
> >    the current Epoch.
> > How does the SWIMA-PC garbage collect? It seems like the answer is it can
> > just
> > change epochs?
> >
> >    records.  This ensures that every partial list of event records is
> >    always complete within its indicated range.
> > Is the point here that the list must be consecutive?
> >
> >    |              | (8)        | PA-TNC specification [RFC5792].       |
> >    +--------------+------------+---------------------------------------+
> > It's up to you, but isn't this table largely duplicative of S 5.2?
> >
> >    |   Software Identifier Length  | Software Identifier (var len) |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > OK, I think I see what's going on here: you can have an arbitrary number
> of
> > instances of this block. Maybe you should show more than one in the
> > diagram
> > with an indication that it's controlled by SWID Count? Or a .... or
> something?
> > This comment applies to the other PDUs in this document as well.
> >
> >    |                       Timestamp                               |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                       Timestamp                               |
> > I would not put lines between these timestamp fields because they are
> > actually
> > one giant field
> >
> >
>
>