Subject: [Anima] Eric Rescorla's Discuss on draft-ietf-anima-grasp-12: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 May 2017 19:32:57 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-anima-grasp-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

ISSUE 1
The security situation here is pretty unspecified here, in at least two
respects:

1. In terms of communication security, you seem to have two modes:

   (a) Punt it to ACP
   (b) Use TLS as specified in S 3.5.2.1

I'm not reviewing ACP here (though I have some comments on that too)
but S 3.5.2.1 doesn't (for) instance explain how to do certificate
validation, which it clearly needs to do. Finally, I don't
understand the security story for the multicast packets.
This is especially relevant for Rapid mode, where you are
attaching real work to these multicast packets.

2. I didn't find the security model very clear. As I understand
things, basically anyone on the network who has ACP credentials
is trusted to engage in negotiation with you, so, for instance,
if you want to get parameter X, then you basically just trust
whoever on the network offers you X. is that correct? That seems
like it needs to be very explicitly called out. And if that's not
true, then I don't understand the spec.

ISSUE 2
This document seems like it provides incomplete guidance on how
to actually implement it. For instance:

   discovery messages to a reasonable value, in order to mitigate
   possible denial of service attacks.  It MUST cache the Session ID
   value and initiator address of each relayed Discovery message until

What's "reasonable"?

ISSUE 3.
I don't think I understand how the transition from UDP multicast
to TCP/TLS unicast works. Maybe I'm just misreading the spec,
so could you point me to the section that describes this.

Finally, I don't see a spec for how you map CBOR onto the wire. Do you
just shove them on? Something else?

I see that Martin Thomson raised a number of these issues in his review
in more detail.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S 3.5.4.3.
   After a GRASP device successfully discovers a locator for a
Discovery
   Responder supporting a specific objective, it MUST cache this
   information, including the interface index via which it was
   discovered.  This cache record MAY be used for future negotiation or
   synchronization, and the locator SHOULD be passed on when
appropriate
   as a Divert option to another Discovery Initiator.

What's an "interface index"

S 3.5.4.4.
   Since the relay device is unaware of the timeout set by the original
   initiator it SHOULD set a timeout at least equal to
GRASP_DEF_TIMEOUT
   milliseconds.

I'm not sure I'm following here. Does the relay instance retransmit
with its own timeout?

   It MUST cache the Session ID
   value and initiator address of each relayed Discovery message until
   any Discovery Responses have arrived or the discovery process has
   timed out.

How does this behave if the original initiator's timeout is
longer than GRASP_DEF_TIMEOUT?

S 3.5.5.
   A negotiation procedure concerns one objective and one counterpart.
   Both the initiator and the counterpart may take part in simultaneous
   negotiations with various other ASAs, or in simultaneous
negotiations
   about different objectives.  Thus, GRASP is expected to be used in a
   multi-threaded mode.  Certain negotiation objectives may have
   restrictions on multi-threading, for example to avoid
over-allocating
   resources.

"multi-threaded" is an odd word here. I assume you mean that you
are doing multiple stuff at once, but you might actually write
the system using non-multi-threaded techniques.

S 3.7.
You seem to be going to a lot of trouble to deal wit session
ID collisions. Why don't you just make session IDs 128-bit
random values and then you won't have to worry about
collisions.

  The Session ID SHOULD have a very low collision rate locally.  It
   MUST be generated by a pseudo-random algorithm using a locally
   generated seed which is unlikely to be used by any other device in
   the same network [RFC4086].

Why don't you just require a cryptographically secure PRNG?
That will be required to implement the rest of this protocol

S 3.8.2.
You seem to introduce a normative dependency on CDDL here.
I see that it's in your changelog here, but what are
your intentions about this document, given that CDDL seems
to not even be a WG document

S 3.8.5.
      It MUST contain a time-to-live (ttl) for the validity of the
      response, given as a positive integer value in milliseconds. 
Zero
      is treated as the default value GRASP_DEF_TIMEOUT (Section 3.6).

Why do this, rather than just forbidding 0.

S 3.8.6.
   If a node receives a Request message for an objective for which no
   ASA is currently listening, it MUST immediately close the relevant
   socket to indicate this to the initiator.  This is to avoid
   unnecessary timeouts if, for example, an ASA exits prematurely but
   the GRASP core is listening on its behalf.

This is not secure. You need a secure indication of non-knowledge,
not a transport-level close.

S 3.9.5.4.
What are the semantics of a Divert URI? What do I dow ith the
path part?

S 3.10.4.
The semantics of "dry run" seem pretty unclear. Is it just
"tell me if you would be sad about doing this"?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 May 2017 17:14:59 +1200

Eric,

On 25/05/2017 14:32, Eric Rescorla wrote:
...

Yes, that certainly needs a thorough security review ASAP.

> validation,

Indeed not. But...

> which it clearly needs to do. 

We intentionally want to leave this for further study. Surely that
is allowed? The text seems very clear on that. Personally, I'm not
competent to design that, and this draft is already plenty long enough.
So what can we write if we can't write "Further details are out of scope
for this document."?

> Finally, I don't

I think I already typed this a day or two ago, but with an ACP,
they are secured, because the ACP is a secure virtual overlay
network.

With no ACP they are of course wide open, unless some new
magic has been invented that I'm not aware of. Hence the
restrictions in 3.5.2.2. "Discovery Unsolicited Link-Local"

> attaching real work to these multicast packets.

Correct. I think we need to forbid that in the no-ACP case.
 
> true, then I don't understand the spec.

That is the trust model, but really as an explanatory matter I think
it belongs in draft-ietf-anima-reference-model rather than here.
I will add a few words in the High Level Deployment Model
section and/or the Security Considerations.

What we do say already is that authorization of ASAs is out of scope.
I am certain that it needs to be tackled, but not here.

>    value and initiator address of each relayed Discovery message until

Yes, we will fix various instances of "reasonable" but I daresay
further experience will shed new light.

> so could you point me to the section that describes this.

This only arises for discovery; the discovery result explicitly includes
the address/protocol/port for the actual operation.

For discovery it's in
https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.8.4 

<t>The listening port used for TCP MUST be the same port as used for sending the
Discovery UDP multicast, on a given interface. In a low-end implementation this MAY
be GRASP_LISTEN_PORT. In a more complex implementation, the GRASP discovery mechanism
will find, for each interface, a dynamic port that it can bind to for both UDP and TCP
before initiating any discovery.</t>

Python code on request ;-)

> just shove them on? Something else?

Yep, CBOR is just a string of bytes. That's CBOR 101 so I don't
think we need to say anything more.

> I see that Martin Thomson raised a number of these issues in his review
Martin Stiemerling I think.

Almost dinner time. I will get to your other comments tomorrow.

Thanks
     Brian

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 May 2017 05:29:28 -0700

> So what can we write if we can't write "Further details are out of scope

It's the job of this group of specifications to provide a complete
security story, so it must either be here or it must be in some other
document which is normatively referenced from here and which
therefore one can read to determine if this document achieves the
appropriate security objectives. Just generally pointing in the direction
of TLS is not sufficient. You could, of course, say that TLS is not to
be used at all and you rely entirely on ACP, but the current text
doesn't do that either.

> they are secured, because the ACP is a secure virtual overlay

This document then needs to state which precise properties of
ACP it is relying on for that. A brief skim of ACP suggests that
it relies on other protocols for its actual transport security and
at least some of those protocols (e.g., DTLS) do not support
multicast.

> restrictions in 3.5.2.2. "Discovery Unsolicited Link-Local"

As above, you need to specify which properties you are relying
on, and how you bridge multicast to unicast.

> I am certain that it needs to be tackled, but not here.

I don't see how you have a complete protocol without that.

> Python code on request ;-)

Thanks.

> think we need to say anything more.

I don't agree. JSON is just a string of bytes and yet ACME, for instance,
contains
a rather extensive protocol mapping to HTTP. So, you need to at least state
that
you just shove them on the wire.

> Martin Stiemerling I think.

Martin Stiemerling may or may not have reviewed this document, but I'm
talking
about Martin Thomson's review, which can be found at:

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Tue, 30 May 2017 14:49:54 +0200

> about Martin Thomson's review, which can be found at:

At..... 
https://mailarchive.ietf.org/arch/msg/art/tFoac4dniuFvXTk3xXtsGkCtUag

?

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 May 2017 05:52:55 -0700

Yes. Thanks.

-Ekr

On Tue, May 30, 2017 at 5:49 AM, Eliot Lear <[email-masked]> wrote:

> At.....  https://mailarchive.ietf.org/arch/msg/art/tFoac4dniuFvXTk3xX
> tsGkCtUag
>
> ?
>
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 May 2017 13:02:31 -0400

Eric Rescorla <[email-masked]> wrote:
    > document which is normatively referenced from here and which therefore
    > one can read to determine if this document achieves the appropriate
    > security objectives. Just generally pointing in the direction of TLS is
    > not sufficient. You could, of course, say that TLS is not to be used at
    > all and you rely entirely on ACP, but the current text doesn't do that
    > either.

The use case for TLS is inter-domain (while the ACP is intra-domain).
I.e. between two ISPs.  Such a GRASP instance would be isolated from other
ANIMA GRASP instances, would perhaps not be hop-by-hop.  Or might be.

As that use case is not well understood at all, and I think can (and SHOULD)
be addressed later on, I have argued for simply not mentioning it because we
don't have a story about certificates or identities or validation, etc.  (I
suspect that many initial uses will use pinned self-signed certificates,
manually configured).

Brian has argued to continue to include the reference so that we remember
that use over a secured ACP is not the only use, and that we shouldn't write
some complex interaction that involves many UDP/TCP port combinations that
would be hard to support over TLS.

Use of GRASP at an Internet Exchange (IX) might be different again, perhaps
using COSE to sign GRASP multicast messages.

Can anyone suggest a way to keep TLS in mind while not actually saying we know
how to use it?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 May 2017 13:11:39 -0400

ekr> 2. I didn't find the security model very clear. As I understand
   ekr> things, basically anyone on the network who has ACP credentials is
   ekr> trusted to engage in negotiation with you, so, for instance, if you
   ekr> want to get parameter X, then you basically just trust whoever on the
   ekr> network offers you X. is that correct? That seems like it needs to be
   ekr> very explicitly called out. And if that's not true, then I don't
   ekr> understand the spec.

   bc> That is the trust model, but really as an explanatory matter I think it
   bc> belongs in draft-ietf-anima-reference-model rather than here.  I will
   bc> add a few words in the High Level Deployment Model section and/or the
   bc> Security Considerations.

I am increasingly uncomfortable with leaving things like this.
There are a number of things that we could do as GRASP extensions:

  1a) M_SIGNED: could be container that encapsulates a GRASP message into
                a COSESign1 structure to indicate who sent the message.

  1b) M_MULTISIGNED: a be a container with a COSESign structure in which
                every passing node signs as it goes through.

  2) transport end to end, run it over TLS or something.  Might be implied or might
     require a M_STARTTLS message.

  3) hop-by-hop, with some kind of M_TUNNEL message, or using COSE Encrypt
     messages with relaying on the outside.

I think that all of these things could be ASA specific, but I think that ASA
should not have to re-invent the wheel here, but can use the GRASP "kernel"
(aka "libgrasp") to do the right thing.

My request for the Chairs to put this on the "re-chartering" list for later
on, but to discuss with ADs now so that some of the GRASP or framework work
could say something aobut "future work".

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 May 2017 08:30:07 +1200

Right. I believe that the -12 draft already covers most of Martin Thomson's
points, other than what we are still discussing with Eric. Martin Stiemerling's
points need to fixed in the future -13 draft.

Regards
   Brian

On 31/05/2017 00:52, Eric Rescorla wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 May 2017 13:32:37 -0700

Yes, I incorporated MT's remaining points into my review. I just wanted to
give
him credit.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 May 2017 08:37:57 +1200

> Can anyone suggest a way to keep TLS in mind while not actually saying we know

That's the crux of it. We intentionally did not want to bind GRASP
irrevocably to the ACP, so that it can be used, for example, to implement
dynamic resource management between two ISPs that have a specific trust
model between themselves. But clearly that's future work. How can we
express that?

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 May 2017 08:41:05 +1200

> I am increasingly uncomfortable with leaving things like this.

It's clearly not the end state, but surely we are on shifting sands
until BRSKI and the ACP are stable.

> could say something aobut "future work".

Yes, certainly, after we get the basic infrastructure documents out of the
door.

    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 May 2017 13:47:48 -0700

On Tue, May 30, 2017 at 1:37 PM, Brian E Carpenter <
[email-masked]> wrote:

> therefore

The usual way is to define things for ACP and then say that future specs may
define other protection mechanisms.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 May 2017 10:00:38 +1200

> define other protection mechanisms.

OK, so no spec is better than an incomplete spec. That's easy enough.

It also, IMHO, means deleting the "SONN" subsection, 3.5.2.3.
Toerless: you invented that, but as I understand it BRSKI does
not need it since the registrar-proxy interaction will take place
over the ACP.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 May 2017 11:19:21 +1200

On some other points that are dangling after previous messages:

... 
> at least some of those protocols (e.g., DTLS) do not support

Indeed, but as I understand it they will emulate link-local multicast
over the secured connections. We don't need wider scope multicast,
which is much harder to emulate. We'll try to make this expectation
clear.
 
> on, 

But in DULL we aren't relying on anything; we're just sending GRASP
packets over an interface. I don't see anything that needs specifying.

> and how you bridge multicast to unicast.

? We don't do that.

> I don't see how you have a complete protocol without that.

The starting position is that we trust all autonomic nodes and therefore
the ASAs installed in them. We are in the context of a single operator
so this isn't really a stretch. The questions around life cycle
management of ASAs, which would certainly involve authorization,
were intentionally not in the initial WG charter. I think it's true
that you can't have a complete *system* without that, but I disagree
that it's a requirement for the protocol.
 
...
> you just shove them on the wire.

Will do.

    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 May 2017 16:30:06 -0700

On Tue, May 30, 2017 at 4:19 PM, Brian E Carpenter <
[email-masked]> wrote:

> over the secured connections.

It's not clear to me what that means. You perhaps expect to tie up
a connection to every counterparty in the network?

> packets over an interface. I don't see anything that needs specifying.

As you indicate, DULL has a whole pile of rules. Why are those rules
sufficient?

> and how you bridge multicast to unicast.

Huh? You send out a discovery packet in multicast and then expect
someone to connect to you via unicast, no?

> the ASAs installed in them. We are in the context of a single operator

so this isn't really a stretch.

I certainly can see how someone might decide to deploy a system like
this, but it seems pretty problematic to have a system that is so brittle
to single-point compromise (The term of art here is "distributed single
point of failure")

> The questions around life cycle

At minimum you need to specify that this is your trust model and
then work through the implications of compromise of some subset
of nodes, as well as of an attacker who can influence which nodes
you talk to.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 May 2017 13:32:29 +1200

Now getting to Eric's COMMENTs:

It's a term of art in the socket API:
https://tools.ietf.org/html/rfc3493#section-4
Does it need a reference?

> I'm not sure I'm following here. Does the relay instance retransmit

Yes, but this text was broken anyway (as detected by Bill Atwood testing
my code, embarassingly recently). The next version should be clearer,
as well as being corrected.

> longer than GRASP_DEF_TIMEOUT?

That case works, except that the original initiator waits unnecessarily.
But consider what happens if the original initiator's timeout is *shorter*
than the timeout on the relayed discovery. It can then happen that the
relayed discovery response is returned to the originator after the
originator has timed out. That's what Bill discovered :-(. 

Will fix.

> the system using non-multi-threaded techniques.

You could, and we need to make sure that the API allows for that.
Logically it's always multi-threaded though, even if you use
something like an event-loop technique. We can tweak the wording
accordingly.

> random values and then you won't have to worry about

Well, yes, the odds would be better with 128 than 32 but
that's extra bits on the wire and there'd still be the
birthday paradox... 

> That will be required to implement the rest of this protocol

Well, certainly there will be for the security bootstrap
and the ACP. Is there a different reference for that?
 
> to not even be a WG document

Resolve at AUTH48. If CDDL advances as planned in the CBOR WG,
we're fine. If not, we have a backup plan to add a short appendix
defining the subset of CDDL that we use. The text is already
drafted in case we need it.
 
> Why do this, rather than just forbidding 0.

This feeds back to the API, so that a lazy ASA programmer doesn't
have to provide a value. (Also, I realised when fixing the discovery
timeout issue above that this default is low. Will fix.)

> not a transport-level close.

I don't see this as a security issue. There would be an alternative,
which is to send back an immediate M_DECLINE, but that is quite
a bit harder to implement and I don't really see an advantage:
the requester will just get back an error code in either case.
An ASA must always be ready for an error return.
 
> What are the semantics of a Divert URI? What do I dow ith the

Two things on this:
Following Alexy's comment, we are likely to add protocol/port
to this type of locator option. Given that, is there anything special
about the Divert case? A URI should be valid however you receive it.
 
> "tell me if you would be sad about doing this"?

This is explained better in an earlier section:
https://tools.ietf.org/html/draft-ietf-anima-grasp-12#section-3.5.5

We will try to clarify this, at least with a cross-reference.

Thanks,
     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 May 2017 13:59:57 +1200

> a connection to every counterparty in the network?

That is exactly what the ACP does, as I understand it.

> As you indicate, DULL has a whole pile of rules. Why are those rules

They are supposed to be self-explanatory. I'm not sure what
the issue is.

Toerless: please speak up, you wrote that text!
 
> someone to connect to you via unicast, no?

Yes, but that is elsewhere in the document (I think that came up
in Alissa's comments). Nothing new to say in this part.

> of nodes, as well as of an attacker who can influence which nodes

That really, really belongs in the reference model or the ACP draft;
it's in no way specific to GRASP, because nodes could use any protocol
they please over the ACP.

    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 May 2017 19:17:16 -0700

> Does it need a reference?

Yes.

> that's extra bits on the wire and there'd still be the

Why is this amount of extra bits on the wire significant?

As far as birthday paradox, I suspect this protocol is going to
break down well before 2^32 endpoints, let alone 2^64.

> and the ACP. Is there a different reference for that?

I'm not understanding the question here. You basically can't build any
cryptographic system without a secure PRNG (in the worst case, if you
have a private key you can use that to seed the PRNG).

> An ASA must always be ready for an error return.

If the attacker can force an error when the other side didn't want one then
that implicates the security of the system.

> about the Divert case? A URI should be valid however you receive it.

Again, what do you do with the path section of the URI?

> https://tools.ietf.org/html/draft-ietf-anima-grasp-12#section-3.5.5

This just seems to say "it's up to the ASA"

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 31 May 2017 05:59:47 -0700

> >>>> On 25/05/2017 14:32, Eric Rescorla wrote:

That's not what I got from 5.4.3, which says:

   GRASP discovery and flooding messages are designed for use over link-
   local multicast UDP.  They MUST NOT be fragmented, and therefore MUST
   NOT exceed the link MTU size.

Perhaps a ladder diagram of how this works would help, both here
and in the document.

> they please over the ACP.

It's a WG decision which document it goes in, but it's something
that needs to exist, because otherwise it is not possible to assess the
security of this document.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Jun 2017 08:55:14 +1200

Will fix.

> Why is this amount of extra bits on the wire significant?

We do have people in Anima who care about every extra byte, in
case this stuff does end up in constrained devices.

> break down well before 2^32 endpoints, let alone 2^64.

Of course, but it's the number of overlapping sessions that would
be relevant for the birthday paradox. However, my point is that
regardless of the odds, the implementer needs to check for a collision;
that's just correct programming.

> have a private key you can use that to seed the PRNG).

Sure. I just meant is that covered by RFC4086? Now I have to go look...
yes, I guess it is. OK, will fix.

> that implicates the security of the system.

True, but I don't think your suggestion helps. Let me explain:

Suppose that we add a new use of the M_DECLINE message for this case.
Then the ASA which is currently not accepting Request messages will
send an M_DECLINE followed by a TCP FIN. The initiator receives
an M_DECLINE, closes its socket and returns an error code to the API.

If it receives an unexpected FIN (or RST) it closes its socket and returns
an error code to the API anyway. It has to; there's nothing else it can
do. As far as the ASA involved is concerned, it's a failure in any case.

If it's an attacker, or some other random event, that causes the failure,
it really looks no different than a failure caused by the remote ASA.
(OK, one possible difference: the error code in the API might be 
18 #"Socket error sending negotiation request" instead of 
23 #"Negotiation peer not listening", depending on the exact timing.)
But this doesn't affect what the ASA does in any way: it shrugs
its shoulders, probably waits for a few seconds, and tries again.
Inserting the M_DECLINE really makes no difference.

> Again, what do you do with the path section of the URI?

   Note 2: Normal GRASP operations are not expected to use this option.
   It is intended for special purposes such as discovering external
   services.  Therefore its use is not further described in this
   specification.

GRASP is just the carrier so is completely agnostic about your 
question.

> This just seems to say "it's up to the ASA"

Yes. FYI, draft-carpenter-anima-asa-guidelines, "Guidelines for
Autonomic Service Agents" will hopefully be filling in a number
of gaps in future. (I think one the issues here is that GRASP
is just part of a complete system, which happens to have reached
the IESG first.)

Rgds
    Brian

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 31 May 2017 14:09:07 -0700

> case this stuff does end up in constrained devices.

Yeah, I hear this stuff a lot, but I'd want to see some real analysis of
whether
this is an issue.

> be relevant for the birthday paradox.

You think you're going to have anywhere near 2^64 sessions?

> However, my point is that

> that's just correct programming.

No, I don't agree with this. Once collisions are sufficiently statistically
unlikely, you can assume they will not happen. Note that we routinely
assume this in situations where the results of collisions are far more
severe (e.g., generating cryptographic keys).

> do. As far as the ASA involved is concerned, it's a failure in any case.

Not necessarily. You might, for instance, log an error and do something
when you believe that your network is under attack/broken.

> GRASP is just the carrier so is completely agnostic about your

Yeah, I'm not generally a big fan of "here is some placeholder we have
no idea what we're going to do with"

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Jun 2017 11:41:50 +1200

Eric,

On 01/06/2017 09:09, Eric Rescorla wrote:
> 
> 
> On Wed, May 31, 2017 at 1:55 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > [email-masked] <mailto:[email-masked]>> wrote:
>     >
>     >> https://tools.ietf.org/html/rfc3493#section-4 <https://tools.ietf.org/html/rfc3493#section-4>
> Yeah, I hear this stuff a lot, but I'd want to see some real analysis of whether
> this is an issue.

Well, I read the published RFC on constrained systems at the beginning
of Anima, so it isn't clear in my mind today, but I think the people working
in that area really do care about every byte. But it's a side issue really.
The main point is that afaik it's still a lot easier to manipulate 32 bit
numbers than say 128 bit numbers, and 2^32 seems plenty big enough for
this particular (non-cryptographic) purpose.
 
> You think you're going to have anywhere near 2^64 sessions?

Not likely, even 2^32 is a lot.
 
> severe (e.g., generating cryptographic keys).

This only adds one uint32 test in the code
    if clash.id_source == session_inst.id_source:
which will almost never test true. So I think we'd better agree to differ.
 
> when you believe that your network is under attack/broken.

We can do that anyway. "Negotiation peer not listening" is not a normal
situation anyway; if it persists it should be logged and investigated.
(This is not just thoughtware - when I've run test ASAs with full diagnostic
logging, this is in fact one of the errors I've used for debugging.)

Note, I'm not saying it's unreasonable to add the M_DECLINED message in this
case; it easily passes my test of "can I code this?" But I'd need a clear
message from the WG to be convinced.

> no idea what we're going to do with"

It's not really a placeholder IMHO. It's something that GRASP, as an
infrastructure component, provides for app (the ASA) to use as it needs.

   Brian

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 31 May 2017 16:49:56 -0700

On Wed, May 31, 2017 at 4:41 PM, Brian E Carpenter <
[email-masked]> wrote:

> >     >> https://tools.ietf.org/html/rfc3493#section-4 <
> https://tools.ietf.org/html/rfc3493#section-4>

Sure, it doesn't need to be cryptographic, just statistically unique. And
as you say,
2^{32} *isn't* large enough for that, but 2^{128} is.

> which will almost never test true.

That's not good, it's bad. It means it's a code path which is likely not to
be tested correctly.

So I think we'd better agree to differ.

Yes, I agree that this is within WG discretion.

> message from the WG to be convinced.

If you opt not to change it, you need to call it out in the security
considerations,
because truncation attacks are a real thing.

> infrastructure component, provides for app (the ASA) to use as it needs.

This seems like a distinction without a difference.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Jun 2017 11:56:58 +1200

On 01/06/2017 00:59, Eric Rescorla wrote:
> 
> 
> On Tue, May 30, 2017 at 6:59 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 

Regardless of that, we will try to ensure that the next draft makes
this clear without too much repetition. By the time the reader gets
to 5.4.3, it should be clear that multicast UDP is via the ACP
just like unicast TCP.

I'll try a diagram but not right now as I have to run.

> security of this document.

Then it had better be the ACP, which is normative.

(!Toerless again!)

    Brian