On Sat, Jul 20, 2019, 9:24 AM Joe Clarke (jclarke)
wrote:
>
>
> > On Jul 20, 2019, at 06:46, Eliot Lear wrote:
> >
> >
>
> >>
> >> I see you’re using a 32-bit int for the drop-count. Would it not make
> sense to make this a 64-bit counter instead? Yeah, this number should be
> low, but if
On Tue, Jul 9, 2019 at 4:13 PM M. Ranganathan wrote:
> The current draft https://datatracker.ietf.org/doc/draft-ietf-capport-api/
>
Wrong reference, I meant
https://datatracker.ietf.org/doc/draft-richardson-shg-mud-quarantined-access/
(sorry for extra email load).
A
t; >> This is not new, I think that this as been the approach of most
> >> enterprise NEA systems upon encountering "infection". This has, I
> >> assume, involved forced HTTP proxies to inform human. But, if we
> have
> >> APIs, we can inform
Hello Eliot,
On Tue, Jul 2, 2019 at 2:10 AM Eliot Lear wrote:
> Hi Ranga,
>
> Sorry for the pre-mature send.
>
> On 1 Jul 2019, at 20:51, M. Ranganathan wrote:
>
> What is the essential difference between a device declaring itself to be a
> "controller" f
been an internal part of
> the network infrastructure.
>
> Let me call this out plainly: letting the app itself directly call the MUD
> manager requires that the MUD manager itself become exposed to the user
> infrastructure, which is a change.
>
> One possibility to addres
API? Again - many answers
possible. A simple one -- it must present a trusted certificate signed by
a trusted authority (verified using a certificate chain and yes key
exposure is a known risk but isn't that always the case for public key
encryption?). There application itself must be trustworthy but that ca
ot.
>
> My thinking is that we do this work in two stages. First handle the easy
> case, which is the MUD file extension, and then figure out how to do the
> app version of this.
>
Sounds good.
Regards, Ranga
>
> Thoughts?
>
> Eliot
>
>
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
to specific services.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
I thought I'd send this
information to the list just in case.
Thank you for your attention.
Regards,
Ranga
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
comparison
operators ( should exist but that is more a question for the ACL spec.
Thanks,
Ranga
--
M. Ranganathan
“If debugging is the process of removing software bugs, then programming
must be the process of putting them in.” – Edsger Dijkstra
file is used to
auto-generate java code. It would be convenient (although not necessary) if
the container name were changed to mud-acl (the way it used to be).
Sorry for nit-picking.
Regards,
--
M. Ranganathan
“If debugging is the process of removing software bugs, then programming
must be the pro
ike to use the grouping in
another YANG model using a "uses" statement.
Thanks in advance for considering it.
Regards,
Ranga.
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
dnsname to appear in from-device-policy and
to-device-policy.
Is it possible to restrict this such that src-dnsname only appears in
to-device-policy and dst-dnsname only appears in from-device-policy.
If not possible via YANG, can language be added to the spec to indicate
On Thu, Oct 26, 2017 at 2:18 PM, Eliot Lear <l...@cisco.com> wrote:
>
>
> 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 indep
nit (perhaps has already been reported):
Does the description comment on scope belong with the acl-name node?
Thanks
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
han ANDed).
If possible it would be nice to impose a restriction on single abstraction
in a match statement (I see no benefit in allowing more than one element).
However, I do not know if it is possible to enforce such a restriction via
YANG.
Ranga
>
>
>
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
lers AND hostnames in a single ACL entry (for reasons of clarity)
but again I don't know how to state that in YANG.
Thanks,
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
they globally scoped (i.e. there is a global
registry of class name URI to host address list mapping similar to DNS)?
Perhaps some words about scoping can be put into the spec?
Thanks,
Ranga
>
> Eliot
>
>
--
M. Ranganathan
___
OPSAWG mailing list
alize it is quite late in the game to campaign for changes.
Thank you all for reading.
Regards,
Ranga.
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
les
for them
Perhaps it is a bit late to suggest this but may I suggest removing
the idea of default
permit access to DNS and NTP. It would simplify some things.
Thanks,
Regards,
Ranga.
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Hi Eliot,
On Thu, Oct 19, 2017 at 4:44 PM, Eliot Lear <l...@cisco.com> wrote:
> 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
On Wed, Oct 18, 2017 at 5:55 PM, M. Ranganathan <mra...@gmail.com> wrote:
> This is a made up example.
>
> Is the following ACE valid for MUD?
>
> "matches": {
> "ietf-mud:mud-acl": {
>
Hello MUD authors,
DNS and NTP have reserved URI names. However, it appears you need to
specify a full ACL for both of these. In that case, why reserve the name?
Is it just for clarity?
Thanks
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
},
"tcp-acl": {
"ietf-mud:direction-initiated": "from-device"
}
}
This ACL has both a controller AND dns-name ACL.
Presumably the controller would take precedence and the dnsname must be
ignored (?)
Thank you in adva
Hi Eliot,
On Thu, Oct 12, 2017 at 3:51 AM, Eliot Lear <l...@cisco.com> wrote:
> 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 r
e some clarification.
Regards,
Ranga.,
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Hi Eliot,
On Mon, Oct 9, 2017 at 9:01 AM, Eliot Lear <l...@cisco.com> wrote:
> 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 con
e expected a
parameter similar to "urn:ietf:params:mud:router" (i.e. in the same
fashion as DNS, NTP and DHCP are specified) but I could not find it.
I must have missed something. Could the author(s) please help clarifying
this.
Thanks in advance,
Ranga.
is-supported
is True then
a new copy of the file should be retrieved.
Good work on the draft!
Regards,
Ranga. (Affiliation: NIST / Advanced Networking Technologies Division)
On Tue, Oct 3, 2017 at 12:52 PM, Steven Rich <sr...@cisco.com> wrote:
>
> On Oct 3, 2017, at 12:40 ,
ACL for the example correct ?
Thanks,
Ranga.
On Tue, Oct 3, 2017 at 2:31 PM, Eliot Lear <l...@cisco.com> wrote:
> 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 k
to the MUD controller when it gets the OPTIONS 161 from the
device. Would this be the way this is envisioned to work?
Would it be worthwhile documenting this interaction (in followup work).
Thanks.
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
We stop short of that in the document, for fear
> of boiling the ocean, but I would happily do some follow-up work with you
> that would include this, if you're interested. The model *is* structured
> so that you can "use" appropriate elements.
>
> Eliot
>
>
> On 9/
t; welcome ;-)
>
> Eliot
>
> ps: thanks for kinking out the example. Chairs, I'll submit an updated
> draft with the example corrected.
>
> On 9/19/17 10:10 PM, M. Ranganathan wrote:
>
> Hello!
>
> MUD profiles are globally identified by the MUD URL. Devices are
>
on this
(for example a simple YANG model that provides the structure of a JSON
document that can give such a mapping) ?
Thanks for reading.
Ranga.
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Hello,
I believe there is an error in the sample MUD profile that has been
supplied in section 8.
I corrected the error. Attached is what I believe to be correct. Please
verify and let me know if I have made an error.
Thank you,
Ranga
--
M. Ranganathan
mud-sample.json
Description
a means to sign and verify the descriptions.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
>
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Hello!
MUD currently does not enforce restrictions on temporal behavior. For
example, I cannot specify how many times per second a device is allowed to
connect to a remote IP address and port.
Would this be worth considering?
Use case:
DDOS attack mitigation (?)
Ranga
--
M. Ranganathan
>
> On 8/31/17 12:00 AM, M. Ranganathan wrote:
>
>
>
> On Wed, Aug 30, 2017 at 1:21 PM, Robert Sparks <rjspa...@nostrum.com>
> wrote:
>
>>
>>
>> Right now, you leave the DHCP server (when it's used) responsible for
>> clearing state in the MUD
On Wed, Aug 30, 2017 at 6:00 PM, M. Ranganathan <mra...@gmail.com> wrote:
>
>
> On Wed, Aug 30, 2017 at 1:21 PM, Robert Sparks <rjspa...@nostrum.com>
> wrote:
>
>>
>>
>> Right now, you leave the DHCP server (when it's used) responsible for
>> c
__
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
ntent is to overload Options 161 for this purpose.
Is this the intent?
Thank you for your clarifications.
Regards,
Ranga.
--
M. Ranganathan
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
41 matches
Mail list logo
