Re: [Gen-art] Genart telechat review of draft-ietf-opsawg-mud-20

[Eliot Lear]

All the way down...


On 11.04.18 18:15, Robert Sparks wrote:
>
>>
>> Similarly, the use of the word standardized naked like that is
>> probably unhelpful.
> Can I infer you plan to edit it out or dress it more?

Yes.

>> One could imagine, for instance, Fairhair or some other consortium
>> deciding to create standard classes.
>>
>> What I propose is two changes to facilitate better understanding:
>>
>>  1. To include the simple example described above.
>>  2. To add an optional "documentation"  element in the "mud"
>> container that consists of a URL that points to documents for
>> each class, when so used.
>>
> Sure.
>>
>> Thoughts?
>>
> With this, I'm puzzled about the use of the word standardized at all.
> I think I'm hearing that you expect MUD controllers to know about some
> well-known classes by convention and that groups like fairhair or
> someone else might make a list of classes that MUD controllers might
> collectively decide to build in knowledge of. Am I getting closer to
> the right picture? (This is opposed to a set of classes that are
> created by a standards action and listed in a registry somewhere).

The class is just a name that expands out to a bunch of IP addresses. 
It happens to take the form of a URI, but it's really just a name. 
There could be well known NAMES, and indeed we create a URN registry
just for that purpose.  Maybe I need to be a bit more clearer on that point?

Eliot
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-opsawg-mud-20

[Robert Sparks]

On 4/11/18 1:35 AM, Eliot Lear wrote:


Hi Robert,

A few additional comments below:


On 10.04.18 16:22, Robert Sparks wrote:




On 4/10/18 5:43 AM, Eliot Lear wrote:


Hi Robert and thanks again for the review.  Please see below for 
responses.  These are my personal views.  The WG chairs / shepherds 
may have different opinions.



Thank you for the very quick response!



On 09.04.18 19:57, Robert Sparks wrote:

Reviewer: Robert Sparks
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-opsawg-mud-20
Reviewer: Robert Sparks
Review Date: 2018-04-09
IETF LC End Date: 2017-11-07
IESG Telechat date: 2018-04-19

Summary: Almost ready but with minor issues to address before publication as a
standards track RFC

Minor issues:

Section 3.15 is confused, and I don't think you'll get the implementation you
intend with the MUST in the current language. direction-indicated is not a
flag. The text about dropping should talk about matching the direction that was
indicated.


Having reread this section (and perhaps I am a bit too close to the 
text), perhaps it is a bit confused.  How about something along the 
following lines:


3.15.  direction-initiated

   When applied this matches the direction in which a TCP connection is
   initiated.  When direction initiated is "from-device", packets 
that are
   transmitted in the direction of a thing MUST be dropped unless 
the thing
   has first initiated a TCP connection.  This node may be 
implemented in
   its simplest form by looking at naked SYN bits, but may also be 
implemented

   through more stateful mechanisms.

  [RFC6092] specifies IPv6 guidance best
   practices.  While that document is scoped specifically to IPv6, its
   contents are applicable for IPv4 as well.


Better?

wfm



The quoted issues below are from my early review of -08. I don't think they've
been addressed or responded to. Apologies if I missed a response.


The document proposes "reputation services". It needs more words about
whether those exist, and what scopes the architecture imagines (an
enterprise might have a different idea of a reputation service than a
residence). There is a notion of "decent web reputations" in the security
considerations section. Who determines that? The security considerations
section should talk about attacks against the reputation services.
I think there needs to be more discussion of the PKI used for signing MUD
files.
  


While this section is admittedly a bit vague, we need some 
operational experience to develop the appropriate use of PKI as an 
anchor for reputations.  This having been said, if you have a 
specific proposal for text, I'd be interested in what you have to say.
Do you envision enterprises or manufacturers creating a new set of 
anchors of trust, or are you hoping to reuse the web PKI or something 
else? If you don't know and all of these are on the table, mentioning 
it would help implementers avoid assumptions that could hinder 
deployment.


Thanks for the guidance.   In fact I think we need to more clearly 
specify the signature in terms of the purpose.  The tools (openssl) 
support S/MIME signing easily enough for CMS.  I think this is what we 
want, and it implies that we are *not* using the webpki, but instead 
just getting an S/MIME certificate.  This implies that the signers 
will have to be "admitted" on first sight.  Would that work for you?

Sure


Also see below.





Consider discussing whether the stacks used by typical things will let
them add DHCP options (or include bits in the other protocols being
enabled). If it's well known (I can't say) that these stacks typically
_won't_ provide that functionality, then you should punch up the
discussion of the controllers mapping other identifiers to MUD URLs on
behalf of the thing.


We did indeed add some text about this, almost verbatim to what you 
have above (I think at your suggestion).  This can be found in the 
introduction toward the bottom of page 9.
I'm not seeing it in -20. Maybe its in your working copy but not 
issued yet, or 9 above isn't where you meant to point? I did a quick 
search for DHCP through the document and didn't spot the discussion. 
Apologies if I'm just missing it.


Actually it's in two places.  See where we say in Section 1.5:

   It is possible that there may be other means for a MUD URL to be
   learned by a network.  For instance, some devices may already be
   fielded or have very limited ability to communicate a MUD URL, and
   yet can be identified through some means, such as a serial number or
   a public key.  In these cases, manufacturers may be able to map those
   

Re: [Gen-art] Genart telechat review of draft-ietf-opsawg-mud-20

[Robert Sparks]

On 4/11/18 11:58 AM, Eliot Lear wrote:


All the way down...


On 11.04.18 18:15, Robert Sparks wrote:




Similarly, the use of the word standardized naked like that is 
probably unhelpful.

Can I infer you plan to edit it out or dress it more?


Yes.

One could imagine, for instance, Fairhair or some other consortium 
deciding to create standard classes.


What I propose is two changes to facilitate better understanding:

 1. To include the simple example described above.
 2. To add an optional "documentation"  element in the "mud"
container that consists of a URL that points to documents for
each class, when so used.


Sure.


Thoughts?

With this, I'm puzzled about the use of the word standardized at all. 
I think I'm hearing that you expect MUD controllers to know about 
some well-known classes by convention and that groups like fairhair 
or someone else might make a list of classes that MUD controllers 
might collectively decide to build in knowledge of. Am I getting 
closer to the right picture? (This is opposed to a set of classes 
that are created by a standards action and listed in a registry 
somewhere).


The class is just a name that expands out to a bunch of IP addresses.  
It happens to take the form of a URI, but it's really just a name.  
There could be well known NAMES, and indeed we create a URN registry 
just for that purpose.  Maybe I need to be a bit more clearer on that 
point?

Probably good to do? I hope I'm not just being too thick-headed here.


Eliot


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-opsawg-mud-20

[Eliot Lear]

Hi Robert,

A few additional comments below:


On 10.04.18 16:22, Robert Sparks wrote:
>
>
>
> On 4/10/18 5:43 AM, Eliot Lear wrote:
>>
>> Hi Robert and thanks again for the review.  Please see below for
>> responses.  These are my personal views.  The WG chairs / shepherds
>> may have different opinions.
>>
> Thank you for the very quick response!
>>
>>
>> On 09.04.18 19:57, Robert Sparks wrote:
>>> Reviewer: Robert Sparks
>>> Review result: Ready with Issues
>>>
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>> by the IESG for the IETF Chair. Please wait for direction from your
>>> document shepherd or AD before posting a new version of the draft.
>>>
>>> For more information, please see the FAQ at
>>>
>>> .
>>>
>>> Document: draft-ietf-opsawg-mud-20
>>> Reviewer: Robert Sparks
>>> Review Date: 2018-04-09
>>> IETF LC End Date: 2017-11-07
>>> IESG Telechat date: 2018-04-19
>>>
>>> Summary: Almost ready but with minor issues to address before publication 
>>> as a
>>> standards track RFC 
>>>
>>> Minor issues:
>>>
>>> Section 3.15 is confused, and I don't think you'll get the implementation 
>>> you
>>> intend with the MUST in the current language. direction-indicated is not a
>>> flag. The text about dropping should talk about matching the direction that 
>>> was
>>> indicated.
>>
>> Having reread this section (and perhaps I am a bit too close to the
>> text), perhaps it is a bit confused.  How about something along the
>> following lines:
>>
>> 3.15.  direction-initiated
>>
>>    When applied this matches the direction in which a TCP connection is
>>    initiated.  When direction initiated is "from-device", packets
>> that are
>>    transmitted in the direction of a thing MUST be dropped unless the
>> thing
>>    has first initiated a TCP connection.  This node may be implemented in
>>    its simplest form by looking at naked SYN bits, but may also be
>> implemented
>>    through more stateful mechanisms.
>>  
>>   [RFC6092] specifies IPv6 guidance best
>>    practices.  While that document is scoped specifically to IPv6, its
>>    contents are applicable for IPv4 as well. 
>>
>>
>> Better?
> wfm
>>
>>> The quoted issues below are from my early review of -08. I don't think 
>>> they've
>>> been addressed or responded to. Apologies if I missed a response.
>>>
 The document proposes "reputation services". It needs more words about
 whether those exist, and what scopes the architecture imagines (an
 enterprise might have a different idea of a reputation service than a
 residence). There is a notion of "decent web reputations" in the security
 considerations section. Who determines that? The security considerations
 section should talk about attacks against the reputation services.
 I think there needs to be more discussion of the PKI used for signing MUD
 files.
>>>  
>>
>> While this section is admittedly a bit vague, we need some
>> operational experience to develop the appropriate use of PKI as an
>> anchor for reputations.  This having been said, if you have a
>> specific proposal for text, I'd be interested in what you have to say.
> Do you envision enterprises or manufacturers creating a new set of
> anchors of trust, or are you hoping to reuse the web PKI or something
> else? If you don't know and all of these are on the table, mentioning
> it would help implementers avoid assumptions that could hinder deployment.

Thanks for the guidance.   In fact I think we need to more clearly
specify the signature in terms of the purpose.  The tools (openssl)
support S/MIME signing easily enough for CMS.  I think this is what we
want, and it implies that we are *not* using the webpki, but instead
just getting an S/MIME certificate.  This implies that the signers will
have to be "admitted" on first sight.  Would that work for you?

Also see below.


>>
 Consider discussing whether the stacks used by typical things will let
 them add DHCP options (or include bits in the other protocols being 
 enabled). If it's well known (I can't say) that these stacks typically
 _won't_ provide that functionality, then you should punch up the
 discussion of the controllers mapping other identifiers to MUD URLs on
 behalf of the thing.
>>
>> We did indeed add some text about this, almost verbatim to what you
>> have above (I think at your suggestion).  This can be found in the
>> introduction toward the bottom of page 9.
> I'm not seeing it in -20. Maybe its in your working copy but not
> issued yet, or 9 above isn't where you meant to point? I did a quick
> search for DHCP through the document and didn't spot the discussion.
> Apologies if I'm just missing it.

Actually it's in two places.  See where we say in Section 1.5:

   It is possible that there may be other means for a MUD URL to be
   learned by a network.  For instance,