Subject: [6tisch] On minimal-security

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 15 May 2018 14:00:11 +0000

Hello Mališa

As you are getting ready to publish a next rev, please find simple comments on 05 that you may want to act upon in 06.

·        As mentioned earlier in the draft,  the most probable collocation for the JRC would be the 6LBR, and probably not a JP deep in the network.
Why did you point on the JP in the below?

the JRC, which may be co-located on the JP or another device.

·        This sentence is too complex :

   4.  In case of successful processing of the request, the pledge
       receives a join response from JRC (via the JP) that sets up one
       or more link-layer keys used to authenticate and encrypt
       subsequent transmissions to peers, and a short link-layer address
       for the pledge.

Who sets up what is unclear. Could you make it 2 sentences?

·        I see what you mean there

It deeply duty cycles its radio, switching the radio on when the provided schedule indicates slots which the pledge may use for the join process.

But this seems to make the process very specific to TSCH when it could easily apply to IEEE Std. 802.15.4 at large. It is my reading that for the most part the protocol is not dependent of TSCH and that it could easily have  larger applicability. Is there a way to word it as “in the case of TSCH, …” ? also suggestion to reword “It deeply duty cycles” to follows the indicated schedule or something.

·        On paper the 6LoWPAN concept of 6LBR (a central registrar, though the 6LoWPAN definition indicates a border router function) is not necessarily the same guy as the RPL root, though it makes full sense that they are – and the 6TiSCH architecture recommends that they be. Maybe we could enforce that they are in another spec.

The JRC can be co-located on the 6LBR. In this special case, the IPv6 address of the JRC can be omitted from the Join Response message for space optimization. The 6LBR then MUST set the DODAGID field in the RPL DIOs {{RFC6550}} to its IPv6 address. The pledge learns the address of the JRC once joined and upon the reception of a first RPL DIO message, and uses it to operate as a JP.

I’d add a sentence at the beginning of the spec that the text makes the assumption that the 6LBR is the RPL root per the architecture and that in case they are separate, you really mean the RPL root?

·        We should not say the following:

When the JRC is not co-located with the 6LBR, then the code point provides a clear indication to the 6LBR that this is join response traffic.

This seems to indicate that the traffic class may only be applied to join response. In the future, we may apply that behavior to other traffic. That’s linked to the point of having a class.

·        This could be listed as a dependency or an expectation, or just be declared out of scope:

Companion SF documents SHOULD specify how traffic with code point AF42 is handled with respect to cell allocation.

I’m not too happy with a SHOULD directed to an unnamed future spec as opposed to an implementer. Unsure how the IESG will react to that.

·        The URI host of the request may point on something more specific to any jrc as opposed to other nodes:

    The Uri-Host option is set to "6tisch.arpa". This is an anycast type of identifier of the JRC that is resolved to its IPv6 address by the JP

Suggestion: "default-jrc.6tisch.arpa".

·        The text below is not future proof

If the decoded CBOR unsigned integer value is larger than 255 (length defined by {{IEEE802.15.4-2015}})

I’d rather say larger than the “max MAC-Layer security key size, which is 255 with {{IEEE802.15.4-2015}}”

·        About the lease ASN, how is the JRC aware of the current ASN?

·        Some  acronyms like AEAD could be spelled out on first use

·        I think we were told to use a form like “IEEE Std. 802.15.4” to refer to the IEEE standards. Note that one should avoid dating the IEEE spec references unless there is a quote or a pointer that is specific to a particular year.

All in all, this is an excellent and very clear document, congratulation.

Do you expect 06 to be ready for WGLC?

Take care,

Pascal

---

From: Mališa Vučinić <[email-masked]>
Date: Tue, 15 May 2018 19:41:45 +0200

Thanks for this review, Pascal. I went quickly through your comments and I
should be able to fix all of this for -06. My goal is to have -06 ready for
WGLC.

On Tue, May 15, 2018 at 4:00 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello Mališa
>
>
>
> As you are getting ready to publish a next rev, please find simple
> comments on 05 that you may want to act upon in 06.
>
>
>
> ·        As mentioned earlier in the draft,  the most probable
> collocation for the JRC would be the 6LBR, and probably not a JP deep in
> the network.
>
> It deeply duty cycles its radio, switching the radio on when the provided
> schedule indicates slots which the pledge may use for the join process.
>
>
>
> But this seems to make the process very specific to TSCH when it could
> easily apply to IEEE Std. 802.15.4 at large. It is my reading that for the
> most part the protocol is not dependent of TSCH and that it could easily
> have  larger applicability. Is there a way to word it as “in the case of
> TSCH, …” ? also suggestion to reword “It deeply duty cycles” to follows
> the indicated schedule or something.
>
>
>
> ·        On paper the 6LoWPAN concept of 6LBR (a central registrar,
> though the 6LoWPAN definition indicates a border router function) is not
> necessarily the same guy as the RPL root, though it makes full sense that
> they are – and the 6TiSCH architecture recommends that they be. Maybe we
> could enforce that they are in another spec.
>
>
>
> The JRC can be co-located on the 6LBR. In this special case, the IPv6
> address of the JRC can be omitted from the Join Response message for space
> optimization. The 6LBR then MUST set the DODAGID field in the RPL DIOs
> {{RFC6550}} to its IPv6 address. The pledge learns the address of the JRC
> once joined and upon the reception of a first RPL DIO message, and uses it
> to operate as a JP.
>
>
>
> I’d add a sentence at the beginning of the spec that the text makes the
> assumption that the 6LBR is the RPL root per the architecture and that in
> case they are separate, you really mean the RPL root?
>
>
>
> When the JRC is not co-located with the 6LBR, then the code point provides
> a clear indication to the 6LBR that this is join response traffic.
>
>
>
> This seems to indicate that the traffic class may only be applied to join
> response. In the future, we may apply that behavior to other traffic.
> That’s linked to the point of having a class.
>
>
>
> I’m not too happy with a SHOULD directed to an unnamed future spec as
> opposed to an implementer. Unsure how the IESG will react to that.
>
>
>
>
>
>     The Uri-Host option is set to "6tisch.arpa". This is an anycast type
> of identifier of the JRC that is resolved to its IPv6 address by the JP
>
>
>
> ·        I think we were told to use a form like “IEEE Std. 802.15.4” to
> refer to the IEEE standards. Note that one should avoid dating the IEEE
> spec references unless there is a quote or a pointer that is specific to a
> particular year.
>
>
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 May 2018 15:06:40 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    pt> ·        We should not say the following:

    txt> When the JRC is not co-located with the 6LBR, then the code point
    txt> provides a clear indication to the 6LBR that this is join response
    txt> traffic. 

    pt> This seems to indicate that the traffic class may only be applied to
    pt> join response. In the future, we may apply that behavior to other
    pt> traffic. That’s linked to the point of having a class.

Maybe we could write:
    new> When the JRC is not co-located with the 6LBR, then the code point
    new> provides a clear indication to how the 6LBR should prioritize this
    txt> traffic. 

    txt> Companion SF documents SHOULD specify how traffic with code point
    txt> AF42 is handled with respect to cell allocation. 

    pt> I’m not too happy with a SHOULD directed to an unnamed future spec as
    pt> opposed to an implementer. Unsure how the IESG will react to that.

I see this as adding a requirement on future SF documents.
So updates draft-ietf-6tisch-6top-protocol section 4.
(It's practically an RFC)

    > The Uri-Host option is set to "6tisch.arpa". This is an anycast type of
    > identifier of the JRC that is resolved to its IPv6 address by the JP 

    > Suggestion: "default-jrc.6tisch.arpa".

Why make it longer? Note that it's already to a unique Path-URI (/j), so we
can add new things if it's CoAP.

    > Do you expect 06 to be ready for WGLC?

I need to do updates to IANA Considerations, but then, I think yes.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 15 May 2018 20:16:03 +0000

Hello Michael:

Regards,

Pascal

> Le 15 mai 2018 à 21:07, Michael Richardson <[email-masked]> a écrit :
> 
> 

The point is that 6TiSCH.arpa doesn’t dénote what 6TISCH service we are after. There may be others in the future like a PCE. 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 18 May 2018 12:27:52 +0200

Hi Pascal,

See responses inline.

Mališa

On Tue, May 15, 2018 at 4:00 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> This was assuming a special case of a pledge that is one hop away from the
6LBR, where 6LBR is co-located with the JP.

I removed "which may be co-located on the JP or another device" to avoid
confusion and added the following two sentences at the end of the Join
Process Overview section:

"
As other nodes in the network, the 6LBR node plays the role of the JP.
The 6LBR may in addition be co-located with the JRC.
"

> Who sets up what is unclear. Could you make it 2 sentences?

done

> the indicated schedule or something.

The join *process*, as described in the draft, is specific to TSCH because
of the EB assumption. The join *protocol*, however, is not and applies to
15.4 at large, as well as it could easily be applied to other IoT technos
with a registration of additional configuration parameters.

I rephrased "It deeply duty cycles" to "It follows the provided schedule"

I also added the following paragraph in the introduction:

"
The 6TiSCH Join Protocol defined in this document is generic and can be
used as-is in modes of IEEE 802.15.4 other than TSCH, that 6TiSCH is based
on.
The 6TiSCH Join Protocol may as well be used in other (low-power)
networking technologies where efficiency in terms of communication overhead
and code footprint is important.
In such a case, it may be necessary to register configuration parameters
specific to the technology in question, through the IANA process.
The overall join process described in {{join-process-overview}} and the
configuration of the stack is, however, specific to 6TiSCH.
"

> could enforce that they are in another spec.

I added the following sentence in the terminology section:

"
The term "6LBR", as used throughout the document, also denotes the function
of the "DODAG root" defined in {{RFC6550}}, assuming the two entities are
co-located, as recommended by {{I-D.ietf-6tisch-architecture}}.
"

I guess this should be enforced by the architecture draft?

> case they are separate, you really mean the RPL root?

See if the sentence above takes care of this.

> That’s linked to the point of having a class.
Deleted the sentence you cited.

> opposed to an implementer. Unsure how the IESG will react to that.
I guess this sentence belongs to the 6P document where SF requirements are
listed. Can we move it there at this point?

> Suggestion: "default-jrc.6tisch.arpa".

I am not happy to add this many bytes to the request..

How about we do "jrc.arpa" ?

> 255 with {{IEEE802.15.4-2015}}”

Rewrote the paragraph on key_index to:

"
* key_index: The identifier of the key, encoded as a CBOR unsigned integer.
This parameter MUST be included.
The parameter uniquely identifies the key and is used to retrieve the key
for incoming traffic.
In case of {{IEEE802.15.4-2015}}, the decoded CBOR unsigned integer value
sets the "secKeyIndex" parameter that is signaled in all outgoing and
incoming frames secured with this key.
If the decoded CBOR unsigned integer value is larger than the maximum
link-layer key identifier, which is 255 in {{IEEE802.15.4-2015}}), the key
is considered invalid.
Additionally, in case of {{IEEE802.15.4-2015}}, the value of 0 is
considered invalid.
In case the key is considered invalid, the implementation MUST discard the
key and attempt to decode the next key in the array.
"

> ·        About the lease ASN, how is the JRC aware of the current ASN?

Good catch, this has an implied assumption on JRC being co-located with
6LBR.

One option is to return this as seconds from the moment Join Response is
received by the pledge. The pledge would then need to convert it to ASN.
Makes sense?

> ·        Some  acronyms like AEAD could be spelled out on first use

Done

> spec references unless there is a quote or a pointer that is specific to a

Removed date from the 15.4 reference and updated the title to the one in
2015 version. Now using IEEE Std 802.15.4 when referring to the IEEE
802.15.4 without a reference.

> Do you expect 06 to be ready for WGLC?

Yes, I am working on it!

The repo commit of these changes is at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/498ec7f8907d42679392df9bd681130439659b27

Waiting for your response on .arpa name and the lease time before resolving
that.

Mališa

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 May 2018 13:00:14 +0000

Hello Mališa :

the JRC, which may be co-located on the JP or another device.
This was assuming a special case of a pledge that is one hop away from the 6LBR, where 6LBR is co-located with the JP.

I removed "which may be co-located on the JP or another device" to avoid confusion and added the following two sentences at the end of the Join Process Overview section:

"
[PT>] WFM : )

•        I see what you mean there

The join *process*, as described in the draft, is specific to TSCH because of the EB assumption. The join *protocol*, however, is not and applies to 15.4 at large, as well as it could easily be applied to other IoT technos with a registration of additional configuration parameters.

"
The 6TiSCH Join Protocol defined in this document is generic and can be used as-is in modes of IEEE 802.15.4 other than TSCH, that 6TiSCH is based on.
The 6TiSCH Join Protocol may as well be used in other (low-power) networking technologies where efficiency in terms of communication overhead and code footprint is important.
In such a case, it may be necessary to register configuration parameters specific to the technology in question, through the IANA process.
The overall join process described in {{join-process-overview}} and the configuration of the stack is, however, specific to 6TiSCH.
"

[PT>] Cool! The more we can indicate what is 6TiSCH specific the better; I really think your work should be considered across the board.

•        On paper the 6LoWPAN concept of 6LBR (a central registrar, though the 6LoWPAN definition indicates a border router function) is not necessarily the same guy as the RPL root, though it makes full sense that they are – and the 6TiSCH architecture recommends that they be. Maybe we could enforce that they are in another spec.

"
The term "6LBR", as used throughout the document, also denotes the function of the "DODAG root" defined in {{RFC6550}}, assuming the two entities are co-located, as recommended by {{I-D.ietf-6tisch-architecture}}.
"

I guess this should be enforced by the architecture draft?
[PT>] it is mentioned; question to ROLL related to the unaware leaves draft is whether we make it the rule. I think that was the intention in 6LoWPAN anyway.

[PT>] WFM

•        This could be listed as a dependency or an expectation, or just be declared out of scope:

I’m not too happy with a SHOULD directed to an unnamed future spec as opposed to an implementer. Unsure how the IESG will react to that.
I guess this sentence belongs to the 6P document where SF requirements are listed. Can we move it there at this point?
[PT>] Question to Xavi. From my perspective, 6P is way too advanced in IESG to add text that would discuss AF behavior. At least we’d need a rereview by the TSV area.

•        The URI host of the request may point on something more specific to any jrc as opposed to other nodes:

How about we do "jrc.arpa" ?
[PT>] To be validated with the arpa registry but I agree shorter is better.

•        The text below is not future proof

"
* key_index: The identifier of the key, encoded as a CBOR unsigned integer.
This parameter MUST be included.
The parameter uniquely identifies the key and is used to retrieve the key for incoming traffic.
In case of {{IEEE802.15.4-2015}}, the decoded CBOR unsigned integer value sets the "secKeyIndex" parameter that is signaled in all outgoing and incoming frames secured with this key.
If the decoded CBOR unsigned integer value is larger than the maximum link-layer key identifier, which is 255 in {{IEEE802.15.4-2015}}), the key is considered invalid.
Additionally, in case of {{IEEE802.15.4-2015}}, the value of 0 is considered invalid.
In case the key is considered invalid, the implementation MUST discard the key and attempt to decode the next key in the array.
"
[PT>] WFM

•        About the lease ASN, how is the JRC aware of the current ASN?

Good catch, this has an implied assumption on JRC being co-located with 6LBR.

One option is to return this as seconds from the moment Join Response is received by the pledge. The pledge would then need to convert it to ASN. Makes sense?
[PT>] Yes; The 6LBR could convert a sense of global time into ASN back and forth. There must be enough buffer to make sure the message reaches the pledge before application ASN has come. I wonder if it could also be that the JRC indicates a relative time offset that the 6LBR could convert?

•        I think we were told to use a form like “IEEE Std. 802.15.4” to refer to the IEEE standards. Note that one should avoid dating the IEEE spec references unless there is a quote or a pointer that is specific to a particular year.

Removed date from the 15.4 reference and updated the title to the one in 2015 version. Now using IEEE Std 802.15.4 when referring to the IEEE 802.15.4 without a reference.
[PT>] You may want 2 references, one dated 2015 for the key-size discussion about and one undated for the general discussion.

Yes, I am working on it!

Waiting for your response on .arpa name and the lease time before resolving that.

[PT>] there you go then

Take care,

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 May 2018 11:09:37 -0400

> The point is that 6TiSCH.arpa doesn’t dénote what 6TISCH service we are
    > after. There may be others in the future like a PCE.

I don't understand at all.  Would a PCE provide enrollment services?

1) We specify the service we want with the Path-URI (/j for join).
   We could have /p for a PCE, but, I'm not sure what it would do.
   
2) There is never an IP address associated with 6tisch.arpa, it's just
   something to put into the Host part of the CoAP.  Since we are talking
   to a Join Proxy, and the Join Proxy points to the JRC, we get the JRC.

   If we had something that wanted a PCE, what would it talk to get that?
   Wouldn't the node already have enrolled?
   How would it get the IP address of the PCE?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 May 2018 18:00:57 +0000

Hello Michael

> -----Original Message-----
> From: 6tisch <[email-masked]> On Behalf Of Michael Richardson
> Sent: vendredi 18 mai 2018 17:10
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [6tisch] On minimal-security
> 
> 
[PT>] We are talking to a stateless CoAP proxy, giving an alias to a service that it will map into the IP address of the server, here the JRC.
I understood that this is an anycast name for the JRC, aimed to be resolved by the proxy in a pseudo DNS fashion into the IP address of the server. Do I have that wrong?
If the proxy is used for only one service, arguable there is no need to pass a string at all. If it is generic enough and used for more than one service than we need something meaningful. I'm not sure which we really want but 6tisch.arpa fails either way.

>    We could have /p for a PCE, but, I'm not sure what it would do.
[PT>] The path URI is on the server, but the proxy needs to find that server. At least that's the way usual http proxies work. 

>    to a Join Proxy, and the Join Proxy points to the JRC, we get the JRC.
[PT>] OK then you seem to be looking at a dedicated proxy; if so, why a string at all?
>    How would it get the IP address of the PCE?
[PT>] The string could be a real DNS name. The question is whether the instance of the proxy is dedicated to join or not...

Cheers,

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 May 2018 17:17:10 -0400

>> I don't understand at all.  Would a PCE provide enrollment services?
    
    pt> [PT>] We are talking to a stateless CoAP proxy, giving an alias to a
    pt> service that it will map into the IP address of the server, here the
    pt> JRC.
    
    pt> I understood that this is an anycast name for the JRC, aimed to be
    pt> resolved by the proxy in a pseudo DNS fashion into the IP address of
    pt> the server. Do I have that wrong?

Not the case.
It's just a value for the CoAP Host "header"

    > If the proxy is used for only one service, arguable there is no need to
    > pass a string at all. If it is generic enough and used for more than
    > one service than we need something meaningful. I'm not sure which we
    > really want but 6tisch.arpa fails either way.

    >> to a Join Proxy, and the Join Proxy points to the JRC, we get the JRC.
    
    pt> [PT>] OK then you seem to be looking at a dedicated proxy; if so, why a
    pt> string at all?

Because CoAP header needs one, and the original name wasn't going to get past
the IESG.

    > [PT>] The string could be a real DNS name. The question is whether the
    > instance of the proxy is dedicated to join or not...

---

From: Mališa Vučinić <[email-masked]>
Date: Sat, 19 May 2018 08:12:32 +0200

Michael,

I am not sure I follow. How come is it not the case that this well-known
host name is resolved to an IP address?

When JP receives a first DIO and learns the DODAG root’s IPv6, it stores
the IP address as the resolution of 6tisch.arpa. Same thing when it learns
the JRC’s IPv6 through the Join Response.

When a CoAP message to be proxied is received, and URI-Host that is in the
clear indicates 6tisch.arpa, the name is resolved to the previously stored
IP address and a new CoAP message is generated creating a new IPv6 packet.
Note that URI-Path is encrypted and therefore not available to the proxy.

How is then 6tisch.arpa never associated with an IPv6 address?

Mališa

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 19 May 2018 11:35:42 +0000

I’m lost as well;

I understood so far sar the CoAP URI host is the same as the http host: header parameter. If I m correct then this is normally a string with the dns name and port to reach the server. Without it, the proxy wouldn’t know how to reach the server in the first place. Without it, a multihomed server wouldn’t know which instance it reached. This is why I understood it became mandatory in http 1.1.

Where is s the disconnect?

Pascal

Le 19 mai 2018 à 08:12, Mališa Vučinić <[email-masked]<mailto:[email-masked]>> a écrit :

Michael,

I am not sure I follow. How come is it not the case that this well-known host name is resolved to an IP address?

When JP receives a first DIO and learns the DODAG root’s IPv6, it stores the IP address as the resolution of 6tisch.arpa. Same thing when it learns the JRC’s IPv6 through the Join Response.

When a CoAP message to be proxied is received, and URI-Host that is in the clear indicates 6tisch.arpa, the name is resolved to the previously stored IP address and a new CoAP message is generated creating a new IPv6 packet. Note that URI-Path is encrypted and therefore not available to the proxy.

Mališa

On Fri, 18 May 2018 at 23:17, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Not the case.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]<mailto:[email-masked]>  http://www.sandelman.ca/        |   ruby on rails    [

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 May 2018 09:02:40 -0400

> host name is resolved to an IP address?

We don't need to map this name to an IP address, nor could we have a
consistent mapping world-wide.  The IP address is known to the Join Proxy
(6LBR root or other JRC address provided to JP).  The CoAP traffic is
directed at the JRC by this process.

The only reason we need the name at all is because we have to fill in the
Uri-Host.  Well.. I just re-read https://tools.ietf.org/html/rfc7252#section-5.10, 
and I realize that Uri-Host is not required, so actually we should just drop
it entirely.

    > the JRC’s IPv6 through the Join Response.

If you want to think of it that way, sure, the JP is storing a mapping
of 6tisch.arpa to that IPv6.  I'm saying that *DNS* won't tell us the answer.

    > How is then 6tisch.arpa never associated with an IPv6 address?

In your model, it could do that.  I didn't think of it as working like that,
but in my model all traffic that the JP receives via that channel
goes to the JRC: it has a single purpose.

In your model, the JP could proxy traffic to any place, I guess, but I didn't
really want that to happen.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 May 2018 09:16:41 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > I understood so far sar the CoAP URI host is the same as the http host:
    > header parameter. If I m correct then this is normally a string with
    > the dns name and port to reach the server. Without it, the proxy
    > wouldn’t know how to reach the server in the first place. Without it, a
    > multihomed server wouldn’t know which instance it reached. This is why
    > I understood it became mandatory in http 1.1.

1) apparently it's not mandatory in CoAP (I thought it was until a few
   minutes ago).    We can save ~15 bytes here.

2) The proxy knows where the JRC is because it's been told the IP address of
   the JRC, either implicitely (it's the DODAG root, aka 6LBR), or
   explicitely via the response.

Remember that we can type https://[fde4:8dba:82e1::1234]/ or, in this case,
we want the pledge to say: coap://[fe80::1234]/j, which the Join Proxy
forwards to coap://[fde4:8dba:82e1::1234]/j (of ourse, using OSCORE).

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 24 May 2018 10:58:57 +0200

@Michael, @Christian

I am re-reading RFC7252, Section 5.7.2:

Unless a proxy is configured to forward the proxy request to another proxy,
> it MUST translate the request as follows: the scheme of the request URI
> defines the outgoing protocol and its details (e.g., CoAP is used over UDP
> for the "coap" scheme and over DTLS for the "coaps" scheme.) For a
> CoAP-to-CoAP proxy, the origin server's IP address and port are determined
> by the authority component of the request URI, and the request URI is
> decoded and split into the Uri-Host, Uri- Port, Uri-Path and Uri-Query
> Options. This consumes the Proxy-Uri or Proxy-Scheme option, which is
> therefore not forwarded to the origin server.
>

I suppose you are referring to this implicit configuration of the proxy
that would forward to the JRC anything received on a link-local address, if
the request does not have the Uri-Host option?

It seems to be OK, and doesn't prevent much of the CoAP proxy functionality
for other purposes. I am waiting for the confirmation from Christian of
there is any other RFC7272 pitfall with this before doing the changes in
the draft.

I kind of liked the 6tisch.arpa "thing", but no argument with ~13-byte
savings :-).

Mališa

On Sat, May 19, 2018 at 3:17 PM Michael Richardson <[email-masked]>
wrote:

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 May 2018 14:44:02 -0400

> I am re-reading RFC7252, Section 5.7.2:

okay, but I'm not claiming that the Join Proxy is a CoAP Proxy by the rules
given in 7252.  It started as just a circuit proxy (i.e. algorithm gateway), but
we wanted it to be stateless, so we (ab)used some CoAP things to do that.
I never intended it go into the contents of the packet, interpret CoAP in any
way.

    >> therefore not forwarded to the origin server.

We don't use Proxy-URI or Proxy-Scheme.

    > I kind of liked the 6tisch.arpa "thing", but no argument with ~13-byte

I don't think we need it.

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 24 May 2018 21:02:18 +0200

On Thu, 24 May 2018 at 20:44, Michael Richardson <[email-masked]>
wrote:

> given in 7252.

Sure it is, every attempt was made to have JP just a regular CoAP proxy
with no application code. I claim that the current text is fully compliant
with RFC7252 proxy and also takes into consideration processing rules of
OSCORE-aware proxy.

It started as just a circuit proxy (i.e. algorithm gateway), but
> I never intended it go into the contents of the packet, interpret CoAP in

It seems we have misunderstandings on this :-)

> We don't use Proxy-URI or Proxy-Scheme.

Sure we do, we use Proxy-Scheme in order to keep OSCORE-aware proxy
processing to a minimum. See the section on the mappings of join protocol
messages to CoAP.