Re: [saag] Identifier uniqueness and draft-gont-predictable-numeric-ids

[Programa STIC <[e-mail]>]

Hello Martin, thanks for your comments, see mine inline

El 7/4/16 a las 15:44, Martin Thomson escribió:
> I feel that the treatment of identifiers and the resulting taxonomy
> needs to be considered differently.
> 
> Identifiers inherently need to uniquely identify things.  That is,
> each identifier needs to identify a single thing [48].  I believe that
> to be constant across these examples, though there might be some
> confusion about what is being identified.

Indeed, identifiers identify things _within a given context_. To avoid a
recursive definition and to try to narrow down the scope of the document
just to numeric ids we defined  "identifier" in section 2 as:
	
	A data object in a protocol specification that can be used to
      definetely distinguish a protocol object (a datagram, network
      interface, transport protocol endpoint, session, etc) from all
      other objects of the same type, in a given context.
	Identifiers are usually defined as a series of bits and
      represented using integer values.  We note that different
      identifiers may have additional requirements or properties
      depending on their specific use in a protocol.  We use the term
      "identifier" as a generic term to refer to any data object in a
      protocol specification that satisfies the identification property
      stated above.

We believe the above definition should capture accurately what you
wrote. Note however that we introduced the "within context" qualifier
because an identifier value could be repeated in different contexts and
still identify a unique thing in each of them, i.e. the value of the
IPv4 ip_id generated by an IP stack could be repeated over time its
running but it would still identify a single packet during its lifetime
on the network.

If you feel the above definition needs to be tweaked please let us know
of suggested changes. One possible change could be to substitute
"definetely" with "uniquely" but I don't know if that's strictly necessary.


>  The example of v6 flow
> labels suggests to me that the thing being labelled is not a single
> flow, but the set of flows that will be collated.

This I will need to look into, for now I defer to Fernando to comment on.
> 
> What differs is the process by which uniqueness is guaranteed.
> Uniqueness in many contexts is assured by fiat: an authority is known
> to control a given space and only that authority can generate
> identifiers in that space.  For example, a server controls what the
> TCP port numbers its servers use identify.

Centralized, delegated, federated or distributed generation of
identifier values does not guarantee uniquess per se, its all dependent
on the algorithms used. In some scenarios, for example a central
authority that generates identifiers on demand, some algorithms will
guarantee uniqueness (ie. a global variable initialized and incremented
by 1 for each request of a new id) while in other scenarios other
algorithms may accomplish the same (ie. a lookup on a table of
precomputed values). However, the point we are trying to raise is that
from the security & privacy perspective, in many cases uniqueness is not
sufficient. In many cases non-predictability and collision resistance
are additional properties desired or even needed to avoid attack.

During the session today somebody (sorry I did not write down your name)
indicated that perhaps it is good to differentiate identifier values
that are generated at "spec time" or/and that remain fixed throughout
the lifetime of the protocol from those that are generated dynamically
at runtime by the protocol's implementation. I concur.

Our draft seeks to analyze S&P issues with the latter and present some
guidelines to both designers and implementors on how to spec identifiers
and how to select suggested algorithms for implementation.

> 
> We have a few examples where uniqueness is distributed (e.g., CGA) and
> protocol mechanisms are used to ensure uniqueness.  There are specific
> privacy and security considerations that arise from having a protocol
> mechanism, so this method of arriving at uniqueness warrants some
> discussion because it entails a new protocol, but I don't believe that
> it justifies the hard/soft distinction in the proposed taxonomy.

The hard/soft distinction in the draft is applied to interoperability.
We what to use the distinction to point out that there isn't bijection
between interop failure modes and S&P failure modes.

What may be considered a "soft failure" for interoperability (ie. a id
collision on a DNS id) may end up being one or more "hard" failures or
serious problems in the security & privacy context (ie. DNS cache
poisoning).

On the other hand, hard failures in interoperability almost always imply
a vulnerability to denial of service attack.

What I took out from today's session is that we may need to make this
mapping more explicit.

> 
> Finally, the monotonically increasing category is not particularly
> special.  The identifier (e.g., a TCP sequence number) still uniquely
> identifies a subject (in this case, the first octet of a segment).
> The process for ensuring uniqueness is merely different.

We believe it is indeed special. The point here is that requiring
monotonically increasing values for a identifier introduces additional,
and sometimes unneeded, property: an ordering relationship. The result
is a protocol field that is "semantically overloaded", it is not just
unique but can also be used to order bytes, or even to order sequences
of bytes. In some cases this property is needed or desirable, in other
cases it is totally unneeded. Again, here we can see how a global
counter incremented by 1 per packet does something more than just ensure
uniqueness.

A protocol that defines an Identifier that needs to be unique (within
context) but specifies generation of its values using a monotonically
increasing sequence is "over specifying" the ID definition and should
trigger a warning in a S&P review.

Likewise a a protocol that defines an Identifier that needs to be unique
but does not properly describe the context or provide guidance on how to
achieve is under specified.

Thanks for your feedback,


-ivan