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

From: Fernando Gont <[email-masked]>
Date: Sat, 18 Jun 2016 15:44:31 +0200

Hi, Martin,

Not sure if I had responded to this one, but... since we're working on a
revision of our I-D, I went through your comments (possibly again). Here
are my comments:

On 04/07/2016 08:44 PM, Martin Thomson wrote:
> Identifiers inherently need to uniquely identify things.  That is,
> each identifier needs to identify a single thing [48]. 

That's how we defined the term in our document, it seems.

> I believe that
> to be constant across these examples, though there might be some
> confusion about what is being identified.  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.

You still mean to identify a single thing. The issue here is that,
depending on the type of identifier, etc., the failure severity may be
different.

e.g., a Flow Label collision is ok, while an IPv6 address collision is not.

> 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.
> 
> 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.

How uniqueness is "guaranteed" also has associated constraints in the
algorithms you may employ. For example, when it comes to Frag IDs, you
should either remember all Frag IDs that you've used in the last 60
seconds (unfeasible for a real implementation), or simply aim at
minimizing the Frag ID resuse frequency.

> 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.

Example: if you just cared about uniqueness, you could e.g. simply come
up with a random number (assumming the id space is large enough, etc.).
However, if the IDs are required to be monotonically increasing, then
such approach is not possible.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Sat, 18 Jun 2016 15:48:52 +0200

On 04/07/2016 08:55 PM, Adam Montville wrote:
[....]
>> [48] A thing might have multiple identifiers, a fact that might be
>> exploited by this document.
> 
> +1  Additionally, such multiple identifiers might be assigned to one thing by multiple authorities.

mm... how does this affect our I-D?

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 18 Jun 2016 16:27:48 +0200

On 04/08/2016 03:51 PM, Martin Thomson wrote:
> On 7 April 2016 at 19:37, Programa STIC <[email-masked]> wrote:
>> 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:
> 
> Yes, agree, context matters.
> 
>>         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.
> 
> The word you want is "definitively".

Doesn't "definitively" have a "time" connotation whereas uniquely doesn't?

>> 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.
> 
> I don't have a good answer for the question, but you make a
> distinction between fixed sized integer identifiers and other
> identifiers.  It's not clear what relevance that delineation has on
> this subject.

I think Iván just meant tat in most cases, IDs are represented as
intergers... but that's just an observation, not e requirement.

>> 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.
> 
> A section/paragraph that says exactly that would be a massive
> improvement.  It belongs in the introduction.

mm.. could you please clarify what such section would cover? Because the
above paragraph seems to cover multiple issues....

>> 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.
> 
> So do I; my email was - in part - about identifying another
> distinction.  That is, between centralized and decentralized
> generation.

Thinking out loud, it would seem to me that the only area for which this
distinction becomes relevant is that if you want to guarantee
availability  by keeping state about the IDs that have so far been
generated/employed, in a decentralized case you couldn't, or you'd need
some for of protocol to synchronize such state.

>> 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.
> 
> Fair point.
> 
>> 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.
> 
> Interesting perspective.  I'm not convinced that is possible in all
> cases.  I'm guessing that it could be difficult to sell that to the
> community, even in the current climate, without some strong backing.
> That could be perceived as quite a heavy burden.

Sell what, specifically?

> I would be interested in seeing a case study here.  For example, how
> would you apply this principle to TCP sequence numbers?

Simple: RFC0793 suggests to use some form of global counter for
generating TCP ISNs. But that suggestion overspecifies TCP ISNs, since
they only need to be monotonically increasing for the same connection-id
(src ip, src port, dst ip, dst port).

RFC6528 achieves such interoperability requirement, without
overspecifying the TCP ISNs: it provides monotonically increasing ISNs
for each connection id.  ISNs corresponding to different connection-ids
don't have any order relationship.

> On a related note, is this exclusively limited to identifiers that are
> sent in a protocol?  Or the subset of those that are sent in the
> clear?  Or are you also interested in implicit identifiers as well,
> those things that are not put in protocol PDUs, but are conceptually
> important for the functioning of the protocol.

...such us?

Just guessing, I'd probably say that this is meant for all of them.

> Further thoughts: this discussion sort of suggests to me that the
> scope of this work is a little ambitious for a single draft.  Maybe
> you could think some more about how you might reduce scope or divide
> the work into more easily digestible pieces.

We're working into that.

Thanks!

Best regards,