Re: [Anima] WG input needed: Ben Campbell's question on GRASP (1)

[Brian E Carpenter]

On 30/05/2017 06:51, Michael Richardson wrote:
> 
> Brian E Carpenter  wrote:
> >> -7, Grasp Message and Options table: Why "Standards Action"? Would you
> >> expect some harm to be done if this were only Spec Required?
> 
> > Personal opinion: I see potential for harm. I could imagine that if
> > GRASP is a success, then with experience we might be more relaxed about
> > it, but for now I tend to be conservative about it. Of course, the WG
> > may disagree...
> 
> Is it easier to raise the bar or lower it?  I think lowering is easier.
> I could live with "Spec Required" or even FCFS for M_* values >65536, btw.

Probably, but it's definitely impossible to squeeze toothpaste back in the tube,
so IMHO lowering the bar later is the safer approach.

Brian

> 
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Need WG input: Adam Roach's comment on GRASP

[Brian E Carpenter]

We can do that, when we need it. To get the draft out of the door, I'll do what
was previously suggested:

> Proposal: Note in the text that the current values are taken from the
> existing Protocol Numbers registry. Also note that if values are required
> in future that are not in that registry, a new registry for values >255
> will be created. So IANA doesn't have to do anything now.

Brian
On 31/05/2017 18:56, Carsten Bormann wrote:
> Ah.  3.9.5.1 currently does not have a “.within” clause giving an expectation 
> as to how the type "transport-proto” is going to grow as the protocol 
> evolves.  Foolishly, my brain inserted “uint” as the most obvious envelope 
> type.
> 
> Allowing negative values for transport-proto certainly would be possible.
> As a design pattern, I try to reserve broad ranges like this for the 
> indication of differences that a receiver can act upon without understanding 
> the details, such as the difference between base attributes and other 
> attributes in SenML.
> 
> So I still would favor sticking with uint for now and carving out a range of 
> that for experimental.
> 
> Grüße, Carsten
> 
> 
>> On May 30, 2017, at 22:53, Michael Richardson  wrote:
>>
>>
>> Carsten Bormann  wrote:
>>> If we ever add not-over-IP “transports”, there might be a need for
>>> experiments before we go registering.  So I would probably identify a
>>> range of numbers that are strictly reserved for use in experiments.
>>> (This needn’t be very small; say, 65280 to 65535.)
>>
>> -1 to -32!
>>
>> --
>> Michael Richardson , Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
>> ___
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Testing ASA Negotiation via GRASP over two hops

[William Atwood]

Brian Carpenter and I are pleased to report that we have successfully
tested communication between two ASAs that are not sharing a link.

ASA Gray  ASA Briggs

  GRASP --X-- GRASP --X--  GRASP

(Gingko) (Ritchie)(Iverson)


Gingko, Richie, and Iverson are three Linux processors.  ASA Briggs is
installed on Iverson, and offers a variety of products.  ASA Gray is
installed on Gingko, and seeks to discover a source for these products.
GRASP is installed on all three machines, and provides the necessary
discovery forwarding.

In the absence of an ACP, I have manually assigned IPv6 Unique Local
Addresses (ULAs) to each interface, and manually installed the necessary
routes.  (These tasks would be part of the functionality of an ACP, once
one gets developed.)

Once this is done, ASA Gray is able to discover (through GRASP) that ASA
Briggs is offering the necessary products, and then negotiate directly
with ASA Briggs (i.e., using ASA Briggs' IPv6 ULA) to acquire these
products.

In the process, some small errors in the specification of GRASP have
been found, and resolved in the latest Internet Draft.

For those interested in the (python) code, it may be found at
https://www.cs.auckland.ac.nz/~brian/graspy/ .

Bill Atwood and Brian Carpenter

-- 

Dr. J.W. Atwood, Eng. tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185 email:william.atw...@concordia.ca
1455 de Maisonneuve Blvd. Westhttp://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] [Anima-bootstrap] Voucher signing method

[Michael Richardson]

Max Pritikin (pritikin)  wrote:
> (libjwt) didn’t support it. After looking at the code more closely I’m
> not sure a jwt abstraction layer is really even needed; JWS is pretty
> simple to use directly. I’ve forked libjwt and will upload my diff to
> github tomorrow so you can see what i mean.

Max, can you indicate what your current thinking is in the movement
From PKIX signed custom JSON to ...

  a) JWS signed custom JSON?
  b) JWT, with standard claims?

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Brian E Carpenter]

On 01/06/2017 00:59, Eric Rescorla wrote:
> 
> 
> On Tue, May 30, 2017 at 6:59 PM, Brian E Carpenter 
> > wrote:
> 
> On 31/05/2017 11:30, Eric Rescorla wrote:
> > On Tue, May 30, 2017 at 4:19 PM, Brian E Carpenter <
> > brian.e.carpen...@gmail.com > wrote:
> >
> >> On some other points that are dangling after previous messages:
> >>
> >> On 31/05/2017 00:29, Eric Rescorla wrote:
> >>> On Mon, May 29, 2017 at 10:14 PM, Brian E Carpenter <
> >>> brian.e.carpen...@gmail.com > 
> wrote:
> >>>
>  Eric,
> 
>  On 25/05/2017 14:32, Eric Rescorla wrote:
>  ...
> > 
> --
> > DISCUSS:
> > 
> --
> >> ...
>  Finally, I don't
> > understand the security story for the multicast packets.
> 
>  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.
> 
> >>>
> >>> 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.
> >>
> >> Indeed, but as I understand it they will emulate link-local multicast
> >> 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?
> 
> That is exactly what the ACP does, as I understand it.
> 
> 
> 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.

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.

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

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

(!Toerless again!)

Brian

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Eric Rescorla]

On Wed, May 31, 2017 at 4:41 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

> Eric,
>
> On 01/06/2017 09:09, Eric Rescorla wrote:
> >
> >
> > On Wed, May 31, 2017 at 1:55 PM, Brian E Carpenter <
> brian.e.carpen...@gmail.com > wrote:
> >
> > On 31/05/2017 14:17, Eric Rescorla wrote:
> > > On Tue, May 30, 2017 at 6:32 PM, Brian E Carpenter <
> > > brian.e.carpen...@gmail.com >
> wrote:
> > >
> > >> Now getting to Eric's COMMENTs:
> > >>
> > >> On 25/05/2017 14:32, Eric Rescorla wrote:
> > >> ...
> > >>> 
> --
> > >>> 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"
> > >>
> > >> It's a term of art in the socket API:
> > >> https://tools.ietf.org/html/rfc3493#section-4 <
> https://tools.ietf.org/html/rfc3493#section-4>
> > >> Does it need a reference?
> > >>
> > >
> > > Yes.
> >
> > Will fix.
> >
> > >
> > >>> 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.
> > >>
> > >> 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...
> > >
> > >
> > > 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.
> >
> >
> > 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.
>

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.


> However, my point is that
> >
> > regardless of the odds, the implementer needs to check for a
> collision;
> > 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).
>
> This only adds one uint32 test in the code
> if clash.id_source == session_inst.id_source:
> 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.



> > > If the attacker can force an error when the other side didn't want
> one then
> > > 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.
> >
> >
> > Not necessarily. You might, for instance, log an error and do something
> > 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 

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

[Eric Rescorla]

On Wed, May 31, 2017 at 1:55 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

> On 31/05/2017 14:17, Eric Rescorla wrote:
> > On Tue, May 30, 2017 at 6:32 PM, Brian E Carpenter <
> > brian.e.carpen...@gmail.com> wrote:
> >
> >> Now getting to Eric's COMMENTs:
> >>
> >> On 25/05/2017 14:32, Eric Rescorla wrote:
> >> ...
> >>> --
> >>> 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"
> >>
> >> It's a term of art in the socket API:
> >> https://tools.ietf.org/html/rfc3493#section-4
> >> Does it need a reference?
> >>
> >
> > Yes.
>
> Will fix.
>
> >
> >>> 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.
> >>
> >> 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...
> >
> >
> > 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.
>

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


> As far as birthday paradox, I suspect this protocol is going to
> > 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.


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



> However, my point is that

regardless of the odds, the implementer needs to check for a collision;
> 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).



>
> >> 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.
> >>
> >> 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.
> >>
> >
> > If the attacker can force an error when the other side didn't want one
> then
> > 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.
>

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


> >>> S 3.9.5.4.
> >>> What are the semantics of a Divert URI? What do I dow ith the
> >>> path part?
> >>
> >> 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.
> >>
> >
> > 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.
>

Yeah, I'm not generally a big fan of 

Re: [Anima] WG input needed: Ben Campbell's question on GRASP (2)

[Ben Campbell]

> On May 28, 2017, at 11:02 PM, Brian E Carpenter  
> wrote:
> 
> On 23/05/2017 13:25, Ben Campbell wrote:
> ...
>> - Is section 2 [Requirements] expected to be useful to implementers once 
>> this is> published as an RFC? Unless there's a reason otherwise, I would 
>> suggest
>> moving this to an appendix, or even removing it entirely. As it is, you
>> have to wade through an unusual amount of front material before you get
>> to the meat of the protocol.
> 
> I'm open to that, and you are not the only reader with that comment.
> But we'd need WG consent…

Understood. I’m not going to stand in the way if the WG wants to keep things as 
is. But I do think that moving/removing the section would make the document 
more friendly to it’s post-publication target audience.

Thanks!

Ben.
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Eric Rescorla]

On Tue, May 30, 2017 at 6:59 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

> On 31/05/2017 11:30, Eric Rescorla wrote:
> > On Tue, May 30, 2017 at 4:19 PM, Brian E Carpenter <
> > brian.e.carpen...@gmail.com> wrote:
> >
> >> On some other points that are dangling after previous messages:
> >>
> >> On 31/05/2017 00:29, Eric Rescorla wrote:
> >>> On Mon, May 29, 2017 at 10:14 PM, Brian E Carpenter <
> >>> brian.e.carpen...@gmail.com> wrote:
> >>>
>  Eric,
> 
>  On 25/05/2017 14:32, Eric Rescorla wrote:
>  ...
> > 
> --
> > DISCUSS:
> > 
> --
> >> ...
>  Finally, I don't
> > understand the security story for the multicast packets.
> 
>  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.
> 
> >>>
> >>> 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.
> >>
> >> Indeed, but as I understand it they will emulate link-local multicast
> >> 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?
>
> That is exactly what the ACP does, as I understand it.


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.

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

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


> Brian
>
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Need WG input: Adam Roach's comment on GRASP

[Carsten Bormann]

Ah.  3.9.5.1 currently does not have a “.within” clause giving an expectation 
as to how the type "transport-proto” is going to grow as the protocol evolves.  
Foolishly, my brain inserted “uint” as the most obvious envelope type.

Allowing negative values for transport-proto certainly would be possible.
As a design pattern, I try to reserve broad ranges like this for the indication 
of differences that a receiver can act upon without understanding the details, 
such as the difference between base attributes and other attributes in SenML.

So I still would favor sticking with uint for now and carving out a range of 
that for experimental.

Grüße, Carsten


> On May 30, 2017, at 22:53, Michael Richardson  wrote:
> 
> 
> Carsten Bormann  wrote:
>> If we ever add not-over-IP “transports”, there might be a need for
>> experiments before we go registering.  So I would probably identify a
>> range of numbers that are strictly reserved for use in experiments.
>> (This needn’t be very small; say, 65280 to 65535.)
> 
> -1 to -32!
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima