Re: [OPSAWG] (Also Ben Campbell's and Alexey's) Re: Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

[Eliot Lear]

On 17.04.18 14:44, Spencer Dawkins at IETF wrote:
> Hi, Eliot,
>
> On Tue, Apr 17, 2018 at 1:43 AM, Eliot Lear  > wrote:
>
> Responding to Spencer, Ben, and Alexy (in order).
>
>
> On 16.04.18 21:09, Spencer Dawkins wrote:
>> Spencer Dawkins has entered the following ballot position for
>> draft-ietf-opsawg-mud-20: Yes
>>
>> 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/iesg/statement/discuss-criteria.html
>> 
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>> 
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> I'm a Yes who's watching Discussions with other ADs, but that's still a 
>> Yes.
>> Thanks for doing this work.
>>
>> I do have some questions and comments.
>>
>> I don't think this requires any changes to the current document, but I 
>> note that
>>
>> 3.15.  direction-initiated
>>
>>When applied this matches packets when the flow was initiated in the
>>corresponding direction.  [RFC6092] specifies IPv6 guidance best
>>practices.  While that document is scoped specifically to IPv6, its
>>contents are applicable for IPv4 as well.  When this flag is set, and
>>the system has no reason to believe a flow has been initiated it MUST
>>drop the packet.  This node may be implemented in its simplest form
>>by looking at naked SYN bits, but may also be implemented through
>>more stateful mechanisms.
>>
>> it's not clear that "looking at naked SYN bits" will have an analogy in 
>> HTTP/2
>> over QUIC, and I'm a bit suspicious of "may also be implemented through 
>> more
>> stateful mechanisms" in 2018. Do the right thing, of course.
>
> I proposed a clarification: direction initiated is a TCP element.
>
>
> That is a clarification. 
>
> I guess what I'm thinking, on reflection, is that direction is likely
> to be helpful for TCP-based communication, is not likely to be helpful
> for UDP-based communication without stateful inspection (so, my camera
> probably does need to act as a DNS client, but probably doesn't need
> to act as a DNS server), and is likely to be increasingly unhelpful if
> we really do see things using encrypted, UDP-based transports like QUIC. 
>
> This does poke the "how are network managers going to manage networks
> running encrypted, UDP-based transport" bear, but that's way bigger
> than this document. Say as much as you think is helpful, and then move
> on, I think.

Well indeed.  I think the key here is to recognize that all MUD can do
is invoke network management capabilities already present in the
infrastructure.  "Picture if you will", however, a MUD extension that
modifies the meaning of "direction-initiated" to say, please do stateful
to allow stuff outbound, and re-adds the element in the UDP context. 
Absolutely possible.  I think it's a matter of whether the underlying
infrastructure broadly supports such a capability.



>> Does
>>
>> 3.5.  is-supported
>>
>>This boolean is an indication from the manufacturer to the network
>>administrator as to whether or not the Thing is supported.  In this
>>context a Thing is said to not be supported if the manufacturer
>>intends never to issue an update to the Thing or never update the MUD
>>file.  A MUD controller MAY still periodically check for updates.
>>
>> ever mean anything except "is-updated"? 
>
> Mostly that what it means, but the implication is that there's no
> support, and enterprise administrators in particular might want to
> know that (usually they do- because those devices represent a
> particular risk).
>
>
>  Here, I must apologize, because I've been thinking of MUD as the
> other side of a coin that also has SUIT, TEEP, and similar tools - If
> your Thing is just being installed and forgotten until it's an attack
> platform, you need MUD descriptions, but if your Thing is going to be
> updated, you should be looking at SUIT, TEEP, and whatever else seems
> helpful. 
>
> I had not been thinking of using both MUD and SUIT/TEEP/whatever, and
> that's a lack of imagination on my part, but the most relevant side
> effect of that, is that if you know what your printer needs to do, to
> be a network printer, and you get a MUD description for it, and the
> printer isn't going to be updated, that MUD descrip

Re: [OPSAWG] (Also Ben Campbell's and Alexey's) Re: Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Eliot,

On Tue, Apr 17, 2018 at 1:43 AM, Eliot Lear  wrote:

> Responding to Spencer, Ben, and Alexy (in order).
>
> On 16.04.18 21:09, Spencer Dawkins wrote:
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Yes
>
> 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found 
> here:https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> --
> COMMENT:
> --
>
> I'm a Yes who's watching Discussions with other ADs, but that's still a Yes.
> Thanks for doing this work.
>
> I do have some questions and comments.
>
> I don't think this requires any changes to the current document, but I note 
> that
>
> 3.15.  direction-initiated
>
>When applied this matches packets when the flow was initiated in the
>corresponding direction.  [RFC6092] specifies IPv6 guidance best
>practices.  While that document is scoped specifically to IPv6, its
>contents are applicable for IPv4 as well.  When this flag is set, and
>the system has no reason to believe a flow has been initiated it MUST
>drop the packet.  This node may be implemented in its simplest form
>by looking at naked SYN bits, but may also be implemented through
>more stateful mechanisms.
>
> it's not clear that "looking at naked SYN bits" will have an analogy in HTTP/2
> over QUIC, and I'm a bit suspicious of "may also be implemented through more
> stateful mechanisms" in 2018. Do the right thing, of course.
>
>
> I proposed a clarification: direction initiated is a TCP element.
>

That is a clarification.

I guess what I'm thinking, on reflection, is that direction is likely to be
helpful for TCP-based communication, is not likely to be helpful for
UDP-based communication without stateful inspection (so, my camera probably
does need to act as a DNS client, but probably doesn't need to act as a DNS
server), and is likely to be increasingly unhelpful if we really do see
things using encrypted, UDP-based transports like QUIC.

This does poke the "how are network managers going to manage networks
running encrypted, UDP-based transport" bear, but that's way bigger than
this document. Say as much as you think is helpful, and then move on, I
think.

> Does
>
> 3.5.  is-supported
>
>This boolean is an indication from the manufacturer to the network
>administrator as to whether or not the Thing is supported.  In this
>context a Thing is said to not be supported if the manufacturer
>intends never to issue an update to the Thing or never update the MUD
>file.  A MUD controller MAY still periodically check for updates.
>
> ever mean anything except "is-updated"?
>
>
> Mostly that what it means, but the implication is that there's no support,
> and enterprise administrators in particular might want to know that
> (usually they do- because those devices represent a particular risk).
>

 Here, I must apologize, because I've been thinking of MUD as the other
side of a coin that also has SUIT, TEEP, and similar tools - If your Thing
is just being installed and forgotten until it's an attack platform, you
need MUD descriptions, but if your Thing is going to be updated, you should
be looking at SUIT, TEEP, and whatever else seems helpful.

I had not been thinking of using both MUD and SUIT/TEEP/whatever, and
that's a lack of imagination on my part, but the most relevant side effect
of that, is that if you know what your printer needs to do, to be a network
printer, and you get a MUD description for it, and the printer isn't going
to be updated, that MUD description should be fine, forever.

I'm still connecting dots.

> "Supported" covers a lot of ground …
>
> If a manufacturer sells off one product line (so, flobbidy.example.com covered
> multiple product lines, but now flobbidy.example.com/mark1/lightbulb will be
> maintained by a manufacturer that isn't flobbidy.example.com), is there a good
> plan for what comes next? I'm not sure what happens to is-supported, for
> instance.
>
>
> The intent is that the entity providing the MUD file (probably the
> manufacturer) will not be issuing software/firmware updates or MUD file
> updates.  But your point is more about device lifecycle, and that's a more
> interesting question than just "is-supported".  Steve Rich and Thorsten
> Dahm have begun to delve in that direction.  There are at least a few
> possibilities, such as the use of redirects, or even domain names that are
> used for particular classes of devices, or even common repos.  More work
> needed.
>

Yeah, and I di

[OPSAWG] (Also Ben Campbell's and Alexey's) Re: Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

[Eliot Lear]

Responding to Spencer, Ben, and Alexy (in order).


On 16.04.18 21:09, Spencer Dawkins wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Yes
>
> 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> --
> COMMENT:
> --
>
> I'm a Yes who's watching Discussions with other ADs, but that's still a Yes.
> Thanks for doing this work.
>
> I do have some questions and comments.
>
> I don't think this requires any changes to the current document, but I note 
> that
>
> 3.15.  direction-initiated
>
>When applied this matches packets when the flow was initiated in the
>corresponding direction.  [RFC6092] specifies IPv6 guidance best
>practices.  While that document is scoped specifically to IPv6, its
>contents are applicable for IPv4 as well.  When this flag is set, and
>the system has no reason to believe a flow has been initiated it MUST
>drop the packet.  This node may be implemented in its simplest form
>by looking at naked SYN bits, but may also be implemented through
>more stateful mechanisms.
>
> it's not clear that "looking at naked SYN bits" will have an analogy in HTTP/2
> over QUIC, and I'm a bit suspicious of "may also be implemented through more
> stateful mechanisms" in 2018. Do the right thing, of course.

I proposed a clarification: direction initiated is a TCP element.
>
> Does
>
> 3.5.  is-supported
>
>This boolean is an indication from the manufacturer to the network
>administrator as to whether or not the Thing is supported.  In this
>context a Thing is said to not be supported if the manufacturer
>intends never to issue an update to the Thing or never update the MUD
>file.  A MUD controller MAY still periodically check for updates.
>
> ever mean anything except "is-updated"? 

Mostly that what it means, but the implication is that there's no
support, and enterprise administrators in particular might want to know
that (usually they do- because those devices represent a particular risk).

> "Supported" covers a lot of ground …
>
> If a manufacturer sells off one product line (so, flobbidy.example.com covered
> multiple product lines, but now flobbidy.example.com/mark1/lightbulb will be
> maintained by a manufacturer that isn't flobbidy.example.com), is there a good
> plan for what comes next? I'm not sure what happens to is-supported, for
> instance.

The intent is that the entity providing the MUD file (probably the
manufacturer) will not be issuing software/firmware updates or MUD file
updates.  But your point is more about device lifecycle, and that's a
more interesting question than just "is-supported".  Steve Rich and
Thorsten Dahm have begun to delve in that direction.  There are at least
a few possibilities, such as the use of redirects, or even domain names
that are used for particular classes of devices, or even common repos. 
More work needed.

>
> I'm sensitive to Eliot's "walk before trying to run" comment on another ballot
> thread, but I'm thinking that
>
> 3.11.  model
>
>This string matches the entire MUD URL, thus covering the model that
>is unique within the context of the authority.  It may contain not
>only model information, but versioning information as well, and any
>other information that the manufacturer wishes to add.  The intended
>use is for devices of this precise class to match, to permit or deny
>communication between one another.
>
> might usefully result in a BCP about naming models, after the community has
> some experience with MUD. So, that's not intended to affect the current draft
> text, only the working group that produced it ;-)
>
> And, double ;-) ;-) but I wrote that before I saw this text in Section 14:
>
>   A caution about some of the classes: admission of a Thing into the
>"manufacturer" and "same-manufacturer" class may have impact on
>access of other Things.  Put another way, the admission may grow the
>access-list on switches connected to other Things, depending on how
>access is managed.  Some care should be given on managing that
>access-list growth.  Alternative methods such as additional network
>segmentation can be used to keep that growth within reason.
>
> So, when people know enough to describe best practices, I hope they do.
>

Thanks, Spencer.  We're just getting going.

Now to Ben:

> §1.6, 2nd paragraph: Why is the SHOULD not a MUST?

Because at this stage