Subject: [manet] Stephen Farrell's No Objection on draft-ietf-manet-rfc6779bis-06: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 01 Jun 2016 11:21:54 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-manet-rfc6779bis-06: No Objection

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-manet-rfc6779bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- My review is based on the diff at [1]

- The security considerations section doesn't seem to
reflect the latest boilerplate. [2] Should it? I'm not
making this a discuss as it's a minor change to a MIB and
I accept that it's arguable that folks might not update
their SNMP security code whilst doing this. But I don't
think I've seen this case before (minor update to MIB
without changed security boilerplate) so maybe the IESG
should chat about it to decide if there's anything to be
done here.

   [1]
https://www.ietf.org/rfcdiff?url1=rfc6779&url2=draft-ietf-manet-rfc6779bis-06
   [2] https://trac.tools.ietf.org/area/ops/trac/wiki/mib-security

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 1 Jun 2016 19:04:14 +0000

On 6/1/16, 2:21 PM, "iesg on behalf of Stephen Farrell"
<[email-masked] on behalf of
[email-masked]> wrote:

Stephen:

Hi!

>should chat about it to decide if there's anything to be

The variations from the boilerplate are minimal:

Boilerplate>
   ...The support for SET operations in a non-secure
   environment without proper protection opens devices to attack.

...
   Implementations SHOULD provide the security features described by the
   SNMPv3 framework (see [RFC3410]), and implementations claiming
compliance 
   to the SNMPv3 standard MUST include full support for authentication and
   privacy via the User-based Security Model (USM) [RFC3414] with the AES
   cipher algorithm [RFC3826].

rfc6779bis>
   ...The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.

...
   Implementations MUST provide the security features described by the
   SNMPv3 framework (see [RFC3410]), including full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].

I don't have any issues with making the text match.

Alvaro.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 Jun 2016 20:15:18 +0100

> The variations from the boilerplate are minimal:

(But represent some arm-wrestling effort between SEC
and OPS ads:-)

> I don't have any issues with making the text match.

Great. Like I said I don't think this is discuss-worthy,
but OTOH, if someone's updating their code then that is
a good time to update the security stuff too.

Cheers,
S.

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 1 Jun 2016 22:17:30 -0700

Stephen,

I have no concerns with matching the text to the boilerplate. There
is one extra paragraph in addition to the minimal differences that
Alvaro pointed out:

"MANET technology is often deployed to support communications of
emergency services or military tactical applications. In these
applications, it is imperative to maintain the proper operation of the
communications network and to protect sensitive information related to
its operation. Therefore, it is RECOMMENDED to provide support for the
Transport Security Model (TSM) [RFC5591] in combination with TLS/DTLS
[RFC6353]."

I am fine with removing this also to match the boiler plate 100%.

Best regards
Ulrich