[OPSAWG] Here's MUD in your eye!

Hi everyone, For the last few months I've been working on a little effort which I call MUD. It stands for Manufacturer Usage Descriptions, and it focuses on the security of Things. There are already quite a lot things and more on the way (Cisco estimates 50 billion by 2020, and others say more).

[OPSAWG] Way forward? Re: Procedural issues with the TACACS+ document

Hi Alan, I'm not unsympathetic to the idea that we should focus efforts where possible, and I'm also not interested in piling on. But I think a comment is in order regarding RFC 3127 and then I have a proposal for a way forward. On 2/11/16 4:25 PM, Alan DeKok wrote: > > - even if there were no p

Re: [OPSAWG] Way forward? Re: Procedural issues with the TACACS+document

Tom, On 2/12/16 10:41 AM, t.petch wrote: > Looking at the Informational RFC in the RFC-index, I see > > Cisco Architecture for Lawful Intercept in IP Networks > Cisco Systems NetFlow Services Export Version 9 > Cisco's Mobile IPv4 Host Configuration Extensions > Cisco Systems UniDirectional Link D

Re: [OPSAWG] TACACS+, a suggestion

Hi Stefan, Unless it is absolutely determined that the current work can't doesn't meet criteria for an IETF standard, I would be opposed to such an exercise. For one thing, we all have other things to do. For another, and as or more important, we would be denying the reality of the situation. I

Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC?

On 2/15/16 9:14 PM, Warren Kumari wrote: > Dear OpsAWG: > > This is the second of three messages [0] to determine what the OpsAWG > should do with TACACS+ > > Should the ID, as presented, or as revised by the WG, be published as > one or more RFCs? Yes, for reasons previously stated. Eliot s

Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?

Chairs, On 2/15/16 9:16 PM, Warren Kumari wrote: > This is the third of 3 messages to determine what the OpsAWG should do > with TACACS+. > > If the answer to the previous question is yes, should the RFC > describing the protocol itself (as opposed to any other document that > might describe appro

Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?

On 2/18/16 9:02 PM, Andy Bierman wrote: > > I think in order for WG consensus to determine decisions wrt/ this > document, > it would no longer be a Cisco protocol. Cisco would have to give all > change control > authority to the IETF. Maybe an expert on IETF process (like Scott) > can clarify.

Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?

Hi Andy, On 2/19/16 2:09 AM, Andy Bierman wrote: > > It is not that clear from the discussions where "documenting a > proprietary protocol" ends > and "WG makes whatever changes and additions they want" begins. > It is not clear how much backward compatibility with existing > implementations is ex

Re: [OPSAWG] Call for Agenda Items for Buenos Aires

I very much look forward to Dan's talk. I also have requested a session from the chairs to talk about Manufacturer Usage Descriptions (MUD) a means by which manufacturers can inform the network of recommended policies for their devices. To do all of this we will make use of a bunch of existing wo

Re: [OPSAWG] mud documents

[It looks like we're moving some of this discussion to OPSAWG, so CCing opsawg]. Getting back to some old threads. On 4/8/16 10:05 PM, Michael Richardson wrote: > Eliot and I have been conversing about policies. I proposed that I want a > policy like: > > He asked me three questions: > > 0 what

[OPSAWG] Fwd: New Version Notification for draft-lear-ietf-netmod-mud-02.txt

--- Begin Message --- A new version of I-D, draft-lear-ietf-netmod-mud-02.txt has been successfully submitted by Eliot Lear and posted to the IETF repository. Name: draft-lear-ietf-netmod-mud Revision: 02 Title: Manufacturer Usage Description Specification Do

Re: [OPSAWG] Fwd: New Version Notification for draft-lear-ietf-netmod-mud-02.txt

Hi Uri, On 6/7/16 7:32 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > * We now include a signature mechanism for the MUD files. It > was always the plan to do this. There were two choices: > CMS/PKCS#7 or JWS. Again for tooling's sake, so that people > don't need t

Re: [OPSAWG] Comments on draft-lear-ietf-netmod-mud-02

Hi Cullen, Generic answer to your message: please send text. More specifics below. On 6/7/16 11:57 PM, Cullen Jennings wrote: > I like how this is evolving ... few things > > Few small things > > If you use CMS, I think you need to deal with how the JSON in canonicalized > before being s

Re: [OPSAWG] Comments on draft-lear-ietf-netmod-mud-02

Hi Uri, On 6/10/16 5:48 PM, Blumenthal, Uri - 0553 - MITLL wrote: > Canonicalization is the way to avoid file content being mangled or > represented differently by different (software) entities that try to create > or verify digital signature over it. It doesn't matter if your file is binary >

[OPSAWG] Fwd: New Version Notification for draft-lear-ietf-netmod-mud-03.txt

ke. Eliot --- Begin Message --- A new version of I-D, draft-lear-ietf-netmod-mud-03.txt has been successfully submitted by Eliot Lear and posted to the IETF repository. Name: draft-lear-ietf-netmod-mud Revision: 03 Title: Manufacturer Usage Description Specification Document d

[OPSAWG] Fwd: New Version Notification for draft-lear-ietf-netmod-mud-04.txt

Yes, one more version. This one incorporates a means to communicate the MUD URL via LLDP. Thanks to Dan Romascanu who is now also a co-author. Eliot --- Begin Message --- A new version of I-D, draft-lear-ietf-netmod-mud-04.txt has been successfully submitted by Eliot Lear and posted to the

Re: [OPSAWG] Adoption poll for draft-lear-ietf-netmod-mud-04

Hi Bert, On 8/3/16 12:54 PM, Bert Wijnen (IETF) wrote: > M > > - first I wonder why this document has "netmod" in the draftname". > it is targeted at opsawg, and besides, it not only has a YANG > datamodel, but also talks bout DHCP, x509 and LLDP. > So people should be aware that this i

Re: [OPSAWG] Adoption poll for draft-lear-ietf-netmod-mud-04

Thanks, Warren. Before we do that, I would like to make two proposals, to keep things moving (and I'm not quite sure of order here); First, and hopefully most trivially, I propose just to capture a point or two more from the expired informational document. This would be non-normative text. I th

Re: [OPSAWG] Adoption poll for draft-lear-ietf-netmod-mud-04

On 8/17/16 4:17 PM, Warren Kumari wrote: > > > On Wednesday, August 17, 2016, Eliot Lear <mailto:l...@cisco.com>> wrote: > > Thanks, Warren. Before we do that, I would like to make two > proposals, > to keep things moving (and I'm not quite sure

Re: [OPSAWG] Adoption poll for draft-lear-ietf-netmod-mud-04

Hi Warren, Tianran, and all, On 8/17/16 4:17 PM, Warren Kumari wrote: > > > > Second, and hopefully not that more of a controversy, I would like to > request early IANA assignments to assist with interoperable > development. These would be listed in the IANA considerations section

Re: [OPSAWG] WG consensus call for the IANA early assignment //RE: Adoption poll for draft-lear-ietf-netmod-mud-04

values > > are represented as a JSON object; UTF-8 encoding SHOULD be > > employed. > >o Security considerations: See {{secon}} of this document. > >o Interoperability considerations: n/a > >o Published specification: this document > >o Applic

Re: [OPSAWG] WG consensus call for the IANA early assignment //RE: Adoption poll for draft-lear-ietf-netmod-mud-04

I don’t see why this draft should get a pass. Is there any > documentation detailing criteria for early assignments? > > > > Kent > > > > *From: *Eliot Lear > *Date: *Thursday, August 25, 2016 at 2:36 PM > *To: *Kent Watsen , Zhoutianran > , Warren Kumar

Re: [OPSAWG] WG consensus call for the IANA early assignment //RE: Adoption poll for draft-lear-ietf-netmod-mud-04

eally think the URL is going to change, and there isn't that much there to change, there's not much risk. I don't think it's a big deal to wait on the media type, and I could envision some changes to the model. In fact I have one proposal I'm pondering. Eliot > B

[OPSAWG] MUD: need descriptive text in meta information

Hi everyone, Here come about four issues that we're seeing in some of our testing. I'll separate them so we can handle them in different threads, as some of them are easier than others to deal with. The first are two small issues. Currently there is a container in the model called "support-info

[OPSAWG] MUD: a MUD file generator for your perusal

Hi everyone, I've created a MUD file generator that you can play with. It's at https://www.ofcourseimright.com/mudmaker. Please feel free to kick the wheels. If anyone wants the code, please feel free to ask. It doesn't implement every aspect of MUD just yet but should cover a lot of general c

[OPSAWG] MUD: certain enterprise service functions and descriptions & defaults

Hi everyone again, This one is more interesting. Right now, if you want to allow DNS and NTP and similar services, you have to entirely allow them. You can't specify which servers to allow. But we are this close to being able to do just that. There is a controller class function already availa

[OPSAWG] MUD: certificates and trust

Hi, The current text in the MUD draft around trust of certificates needs cleaning up. What I propose to do is to simply state that MUD controller implementations MUST NOT blindly trust unknown signers, and that they should apply restrictive controls until someone has reviewed the content of the f

Re: [OPSAWG] MUD: certain enterprise service functions and descriptions & defaults

On 9/26/16 3:47 PM, Thorsten Dahm wrote: > Hi Eliot, > > On 21 September 2016 at 07:15, Eliot Lear <mailto:l...@cisco.com>> wrote: > > Right now, if you want to allow DNS and NTP and similar services, you > have to entirely allow them. You can't spec

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-01.txt

fts > directories. > This draft is a work item of the Operations and Management Area Working Group > of the IETF. > > Title : Manufacturer Usage Description Specification > Authors : Eliot Lear > Ralph Droms >

[OPSAWG] A mud example

Hi everyone, In a recent large scale attack against a well known blogger, one of the devices said to be used was a Digital Video Recorder. I don't actually know which model, but there is a known vulnerability in one particular brand[1]. There were essentially two forms of attack against this dev

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-02.txt

> Authors : Eliot Lear > Ralph Droms > Dan Romascanu > Filename: draft-ietf-opsawg-mud-02.txt > Pages : 37 > Date: 2016-11-30 > > Abstract: >This memo sp

[OPSAWG] just a brief MUD update

Hi everyone, Given that we have a bunch of assignments, I've worked with the owner of dhcpcd to get some code checked in. That has happened. There is also a pending pull request now for tcpdump, and a similar pull request will be made for the dhcp option for Wireshark. Now looking for reviews so

[OPSAWG] MUD status (Re: I-D Action: draft-ietf-opsawg-mud-03.txt)

r Usage Description Specification > Authors : Eliot Lear > Ralph Droms > Dan Romascanu > Filename: draft-ietf-opsawg-mud-03.txt > Pages : 39 > Date: 2017-01-05 > > Abstr

[OPSAWG] MUD: open issue: controller v. my-controller

Hi everyone, I am getting ready to rev the draft and a few issues have come up as we get a little more experience. Here's one to chew on. Currently the draft specifies a "controller" class that is a URI. That URI could be a URN that describes standard behavior or it could just be an open class.

Re: [OPSAWG] MUD: open issue: controller v. my-controller

Well, foist on my own petard. We've run into a small issue with the following: On 2/9/17 4:47 PM, Eliot Lear wrote: > My second proposal is not to remove the "controller" component, but to > modify it to be a grouping of some form that consists of a URI, much as > it

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-04.txt

m the on-line Internet-Drafts > directories. > This draft is a work item of the Operations and Management Area Working Group > of the IETF. > > Title : Manufacturer Usage Description Specification > Authors : Eliot Lear >

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-05.txt

m the on-line Internet-Drafts > directories. > This draft is a work item of the Operations and Management Area Working Group > of the IETF. > > Title : Manufacturer Usage Description Specification > Authors : Eliot Lear >

[OPSAWG] new release of mudmaker

Hi everyone, There is a new release of mudmaker available online: https://www.ofcourseimright.com/mudmaker This one provides support for "my-controller". Eliot signature.asc Description: OpenPGP digital signature ___ OPSAWG mailing list OPSAWG@iet

Re: [OPSAWG] IPR poll on draft-ietf-opsawg-mud-05

On 3/15/17 2:24 AM, Tianran Zhou wrote: > Dear WG Members, > > We are currently preparing draft-ietf-opsawg-mud-05 for working group last > call. Here is an IPR poll prior to the wglc. > > Are you aware of any IPR that applies to draft-ietf-opsawg-mud-05.txt? Yes. What I am aware of is disclo

[OPSAWG] Fwd: Re: IPR poll on draft-ietf-opsawg-mud-05

FYI --- Begin Message --- Sorry, I was traveling at the antipodes and I missed this message. I am not aware about any IPR related to the MUD work. Please forward back to WG list, as I do not have the original. Regards, Dan Sent from my iPhone > On 15 Mar 2017, at 14:25, Eliot Lear wr

Re: [OPSAWG] Review and comments: mud-05

Hi Tim, Thanks very much for raising these questions. Although they are not on my slides for tomorrow (already submitted) I propose to address them first in person then if you can make it, or otherwise on list. Regards, Eliot On 3/29/17 5:09 PM, Tim Polk wrote: > After a hallway conversation

Re: [OPSAWG] WG LC for draft-ietf-opsawg-mud-05

Hi Kent, Thanks very much for taking the time to review the draft. Based on your review, unless the WG objects, I'll include some changes as discussed below. On 4/7/17 3:37 AM, Kent Watsen wrote: > > Hi, > > > > First off, I think that this is an interesting and useful idea. > However, I hav

Re: [OPSAWG] WG LC for draft-ietf-opsawg-mud-05

Hi Brian, Apologies for the late response. On 3/31/17 6:40 AM, Brian Weis (bew) wrote: > I support advancing this document, and have the following minor comments. > > (1) Section 1.3. LLDP should be referenced at first use. The wording > at the beginning of Section 11 is nice: "IEEE802.1AB Link L

[OPSAWG] dealing with multiple manufacturer services with a single certificate extension

Hi everyone, Just a quick update on this document. I am preparing for the next version of the draft. There is one major change contemplated that is not yet addressed. I received feedback from the IETF Chicago meeting regarding how best to structure URLs in manufacturer certificates. There are

Re: [OPSAWG] [Anima] dealing with multiple manufacturer services with a single certificate extension

for my position. > >> On Apr 23, 2017, at 5:23 AM, Eliot Lear > <mailto:l...@cisco.com>> wrote: >> >> Hi everyone, >> >> Just a quick update on this document. I am preparing for the next >> version of the draft. There is one major change contemplate

Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-mud-06.txt

-dra...@ietf.org wrote: > A new version of I-D, draft-ietf-opsawg-mud-06.txt > has been successfully submitted by Eliot Lear and posted to the > IETF repository. > > Name: draft-ietf-opsawg-mud > Revision: 06 > Title:Manufacturer Usage Description Spe

Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 ASCII

Isn't this handled by RFC 20? On 5/19/17 7:51 PM, Douglas Gash (dcmgash) wrote: > > On 19/05/2017 18:11, "Alan DeKok" wrote: > >> On May 19, 2017, at 6:38 AM, t.petch wrote: >>> Another fresh topic, so a slight change in the Subject: >>> >>> I think that the use of the term ASCII needs more tho

Re: [OPSAWG] [Anima] dealing with multiple manufacturer services with a single certificate extension

Hi Michael, Below. On 5/23/17 4:23 AM, Michael Richardson wrote: > I've read through the thread. It took more brain-power that I've had > available of recent. > > Let me ask some clarification questions about the original proposal. > > I generally agree with Max that the /.well-known/ part can b

[OPSAWG] FYI on draft-ietf-opsawg-mud

Hi everyone, I wanted to give a brief update on this draft. Right now we've resolved a lot of comments in our previous version. I am awaiting an update on draft-ietf-netmod-acl-model, which is undergoing revisions, as discussed in the last opsawg meeting. Once that has taken place I will rev th

Re: [OPSAWG] binding ACLs to mud devices || [was Re: FYI on draft-ietf-opsawg-mud]

Thanks, Einar. I think this is probably a good change, on the whole. What I like about it is that we can extend later to include things that have nothing to do with access lists, such as QoS. I had initially had QoS as a goal, but it's just a bit too much to bite off this time. Note: there are

[OPSAWG] Fwd: New Version Notification for draft-ietf-opsawg-mud-07.txt

at at the meeting. Eliot --- Begin Message --- A new version of I-D, draft-ietf-opsawg-mud-07.txt has been successfully submitted by Eliot Lear and posted to the IETF repository. Name: draft-ietf-opsawg-mud Revision: 07 Title: Manufacturer Usage Description Specification D

Re: [OPSAWG] DNS Name resolution in https://tools.ietf.org/html/draft-ietf-opsawg-mud-06

Hi! Thanks for your comments. On 7/5/17 8:56 PM, Ranganathan, Mudumbai (Fed) wrote: > Hello, > > I am reading the MUD profile draft > > https://tools.ietf.org/html/draft-ietf-opsawg-mud-06#page-18 > > I have a few questions regarding DNS name resolution: > > Clearly the resolution of the DNS nam

Re: [OPSAWG] DNS Name resolution in https://tools.ietf.org/html/draft-ietf-opsawg-mud-06

Hi again! Trimming: On 7/6/17 2:09 AM, M. Ranganathan wrote: > Thus, for the proposed scheme to work, IF the device does DNS lookup > the ACE must specify DNS names. Or put another way, if the device > directly use addresses, then the mud profile for the device should > also specify addresses

Re: [OPSAWG] MUD draft-ietf-opsawg-mud-07 question on router configuration.

Good afternoon and thanks for your comments. Please now see below. On 7/28/17 4:33 PM, M. Ranganathan wrote: > Hello, > > I am trying to implement the MUD profiles draft on a openwrt based > router using the DHCP based mechanisms that are outlined in the draft. > In my implementation, the "Inter

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-08.txt

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 : Manufacturer Usage Description Specification > Au

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-08.txt

. I think I want to say more than that. What I'm thinking about is as follows: > A number ofmeans may be used to resolve hosts. What is > important is that such resolutions be consistent with ACLs required by > devices to properly operate. > > === > > Appendix B

Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-mud-08

Thanks, Martin, for your timely review.  We'll sort through the issues and come back to the group and to you. Eliot On 8/22/17 3:38 PM, Martin Bjorklund wrote: > Reviewer: Martin Bjorklund > Review result: Ready with Issues > > Hi, > > I am the assigned YANG doctors reviewer for this document.

Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-mud-08

Hi Martin, Thanks for performing the review. Please see responses below.  On 8/22/17 3:38 PM, Martin Bjorklund wrote: > Reviewer: Martin Bjorklund > Review result: Ready with Issues > > Hi, > > I am the assigned YANG doctors reviewer for this document. Here are > my comments: > > > o Section

Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-mud-08, Re: Yangdoctors early review of draft-ietf-opsawg-mud-08

Hi Martin, Trimming: On 8/28/17 10:52 AM, Martin Bjorklund wrote: >> ONLY. > Ok. The text says "a small number ... including ...". I suggest this > is clarified. So clarified. > Ok, but --ietf does not check indentation etc. Ok. >> Yes.  This has been the subject of considerable discussio

Re: [OPSAWG] Secdir early review of draft-ietf-opsawg-mud-08

Hi Adam, Thanks very much for your review.  I'm pleased you like the general approach.  You hit the nail on the head: this is NOT intended to be a panacea, but a means by which the device (and its manufacturer) can enlist the network's protection. Indeed as I mentioned the first time I presented t

Re: [OPSAWG] IoT-DIR early review of draft-ietf-opsawg-mud-08

Hi Henk and thanks very much for your review. Please see below. On 8/29/17 11:40 PM, Henk Birkholz wrote: > > > # IoT-DIR Early Review of I-D.ietf-opsawg-mud-08 > > ## Draft Summary > > This draft defines a canonical way to compose an URI that points to a > specific resource called a MUD file. A

Re: [OPSAWG] Genart early review of draft-ietf-opsawg-mud-08

Hi Ranga, Robert wrote a great review, and I'll respond to him in due course with suggested changes.  I wanted to take just a moment to comment to you on your point: On 8/31/17 12:00 AM, M. Ranganathan wrote: > > > On Wed, Aug 30, 2017 at 1:21 PM, Robert Sparks > wr

Re: [OPSAWG] IoT-DIR early review of draft-ietf-opsawg-mud-08

Hi Henk, On 8/30/17 6:50 PM, Henk Birkholz wrote: > Hello Eliot, > > thank you for your fast feedback! I still have some comments and > questions for another round, though. I hope that is okay - please see > comments in-line. Soon, please. > >> Ok, but a cautionary note: this draft intentionally

Re: [OPSAWG] Genart early review of draft-ietf-opsawg-mud-08

Robert, As I wrote earlier, this was a great review.  Thanks for that.  Please see below. On 8/30/17 7:21 PM, Robert Sparks wrote: > Reviewer: Robert Sparks > Review result: Almost Ready > > This is an exciting concept, and the draft overall is approachable. I > have identified a few areas I thi

Re: [OPSAWG] Genart early review of draft-ietf-opsawg-mud-08

Hi Robert, Thanks now for BOTH of your reviews.  I've a number of proposals below. On 9/7/17 5:51 PM, Robert Sparks wrote: > There is one aspect of caching semantics we should probably capture, > which is that the cache-validity period should exceed the HTTP cache > or expiry period as specified

Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-mud-09.txt

On 9/11/17 9:54 AM, internet-dra...@ietf.org wrote: > A new version of I-D, draft-ietf-opsawg-mud-09.txt > has been successfully submitted by Eliot Lear and posted to the > IETF repository. > > Name: draft-ietf-opsawg-mud > Revision: 09 > Title:

Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-mud-09.txt

Also, www.mudmaker.org now generates to this draft.  The old version can be found at https://www.mudmaker.org/v08. Eliot On 9/11/17 10:02 AM, Eliot Lear wrote: > > Hi everyone, > > This draft takes into account comments received from early reviews.  > The changes includ

[OPSAWG] Fwd: New Version Notification for draft-ietf-opsawg-mud-10.txt

ch is expected.  This is because yanglint does not know what to expect in terms of what features are implemented in the ACL model.  Thus the above statement. Eliot --- Begin Message --- A new version of I-D, draft-ietf-opsawg-mud-10.txt has been successfully submitted by Eliot Lear and posted t

Re: [OPSAWG] Fwd: New Version Notification for draft-ietf-opsawg-mud-10.txt

list-entries/acl:ace/acl:matches/acl:tcp-acl" > > > I am basing this on ietf-access-control-l...@2017-06-16.yang, which I > believe to be the latest draft of the ietf-access-control-list > > Perhaps I am mistaken (in which case please correct me). > > Thanks, >

Re: [OPSAWG] draft-ietf-opsawg-mud-10.txt : Error in sample MUD profile.

Thanks, Ranga.  I confirm this is indeed a bug in the example, and will take your correction.  What happened was that we changed "is-supported" to mandatory based on Joe's suggestion, but I failed to make the change in the tool that generated the example.  I am correcting this in my working copy.

Re: [OPSAWG] Associating a MUD profile with a specific device

Hi Ranga, The way we did the early code on github was just with FreeRadius and leveraging sessions which are indexed precisely by MAC address.  And so the MUD Controller functionality sits next to FreeRadius through callouts.  I don't think we want to get that specific in the draft, and there are

Re: [OPSAWG] Associating a MUD profile with a specific device

below. > > How does this sound? Thanks. > > > > On Tue, Sep 19, 2017 at 5:39 PM, Eliot Lear <mailto:l...@cisco.com>> wrote: > > Hi Ranga, > > The way we did the early code on github was just with FreeRadius > and leveraging sessions which are i

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-11.txt

ing Group > WG of the IETF. > > Title : Manufacturer Usage Description Specification > Authors : Eliot Lear > Ralph Droms > Dan Romascanu > Filename: draft-ietf-opsawg-mud-11.tx

Re: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11

Hi Kent, I'll respond in two messages (I need to get more info in one case). On 9/26/17 2:57 AM, Kent Watsen wrote: > Hi Elliot, > > In my previous review, I had asked about how MUD intersects with my zerotouch > draft, which has the device reaching out to either a well-known > Internet-based

Re: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11

Hi, On 9/26/17 8:54 PM, Kent Watsen wrote: > Hiya again, > >>> In my previous review, I had asked about how MUD intersects with my >>> zerotouch draft, which has the device reaching out to either a well-known >>> Internet-based or deployment-specific HTTPS resource. But the need to >>> reach

Re: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11

Hi Kent, On 9/26/17 10:17 PM, Kent Watsen wrote: > I'm not disputing the value of being able to relay such information (though > it's missing in the brski draft), I'm just thinking that rather than hardcode > something into the base MUD file description, that the same can be done using > the e

Re: [OPSAWG] MUD : Default ACLs for DHCP . Time and DNS.

Hi Ranga, On 10/3/17 6:40 PM, M. Ranganathan wrote: > MUD suggests that devices should always have access to DHCP and DNS. > However, I don't know how to communicate this information to the MUD > controller so that appropriate ACLs can be installed when a device > comes up. A logical place to put

Re: [OPSAWG] Review of draft-ietf-opsawg-mud-11

Hi Joe, Ranga, Kent, and others, Now that last call has closed I have a number of comments to resolve.  I will go through in the next day or so and indicate the resolution to each comment. Regards, Eliot On 10/4/17 5:01 PM, Joe Clarke wrote: > I have re-read the latest MUD draft, and in genera

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-12.txt

t-dra...@ietf.org wrote: > 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 : Manufacturer Usage Description Specificati

Re: [OPSAWG] MUD : Default ACLs for DHCP . Time and DNS.

Hi Ranga, I apologize- I thought I had answered this note.  I'm going to top post because the theme of your note is pretty consistent: it essentially asks, what happens if we want to decompose the MUD controller into two?  I don't see anything particularly wrong with the idea, but that's not where

Re: [OPSAWG] draft-ietf-opsawg-mud-12: MUD Draft : Identifying the Router.

Hi Ranga, On 10/9/17 2:54 PM, M. Ranganathan wrote: > Hello, > > I am implementing MUD using an external controller. i.e. a cloud > resident controller that could potentially control several "home" > routers. I need some way of communicating the address of the LAN > router to the controller but I

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-12.txt

Hi Joe, On 10/9/17 4:29 PM, Joe Clarke wrote: > On 10/7/17 07:58, Eliot Lear wrote: > > This version is intended to address all outstanding issues based on > > last call.  That includes the following: > > > o  Correct examples based on ACL model changes. o  Chan

Re: [OPSAWG] Understanding MUD : Controller and my-controller

Hi Ranga, On 10/12/17 4:16 AM, M. Ranganathan wrote: > Hello, > > I am reading through previous discussion on these topics and am still > not quite "getting it". So I request some explanation from the > authors. My understanding is as follows: > > controllers : this is a place holder for things l

Re: [OPSAWG] MUD: Why reserve names for "well-known" controllers

Hi Ranga, Sorry I've been quiet for a few days.  I'll have more to say later.  Please see below. On 10/19/17 4:28 PM, M. Ranganathan wrote: > > I am not clear in my mind about why this should be the case for NTP server > i.e. why do we reserve a special URN for NTP server? Why is it not just a >

Re: [OPSAWG] MUD : ACE with BOTH controller and src-dnsname

Hi Ranga, On 10/18/17 11:55 PM, M. Ranganathan wrote: > This is a made up example. > > Is the following ACE valid for MUD? > > "matches": { > "ietf-mud:mud-acl": { > "controller": "urn:ietf:params:mud:dns" > }, > "ipv4-acl": {

Re: [OPSAWG] MUD: Why reserve names for "well-known" controllers

On 10/20/17 2:47 AM, M. Ranganathan wrote: > > Scenario: Perhaps the manufacturer would like the IOT devices to use HIS > name server - not necessarily what is returned by dhcp when the IOT device > goes to get it's IP address assigned. That is the device gets a server > address of the desired n

Re: [OPSAWG] AD review of: draft-ietf-opsawg-mud.

[this time to the wg and chairs] Warren, Thanks for your review, and I'm sorry to hear of your illness. On 10/24/17 12:37 AM, Warren Kumari wrote: > First, sorry for the delay in reviewing this -- I'm recovering from > pneumonia and so it took longer than it should have. > > I do have a few co

Re: [OPSAWG] MUD : actions { forwarding : drop } utility.

I want to confirm this with the WG and the chairs.  I'm okay removing this if others are as well.  It's past WGLC and I am about to post -13.  Objections? On 10/24/17 12:02 AM, M. Ranganathan wrote: > Hello, > > I am wondering about the utility of the actions part of the ACE. > > In the latest MUD

Re: [OPSAWG] MUD : actions { forwarding : drop } utility.

On 10/24/17 2:48 PM, Joe Clarke wrote: > On 10/24/17 07:48, Eliot Lear wrote: > > I want to confirm this with the WG and the chairs.  I'm okay > > removing this if others are as well.  It's past WGLC and I am about > > to post -13. Objections? > > This seems

Re: [OPSAWG] MUD : actions { forwarding : drop } utility.

PM, Joe Clarke wrote: > On 10/24/17 09:28, Eliot Lear wrote: > > > > On 10/24/17 2:48 PM, Joe Clarke wrote: > >> On 10/24/17 07:48, Eliot Lear wrote: > >>> I want to confirm this with the WG and the chairs.  I'm okay > >>> removing this if others

Re: [OPSAWG] AD review of: draft-ietf-opsawg-mud.

Wait! I haven't put the doc out yet!! On 10/24/17 4:29 PM, Warren Kumari wrote: > On Tue, Oct 24, 2017 at 7:46 AM, Eliot Lear wrote: >> [this time to the wg and chairs] >> >> Warren, >> >> Thanks for your review, and I'm sorry to hear of your ill

Re: [OPSAWG] MUD : actions { forwarding : drop } utility.

Hi Ranga, Let's step through these. On 10/24/17 5:15 PM, M. Ranganathan wrote: > Hello Eliot, Joe, > > > On Tue, Oct 24, 2017 at 10:15 AM, Eliot Lear <mailto:l...@cisco.com>> wrote: > > Joe, > > In talking with a few more people, I'm coming

Re: [OPSAWG] MUD : actions { forwarding : drop } utility.

Giid evening Juergen, On 10/24/17 5:51 PM, Juergen Schoenwaelder wrote: > > What you describe seem to be different policies. Are you saying that > these different policies are bad or a huge management problem and > hence we hard-code a default policy that is considered "good" in most > situations

Re: [OPSAWG] MUD : actions { forwarding : drop } utility.

On 10/24/17 7:20 PM, M. Ranganathan wrote: > Hi Eliot, > > Your comment brings up something that I believe needs some clarification: > > > > >   > > Better to > have a single class, given its commonality.  There are very few such > common services on a network, but there are presumabl

Re: [OPSAWG] MUD : ietf-acldns YANG model question.

I did add some text into the last draft explictly warning against this sort of construct. Eliot On 10/25/17 4:44 PM, M. Ranganathan wrote: > Hi Juergen, Einar, > > On Wed, Oct 25, 2017 at 10:30 AM, Juergen Schoenwaelder > > wrote: > > RFC 7858 de

Re: [OPSAWG] MUD : ietf-acldns YANG model question.

he same value. On 10/25/17 5:57 PM, Juergen Schoenwaelder wrote: > May I ask what this warning is and where I find it? And yes, I am still > reading and learning so be patient with me. > > /js > > On Wed, Oct 25, 2017 at 05:01:50PM +0200, Eliot Lear wrote: >> I did

Re: [OPSAWG] MUD : ietf-acldns YANG model question.

wanted to test. > > Cheers, > > Einar > >> On 25 Oct 2017, at 18:11, M. Ranganathan > <mailto:mra...@gmail.com>> wrote: >> >> >> >> On Wed, Oct 25, 2017 at 12:45 PM, Eliot Lear > <mailto:l...@cisco.com>> wrote: >>

Re: [OPSAWG] MUD draft 13 nit : Scope of ACL Name

The acl name comes directly from draft-ietf-netmod-acl.  However, if it is not clear, the scope is intended to be solely within a MUD file itself.  I can add words to that effect as part of LC if nobody objects. Eliot On 10/26/17 7:12 PM, M. Ranganathan wrote: > leaf acl-name { >

Re: [OPSAWG] MUD draft 13 nit : Scope of ACL Name

On 10/26/17 7:26 PM, M. Ranganathan wrote: > > I would like to suggest that an ACL name be directly derived from a a MUD URL > instead of scoping it this way (so that it can be specified independently of > the MUD file while achieving the scoping goal you had in mind). > > That would ease the p

Re: [OPSAWG] MUD draft 13: ietf-acldns Another YANG question

On 10/29/17 2:12 PM, M. Ranganathan wrote: > I see that a grouping is used in ietf-acldns i.e. > > >  dns-matches { >     description "Domain names for matching."; > >     leaf src-dnsname { >   type inet:host; >   description "domain name to be matched against"; >     } >     leaf dst-dn

  1   2   3   4   >