Re: [6tisch] security text on minimal

could be the same as K2, as an implementor might assume this to always be the case.} I think that your text captures consensus. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature

Re: [6tisch] Removing the 'e' in the charter

do that in November. At which point, my question about -year vs not year might have a different answer. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature

Re: [6tisch] Shipping minimal

! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ 6tisch mailing list

Re: [6tisch] Shipping minimal

the initial bootstrap, but those uses will require the EBs to integrity protected for those devices who are already part of network. Good... I'd like to hear more. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software

Re: [6tisch] Shipping minimal

will get set at the same time, and K1 and K2 will get set to . -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https

Re: [6tisch] joining security start and end states

would prefer to leave (A) out for now. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo

Re: [6tisch] security section in minimal

a choice about. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6top and neighbour list

___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6top and neighbour list

, but maybe you can format on linux or mac. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman

Re: [6tisch] 6top and neighbour list

a YANG model for RPL info. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] 6tisch-rechartering: ANIMA vs. Join process

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

Re: [6tisch] security of EBs

that perhaps in one PANID might be easily answered. (A 6TiSCH network could span many physical locations, be bridged across ethernet, and include a multitude of PANIDs, behind a multitude of 6BRs) -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting

Re: [6tisch] security of EBs

it matter that the EB be authenticated? -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman

Re: [6tisch] questions about draft-richardson-security-6top

out response... On 13 May 2015, at 09:43, Michael Richardson mcr+i...@sandelman.ca wrote: So, here, I think you are imagining using some kind of pre-provisioned session-resumption ticket to replace the initial TLS handshake. I think that this is something that one could

Re: [6tisch] Directions on the join process

this be a new milestone? -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Directions on the join process

are resuable depends upon how they are made, I think. If there is more than one of them, that's another question, but they can be produced by the manufacturer in a situation where there is lot of power, or the key is available, etc. -- Michael Richardson -on the road- pgp3wEaiJWKDZ.

Re: [6tisch] about the secure join process

ever tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ 6tisch mailing list 6tisch@ietf.org

Re: [6tisch] about the secure join process

> necessary, strictly from a security perspective? All the relevant protocols require between 2 and 3 round trips to get things working. How many fraglets that works out depends upon how big the certificate chains (if any) are sent. -- Michael Richardson <mcr+i...@sandelman.ca>, S

Re: [6tisch] about the secure join process

aged by the JCE as it potentially has resources similar to the attacker. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@iet

[6tisch] an idea about 1X and 6tisch

layer does fragmentation/fraglettation; or even if there is enough bytes left over to make this useful at all. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http

Re: [6tisch] #41 (minimal): intended status for draft minimal

of 6LoWPAN on normal > 802.15.4. > Do you mean that we should be explicit in saying the a minimal node > must support at least 6LoWPAN RFCs ? I'm saying that an IP-over-FOO(802.15.4e) should probably say these things. -- Michael Richardson <mcr+i...@sandelman.ca>

Re: [6tisch] #41 (minimal): intended status for draft minimal (was: internded status for draft minimal)

al difference between those > two, i.e. it does not matter whether it is profile or whether it is new > protocol for the IETF process point of view. Would a profile = BCP? -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signatu

Re: [6tisch] Summary of proposed resolution for issue 40:

all the changes. You don't tell me if will be Informational, BCP, or Standards track. (I am still in favour of PS/IS, but my previous objection to BCP is withdrawn) -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Descr

Re: [6tisch] FW: ETSI CL15_3234: Call for technical expertise for the 2nd 6TiSCH Plugtests™

see inline On 10/09/15 09:45, Miguel Angel Reina Ortega wrote: > Let me forward you the Call for Expertise that has been recently sent > out from ETSI for the upcoming 2^nd 6TiSCH Plugtests that will be held > from 2^nd to 4^th February 2016 in Paris. Thank you again for organizing this. Do

Re: [6tisch] #41 (minimal): intended status for draft minimal (was: internded status for draft minimal)

LL document that should be on standards track that minimal should reference. This might still be a good idea. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature __

Re: [6tisch] #41 (minimal): intended status for draft minimal

o we support ND-only nodes that don't speak RPL, 6top or minimal? -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org

Re: [6tisch] #41 (minimal): intended status for draft minimal

ple who know both. I know it only as the hammer we use to deal with vendor proprietary protocols in government procurement) Minimal is definitely more like 6881 than 7696. BUT, I think it (rfc6881) should have been published as standards track myself! -- Michael Richardson <mcr+i...@sandelman.c

Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH

runs over ICMP ND messages. I think the thing you are describing is the IPv6 stack, and you don't like that the IPv6 stack has to interact with the link adaptation layer. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works IETF ROLL WG co-chair.http://dat

Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH

original headers, I think it is a pity that 6LoRH > doesn't. It's true that not all RH3 headers can be as efficiently compressed. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architec

Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH

do you feel is required? There needs to be some communication of what are the interesting prefixes. I don't see this as a problem. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Descript

Re: [6tisch] [6lo] The "BEFORE" and "AFTER"

om one leaf to another leaf, would either end actually know the IP of the root? I think that the RPL daemon would have to program them. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signatu

Re: [6tisch] [6lo] Compression Reference and Coalescence

one just before > it). The above paragraph is pretty clear. Use it. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.

Re: [6tisch] [6lo] AD sponsoring draft-kivinen-802-15-ie-02

9 have it's own registry, and if so would we need different liason request for that? -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mail

[6tisch] virtual meetings

A number of us were told by our calendars that there was a meeting today, but actually I realize that nothing has been announced on the list, and the bitbucket.org is empty. For the benefit of our calendars, when will the friday phone calls resume? -- Michael Richardson <mcr+i...@sandelman

[6tisch] section 11.2 of minimal

-paging-dispatch]. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] 6lo-ra-in-ie becoming

of the network. The result will be a 32-byte hash, and the lower 16-bytes should be used. {oh. I show only 8 bytes of network-ID in the picture. Oops. I will grow the diagram} -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT cons

[6tisch] avoiding allocating cells for join traffic

? Either explicitely (DSCP perhaps?), or implicitely (this cell is join traffic). -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list

Re: [6tisch] secure join bootstrap

see inline. On 02/08/17 04:10, peter van der Stok wrote: > Hi 6tisch security, > > Having re-read RPLinfo and reading the secure-join draft, I do have a > suggestion about the traffic from pledge to registrar. The draft already > mentions the IP-in-IP encapsulation specified in RPLinfo draft.

[6tisch] converging on some common terminology

and it might be out of scope. ACTION ITEMS 1) ANIMA documents to update terms, and be authoritative for terms. 2) 6tisch documents to update terms, pointing at ANIMA and 6tisch terminology. 3) 6tisch terminology document to include the terms as being imported from ANIMA. 4) ne

Re: [6tisch] Time to Live - ASN in a packet

ed for another RPL artifact. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] about 6lo-ra-in-ie

A few weeks ago I posted about draft-ietf-richardson-6lo-ra-in-ie, which was a method for storing 6loRH compressed Routing Advertisements in 802.15.4 Information Elements. The mechanism described would have permitted arbitrary IPv6 packets to be stored there (it was a general mechanism). The

[6tisch] 6tisch security bi-weekly meetings

://ietf.webex.com/ietf/j.php?MTID=me98f12cebda5e6b55c1b8c66c095d0a9 Host key: 587716 Audio connection: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT cons

Re: [6tisch] [Anima] 6tisch security bi-weekly meetings

peter van der Stok <stokc...@xs4all.nl> wrote: > which meeting do you want me to join? You are welcome at both. The 6tisch is probably more important in some ways, The EST/CoAP discussion will be easier to have in the anima group. (I will post to ace about that this week) -

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

tever internal API it wants to your RPL implementation. This is hardly a standardization issue or problem; this is a quality of implementation issue. The observation of *when* RPL should clear traffic reservation may have some impact on the SF0 protocol, but I'd think it would be just some impleme

Re: [6tisch] [Ace] EST over CoAP in ACE wg

is where OSCOAP and EDHOC seem to be, I'm happy to work on a document here. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ie

Re: [6tisch] [Ace] EDHOC and EALS use in 6tisch (minimal) bootstrap

s ideally suited to make the >> introductions between RS<->RO, and C<->RqP that ACE needs for >> bootstraping it's trust model. > RS <-> RO and C<->RqP?; what is the mapping to pledge, JA and > Registrar? > Looking forward to the present

Re: [6tisch] [6tisch-security] IP-IP-IP example?

ld use (well-known?) 6LoWPAN > contexts and hostnames to avoid that. I agree that using a 6lo context would be a good idea here. It seems that it can also be used with either method. I will write some examples today and post. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman S

[6tisch] EDHOC and EALS use in 6tisch (minimal) bootstrap

e-eals-00.txt > This is a strawman on certificate enrolment using the new IoT > application layer security protocols. If certificate enrolment for IoT > devices is on the agenda then we would like to present this. > Time: 10 min Objective: Ask for review -- Mi

Re: [6tisch] Interim, 14 April 2017 interim, 6TiSCH WG

t; * [7:22] 6P finalization (Thomas, Qin) [10min] > * [7:37] Update on security (Michael/Malisa) [10min] I don't know much new to say to soon after IETF98. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- sign

[6tisch] Thomas comments on enhanced-beacon draft (Re: [6lo] Thomas' review of draft-richardson-6lo-ra-in-ie-00)

Thomas, I didn't want process your review last fall when you did it because it was clear the document would mutate. I just went through and salvaged what parts I thought still applied. https://goo.gl/xuesHh contains a diff that contains your suggestions. -- Michael Richardson <mc

Re: [6tisch] [Anima-bootstrap] [Ace] EST over CoAP in ACE wg

tand this. Why do you say that the pledge did not generate it by himself? I"m assuming that it did so at manufacturing time, and that an IDevID certificate was bound to the public part of the key. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -=

Re: [6tisch] [Anima] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017

does. Also proves you read every word. We also accept patches via github :-) -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6tisch-pre-reqs-00 <- can it be implemented??

overhearing device will know... In the overhearing case, yes. It implies in the end that we can't have per-pair keying. In the case where we send two unicast packets, the keying can be done in anyway. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works

Re: [6tisch] Suggestion to add Example Packets for 6TiSCH Configuration into useofrplinfo draft

de such packets. I'm not sure what we would do with the beacons and other L2 examples. Maybe this was a poor idea in the end. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___

[6tisch] BRSKI voucher document passed WGLC

comments) -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [Roll] Suggestion to add Example Packets for 6TiSCH Configuration into useofrplinfo draft

r. But perhaps we will still want to grab a few example packets both uncompressed and compressed for useofrplinfo. (There is a reason to implement uncompressed RPI, which is because you extend the RPL DODAG across non-constrained media) -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Sof

Re: [6tisch] draft-richardson-6tisch-roll-join-priority-00 --- RPL DIO message

balling > here... Doing that would involve exposing the DIOs to untrusted strange nodes. That would disclose the PIOs, which many people were uncomfortable with. I'm also not sure if it would fit into the Enhanced Beacon! BUT, it would eliminate a multicast! -- Michael Richardson &

[6tisch] draft-richardson-6tisch-roll-join-priority-00 --- RPL DIO message

uld suggest that if there was no thought that the first one (enhanced-beacon) might be turned over the IEEE. Perhaps Pascal could explain that comment from Monday. internet-dra...@ietf.org wrote: > A new version of I-D, draft-richardson-6tisch-roll-join-priority-00.txt > has been successfu

Re: [6tisch] new command for 6P

eems like at least the content must include the SFx type so that there is no confusion of SFx's IE with SFy's IE. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature __

[6tisch] draft-duquennoy-6tisch-asf-00

to the simulation if the addresses are skewed in this fashion? 2) can the JRC hand out short addresses in a way that benefits ASF? 3) could/should the RPL rank be incorporated in some way into the hash? -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IP

[6tisch] 6tisch-pre-reqs-00 <- can it be implemented??

lities of this are amazing, but I wonder if this will realistically work with many pieces of hardware. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- ___ 6tisch mailing list 6tisch@ietf.org https://

Re: [6tisch] 6tisch-pre-reqs-00 <- can it be implemented??

urse, over time hardware will evolve. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-03.txt

message to the JRC. Are these messages from the same pledge? Or messages from different pledges? The pledge needs to pick a single proxy for a single exchange. The pledge *MAY* initiate exchanges via multiple proxies, but they should be different messages. -- Michael Richardson <mcr+i...@san

Re: [6tisch] 6TiSCH interop: 6LoRH and OSCOAP as a requirement?

Simon Duquennoy <simon.duquen...@inria.fr> wrote: > Will single-hop communication work seamlessly between a 6LoRH node and > a non-6LoRH node? no. A 6loRH node could implement both, but in general, it is a flag day on the protocol. -- Michael Richardson <mcr+i.

Re: [6tisch] Minutes, 23 June 2017 interim, 6TiSCH WG

yptable for others. > * Malisa: Biggest issue is status of EDHOC draft. we anticipate a possible phone call before IETF99, with a meeting at IETF99 to resolve things. Apparently, re-opening COSE WG has been considered. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Wo

[6tisch] 6P - lollipop

reach the end of the numbering space[1]. > with a link to: > http://www.ciscopress.com/articles/article.asp?p=24090=4 > are we sure that we are not being bitten in the same way? -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consu

[6tisch] SF0 - lollipop

of the numbering space[1]. with a link to: http://www.ciscopress.com/articles/article.asp?p=24090=4 are we sure that we are not being bitten in the same way? -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP sig

Re: [6tisch] Agenda, 8 September 2017 interim, 6TiSCH WG

f-anima-bootstrapping-keyinfra-07 or: https://goo.gl/mc7S2q -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org h

Re: [6tisch] Agenda, 8 September 2017 interim, 6TiSCH WG

I think that I can cover core-coap-est as part of reshaping. So maybe 10+5 would be enough. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mail

Re: [6tisch] draft-duquennoy-6tisch-asf-00

rovisioning more bandwidth closer to the root is one thought I had. The pending frame bit could work to extend the duration of the slot, but that won't help if that slot is allocated to another child! -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulti

[6tisch] pending with 6tisch-minimal-security

we are now using POST, we can now consider if we can return this. I'd like to make it in-scope. It clearly can not be trusted, but it can help. If a pledge had other options then it could continue on to those options immediately and return to this network at the time indicated. -- Michael Richard

Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?

plinfo! Pascal is, I think, overstating the compromise/ambiguous text in RFC8200. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list

[6tisch] agenda for design team meeting 11am EST

6tisch-security?useMonospaceFont=true The agenda is loose, but: 1) recap of IETF100, things arising from meeting. 2) frequency of these meetings 3) state of 6tisch-minimal (briefly) 4) state of 6tisch-zerotouch-join (briefly) 5) plan for getting EST-COAPS to progress -- Michael Richardson

Re: [6tisch] [6tisch-security] agenda for design team meeting 11am EST

peter van der Stok <stokc...@xs4all.nl> wrote: > Meeting 25 December (Xmas 1) is a bit of an exaggeration. I did delete that from the recurrance in the ics invite. :-) -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

Re: [6tisch] Tagging join traffic

s before we know that the node is legitimate. (many RTTs if we have to use DTLS, two if we can have EDHOC) -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___

Re: [6tisch] Tagging join traffic

Michael Richardson <mcr+i...@sandelman.ca> wrote: > To be specific, I think that the JP should set the DSCP bits in the packet > as per rfc2597 section 6, we want AF43 (0b100110). https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/pull-requests/4/join-traffic-

Re: [6tisch] Tagging join traffic

et it. https://tools.ietf.org/html/rfc3542#section-6.5 -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.o

Re: [6tisch] Tagging join traffic

Michael Richardson <mcr+i...@sandelman.ca> wrote: > Pascal Thubert (pthubert) <pthub...@cisco.com> wrote: >> Yet not sure the MAY on the return path is a good idea. Either make it >> a SHOULD or a no no. Otherwise we do not know what to expect in a give

Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?

he one leaving the DAGroot, and so if the JRC employs even a simple BQL on the outgoing AF43 queue is should work well. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: P

Re: [6tisch] Tagging join traffic

at the 6lowRH level to send the bits which were otherwise zero and compressed out. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] pending with 6tisch-minimal-security

l to attempt later? If there is an error at JRC, we stay silent > anyways. Yes, you make a good point. If the response fits into a single 802.15.4 frame, then any Pending takes the same amount of bandwidth. -- ] Never tell me the odds! | ipv6 mesh networks [ ]

Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?

hy in this non-storing, RPL-aware situation is there even an IPIP outer header for traffic from the proxy to the DODAG root? -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature _

Re: [6tisch] pending with 6tisch-minimal-security

s for a different situation: The request was accepted, but > needs more work before it can return its result. "more work", I interpret to include, "more crypto"? -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?

ly run a second Join Proxy pointing at the JRC, or being much more resourceful node, even a stateful proxy. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature _

Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?

cision. If one has a network that is intolerant of the 0x63 RPI option, and updating the LLN is not feasible, then either fixing that in the DODAG root or removing the header at the DODAG seems like something a product might just do. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman So

[6tisch] poll for weekly teleconference

. If you have suggestions for additional times, let me know. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org

Re: [6tisch] Tagging join traffic

> spec, which allows a forwarding node to identify join traffic... Even if it wasn't encrypted end to end (it's not in CoAP+OSCOAP), you don't really want to be doing deep packet inspection in the middle, and there is no guarantee that attackers will put that value in for you. -- Michael

Re: [6tisch] Tagging join traffic

et as per rfc2597 section 6, we want AF43 (0b100110). -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] I-D Action: draft-ietf-6tisch-dtsecurity-zerotouch-join-01.txt

[ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

idea what's where) I'm fine with that, but in that case, we need to tell such a pledge how to find a Join Proxy and/or the actual JRC. At present, we use the 15.4 specific Enhanced Beacon. There a bunch of options: 1) DHCPv6 2) GRASP 3) mDNS (DNS-SD) 4) RA option -- ] Ne

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

ing > mechanism that we discussed. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ s

Re: [6tisch] On minimal-security

e the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___

Re: [6tisch] On minimal-security

the pledge to say: coap://[fe80::1234]/j, which the Join Proxy forwards to coap://[fde4:8dba:82e1::1234]/j (of ourse, using OSCORE). -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ]

Re: [6tisch] On minimal-security

if it's CoAP. > All in all, this is an excellent and very clear document, congratulation. > 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 [ ]

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

ose. Good, so we can just mark it as out-of-scope. I think that this is okay. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

I take your point. > Makeing this minimal-security draft to only allow AES-CCM-128 and not > even allow easy extensibility for other algorithms would be bad idea > now. Agreed. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richards

Re: [6tisch] On minimal-security

> the draft. > I kind of liked the 6tisch.arpa "thing", but no argument with ~13-byte > savings :-). I don't think we need it. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Softwa

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

ill also need updating? It would be good to start an internet-draft to collect things. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca

Re: [6tisch] On minimal-security

t would it talk to get that? Wouldn't the node already have enrolled? How would it get the IP address of the PCE? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sande

Re: [6tisch] On minimal-security

>> 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... -- ] Never tell me the odds! | ipv6 mesh networks [

  1   2   3   >