Re: [OPSAWG] [Iotops] Status update on MUD-IoT-DNS-Considerations

2021-07-15 Thread Eliot Lear
I think the deployments also have to be somewhat forgiving in terms of maintaining an ACL some period beyond TTL.  It would make a good paper to understand just how much. On 15.07.21 23:02, Michael Richardson wrote: Eliot Lear wrote: > What is and is not a good idea is highly contextual

Re: [OPSAWG] [Iotops] Status update on MUD-IoT-DNS-Considerations

2021-07-15 Thread Michael Richardson
Eliot Lear wrote: > What is and is not a good idea is highly contextual in this case.  The > network CAN provide a level of protection to limit attacks on devices, but it > can only do so if it knows who that device wants to talk to.  There is no > magic here.  Either the

Re: [OPSAWG] [Iotops] Status update on MUD-IoT-DNS-Considerations

2021-07-15 Thread Eliot Lear
What is and is not a good idea is highly contextual in this case.  The network CAN provide a level of protection to limit attacks on devices, but it can only do so if it knows who that device wants to talk to.  There is no magic here.  Either the bindings can be established or they can't.

Re: [OPSAWG] Status update on MUD-IoT-DNS-Considerations

2021-07-15 Thread Michael Richardson
Carsten Bormann wrote: >> As an example of a TCP connection that would be hard to describe, > Ah, right, we are using IP addresses as credentials (in the “ACLs” inside MUD). >> That's a lot of access, and leaves all of EC2 attackable by IoT devices. > And, more importantly,

Re: [OPSAWG] Status update on MUD-IoT-DNS-Considerations

2021-07-15 Thread Toerless Eckert
Reminds me of the concern about authentication of addressing i just brought up on another mailing list to you ;-) On Thu, Jul 15, 2021 at 08:39:44PM +0200, Carsten Bormann wrote: > On 15. Jul 2021, at 20:16, Michael Richardson wrote: > > > > As an example of a TCP connection that would be hard

Re: [OPSAWG] Status update on MUD-IoT-DNS-Considerations

2021-07-15 Thread Carsten Bormann
On 15. Jul 2021, at 20:16, Michael Richardson wrote: > > As an example of a TCP connection that would be hard to describe, Ah, right, we are using IP addresses as credentials (in the “ACLs” inside MUD). > That's a lot of access, and leaves all of EC2 attackable by IoT devices. And, more

Re: [OPSAWG] Status update on MUD-IoT-DNS-Considerations

2021-07-15 Thread Michael Richardson
Carsten Bormann wrote: >> My takeaway from all of this was that essentially... if geofenced/CDNed DNS >> is not gonna for for IoT devices with MUD files... then maybe the advice >> about working around them is WRONG. Maybe the right advice is... DON'T DO THAT. >> >> {ME:

Re: [OPSAWG] [Iotops] Status update on MUD-IoT-DNS-Considerations

2021-07-15 Thread Michael Richardson
Robert Kisteleki wrote: >> but also that the IoT device should also be careful to observe >> caching semantics, particularly in the case of a connection failure. > Doesn't that prescribe that the IoT devices "should behave correctly"? > Because we all know in reality they do

Re: [OPSAWG] [Qlog] adopting draft-gharris-opsawg-pcap and draft-tuexen-opsawg-pcapng

2021-07-15 Thread Michael Richardson
> "tp" == OPSAWG on behalf of Michael Richardson > writes: tom petch wrote: mcr> Yes, this is called First Come, First Served. mcr> It usually has an Designated Expert that IANA consults. tp> tp> Not really - see RFC8126 s.4. tp> FCFS is no more than an

[OPSAWG] L2NM: Make the Ethernet Segment (ES) a standalone entity

2021-07-15 Thread mohamed.boucadair
Hi all, Moti raised two days ago a comment about moving the ES upper in the hierarchy. More details about the issue can be found at: https://github.com/IETF-OPSAWG-WG/lxnm/issues/327. Unless there are objections, we will proceed with the change and update the examples accordingly. Cheers,

[OPSAWG] I-D Action: draft-ietf-opsawg-vpn-common-09.txt

2021-07-15 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : A Layer 2/3 VPN Common YANG Model Authors : Samier Barguil

[OPSAWG] I-D Action: draft-ietf-opsawg-l3sm-l3nm-10.txt

2021-07-15 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : A Layer 3 VPN Network YANG Model Authors : Samier Barguil

Re: [OPSAWG] Status update on MUD-IoT-DNS-Considerations

2021-07-15 Thread Carsten Bormann
> My takeaway from all of this was that essentially... if geofenced/CDNed DNS > is not gonna for for IoT devices with MUD files... then maybe the advice > about working around them is WRONG. Maybe the right advice is... DON'T DO > THAT. > > {ME: Doctor! Doctor! It hurts when I use a geographic

Re: [OPSAWG] [Iotops] Status update on MUD-IoT-DNS-Considerations

2021-07-15 Thread Robert Kisteleki
This means that the resolver needs to be integrated with the MUD manager I think you're right. However, we also know this kind of bundling is not always a good idea, or even favourable. Like an init system that has a built-in network manager, DNS resolver or MUD controller :-) > but also

Re: [OPSAWG] Status update on MUD-IoT-DNS-Considerations

2021-07-15 Thread Robert Kisteleki
Hi, Due to the unpredictability of cache evictions, one can never be sure that that the DNS server won't have to make a new query, and get a new geofenced answer. I believe it's not only about geofenced answers, but answers in general. Maybe because of geofencing, maybe for other reasons.

Re: [OPSAWG] [Qlog] adopting draft-gharris-opsawg-pcap and draft-tuexen-opsawg-pcapng

2021-07-15 Thread tom petch
From: OPSAWG on behalf of Michael Richardson Sent: 14 July 2021 18:16 Guy Harris wrote: > One of the other daemons is journald, which is a syslogd replacement: > https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html > The "systemd" block in pcapng is