From: OPSAWG on behalf of Thomas Fossati
Sent: 17 October 2022 11:10
Hi, all,
I was asked to bring to the list one comment from my shepherd write-up
[1]; specifically, that draft-ietf-opsawg-mud-tls hasn't been reviewed
by the YANG Doctors (yet).
There seems to be an expectation [2] that the
Hi Med,
On 17/10/2022, 12:01, wrote:
> I don’t see why this draft should be an exception.
Thanks for confirming.
> BTW in addition to the yang doctors review, I suggest to also request
> an early secdir review. Thanks.
I agree and suggested the same in the write-up.
cheers, t
--
IMPORTANT
draft-ietf-opsawg-mud-tls YANG Doctor review
Hi, all,
I was asked to bring to the list one comment from my shepherd write-up
[1]; specifically, that draft-ietf-opsawg-mud-tls hasn't been reviewed
by the YANG Doctors (yet).
There seems to be an expectation [2] that the YANG Doctor review is
Hi, all,
I was asked to bring to the list one comment from my shepherd write-up
[1]; specifically, that draft-ietf-opsawg-mud-tls hasn't been reviewed
by the YANG Doctors (yet).
There seems to be an expectation [2] that the YANG Doctor review is
completed before or during WGLC.
I am not sure whe
Yes, but they're not quite ready for release (I know of at least two).
I think they're waiting for this doc to get finished.
On 19.02.18 19:07, Marco Davids (SIDN) wrote:
> Op 19-02-18 om 17:38 schreef Eliot Lear:
>
>>> I know of some
>>> people working to implement this. I don't think they are
Op 19-02-18 om 17:38 schreef Eliot Lear:
I know of some
people working to implement this. I don't think they are all on this
list. Have you run this by them to see if this limits any use cases
out of the box?
I have. I think they're okay with it.
Anyone knows if these implementations-in-t
On 19.02.18 16:30, Joe Clarke wrote:
> Speaking as a contributor...
>
> On 2/19/18 05:03, Eliot Lear wrote:
> > All,
>
> > Mark Nottingham and I had some extensive conversations about how
> > to handle the MUD URL. The issue is was that Mark identified a
> > potential violation of a best practic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Speaking as a contributor...
On 2/19/18 05:03, Eliot Lear wrote:
> All,
>
> Mark Nottingham and I had some extensive conversations about how
> to handle the MUD URL. The issue is was that Mark identified a
> potential violation of a best practice in
All,
Mark Nottingham and I had some extensive conversations about how to
handle the MUD URL. The issue is was that Mark identified a potential
violation of a best practice in the way the URL was structured. The
principles I seek to maintain are these:
* The base MUD URL is formed solely by th
Everyone,
In discussions as part of the GENART review processes, Mark Nottingham
has further clarified his concerns about the use of .well-known. He
would prefer that we abandon its use altogether. He suggests instead
that we use the templating approach for parameters that are coming from
the MU
On 31.01.18 21:35, M. Ranganathan wrote:
> The ACL draft has various operators for ports, including eq, lte, gte
>
> Does a compliant MUD implementation have to support all of these
> operators? If ONLY eq is required to be supported (I hope ) , can this
> be stated in the draft.
All. The MUD f
The ACL draft has various operators for ports, including eq, lte, gte
Does a compliant MUD implementation have to support all of these operators?
If ONLY eq is required to be supported (I hope ) , can this be stated in
the draft.
Given that port ranges can be specified I wonder why the other comp
Hi Ranga,
I understand this to be a tooling issue. Nevertheless, I will revert
the change back to mud-acl as we progress the draft.
Eliot
On 30.01.18 21:53, M. Ranganathan wrote:
> In the acldns yang file I see
> augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches" {
>d
In the acldns yang file I see
augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches" {
description
"adding abstractions to avoid need of IP addresses";
container mud {
This leads to a few annoying naming conflicts when the Yang file is used to
auto-generate
Hi Eliot,
On Mon, Oct 9, 2017 at 9:01 AM, Eliot Lear 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 control several "home" routers. I need
> some way of
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
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 can't figure out where this is specified. I would have expected
I have fixed these warning. Eliot, I am including the updated ACL models. Can you verify?These changes will be uploaded as part of the next update that Sonal is planning to post on Oct. 2.
ietf-access-control-list@2017-09-21.yang
Description: Binary data
ietf-packet-fields@2017-09-21.yang
Descri
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.
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: applicat
Dear draft-ietf-opsawg-mud authors,
A new version of the draft-ietf-netmod-acl-model has been posted, and it
now passes validation. It failed previously with:
/ietf-packet-fie...@2017-09-01.yang:118: warning: The 'must'
expression will fail: the node 'upper-port' from module
'ietf-access-c
On 12 Sep 2017, at 14:48, Thorsten Dahm
mailto:thorstend...@google.com>> wrote:
Hi Einar,
thanks for the reply. Let me clarify my thoughts below. :-)
On 11 September 2017 at 17:03, Einar Nilsen-Nygaard (einarnn)
mailto:eina...@cisco.com>> wrote:
But I do also agree that things like rate limi
While I agree that this is beyond the scope of the initial MUD draft, I’m not
sure I agree that this is beyond the scope of MUD in the longer term.
If a manufacturer can define behavior in this way, why wouldn’t it possibly be
a new policy type that can be an extension/augmentation to the MUD YA
Hi Ranga,
I think this would go beyond the job of MUD and would be at the discretion
of the network administrator to enforce rate limits probably at the same
network devices that are also responsible for implementing the packet
filters and such.
cheers,
Thorsten
On 8 September 2017 at 19:54, M.
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
25 matches
Mail list logo
