[OPSAWG] John Scudder's Discuss on draft-ietf-opsawg-mud-acceptable-urls-11: (with DISCUSS)

[John Scudder via Datatracker]

John Scudder has entered the following ballot position for
draft-ietf-opsawg-mud-acceptable-urls-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-acceptable-urls/



--
DISCUSS:
--

Despite having reviewed a number of the recent MUD specs, I'm not sufficiently
expert in the subject area to be confident all my concerns below are right, so
naturally I'm open to correction. That being said, I do have several concerns
about the document that I'd like to resolve (either with changes to the
document, or a clue bat) before it moves forward. Thanks in advance.

### Section 5.1 -- AND or OR? It matters!

   Subsequent MUD files are considered valid if:

   *  they have the same initial Base-URI as the MUD-URL, but may have a
  different final part

   *  they are signed by an equivalent End Entity (same trusted CA and
  same Subject Name) as the "root" MUD file.

It’s not explicit if the requirement is that either condition is fulfilled, or
both. I assume the requirement is both, but please make this explicit. I think
it would scan better if you got rid of the bullets and just made this a regular
sentence, although I guess you’d have to get rid of the “but” clause in the
first bullet (which would be an improvement in my book). But do it however you
wish, as long as it’s unambiguous. An "and" between the bullets is the minimum
fix (assuming I'm right of course).

### Section 5.1 -- what to do with those darn suspicions

MUD
   managers SHOULD keep track of the list of MUD-URLs that they have
   successfully retrieved, and if a device ever suggests a URL that was
   previously used, then the MUD manager should suspect that is a
   rollback attack.

What, specifically, is the MUD manager supposed to do if it has this suspicion?
I’m somehow picturing the manager giving the client a very stern look 類 but
otherwise doing nothing, because the developer who implemented it wasn’t given
any guidance by the specification.

### Section 5.1 -- any URL that was previously used is suspicious O RLY?

Further to the previous, as written it sounds to me as though this could
describe a perfectly innocent situation. As in,

- Device A of type N with firmware version 1 is powered up and suggests URL foo
- MUD manager retrieves foo and adds it to its “successfully retrieved” list
- Now device A is upgraded to firmware version 2 and suggests URL bar
- MUD manager retrieves bar and adds it to its “successfully retrieved” list
- Now a new device B of type N with firmware version 1 is powered up and
suggests URL foo - MUD manager consults its list, finds foo was previously
retrieved, and becomes suspicious, gives B the stink-eye

Perhaps you mean “previously used *by that device*” in which case you should
say so (although I still hope you’ll clarify what the manager is supposed to do
with its suspicion). Or, perhaps you mean something else entirely, in which
case let’s discuss. (Even if it's "by that device" aren't there benign cases,
such as a factory reset?)

This requirement also appears to fly in the face of Section 6, see below.

### Section 5.3.2 -- new requirement? OR restatement?

   Note, however, that a 301 Redirect that changed the hostname SHOULD
   NOT be accepted by MUD controllers.

Is this a restatement of a preexisting requirement (in which case a reference
is called for) or a new requirement (in which case it seems lacking in detail)?

### Section 6 -- file update mechanisms WUT?

   The MUD file update mechanisms described in Section 3 requires that
   the MUD controller poll for updates.

I don’t see any such requirement enumerated in Section 3. In fact, Section 3
has no requirements whatsoever, it reads like a litany of complaints about what
a bad idea MUD file in-place updating is, as a way of motivating why the
methods of Sections 4 + 5 should be used instead.

Possibly this is just a combination of my lack of knowledge of the MUD document
set, combined with less-than-precise wording of the quoted text. Would it be
correct to re-word something like,

NEW:
   If MUD files are updated in place, as discussed in Section 3, the updates
   will not be detected unless the MUD controller polls to discover them.

I.e., write the sentence in terms of natural consequences, without using the
r-word ("requires") and without implying that Section 3 describes a mechanism.

### Section 6 -- in-place 

[OPSAWG] Paul Wouters' Abstain on draft-ietf-opsawg-mud-acceptable-urls-11: (with COMMENT)

[Paul Wouters via Datatracker]

Paul Wouters has entered the following ballot position for
draft-ietf-opsawg-mud-acceptable-urls-11: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-acceptable-urls/



--
COMMENT:
--

I agree with many things from the SecDir review from Christian Huitema:

https://datatracker.ietf.org/doc/review-ietf-opsawg-mud-acceptable-urls-11-secdir-telechat-huitema-2024-04-02/

I think the concept of small vs big changes is problematic.

There is also the issue of any lower version being seen as a roll back attack.
If successfull, it would prevent an administrator to downgrade the MUD file
after finding that it is preventing proper functioning.


A device has a firmware version and a MUD file that belongs to that version.
It seems this draft says that the MUD file can be upgraded to firmware versions
it was not intended for. It seems the simple fix is to not do that.

Updating a MUD file to plug a security hole seems the wrong mechanism. Instead
of updating the MUD file, the firmware should be updated (and that firmware
should come with a new MUD file covering that firmware version)

So I am confused about the mechanim of the firmware handing a URL to the
MUD manager, who then picks up the MUD file from the manufacturor. In a way,
one could see this as a firmware that has a bit of external firmware hosted
elsewhere. And these two can get out of sync. To me that just seems like
broken firmware and building a protocol mechanism to resolve this seems
the wrong way to fix this.

Similarly, changing a MUD file location seems to be something that should
be addressed in a firmware update - including updating the location of
future firmware updates.

I don't see a way for this document to resolve my issues, so instead of
balloting DISCUSS, I am ABSTAINing.



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

Re: [OPSAWG] Roman Danyliw's No Objection on draft-ietf-opsawg-mud-acceptable-urls-11: (with COMMENT)

[Michael Richardson]

Roman Danyliw via Datatracker  wrote:
> ** Section 3.1 While there is an argument that old firmware was
> insecure and should be replaced, it is often the case that the upgrade
> process involves downtime, or can introduce risks due to needed
> evaluations not having been completed yet.  As an example: moving
> vehicles (cars, airplanes, etc.) should not perform upgrades while in
> motion!  It is probably undesirable to perform any upgrade to an
> airplane outside the service facility.  A vehicle owner may desire only
> to perform software upgrades when they are at their residence.  Should
> there be a problem, they could make alternate arrangements for
> transportation.  This contrasts with an alternative situation where the
> vehicle is parked at, for instance, a remote cabin, and where an
> upgrade failure could cause a much greater inconvenience.

>The situation for upgrades of medical devices has even more
> considerations involving regulatory compliance.

> I’m having trouble understanding the examples provide and the
> associated analysis. Editorial recommendation: cut all the text after
> the first sentence.  Otherwise:

If you find it enough to claim that upgrades introduce risks, I don't mind
cutting there.

> -- What does vehicles, aircraft and medical devices have to do with
> MUD? Is there existing and planned penetration of MUD in those markets?

There isn't a penetration of MUD in any market yet.

Aircraft have hundreds of non-critical systems (seat-back movie players for 
instance).

MUD could have prevented the 2015 Jeep attack:
https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/
(The LTE provider(s) would have had to run MUD, and that's really not
crazy.  Someone writing the MUD file would have included incoming telnet in
the acceptlist)

> -- Per “While there is an argument that old firmware was insecure and
> should be replaced, it is often the case that the upgrade process
> involves downtime, or can introduce risks due to needed evaluations not
> having been completed yet. As an example, moving vehicles ...”

> Where does the suggestion that moving cyber-physical systems should
> upgrade their firmware in use come from?

>From many people who think that you have to always run the latest software,
NOW, or else.   I wrote the above a few years ago thinking nobody would be
stupid enough to upgrade while away, but Tesla did exactly that.

> -- What is the basis for the claim that the regulatory compliance of
> medical devices is more considerations than say of aircraft?

Different regulatory agency, different rules, different processes.

Many small aircraft use iPads for navigation/maps for instance.
They aren't critical systems, they aren't really regulated.

> ** Reference

>[falsemalware] "False malware alerts cost organizations $1.27M
> annually, report says", 18 January 2020,
>  malware-alerts-cost-organizations-1-27m-annually-report- says/ and
> http://go.cyphort.com/Ponemon-Report-Page.html>.

> Pick a single URL.

okay.  Looks like second URL has died already.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[





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

[OPSAWG] IETF 119 Minutes Posted

[Joe Clarke (jclarke)]

Hello, WG.  The initial minutes from our 119 meeting are now posted:

https://datatracker.ietf.org/doc/minutes-119-opsawg-202403180530/

Thank you to Rob, Adrian, and Jean for your contributions to the proceedings!  
Let us know if there are large errors or omissions.

Henk and I are working through the AIs.  We’re closing on consensus on the 
IPFIX drafts to get them to the IESG, and we will be calling for adoption on 
the OAM terminology work soon based on the in-meeting poll.

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

Re: [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00

[xiao.min2]

Got it. Thank you Thomas!
If some text can be added to clarify this usage of 
ingressInterface/egressInterface and 
ingressPhysicalInterface/egressPhysicalInterface, that would help the 
implementer.

Cheers,
Xiao Min

Original


From: thomas.g...@swisscom.com 
To: 肖敏10093570;
Cc: draft-gfz-opsawg-ipfix-alt-m...@ietf.org 
;opsawg@ietf.org 
;i...@ietf.org ;
Date: 2024年04月03日 11:41
Subject: Re: [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00


Dear Xiao,

 
Correct. Obviously this will be exported per flow and the interface entities 
have to be key fields as the flow entities as well.

 
Best wishes
Thomas
 On 3 Apr 2024, at 04:54, xiao.m...@zte.com.cn wrote:
 
 



Be aware: This is an external email.

 

Correcting the email address i...@ietf.org.
 
Hi Thomas,
 
If I understand you correctly, you mean the IE exporter can use 
ingressInterface/egressInterface to indicate LAG port and 
ingressPhysicalInterface/egressPhysicalInterface to indicate LAG member port, 
so the receiver can deduce the implicit meanings of them if they have different 
values, is that right?

 

Cheers,
Xiao Min
 







From: thomas.g...@swisscom.com 
To: 肖敏10093570;draft-gfz-opsawg-ipfix-alt-m...@ietf.org 
;
Cc: opsawg@ietf.org ;'i...@ietf.org <'i...@ietf.org>;
Date: 2024年04月02日 19:32
Subject: RE: [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00



Dear Xiao,
 
I agree that the description and the additional information does not provide 
information to distinguish between
 
ingressInterface, egressInterface
 
and
 
ingressPhysicalInterface, egressPhysicalInterface
 
However from an implementation perspective I have observed that in all cases 
ingressInterface and egressInterface refer to logical and 
ingressPhysicalInterface and egressPhysicalInterface to physical interfaces.
 
Where ingressInterfaceType and egressInterfaceType, which references to 
https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib, is describing 
what type of interface it is.
 
I would expect in a LAG configuration that the lag interface is 
ingressInterface resp. egressInterface and the member interfaces are 
ingressPhysicalInterface resp. egressPhysicalInterface.
 
I hope that helps.
 
Best wishes
Thomas
 


From: OPSAWG  On Behalf Of xiao.m...@zte.com.cn
 Sent: Tuesday, April 2, 2024 10:58 AM
 To: draft-gfz-opsawg-ipfix-alt-m...@ietf.org
 Cc: opsawg@ietf.org; 'i...@ietf.org
 Subject: [OPSAWG] draft-gfz-opsawg-ipfix-alt-mark-00



 


 
Be aware: This is an external email.



 
Hi authors,
 
At the request of Giuseppe, I had a read on draft-gfz-opsawg-ipfix-alt-mark-00.
There are IPFIX IEs ingressInterface, egressInterface, ingressPhysicalInterface 
and egressPhysicalInterface, is there an IE indicating a LAG interface? 
 
Best Regards,
Xiao Min___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] ac-svc-name/attachment-circuit (was RE: Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06)

[mohamed . boucadair]

Hi Mahesh,

(changing the subject as this point is related to a teas WG doc + adding teas 
mailing list)

A choice would be intuitive here. However, a case it might be useful to have 
both rather than a choice is to handle migration cases. For example, a slice 
service was first bound to a very basic dedicated AC, but then the management 
of that AC is handed to the ACaaS because the AC is shared between several 
services. But, one would argue that the basic AC can also be created using 
ACaaS, which is fair as well.

I let the authors of draft-ietf-teas-ietf-network-slice-nbi-yang clarify the 
intended usage. Independent of whether the current design is maintained or a 
choice is used, some text to explain the design rationale would be helpful in 
the spec.

Thank you.

Cheers,
Med

De : Mahesh Jethanandani 
Envoyé : mardi 2 avril 2024 23:09
À : BOUCADAIR Mohamed INNOV/NET 
Cc : Gyan Mishra ; rtg-...@ietf.org; 
draft-ietf-opsawg-ac-lxsm-lxnm-glue@ietf.org; opsawg@ietf.org
Objet : Re: Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06



Hi Med,

Just one comment. See inline with [mj]


On Apr 1, 2024, at 11:05 PM, 
mohamed.boucad...@orange.com wrote:

Hi Gyan,

Thank you for the review.

The candidate revisions can be tracked here:

* 
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-common-ac.diff
* 
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-teas-attachment-circuit.diff
* 
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-ntw-attachment-circuit.diff
* 
https://boucadair.github.io/attachment-circuit-model/#go.draft-ietf-opsawg-ac-lxsm-lxnm-glue.diff

See more context inline.

Cheers,
Med


-Message d'origine-
De : Gyan Mishra via Datatracker mailto:nore...@ietf.org>>
Envoyé : vendredi 29 mars 2024 18:05
À : rtg-...@ietf.org
Cc : 
draft-ietf-opsawg-ac-lxsm-lxnm-glue@ietf.org;
 opsawg@ietf.org
Objet : Rtgdir early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-06


Reviewer: Gyan Mishra
Review result: Has Issues

I have been selected as the Routing Area Directorate Reviewer for the
draft
below:

draft-ietf-opsawg-ac-lxsm-lxnm-glue-06

I reviewed the latest version 6 and the ideas behind the concept of
the draft makes sense, however some additional recommendations on
clarity of the draft I believe is necessary before publication.

This draft was presented at IETF 117 last summer by Mohamed Boucadair
and adopted on November 6th 2023.  As the draft was adopted fairly
recently, my goal is to catch any issues with the draft before
publication.

The 3 additional drafts below were reviewed together as requested.

! Draft being reviewed
draft-ietf-opsawg-ac-lxsm-lxnm-glue-06

! Additional drafts reviewed
draft-ietf-opsawg-ntw-attachment-circuit-05
draft-ietf-opsawg-teas-attachment-circuit-06
draft-ietf-opsawg-teas-common-ac-05

All 4 drafts were adopted on November 6th 2023.

I ran IDNITS against all 4 drafts and result was "no issues found
here"

Routing Area Directorate Review request Main Draft
draft-ietf-opsawg-ac-lxsm-lxnm-glue-06

Major Issues:
None

Minor Issues:
The main use case for this draft is for network slicing

[Med] Actually, no. This draft focuses on binding LxVPN to ACs. The required 
functionality to bind a slice service with ACs is built as part of the service 
slice model itself. FWIW, draft-ietf-teas-ietf-network-slice-nbi-yang includes 
the following:

  *  "ac-svc-name": Indicates the names of AC services, for association
 purposes, to refer to the ACs that have been created.  When both
 "ac-svc-name" and the attributes of "attachment-circuits" are
 defined, the "ac-svc-name" takes precedence.

[mj] Is there a reason to have both? Should it not be a choice statement?

| +--rw ac-svc-name*  string
| +--rw attachment-circuits
| |  +--rw attachment-circuit* [id]
| | +--rw id   string
| | +--rw description? string
| | +--rw ac-svc-name? string

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