[OPSAWG] I-D Action: draft-ietf-opsawg-mud-iot-dns-considerations-05.txt

[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   : Operational Considerations for use of DNS in IoT 
devices
Authors : Michael Richardson
  Wei Pan
  Filename: draft-ietf-opsawg-mud-iot-dns-considerations-05.txt
  Pages   : 15
  Date: 2022-10-06

Abstract:
   This document details concerns about how Internet of Things devices
   use IP addresses and DNS names.  The issue becomes acute as network
   operators begin deploying RFC8520 Manufacturer Usage Description
   (MUD) definitions to control device access.

   This document makes recommendations on when and how to use DNS names
   in MUD files.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerations-05.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-iot-dns-considerations-05


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [IANA #1240167] IANA question regarding draft-ietf-opsawg-ipfix-srv6-srh-01

[Benoit Claise]

Hi Amanda, IPFIX IE doctors,

See inline.

On 9/30/2022 4:58 AM, Amanda Baber via RT wrote:

Hi Benoit, all,


Dear IPFIX doctors, (IANA),

We would like to get your feedback regarding the IANA section in
draft-ietf-opsawg-ipfix-srv6-srh-01.
Especially, the two following information elements:
srhFlagsIPv6:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-
srh-01#section-5.1
srhSegmentEndpointBehavior:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-
srh-01#section-5.11

We can keep separate registries in sync (although we don't currently have 
automation to ensure this), but is the intention for the IPFIX IPv6 SRH Flags 
and IPFIX SRV6 Endpoint Behavior registries to be contained within each IPFIX 
IE registration's Description field?

In 2020, with IE Doctor approval, all IPFIX IE Description field tables that constituted 
sub-registries were replaced with links to separate sub-registries located outside of the 
IPFIX Information Elements registry. You can see the list of sub-registries under the 
heading "Registries included below":

https://www.iana.org/assignments/ipfix
  

I went to the IANA table in Philly and we discussed those. Hence I
copied IANA here.
In the currentdraft-ietf-opsawg-ipfix-srv6-srh-01


version, we created two IPFIX subregistries, which mimic existing
Segment Routing registries.
The main reason is that we are in favor of having a self contained
IPFIX
IANA registry, which we can download as a cron job in the collector.
We
discussed such a project with Michelle Cotton in the past (I know that
Michelle moved on).

I'm afraid we don't have any of Michelle's notes on this topic. What will you 
need IANA to do? We may need to put you in touch with IANA's technical 
director. In the future, the registries will be moved from an XML-based to a 
database-based registry system.
Regarding the argument of "having a self having a self contained IPFIX 
IANA registry, which we can download as a cron job in the collector", 
what we need is the ability to retrieve either the entire registry in 
one go, or have pointers to other (registries) the IPFIX collector has 
to take into account ... in an automatic manner
The former, with subregistries duplication (and synchronization) might 
be beyond repair at this point in time (at least, I don't have the 
courage to engage), on top of pushing much administration to IANA for 
the synchronization/maintenance


Looking closer at the IFPIX registry, let me provide a logic that might 
work, without too much changes IMO.


Let's say I take care of a IPFIX collector, which I need to update on 
regular basis, there are different cases:

1. A new IPFIX IE is added in the registry
    Ex: Let's say I specify in IANA the IPFIX IE 492 = "my-new-field"
    I download the entire registry as a cronjob, install it in my 
collector, and I can now understand all flow records that contain the 
new IPFIX IE 492

2. A new value is added for one of the IPFIX sub-registries
    Ex: Let's say I add value 25 = "my-new-classification-engine-id" at 
https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids

    What is the logic?
    I download the entire registry as a cronjob, parse the file, when I 
arrive at IPFIX field 101 (classificationEngineId) => I do a lookup on 
*[https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids] 
in the Description field* , read the new value 25, install it in my 
collector, and I can now understand all flow records that contain a 
classificationEngineId value 25.

3. A new value is added for in the external (non-IPFIX) registry
    Ex: a new port is added to 
https://www.iana.org/assignments/service-names-port-numbers].
    The following IPFIX IEs refer to this registry: 
sourceTransportPort, destinationTransportPort, udpSourcePort, 
udpDestinationPort, udpDestinationPort, etc.

    What is the logic?
    I download the entire registry as a cronjob, parse the file, when I 
arrive at any of those IPFIX IEs => I do a lookup**on 
https://www.iana.org/assignments/service-names-port-numbers*in the 
Addition Information field*, read the new port value, install it in my 
collector, and I can now understand all flow records that contain the 
new port value


At least the logic could work (even if looking up two fields is not 
ideal from a logic point of view)

I checked all http links in the IPFIX registry and found 3 "exceptions"
- [http://standards.ieee.org/regauth/ethertype/eth.txt], will not work, 
but we might consider this one as an exception.
- portRangeStart and portRangeEnd point to 
https://www.iana.org/assignments/service-names-port-numbers. Not to sure 
how to treat this one in an automatic way
- [https://www.iana.org/assignments/ianaiftype-mib] should be treated 
differently, but that's fine.


One conclusion is that there are different treatments whether the links 
are in the 

[OPSAWG] I-D Action: draft-ietf-opsawg-add-encrypted-dns-03.txt

[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   : RADIUS Extensions for Encrypted DNS
Authors : Mohamed Boucadair
  Tirumaleswar Reddy
  Filename: draft-ietf-opsawg-add-encrypted-dns-03.txt
  Pages   : 19
  Date: 2022-10-06

Abstract:
   This document specifies new Remote Authentication Dial-In User
   Service (RADIUS) attributes that carry an authentication domain name,
   a list of IP addresses, and a set of service parameters of encrypted
   DNS resolvers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-encrypted-dns/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-add-encrypted-dns-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-add-encrypted-dns-03


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-add-encrypted-dns-02.txt

[Alan DeKok]

On Oct 6, 2022, at 9:32 AM,  
 wrote:
> I added an appendix for this as you can see at: 
> https://tinyurl.com/opsawg-add-latest. 

  I missed that, sorry.

> Do we need to sway more?

  No, I think this looks good.

  Alan DeKok.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-add-encrypted-dns-02.txt

[mohamed.boucadair]

Hi Alan, 

I added an appendix for this as you can see at: 
https://tinyurl.com/opsawg-add-latest. 

Do we need to sway more?

Thanks.

Cheers,
Med

> -Message d'origine-
> De : Alan DeKok 
> Envoyé : jeudi 6 octobre 2022 14:52
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : opsawg@ietf.org
> Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-add-encrypted-
> dns-02.txt
> 
> On Oct 5, 2022, at 10:21 AM, mohamed.boucad...@orange.com wrote:
> >
> > Re-,
> >
> > This version fixes the type for the ADN TLV.
> 
>   I would suggest also adding text on how to map RADIUS attributes
> to DHCPv6 options.  Right now it's just 
> 
>   Any implementors have to read multiple documents, and then "read
> between the lines" to see what's implied.  This is hard.
> 
>   Alan DeKok.


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-add-encrypted-dns-02.txt

[Alan DeKok]

On Oct 5, 2022, at 10:21 AM, mohamed.boucad...@orange.com wrote:
> 
> Re-,
> 
> This version fixes the type for the ADN TLV. 

  I would suggest also adding text on how to map RADIUS attributes to DHCPv6 
options.  Right now it's just 

  Any implementors have to read multiple documents, and then "read between the 
lines" to see what's implied.  This is hard.

  Alan DeKok.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-sbom-access-05

[Henk Birkholz]

Dear authors and contributors,

thank you for your hard work. As it seems that all existing issues have 
been resolve, we'll move the I-D to write-up in the datatracker.


The resulting I-D can be found here:


https://www.ietf.org/archive/id/draft-ietf-opsawg-sbom-access-11.html



Also, a big thanks to Qin for stepping up as shepherd!


For the OPSAWG co-chairs,

Henk

On 04.05.22 18:22, Henk Birkholz wrote:

Dear OPSAWG members,

as a reminder, today ends the WGLC for draft-ietf-opsawg-sbom-access-05.

This is your last chance to add your comments to the list or an 
assessment of whether or not the draft is ready to proceed to publication.



For the OPSAWG co-chairs,

Henk


On 01.05.22 19:27, Henk Birkholz wrote:

Dear OPSAWG members,

as a reminder, the WGLC for draft-ietf-opsawg-sbom-access-05 ends in 
*three days* at the end of May 4th.


If you'd like to add your comments to the list or an assessment of 
whether or not the draft is ready to proceed to publication, please 
keep the deadline in mind.



For the OPAWG co-chairs,

Henk

On 15.04.22 02:30, Henk Birkholz wrote:

Dear OPSAWG members,

please be aware that I introduced an inconsistency in the recent WGLC 
announcement.


It is actually a period of *three weeks* to get your feedback in. I 
extended the time frame from two weeks due to the Eastern holidays 
occurring all over the EU.


As a result, the deadline to send your comments to the list and your 
assessment of whether or not it is ready to proceed to publication 
effectively is *May 4th* and it is not terminating on April 27th 
already.


There so no harm though in providing feedback before April 27th! :-) 
So don't stop doing that!


Thanks Tom for pointing that out.

Viele Grüße & a enjoy a inspiring Easter time,

Henk

On 12.04.22 13:15, Henk Birkholz wrote:

Dear OPSAWG members,

this email starts a three week period for a Working Group Last Call of

 > https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/05/

ending on Wednesday, April 27th.

The authors believe the Internet-Draft is ready for a WGLC. The 
draft has been discussed at meetings, as well as on the list, and 
review feedback has been incorporated in -05.


Please send your comments to the list and your assessment of whether 
or not it is ready to proceed to publication before April 27th.



For the OPSAWG co-chairs,

Henk

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-tls-07

[Henk Birkholz]

Dear authors and contributors,

thank you for your hard work. As it seems that all existing issues have 
been resolve, we'll move the I-D to write-up in the datatracker.


Also, thanks Thomas Fossati for stepping up as shepherd!


For the OPSAWG co-chairs,

Henk

On 29.09.22 10:27, Henk Birkholz wrote:

Dear OPSAWG members,

this email concludes the first WGLC call for
https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html.

A few comments where raised. Authors/editors, please go ahead and 
address these as discussed on the list.



For the OPSAWG co-chairs,

Henk

On 14.09.22 16:07, Henk Birkholz wrote:

Dear OPSAWG members,

this email starts a two week period for a Working Group Last Call of


https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-07.html


ending on Thursday, September 28th.

The authors believe the Internet-Draft is ready for a WGLC and the 
chairs agree. The draft has been discussed visibly at IETF 114 and 
review feedback has been incorporated in -07.


Please send your comments to the list and your assessment of whether 
or not it is ready to proceed to publication before September 28th.



For the OPSAWG co-chairs,

Henk


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Eliot Lear]

This draft corrects several editorial matters, and adds a small amount 
of text to security considerations.


On 06.10.22 13:35, internet-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   : Discovering and Retrieving Software Transparency and 
Vulnerability Information
 Authors : Eliot Lear
   Scott Rose
   Filename: draft-ietf-opsawg-sbom-access-11.txt
   Pages   : 21
   Date: 2022-10-06

Abstract:
To improve cybersecurity posture, automation is necessary to locate
what software is running on a device, whether that software has known
vulnerabilities, and what, if any recommendations suppliers may have.
This memo specifies a model to provide access to this information.
It may optionally be discovered through manufacturer usage
descriptions.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sbom-access-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-sbom-access-11


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg



OpenPGP_signature
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] I-D Action: draft-ietf-opsawg-sbom-access-11.txt

[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   : Discovering and Retrieving Software Transparency and 
Vulnerability Information
Authors : Eliot Lear
  Scott Rose
  Filename: draft-ietf-opsawg-sbom-access-11.txt
  Pages   : 21
  Date: 2022-10-06

Abstract:
   To improve cybersecurity posture, automation is necessary to locate
   what software is running on a device, whether that software has known
   vulnerabilities, and what, if any recommendations suppliers may have.
   This memo specifies a model to provide access to this information.
   It may optionally be discovered through manufacturer usage
   descriptions.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-sbom-access/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-sbom-access-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-sbom-access-11


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07

[Kenneth Vaughn]

Joe, et al.

I am working in a draft that includes the text suggested by Tom (e..g, "This 
module makes reference to"). I have also ensured that the list of references is 
accurate and properly classified between normative and informative.  While 
doing this, I noticed that RFC 6353 seems to treat two RFCs differently, 
despite the text referring to them in a similar fashion. Specifically, the MIB 
contains the following text, which is repeated in the updated MIB:

> A hostname is always in US-ASCII (as per RFC 1123); internationalized 
> hostnames are encoded as A-labels as specified in  
> RFC 5890. 

Neither of these RFCs are referenced in any other way in RFC 6353, but RFC 1123 
is listed as a normative reference while RFC 5890 as an informative reference. 
It seems to me that the two documents should be referenced in the same fashion, 
but I am not sure which type is most correct. A basic reading of the text 
implies that this is just an informative fact; but I believe the intent is that 
the "is always" and "are" expressions are intended to be "MUST be" expressions 
- and parallel the prior paragraphs that describe IPv4 and IPv6 addresses. So I 
see the following options; I know what ISO would like, but I am interested in 
hearing which option is the best to conform with IETF rules...
1) leave as is (i.e., no change to MIB module, keep RFC 1123 as normative and 
EFC 5890 as informative)
2) no change to MIB module, make both RFC 1123 and RFC 5890 normative
3) no change to MIB module, make both RFC 1123 and RFC 5890 informative
4) Replace the "is always" and "are" in the text above with "MUST be" and make 
both RFC 1123 and RFC 5890 normative

Thanks for your advice

Regards,
Ken Vaughn

Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
+1-571-331-5670 cell
kvau...@trevilon.com
www.trevilon.com

> On Oct 5, 2022, at 4:53 AM, tom petch  wrote:
> 
> From: OPSAWG  on behalf of Joe Clarke (jclarke) 
> 
> Sent: 04 October 2022 17:45
> 
> Thanks, Ken.  I saw your updates, and I agree with you on 5246.
> 
> But now that I am done with my shepherd write-up, I notice that there are a 
> slew of references in the MIB that are not reflected in the document 
> references (e.g., 1123, 5890, etc.).  Given that the full MIB is included in 
> this new document, you should include the same references in the Norm/Inform.
> 
> 
> This has been a problem with YANG for years and the accepted solution is to 
> include a section 4.1 'This module makes references to [RFC1123], [RFC5890] 
> etc '
> 
> Consistency with YANG would be good:-)
> 
> Tom Petch
> 
> Joe
> 
> From: Kenneth Vaughn 
> Date: Tuesday, October 4, 2022 at 10:37
> To: Joe Clarke (jclarke) 
> Cc: opsawg@ietf.org 
> Subject: Re: SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07
> I've updated the document; the only items that remain in the id-nits check 
> (https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-09.txt=True)
>  are:
> 
> 
>  == Unused Reference: 'STD58' is defined on line 1472, but no explicit
> 
> reference was found in the text
> 
> STD 58 is referenced in the MIB but I am guessing that the checking tool does 
> not check that content? (I don't think I am supposed to use the formal 
> cross-referencing in the MIB section)
> 
> 
> 
>  -- Obsolete informational reference (is this intentional?): RFC 5246
> 
> (Obsoleted by RFC 8446)
> This reference is intentional as we are identifying the initial entries for 
> the SNMP-TLSTM HashAlgorithm Registry, which needs to point to the older RFC.
> 
> Regards,
> Ken Vaughn
> 
> Trevilon LLC
> 6606 FM 1488 RD #148-503
> Magnolia, TX 77354
> +1-571-331-5670 cell
> kvau...@trevilon.com
> www.trevilon.com
> 
> 
> On Oct 3, 2022, at 12:20 PM, Joe Clarke (jclarke) 
> mailto:jcla...@cisco.com>> wrote:
> 
> I’m working through the shepherd write-up now.  As part of that, I am 
> reviewing the IDNITS checks, and there are a number of warnings.
> 
> See 
> https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-08.txt.
>   Please work through and address these.  Thanks.
> 
> Joe
> 
> From: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
> Date: Tuesday, September 27, 2022 at 13:00
> To: Kenneth Vaughn mailto:kvau...@trevilon.com>>
> Cc: opsawg@ietf.org 
> mailto:opsawg@ietf.org>>
> Subject: Re: SHEPHERD REVIEW: draft-ietf-opsawg-tlstm-update-07
> Thanks for refreshing my memory.  The clutter argument is sound.  I do wish 
> we would have gotten a SEC DIR review, but it will certainly get some eyes 
> from the IESG.
> 
> I’ll mention this point in the shepherd write-up, and we’ll leave things the 
> way they are text-wise for now.
> 
> Joe
> 
> From: Kenneth Vaughn mailto:kvau...@trevilon.com>>
> Date: Tuesday, September 27, 2022 at 12:51
> To: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
> Cc: