Re: [Anima] discovery of Registrar by stateless Join-Proxy (was Re: [core] Join-proxy information in the RD (Re: CoRE WG Virtual Interim 2022-09-14))

2022-09-16 Thread Michael Richardson

Christian Amsüss  wrote:
>> It's not unidirectional!  I'm not able to parse "semi-" here, but I
>> suspect that is what you are trying to get at.

> What I meant was "duplex, but one side can only reply to traffic
> initiated by the other"; I think we're in agreement here.

There are situations in DTLS where more than one "reply" packet has to be sent 
by the
server, or where it needs to initiate an interaction.   But, you are right
that the tunnel can only be initiated via the pledge.

>> > Given that this only works locally (if it were run > separately,
>> that separte entity would need to keep state, whereas the
>>
>> I'm not sure what you mean, "only works locally" Do you mean it only
>> works on the localhost, on the link-local, or in the local
>> (autonomous) network?

> What I meant by "working locally" was that the UDP endpoint that is the
> server in the JPY protocol typically resides on the same host as the
> one UDP endpoint that server in CoAPS -- in figures 2 and 3, this is
> the case by both being IP_R:something.

yes, you are right: the mechanism is easiest to implement inside of the
Registrar itself, as it an put the extra state into the DTLS context.
But, it could also be done with a stateful join proxy :-)

>> The join-proxy is the thing looking for this resource, not the
>> (pledge) end node.  The pledge can tunnel a RD through the COAPS to
>> get a list of things.

> Outside of all the .jp and .rjp proxy addresses, can you give an
> example of the concrete resources the pledge would want to discover
> at/through the join proxy? In section 6.2.1 it discovers transport, but
> I suppose at a later step it will want to discover a path for a
> concrete resources (dunno, maybe an rt=brski.es or brski.rv), where
> would it currently learn that?

> These lines might be a good starting point to work out a more concrete
> example with a `;jpy-port=...` option.

I think that this is in the other thread now.

--
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] discovery of Registrar by stateless Join-Proxy (was Re: [core] Join-proxy information in the RD (Re: CoRE WG Virtual Interim 2022-09-14))

2022-09-14 Thread Christian Amsüss
Hello Michael,

> It's not unidirectional!
> I'm not able to parse "semi-" here, but I suspect that is what you are trying
> to get at.  

What I meant was "duplex, but one side can only reply to traffic
initiated by the other"; I think we're in agreement here.

> > Given that this only works locally (if it were run
> > separately, that separte entity would need to keep state, whereas the
> 
> I'm not sure what you mean, "only works locally"
> Do you mean it only works on the localhost, on the link-local, or in the
> local (autonomous) network?

What I meant by "working locally" was that the UDP endpoint that is the
server in the JPY protocol typically resides on the same host as the one
UDP endpoint that server in CoAPS -- in figures 2 and 3, this is the
case by both being IP_R:something.

While in theory these might be separate services (with the process
serving IP_R:p_Ra forwarding requests through some mechanism to
IP_R:5684), my impression is that this is most efficiently implemented
as one, and in particular that it is expected that only p_Ra (and not a
separate address) needs to be advertised.

> > local service can take shortcus and only keep state after DTLS got
> > established), might it not be a better option to just advertise that
> > the CoAPS port has a an additional way in, say,
> > `;jpy-port=7634` (abbreviated as
> > `;jpy-port=7634`)?
> 
> We looked at ways which would allow us to insert the state information into
> the DTLS framing, like we can when CoAP is on the outside, but that couldn't
> be done in a way that didn't violate the crypto context of DTLS.

All the suggestions I've made purely relate to how this is discovered,
not any changes on the wire outside of discovery.

> The join-proxy is the thing looking for this resource, not the (pledge) end 
> node.
> The pledge can tunnel a RD through the COAPS to get a list of things.

Outside of all the .jp and .rjp proxy addresses, can you give an example
of the concrete resources the pledge would want to discover at/through
the join proxy? In section 6.2.1 it discovers transport, but I suppose
at a later step it will want to discover a path for a concrete resources
(dunno, maybe an rt=brski.es or brski.rv), where would it currently
learn that?

These lines might be a good starting point to work out a more concrete
example with a `;jpy-port=...` option.

BR
c

-- 
We are dreamers, shapers, singers, and makers.
  -- Elric


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


[Anima] discovery of Registrar by stateless Join-Proxy (was Re: [core] Join-proxy information in the RD (Re: CoRE WG Virtual Interim 2022-09-14))

2022-09-14 Thread Michael Richardson

Hi, I've added anima@ietf.org, and removed some of the direct CC's, because I
know those people are on the MLs.  I will also reply a few times with the
intention of splitting up the discussion into better threads.

Christian Amsüss  wrote:
> There are some aspects about both rt= that make me concerned:

> * ;rt=brski.rjp

>   This indicates that there is a resource at the given URI that can be
> interacted with in some way described by this resource type. But while
> there may be also a resource there (in particular, the `/` resource of
> the forward target), that's not what this line is making a statement
> about. This line is making a statement about the transport endpoint
> associated with the URI (which is a bit of a hack but does not disturb
> the semantics of the remaining URI metadata ecosystem; at [1] I'm
> developing terminology for that).

I agree that it's awkward.

>   At the minimum, I think this should use a dedicated target attribute
> rather than the rt=, as Resource Type semantics are (in all their

I don't have a problem with changing rt= to something else completely.

> * Only partially related, the whole coaps+jpy scheme (which looks to me
> really more like a generic semi-unidirectional UDP tunnel than anything
> CoAP related) might not need registration at all.

It's not unidirectional!
I'm not able to parse "semi-" here, but I suspect that is what you are trying
to get at.  

>   The relevant metadatum which is transported in this (AIU) is that for
> some UDP port (eg. [2001:db8:0:abcd::52]:5684), there is an additional
> UDP port (currently advertised as
> `;rt=brski.rjp`) that has
> equivalent destination semantics but does all the state-keeping and
> unwrapping.

Yes, that's totally correct.
In practice, we can do whatever smells the least.
Our goal is simply to have a pure-RD mechanism for networks that want CoAP
and do not want GRASP or mDNS.

> Given that this only works locally (if it were run
> separately, that separte entity would need to keep state, whereas the

I'm not sure what you mean, "only works locally"
Do you mean it only works on the localhost, on the link-local, or in the
local (autonomous) network?

Yes, the Join Proxy probably has a ULA, and I expect the reply will be a ULA,
but there is nothing in the protocol that constrains that.  Yes, I use the
GUA documentation prefix in the examples.
(I actually started to write a draft in 6man creating a documentation prefix
in ULA-R space) 

> local service can take shortcus and only keep state after DTLS got
> established), might it not be a better option to just advertise that
> the CoAPS port has a an additional way in, say,
> `;jpy-port=7634` (abbreviated as
> `;jpy-port=7634`)?

We looked at ways which would allow us to insert the state information into
the DTLS framing, like we can when CoAP is on the outside, but that couldn't
be done in a way that didn't violate the crypto context of DTLS.

>   There is a downside compared to the current approach -- the
> `?rt=brski*` does not offer all relevant information any more.
> However, the registrar may still offer the `;jpy-port=7634` the line
> even when it does not match the filters, given that query filtering is
> generally optional, or offer it on any of the brski.* lines reported.

Yes, that's true.
The join-proxy is the thing looking for this resource, not the (pledge) end 
node.
The pledge can tunnel a RD through the COAPS to get a list of things.

> * In unrelated comments, I find it odd that the JP MUST implement both
> and the registrar only SHOULD do stateless. I can well imagine a JP

I think that we changed this at least, I want to.

>   I think that "JP may implement either, JR MUST support both" would be
> better..

I did put that into my presentation for 114.
It's possible we didn't implement that conclusion into the ID.


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