[OPSAWG] [Errata Verified] RFC9291 (7163)

[RFC Errata System]

The following errata report has been verified for RFC9291,
"A YANG Network Data Model for Layer 2 VPNs". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7163

--
Status: Verified
Type: Editorial

Reported by: Nikolai Malykh 
Date Reported: 2022-10-13
Verified by: RFC Editor  

Section: A.2

Original Text
-
  Figure 25: An Example of VPLS

Corrected Text
--
  Figure 25: An Example of VPWS

Notes
-
Typo

--
RFC9291 (draft-ietf-opsawg-l2nm-19)
--
Title   : A YANG Network Data Model for Layer 2 VPNs
Publication Date: September 2022
Author(s)   : M. Boucadair, Ed., O. Gonzalez de Dios, Ed., S. Barguil, 
L. Munoz
Category: PROPOSED STANDARD
Source  : Operations and Management Area Working Group
Area: Operations and Management
Stream  : IETF

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

Re: [OPSAWG] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[Alan DeKok]

On Oct 13, 2022, at 4:19 PM, Michael Richardson  wrote:
> If I understand you correctly, the DHCPv6 option bytes would just be sliced
> up into 253 byte fragments, and then reassembled into DHCPv6 options.

  Largely, yes.

> The radius part need not respect the DHCPv6 option boundaries, but can fill
> each DHCPv6-Options with as much as the fragment as fits.

  Yes.

  Similar things happen already with EAP packets.  These are ~1K or more.  
RADIUS is just a transport, so "EAP goes in" and "EAP comes out".  The EAP 
contents are unmodified.

> Does Radius over TCP relax any of the 4K issue?

  No.  But it avoids fragmentation of UDP packets.  Which is positive.  And 
RADIUS/UDP needs to die anyways, so 

  Taking a quick look, nothing else in RADIUS mandates support for longer than 
4K packets.  However, I believe that many implementations are happy to accept 
longer packets.

  i.e. it's 2022, I think that software can easily handle 64K buffers for 
network protocols.

  There's also RFC 7499 which supports fragmentation of CoA packets.  Perhaps a 
similar method could be used here, if required?

  Alan DeKok.

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

Re: [OPSAWG] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[Michael Richardson]

Alan DeKok  wrote:
> The only solution which entirely avoids the 253 octet limit is to just
> define a DHCPv6-Options attribute in RADIUS.  It can carry a blob of
> DHCPv6 options, encoded as DHCPv6 options.  This is behavior is
> permitted by https://www.rfc-editor.org/rfc/rfc6158#section-3.2.4:

If I understand you correctly, the DHCPv6 option bytes would just be sliced
up into 253 byte fragments, and then reassembled into DHCPv6 options.
The radius part need not respect the DHCPv6 option boundaries, but can fill
each DHCPv6-Options with as much as the fragment as fits.

> Since the encoding is now DHCPv6 options, all limitations other than
> the 4K RADIUS "maximum packet size" limitation disappear.  And many
> RADIUS implementations support packets larger than 4K, so that limit is
> not concrete either.  The specification defining DHCPv6-Options could
> suggest that implementations SHOULD support 64K RADIUS packets.

Does Radius over TCP relax any of the 4K issue?


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[Alan DeKok]

On Oct 13, 2022, at 10:50 AM, Ben Schwartz  wrote:
> Even if longer SvcParams aren't useful in DNR, creating an encoding that 
> can't carry them introduces a serious compatibility problem for systems that 
> copy between SVCB, DNR, and RADIUS.  What is such a tool supposed to do when 
> a valid SVCB record or DNR option is unrepresentable in RADIUS?  What is a 
> naive operator to do, faced with this error message?

  The traditional RADIUS solution for encoding data which can't fit into an 
attribute is one of (a) truncation, or (b) dropping the attribute entirely.  
The standards are silent on this issue, so the behavior is entirely 
implementation-defined.

  As for this issue, it may be best to avoid it entirely with careful design, 
so that it's not possible for implementations to run into the problem.


  The only solution which entirely avoids the 253 octet limit is to just define 
a DHCPv6-Options attribute in RADIUS.  It can carry a blob of DHCPv6 options, 
encoded as DHCPv6 options.  This is behavior is permitted by 
https://www.rfc-editor.org/rfc/rfc6158#section-3.2.4:

 Another exception to the recommendation against complex types is for
 types that can be treated as opaque data by the RADIUS server.

  So just define a DHCPv6-Options attribute from the 245.X space.  Allow it to 
contain any DHCPv6 option.  Suggest that the switch / RADIUS client send the 
options in a DHCPv6 packet.  And then it can carry the options needed here.

  Since the encoding is now DHCPv6 options, all limitations other than the 4K 
RADIUS "maximum packet size" limitation disappear.  And many RADIUS 
implementations support packets larger than 4K, so that limit is not concrete 
either.  The specification defining DHCPv6-Options could suggest that 
implementations SHOULD support 64K RADIUS packets.

  Alan DeKok.

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

Re: [OPSAWG] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[Erik Kline]

On Thu, Oct 13, 2022 at 7:51 AM Ben Schwartz  wrote:

> I don't think we need to determine whether ECH is relevant for the DNR use
> case.  Indeed, ECH as presently specified will generally fit inside the
> 250-octet limit.  My point is that we are setting ourselves up for a very
> painful compatibility challenge if longer SvcParams come into use in the
> future.  I can certainly imagine longer parameters (e.g. signed objects
> with certificate chains) that might be useful in DNR.
>
> Even if longer SvcParams aren't useful in DNR, creating an encoding that
> can't carry them introduces a serious compatibility problem for systems
> that copy between SVCB, DNR, and RADIUS.  What is such a tool supposed to
> do when a valid SVCB record or DNR option is unrepresentable in RADIUS?
> What is a naive operator to do, faced with this error message?
>
> I understand that we can't eliminate this problem, due to the 4K limit,
> but I think it's worth avoiding it as much as we can, even if it costs us a
> page or two of standards text.
>

+1

--Ben
>
> On Thu, Oct 13, 2022 at 9:03 AM Joe Abley  wrote:
>
>> Hi Mohamed,
>>
>> I may well have missed some nuance in the discussion that came before,
>> but I found this comment interesting:
>>
>> On Oct 13, 2022, at 03:41, mohamed.boucad...@orange.com wrote:
>>
>> This specification targets typical broadband services in which the use of
>> ECH is not relevant. It does not make sense for ISPs to be hosting multiple
>> domains on the same IP address as the encrypted DNS resolver.
>>
>>
>> Can you say why?
>>
>> If an operator has invested in infrasructure designed to be able to
>> handle TLS and HTTP at high volumes with high availability, does it not
>> seem possible that they would seek to reuse that general TLS/HTTP
>> infrastructure for multiple purposes? If ECH is relevant in other services
>> carried over HTTPS, why is it definitively not relevant for this one?
>>
>>
>> Joe
>> --
>> Add mailing list
>> a...@ietf.org
>> https://www.ietf.org/mailman/listinfo/add
>>
> ___
> 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] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[Ben Schwartz]

I don't think we need to determine whether ECH is relevant for the DNR use
case.  Indeed, ECH as presently specified will generally fit inside the
250-octet limit.  My point is that we are setting ourselves up for a very
painful compatibility challenge if longer SvcParams come into use in the
future.  I can certainly imagine longer parameters (e.g. signed objects
with certificate chains) that might be useful in DNR.

Even if longer SvcParams aren't useful in DNR, creating an encoding that
can't carry them introduces a serious compatibility problem for systems
that copy between SVCB, DNR, and RADIUS.  What is such a tool supposed to
do when a valid SVCB record or DNR option is unrepresentable in RADIUS?
What is a naive operator to do, faced with this error message?

I understand that we can't eliminate this problem, due to the 4K limit, but
I think it's worth avoiding it as much as we can, even if it costs us a
page or two of standards text.

--Ben

On Thu, Oct 13, 2022 at 9:03 AM Joe Abley  wrote:

> Hi Mohamed,
>
> I may well have missed some nuance in the discussion that came before, but
> I found this comment interesting:
>
> On Oct 13, 2022, at 03:41, mohamed.boucad...@orange.com wrote:
>
> This specification targets typical broadband services in which the use of
> ECH is not relevant. It does not make sense for ISPs to be hosting multiple
> domains on the same IP address as the encrypted DNS resolver.
>
>
> Can you say why?
>
> If an operator has invested in infrasructure designed to be able to handle
> TLS and HTTP at high volumes with high availability, does it not seem
> possible that they would seek to reuse that general TLS/HTTP infrastructure
> for multiple purposes? If ECH is relevant in other services carried over
> HTTPS, why is it definitively not relevant for this one?
>
>
> Joe
> --
> Add mailing list
> a...@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] [Editorial Errata Reported] RFC9291 (7163)

[RFC Errata System]

The following errata report has been submitted for RFC9291,
"A YANG Network Data Model for Layer 2 VPNs".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7163

--
Type: Editorial
Reported by: Nikolai Malykh 

Section: A.2

Original Text
-
  Figure 25: An Example of VPLS

Corrected Text
--
  Figure 25: An Example of VPWS

Notes
-
Typo

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC9291 (draft-ietf-opsawg-l2nm-19)
--
Title   : A YANG Network Data Model for Layer 2 VPNs
Publication Date: September 2022
Author(s)   : M. Boucadair, Ed., O. Gonzalez de Dios, Ed., S. Barguil, 
L. Munoz
Category: PROPOSED STANDARD
Source  : Operations and Management Area Working Group
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

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

Re: [OPSAWG] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[Joe Abley]

Hi Mohamed,

I may well have missed some nuance in the discussion that came before, but I 
found this comment interesting:

On Oct 13, 2022, at 03:41, mohamed.boucad...@orange.com wrote:

> This specification targets typical broadband services in which the use of ECH 
> is not relevant. It does not make sense for ISPs to be hosting multiple 
> domains on the same IP address as the encrypted DNS resolver.

Can you say why?

If an operator has invested in infrasructure designed to be able to handle TLS 
and HTTP at high volumes with high availability, does it not seem possible that 
they would seek to reuse that general TLS/HTTP infrastructure for multiple 
purposes? If ECH is relevant in other services carried over HTTPS, why is it 
definitively not relevant for this one?


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

Re: [OPSAWG] [Editorial Errata Reported] RFC9291 (7162)

[Joe Clarke (jclarke)]

Agreed.  Rob?

Joe

From: OPSAWG  on behalf of 
mohamed.boucad...@orange.com 
Date: Thursday, October 13, 2022 at 7:29 AM
To: RFC Errata System , nmal...@ieee.org 

Cc: luis-angel.mu...@vodafone.com , 
opsawg@ietf.org 
Subject: Re: [OPSAWG] [Editorial Errata Reported] RFC9291 (7162)
Hi Nikolai, all,

Thank you for reporting this.

This editorial erratum should be accepted. Thanks.

Cheers,
Med

> -Message d'origine-
> De : RFC Errata System 
> Envoyé : jeudi 13 octobre 2022 13:23
> À : rfc-edi...@rfc-editor.org
> Cc : nmal...@ieee.org; BOUCADAIR Mohamed INNOV/NET
> ;
> oscar.gonzalezded...@telefonica.com;
> samier.barguilgiraldo@telefonica.com; luis-
> angel.mu...@vodafone.com; opsawg@ietf.org
> Objet : [Editorial Errata Reported] RFC9291 (7162)
>
> The following errata report has been submitted for RFC9291, "A
> YANG Network Data Model for Layer 2 VPNs".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7162
>
> --
> Type: Editorial
> Reported by: Nikolai Malykh 
>
> Section: 9
>
> Original Text
> -
>'ethernet-segments' and 'vpn-services':  An attacker who is
> able to
>   access network nodes can undertake various attacks, such as
>   deleting a running L2VPN service, interrupting all the
> traffic of
>   a client.  In addition, an attacker may modify the
> attributes of a
>   running service (e.g., QoS, bandwidth) or an ES, leading to
>   malfunctioning of the service and therefore to SLA
> violations.  In
>   addition, an attacker could attempt to create an L2VPN
> service,
>   add a new network access, or intercept/redirect the traffic
> to a
>   non-authorized node.  In addition to using NACM to prevent
>   authorized access, such activity can be detected by
> adequately
>   monitoring and tracking network configuration changes.
>
>
> Corrected Text
> --
>'ethernet-segments' and 'vpn-services':  An attacker who is
> able to
>   access network nodes can undertake various attacks, such as
>   deleting a running L2VPN service, interrupting all the
> traffic of
>   a client.  In addition, an attacker may modify the
> attributes of a
>   running service (e.g., QoS, bandwidth) or an ES, leading to
>   malfunctioning of the service and therefore to SLA
> violations.  In
>   addition, an attacker could attempt to create an L2VPN
> service,
>   add a new network access, or intercept/redirect the traffic
> to a
>   non-authorized node.  In addition to using NACM to prevent
>   unauthorized access, such activity can be detected by
> adequately
>   monitoring and tracking network configuration changes.
>
>
> Notes
> -
> Typo in last sentence, should be "unauthorized".
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary,
> please use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party can log
> in to change the status and edit the report, if necessary.
>
> --
> RFC9291 (draft-ietf-opsawg-l2nm-19)
> --
> Title   : A YANG Network Data Model for Layer 2 VPNs
> Publication Date: September 2022
> Author(s)   : M. Boucadair, Ed., O. Gonzalez de Dios, Ed.,
> S. Barguil, L. Munoz
> Category: PROPOSED STANDARD
> Source  : Operations and Management Area Working Group
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG

_

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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[Joe Clarke (jclarke)]

For an operator standpoint, it seems this point may not be clear enough in the 
draft and at the very least would likely benefit from some text to call out the 
limitation.

Joe

From: mohamed.boucad...@orange.com 
Date: Thursday, October 13, 2022 at 3:41 AM
To: Ben Schwartz , Alan DeKok 

Cc: Joe Clarke (jclarke) , opsawg@ietf.org 
, rad...@ietf.org , a...@ietf.org 

Subject: RE: [Add] [OPSAWG]  WG LC: RADIUS Extensions for Encrypted DNS
Hi Ben, all,

This specification targets typical broadband services in which the use of ECH 
is not relevant. It does not make sense for ISPs to be hosting multiple domains 
on the same IP address as the encrypted DNS resolver.

Cheers,
Med

De : Add  De la part de Ben Schwartz
Envoyé : mercredi 12 octobre 2022 19:54
À : Alan DeKok 
Cc : Joe Clarke (jclarke) ; opsawg@ietf.org; 
rad...@ietf.org; a...@ietf.org
Objet : Re: [Add] [OPSAWG]  WG LC: RADIUS Extensions for Encrypted DNS

A practical limit of around 4000 octets for SvcParams seems likely to be fine.  
A hard limit of 250 octets has a real chance of becoming a practical problem.  
I would encourage you to reconsider the format.

As a concrete example, SvcParams are used to deliver public keys for ECH.  
Currently, only elliptic-curve keys are used, but if a future iteration relied 
on RSA public keys, they would not fit within this limit.

On Wed, Oct 12, 2022 at 1:41 PM Alan DeKok 
mailto:al...@deployingradius.com>> wrote:
On Oct 12, 2022, at 1:32 PM, Ben Schwartz 
mailto:40google@dmarc.ietf.org>> wrote:
>
> The Encrypted-DNS-SvcParams TLV seems to be limited to 253 octets.  This is a 
> problem, since it is meant to hold a SvcParams object that is allowed to be 
> much larger (up to ~65000 octets in principle).

  The length is less than 253 octets, as it is encapsulated inside of another 
attribute "wrapper".  So the practical limit is probably 250 or less.

  RADIUS provides for encoding more than 253 octets in an attribute.  See 
https://www.rfc-editor.org/rfc/rfc8044#section-3.16

  However, this capability exists only for "top level" attributes, and cannot 
be used here.

  Further, RADIUS packets are generally limited to 4K octets total.  So even if 
the limits on this attribute are removed, then there's still a practical limit 
of around 4000 octets.

  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] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[mohamed.boucadair]

Re-,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Alan DeKok 
> Envoyé : jeudi 13 octobre 2022 13:40
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Ben Schwartz ; Joe Clarke (jclarke)
> ; opsawg@ietf.org; rad...@ietf.org;
> a...@ietf.org
> Objet : Re: [Add] [OPSAWG]  WG LC: RADIUS Extensions for
> Encrypted DNS
> 
> On Oct 13, 2022, at 4:11 AM, mohamed.boucad...@orange.com wrote:
> >
> > Hi Alan, all,
> >
> > FYI, we do already have the following in the draft to pass
> RADIUS attributes in DHCPv6:
> >
> >   In deployments where the NAS behaves as a DHCPv6 relay agent,
> the
> >   procedure discussed in Section 3 of [RFC7037] can be followed.
> To
> >   that aim, Section 6.3 updates the "RADIUS Attributes Permitted
> in
> >   DHCPv6 RADIUS Option" registry ([DHCP-RADIUS]).
> 
>   I was thinking of the other way around: allowing DHCPv6 options
> inside of a RADIUS attribute.

[Med] Yes, I got that. But I wanted to highlight that, as we are already 
allowing to encapsulate radius attributes in dhcp, if we encapsulate dhcp in 
radius, then for the case in 7037, we will end up with 
dhcp_option(radius(dhcp_option)) encapsulation. 

> 
> > For the typical target deployment in the draft, I don' think we
> have a valid case for long data. That's said, we may include a
> provision to allow for multiple TLVs; each carrying self-contained
> key=value data.
> 
>   If that's the target deployment, then that works.  I'd suggest
> updating the draft to explicitly mention this limitation, and
> describe why it's acceptable.

[Med] Yes, that's exactly what I have in mind. 

> 
>   I'd also suggest changing the RADIUS attribute space from 241.X
> to 245.X.  See https://www.rfc-editor.org/rfc/rfc8044#section-3.16

[Med] Agree. Will fix that. Thanks. 

> 
>   With 241.X, the maximum amount of data which can be carried is
> 252 octets.  This space has to encapsulate all child attributes,
> including headers and contents.  Which means that each individual
> child attribute can carry much less than 253 octets.
> 
>   With 245.X, the maximum amount of data which can be carried is
> limited only by the RADIUS packet length.  Each child attribute
> can then carry a full 253 octets of data.  And there are no limits
> on the number of child attributes which ca be carried.
> 
>   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] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[Alan DeKok]

On Oct 13, 2022, at 4:11 AM, mohamed.boucad...@orange.com wrote:
> 
> Hi Alan, all,
> 
> FYI, we do already have the following in the draft to pass RADIUS attributes 
> in DHCPv6: 
> 
>   In deployments where the NAS behaves as a DHCPv6 relay agent, the
>   procedure discussed in Section 3 of [RFC7037] can be followed.  To
>   that aim, Section 6.3 updates the "RADIUS Attributes Permitted in
>   DHCPv6 RADIUS Option" registry ([DHCP-RADIUS]).

  I was thinking of the other way around: allowing DHCPv6 options inside of a 
RADIUS attribute.

> For the typical target deployment in the draft, I don' think we have a valid 
> case for long data. That's said, we may include a provision to allow for 
> multiple TLVs; each carrying self-contained key=value data. 

  If that's the target deployment, then that works.  I'd suggest updating the 
draft to explicitly mention this limitation, and describe why it's acceptable.

  I'd also suggest changing the RADIUS attribute space from 241.X to 245.X.  
See https://www.rfc-editor.org/rfc/rfc8044#section-3.16

  With 241.X, the maximum amount of data which can be carried is 252 octets.  
This space has to encapsulate all child attributes, including headers and 
contents.  Which means that each individual child attribute can carry much less 
than 253 octets.

  With 245.X, the maximum amount of data which can be carried is limited only 
by the RADIUS packet length.  Each child attribute can then carry a full 253 
octets of data.  And there are no limits on the number of child attributes 
which ca be carried.

  Alan DeKok.

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

Re: [OPSAWG] [Editorial Errata Reported] RFC9291 (7162)

[mohamed.boucadair]

Hi Nikolai, all, 

Thank you for reporting this. 

This editorial erratum should be accepted. Thanks.

Cheers,
Med

> -Message d'origine-
> De : RFC Errata System 
> Envoyé : jeudi 13 octobre 2022 13:23
> À : rfc-edi...@rfc-editor.org
> Cc : nmal...@ieee.org; BOUCADAIR Mohamed INNOV/NET
> ;
> oscar.gonzalezded...@telefonica.com;
> samier.barguilgiraldo@telefonica.com; luis-
> angel.mu...@vodafone.com; opsawg@ietf.org
> Objet : [Editorial Errata Reported] RFC9291 (7162)
> 
> The following errata report has been submitted for RFC9291, "A
> YANG Network Data Model for Layer 2 VPNs".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7162
> 
> --
> Type: Editorial
> Reported by: Nikolai Malykh 
> 
> Section: 9
> 
> Original Text
> -
>'ethernet-segments' and 'vpn-services':  An attacker who is
> able to
>   access network nodes can undertake various attacks, such as
>   deleting a running L2VPN service, interrupting all the
> traffic of
>   a client.  In addition, an attacker may modify the
> attributes of a
>   running service (e.g., QoS, bandwidth) or an ES, leading to
>   malfunctioning of the service and therefore to SLA
> violations.  In
>   addition, an attacker could attempt to create an L2VPN
> service,
>   add a new network access, or intercept/redirect the traffic
> to a
>   non-authorized node.  In addition to using NACM to prevent
>   authorized access, such activity can be detected by
> adequately
>   monitoring and tracking network configuration changes.
> 
> 
> Corrected Text
> --
>'ethernet-segments' and 'vpn-services':  An attacker who is
> able to
>   access network nodes can undertake various attacks, such as
>   deleting a running L2VPN service, interrupting all the
> traffic of
>   a client.  In addition, an attacker may modify the
> attributes of a
>   running service (e.g., QoS, bandwidth) or an ES, leading to
>   malfunctioning of the service and therefore to SLA
> violations.  In
>   addition, an attacker could attempt to create an L2VPN
> service,
>   add a new network access, or intercept/redirect the traffic
> to a
>   non-authorized node.  In addition to using NACM to prevent
>   unauthorized access, such activity can be detected by
> adequately
>   monitoring and tracking network configuration changes.
> 
> 
> Notes
> -
> Typo in last sentence, should be "unauthorized".
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary,
> please use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party can log
> in to change the status and edit the report, if necessary.
> 
> --
> RFC9291 (draft-ietf-opsawg-l2nm-19)
> --
> Title   : A YANG Network Data Model for Layer 2 VPNs
> Publication Date: September 2022
> Author(s)   : M. Boucadair, Ed., O. Gonzalez de Dios, Ed.,
> S. Barguil, L. Munoz
> Category: PROPOSED STANDARD
> Source  : Operations and Management Area Working Group
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG

_

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]  WG Last Call for draft-ietf-opsawg-mud-tls-07

[tom petch]

From: tirumal reddy 
Sent: 13 October 2022 07:57

Thanks Tom for the review. Yes, we will fix the references identified by Tom.


-09 looks better.

I still see a mix of TLS-1.2 and TLS-1-2; I am not sure if there is a rationale 
for that.  I prefer the former but that mix of characters may confuse others.

I see a number of editorial issues - I do not know if you want to look at those 
now or leave them to Last Call.

One slightly technical one is that it is very rare to start a YANG prefix with 
ietf as the IANA webpages show - filename, MUST, prefix SHOULD NOT IMHO.  Thus 
acl has a prefix of acl so I would see the augment as acl-tls and not 
ietf-acl-tls; but mud is ietf-mud (unfortunately:-( so the augment is perhaps  
better as ietf-mud-tls.  

Tom Petch

Cheers,
-Tiru

On Wed, 12 Oct 2022 at 18:37, Henk Birkholz 
mailto:henk.birkh...@sit.fraunhofer.de>> wrote:
Hi Tom,

would it be possible for you to augment your first comment with change
proposals, if possible?

@authors: it seems to me that the references issues Tom now provided in
specific detail could be resolved in this thread in a timely manner. Is
that correct?

Viele Grüße,

Henk

On 12.10.22 13:39, tom petch wrote:
> From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
> behalf of Henk Birkholz 
> mailto:henk.birkh...@sit.fraunhofer.de>>
> Sent: 06 October 2022 13:26
>
> 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!
>
> 
> My main comment on this remains the mix of two different YANG modules with 
> different life cycles; I expect that l will comment again on the Last Call 
> list to give this issue more exposure.
>
> Of lesser import, I cannot make sense of the references.
> I see [RFC5246] which normally means that a reference has been created.  Not 
> here, so there would seem to have been some chicanery involved, that this I-D 
> has not been produced by the usual IETF tools.
>
> I also see RFC5869, RFC6346, RFC8447 which seem absent from the I-D 
> References.
>
> dtls13 is now an RFC.
>
> What is the difference between
> draft-ietf-tls-dtls13:
> and
>  "RFC : Datagram Transport Layer Security 1.3";
>   ?
> How do I find
>  "RFC : Common YANG Data Types for Cryptography";
>   or
> "RFC : Common YANG Data Types for Hash algorithms"; ?
>
> Does tls-1-2 mean the same as tls-1.2?  And is this the same as that which 
> the Netconf WG refers to as tls12?
>
> Tom Petch
>
>
> 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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] [Editorial Errata Reported] RFC9291 (7162)

[RFC Errata System]

The following errata report has been submitted for RFC9291,
"A YANG Network Data Model for Layer 2 VPNs".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7162

--
Type: Editorial
Reported by: Nikolai Malykh 

Section: 9

Original Text
-
   'ethernet-segments' and 'vpn-services':  An attacker who is able to
  access network nodes can undertake various attacks, such as
  deleting a running L2VPN service, interrupting all the traffic of
  a client.  In addition, an attacker may modify the attributes of a
  running service (e.g., QoS, bandwidth) or an ES, leading to
  malfunctioning of the service and therefore to SLA violations.  In
  addition, an attacker could attempt to create an L2VPN service,
  add a new network access, or intercept/redirect the traffic to a
  non-authorized node.  In addition to using NACM to prevent
  authorized access, such activity can be detected by adequately
  monitoring and tracking network configuration changes.


Corrected Text
--
   'ethernet-segments' and 'vpn-services':  An attacker who is able to
  access network nodes can undertake various attacks, such as
  deleting a running L2VPN service, interrupting all the traffic of
  a client.  In addition, an attacker may modify the attributes of a
  running service (e.g., QoS, bandwidth) or an ES, leading to
  malfunctioning of the service and therefore to SLA violations.  In
  addition, an attacker could attempt to create an L2VPN service,
  add a new network access, or intercept/redirect the traffic to a
  non-authorized node.  In addition to using NACM to prevent
  unauthorized access, such activity can be detected by adequately
  monitoring and tracking network configuration changes.


Notes
-
Typo in last sentence, should be "unauthorized".

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC9291 (draft-ietf-opsawg-l2nm-19)
--
Title   : A YANG Network Data Model for Layer 2 VPNs
Publication Date: September 2022
Author(s)   : M. Boucadair, Ed., O. Gonzalez de Dios, Ed., S. Barguil, 
L. Munoz
Category: PROPOSED STANDARD
Source  : Operations and Management Area Working Group
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

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

[OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-13.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   : A YANG Model for Network and VPN Service Performance 
Monitoring
Authors : Bo Wu
  Qin Wu
  Mohamed Boucadair
  Oscar Gonzalez de Dios
  Bin Wen
  Filename: draft-ietf-opsawg-yang-vpn-service-pm-13.txt
  Pages   : 43
  Date: 2022-10-13

Abstract:
   The data model for network topologies defined in RFC 8345 introduces
   vertical layering relationships between networks that can be
   augmented to cover network and service topologies.  This document
   defines a YANG module for performance monitoring (PM) of both
   underlay networks and overlay VPN services that can be used to
   monitor and manage network performance on the topology of both
   layers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-yang-vpn-service-pm-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-13


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]  WG Last Call for draft-ietf-opsawg-mud-tls-07

[tom petch]

From: Henk Birkholz 
Sent: 12 October 2022 14:07
To: tom petch; opsawg; draft-ietf-opsawg-mud-...@ietf.org; Thomas Fossati
Subject: Re: [OPSAWG]  WG Last Call for draft-ietf-opsawg-mud-tls-07

Hi Tom,

would it be possible for you to augment your first comment with change
proposals, if possible?


Henk

Apologies (as ever) for being so late to the party.

I believe that the life cycle of an IANA-maintained module is different to that 
of any other and so having both in one I-D creates future problems for the IETF 
so I believe that s.5.3 along with supporting boiler plate, references, IANA 
Considerations, Security Considerations and a brief Introduction should be in a 
separate I-D.

I have made this comment against a number of I-D but my suggestions have not 
gained consensus.  I am usually somewhat late in making them and am looking to 
make such a comment prior to WG adoption of an I-D but have not yet managed 
that.  My experience suggests that this I-D will go forward much as-is, with 
editorial corrections such as to the references, in which case I will post 
something like the above to Last Call not in the expectation that it will gain 
consensus there for this I-D but rather that the next time an author proposes 
this approach, they may consider the path they are taking and choose another 
one.

I would not take this issue to an appeal in case the Document Shepherd is 
wondering what to put in section 3.

Tom Petch.

@authors: it seems to me that the references issues Tom now provided in
specific detail could be resolved in this thread in a timely manner. Is
that correct?

Viele Grüße,

Henk

On 12.10.22 13:39, tom petch wrote:
> From: OPSAWG  on behalf of Henk Birkholz 
> 
> Sent: 06 October 2022 13:26
>
> 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!
>
> 
> My main comment on this remains the mix of two different YANG modules with 
> different life cycles; I expect that l will comment again on the Last Call 
> list to give this issue more exposure.
>
> Of lesser import, I cannot make sense of the references.
> I see [RFC5246] which normally means that a reference has been created.  Not 
> here, so there would seem to have been some chicanery involved, that this I-D 
> has not been produced by the usual IETF tools.
>
> I also see RFC5869, RFC6346, RFC8447 which seem absent from the I-D 
> References.
>
> dtls13 is now an RFC.
>
> What is the difference between
> draft-ietf-tls-dtls13:
> and
>  "RFC : Datagram Transport Layer Security 1.3";
>   ?
> How do I find
>  "RFC : Common YANG Data Types for Cryptography";
>   or
> "RFC : Common YANG Data Types for Hash algorithms"; ?
>
> Does tls-1-2 mean the same as tls-1.2?  And is this the same as that which 
> the Netconf WG refers to as tls12?
>
> Tom Petch
>
>
> 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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[mohamed.boucadair]

Hi Alan, all,

FYI, we do already have the following in the draft to pass RADIUS attributes in 
DHCPv6: 

   In deployments where the NAS behaves as a DHCPv6 relay agent, the
   procedure discussed in Section 3 of [RFC7037] can be followed.  To
   that aim, Section 6.3 updates the "RADIUS Attributes Permitted in
   DHCPv6 RADIUS Option" registry ([DHCP-RADIUS]).

For the typical target deployment in the draft, I don' think we have a valid 
case for long data. That's said, we may include a provision to allow for 
multiple TLVs; each carrying self-contained key=value data. 

Cheers,
Med

> -Message d'origine-
> De : Add  De la part de Alan DeKok
> Envoyé : mercredi 12 octobre 2022 20:11
> À : Ben Schwartz 
> Cc : Joe Clarke (jclarke) ; opsawg@ietf.org;
> rad...@ietf.org; a...@ietf.org
> Objet : Re: [Add] [OPSAWG]  WG LC: RADIUS Extensions for
> Encrypted DNS
> 
> On Oct 12, 2022, at 1:53 PM, Ben Schwartz 
> wrote:
> >
> > A practical limit of around 4000 octets for SvcParams seems
> likely to be fine.  A hard limit of 250 octets has a real chance
> of becoming a practical problem.  I would encourage you to
> reconsider the format.
> 
>   There are a number of limitations which all have to be addressed
> in order for any solution to work.  :(
> 
>   This specification requires "grouped" data, which generally
> means TLVs in RADIUS.  However, it also requires "long" data,
> which is forbidden to be used in TLVs by https://www.rfc-
> editor.org/rfc/rfc8044#section-3.16
> 
>   As the author of RFC 8044, I can say that there are good reasons
> for that prohibition.  I can also say that there are good reasons
> why the prohibited functionality is needed by this standard.
> 
>   I'm not sure there are any perfect solutions.  There's only
> varying amounts of holding your nose, and going with something
> which is the lesser of two evils.
> 
>   Off of the top of my head, one approach is to simply give up on
> transporting the DHCPv6 data as RADIUS attributes, and instead
> just define a DHCPv6-Options attribute in RADIUS, which carries
> raw DHCPv6 options.  This attribute could carry ~4K of data, and
> be in a format which complies with RFC 8044.
> 
>   That would solve the problem not only for this use-case, but for
> any future one, too.  Just define the DHCPv6 option, and then say
> "carry it in RADIUS attribute DHCPv6-Options"
> 
>   That makes it difficult for administrators to configure, as the
> RADIUS configuration now has to carry "raw" DHCPv6 data.  But...
> it's RADIUS.  That's the least of its ugliness.
> 
> 
>   There's already something similar in DHCPv4:
> https://datatracker.ietf.org/doc/html/rfc4014  i.e. DHCPv4 carries
> RADIUS attributes.  So there's reasonable precedent.
> 
>   Alan DeKok.
> 
> --
> Add mailing list
> a...@ietf.org
> https://www.ietf.org/mailman/listinfo/add

_

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

[OPSAWG] I-D Action: draft-ietf-opsawg-mud-tls-09.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   : Manufacturer Usage Description (MUD) (D)TLS Profiles 
for IoT Devices
Authors : Tirumaleswar Reddy
  Dan Wing
  Blake Anderson
  Filename: draft-ietf-opsawg-mud-tls-09.txt
  Pages   : 36
  Date: 2022-10-13

Abstract:
   This memo extends the Manufacturer Usage Description (MUD)
   specification to incorporate (D)TLS profile parameters.  This allows
   a network security service to identify unexpected (D)TLS usage, which
   can indicate the presence of unauthorized software or malware on an
   endpoint.


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

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-tls-09

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


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] [Add]  WG LC: RADIUS Extensions for Encrypted DNS

[mohamed.boucadair]

Hi Ben, all,

This specification targets typical broadband services in which the use of ECH 
is not relevant. It does not make sense for ISPs to be hosting multiple domains 
on the same IP address as the encrypted DNS resolver.

Cheers,
Med

De : Add  De la part de Ben Schwartz
Envoyé : mercredi 12 octobre 2022 19:54
À : Alan DeKok 
Cc : Joe Clarke (jclarke) ; opsawg@ietf.org; 
rad...@ietf.org; a...@ietf.org
Objet : Re: [Add] [OPSAWG]  WG LC: RADIUS Extensions for Encrypted DNS

A practical limit of around 4000 octets for SvcParams seems likely to be fine.  
A hard limit of 250 octets has a real chance of becoming a practical problem.  
I would encourage you to reconsider the format.

As a concrete example, SvcParams are used to deliver public keys for ECH.  
Currently, only elliptic-curve keys are used, but if a future iteration relied 
on RSA public keys, they would not fit within this limit.

On Wed, Oct 12, 2022 at 1:41 PM Alan DeKok 
mailto:al...@deployingradius.com>> wrote:
On Oct 12, 2022, at 1:32 PM, Ben Schwartz 
mailto:40google@dmarc.ietf.org>> wrote:
>
> The Encrypted-DNS-SvcParams TLV seems to be limited to 253 octets.  This is a 
> problem, since it is meant to hold a SvcParams object that is allowed to be 
> much larger (up to ~65000 octets in principle).

  The length is less than 253 octets, as it is encapsulated inside of another 
attribute "wrapper".  So the practical limit is probably 250 or less.

  RADIUS provides for encoding more than 253 octets in an attribute.  See 
https://www.rfc-editor.org/rfc/rfc8044#section-3.16

  However, this capability exists only for "top level" attributes, and cannot 
be used here.

  Further, RADIUS packets are generally limited to 4K octets total.  So even if 
the limits on this attribute are removed, then there's still a practical limit 
of around 4000 octets.

  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]  WG Last Call for draft-ietf-opsawg-mud-tls-07

[tirumal reddy]

Thanks Tom for the review. Yes, we will fix the references identified by
Tom.

Cheers,
-Tiru

On Wed, 12 Oct 2022 at 18:37, Henk Birkholz 
wrote:

> Hi Tom,
>
> would it be possible for you to augment your first comment with change
> proposals, if possible?
>
> @authors: it seems to me that the references issues Tom now provided in
> specific detail could be resolved in this thread in a timely manner. Is
> that correct?
>
> Viele Grüße,
>
> Henk
>
> On 12.10.22 13:39, tom petch wrote:
> > From: OPSAWG  on behalf of Henk Birkholz <
> henk.birkh...@sit.fraunhofer.de>
> > Sent: 06 October 2022 13:26
> >
> > 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!
> >
> > 
> > My main comment on this remains the mix of two different YANG modules
> with different life cycles; I expect that l will comment again on the Last
> Call list to give this issue more exposure.
> >
> > Of lesser import, I cannot make sense of the references.
> > I see [RFC5246] which normally means that a reference has been created.
> Not here, so there would seem to have been some chicanery involved, that
> this I-D has not been produced by the usual IETF tools.
> >
> > I also see RFC5869, RFC6346, RFC8447 which seem absent from the I-D
> References.
> >
> > dtls13 is now an RFC.
> >
> > What is the difference between
> > draft-ietf-tls-dtls13:
> > and
> >  "RFC : Datagram Transport Layer Security 1.3";
> >   ?
> > How do I find
> >  "RFC : Common YANG Data Types for Cryptography";
> >   or
> > "RFC : Common YANG Data Types for Hash algorithms"; ?
> >
> > Does tls-1-2 mean the same as tls-1.2?  And is this the same as that
> which the Netconf WG refers to as tls12?
> >
> > Tom Petch
> >
> >
> > 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
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] IPR POLL: draft-ietf-opsawg-add-encrypted-dns

[tirumal reddy]

No, I'm not aware of any IPR that applies to this draft.

Cheers,
-Tiru

On Wed, 12 Oct 2022 at 22:16, Joe Clarke (jclarke) 
wrote:

> Authors and contributors, please respond on-list as to whether or not you
> are aware of any IPR that pertains to this work.
>
>
>
> Please state either:
>
>
>
> "No, I'm not aware of any IPR that applies to this draft"
>
> or
>
> "Yes, I'm aware of IPR that applies to this draft"
>
>
>
> If you are aware of IPR, indicate whether or not this has been disclosed
> per IETF IPR rules (see RFCs 3669, 5378, and 8179).
>
>
>
> Joe
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] IPR POLL: draft-ietf-opsawg-add-encrypted-dns

[mohamed.boucadair]

Hi Joe, all,

No, I'm not aware of any IPR that applies to this draft.

Cheers,
Med

De : Joe Clarke (jclarke) 
Envoyé : mercredi 12 octobre 2022 18:46
À : opsawg@ietf.org
Cc : draft-ietf-opsawg-add-encrypted-...@ietf.org
Objet : IPR POLL: draft-ietf-opsawg-add-encrypted-dns

Authors and contributors, please respond on-list as to whether or not you are 
aware of any IPR that pertains to this work.

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If you are aware of IPR, indicate whether or not this has been disclosed per 
IETF IPR rules (see RFCs 3669, 5378, and 8179).

Joe


_

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