Subject: [Anima-signaling] Concern about GRASP Flood message

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jul 2016 18:58:18 +1200

During various discussions this week, I decided there is an issue to decide
around the GRASP Flood message.

As it's currently defined, the node/ASA that receives a flooded objective
doesn't know where it came from; the flood relaying mechanism simply
loses the original source locator.

Is this a problem? Does the recipient of a flooded objective sometimes
need to know the source?

If so, we'd have to add a field to the Flood message. For example, we could
allow it to carry a Locator option.

BTW, flooded objectives have no lifetime - they are valid until overwritten
by a subsequent Flood message.

Comments?

-- 
Regards
   Brian Carpenter
   (Don't blame me, I voted Remain.)

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Jul 2016 09:03:55 +0200

Is there going to be any security?
Or is a flood message authenticated by the group key protecting the ASA?
If there is data origin authentication, this already provides a source.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jul 2016 19:31:19 +1200

> Or is a flood message authenticated by the group key protecting the ASA?

No, it will be implicitly authenticated by arriving via the ACP.
(Unless used in a insecure instance of GRASP, but I don't think we will
want that.)

> If there is data origin authentication, this already provides a source.

Right, we had that sort of approach in the old TLV version of the protocol,
but removed it when the ACP came along.

Regards
  Brian

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Jul 2016 00:51:00 -0700

If we had in the future ASA that can come from different vendors,
eg: lightblub ASAs from two different lightning system vendors,
and they want to trust objectives from other ASAs of the same vendor
differently than those from other vendors, then it would certainly
become interesting to have per-objective authentication. Would be an
interesting GRASP CBOR layer question if you want to take the relevant
part of the objective/synchronization payload and create a signature
for the CBOR representation of that and then add that signature to the CBOR message.

Alas, this is a long way off. We'd first need to have models
for per-ASA keying material. Like at least eg: certificates for apps like
android/iOS stores have them. and then expand from there.

On Thu, Jul 21, 2016 at 07:31:19PM +1200, Brian E Carpenter wrote:
> _______________________________________________
> Anima-signaling mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-signaling

-- 
---
Toerless Eckert, [email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Jul 2016 01:13:10 -0700

Coouple of thoughts:

Typically, objectives (synchronization) data would include a locator
for some locator(s) of the objective. Like the EST locator of
a registrar objective. 

The locator ultimately needs to be (address, proto(udp/tcp),port).

Most of the time the address is that of the announcer. If not, then
itswhat i'd call a "third-party" locator.

Its nice if one can logically distinguish normal from third-party
locators. Its nice if you do not need to repeat encoding the
address if you have emultiple locators.

So i would like to see the address of the originator of flood messages
to be available, and locators would have the possibility for the
address filed to be length 0, in which case the address is assumed to be
the one of the originator.

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jul 2016 20:25:31 +1200

> android/iOS stores have them. and then expand from there.

Right. But adding a signature option to all or some GRASP messages
is a backwards-compatible extension we could introduce later. Adding it
at the CBOR level might be a bit more tricky.

For now, I think the requirement to identify the source of a Flood message
is a more urgent question. There is already one use case emerging: using Flood
to announce bootstrap Registrars to all bootstrap Proxies. A proxy needs to
be able to choose which registrar to use, so needs to distinguish them by
source locator.

    Brian

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Jul 2016 10:43:53 +0200

I'd like to understand where that problem is.
draft-ietf-cose-msg...

Grüße, Carsten

Brian E Carpenter wrote:
> Adding it

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Jul 2016 10:45:45 +0200

Brian E Carpenter wrote:
> There is already one use case emerging: using Flood
> be able to choose which registrar to use, so needs to

Well, the content of the message then appears to be "x is offering to be
bootstrap registrar".  This can of course alternatively be represented
by "x says: 'I am offering to be bootstrap registrar'".

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jul 2016 21:06:02 +1200

> by "x says: 'I am offering to be bootstrap registrar'".

Exactly, but the Flood mechanism loses track of x when the message is relayed.
That would need a protocol change.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jul 2016 21:08:20 +1200

> I'd like to understand where that problem is.

I meant: adding it to GRASP as a backwards-compatible retrofit.

If it's added as a GRASP option, it will simply be ignored by
legacy implementations.

If that's also pssible with COSE, that would be fine too.

   Brian

> .

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Jul 2016 02:23:36 -0700

Btw: There where two other flooding refinements we discussed:

Store the original-loop-count in the packet so the GRASP API on
receivers could provide the hopcount distance of the announcer
distance = original-loop-count - loop-count.

Refine flood pruning as: 
 If the distance of a received announcement is smaller than the
 distsance of the cached announcement, flood the new packet (and put
 into cache). 

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jul 2016 22:31:32 +1200

> distance = original-loop-count - loop-count.

The loop count is already a mandatory field in every objective.
We can add original-loop-count as a specific field in this
objective. No problem.

>  distsance of the cached announcement, flood the new packet (and put

I have a problem with that but it's connected with another change
we have to make: caching multiple versions of a flooded objective
iff they come from different sources. We need to do that so that
in your use case (and probably others), the user ASA can make its
own choice among several alternatives. So in the flood cache we
will overwrite the cached value from address A if we receive a
new value from A, but the cached value from address B will not be
overwritten. As long as we do that, the distance comparison isn't
in the cache, it's in the user ASA.

So, to be clear, the objective syntax is:

objective = ["ANI_Registrar", objective-flags, loop-count, original-loop-count, stack-list]

and in the flood cache, it is tagged with its sending address (which
I noticed is already in the Flood message anyway, so that part is solved).

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 21 Jul 2016 05:03:33 -0700

> We can add original-loop-count as a specific field in this

Ok. Any guidelines when you consider some attrbite to be part of
an objective as opposed to eg: a GRASP header ?

> in the cache, it's in the user ASA.

So there are two comparisons:

The first comparison is in GRASP when a new message from A is received.
It's compared with the exxisting cache of A, and when it's better
(longer remaining cache time or lower distance), then it does get into
the cache and is flooded. Else it's dropped, and existing cache is better.

The second comparison is as you said in the ASA between the A cache and B
cache.

> I noticed is already in the Flood message anyway, so that part is solved).

Ok.

And the stack list will have the locators ?

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jul 2016 00:30:40 +1200

> And the stack list will have the locators ?

Certainly they will be available somehow, but let me pass on that question for this
week. I need to think through all the implications of what we've been discussing
when I'm not in a hotel with 1200 geeks.

   Brian