Subject: [OPSAWG] Re: OPSAWG] I-D Action:draft-ietf-opsawg-snmp-engineid-discovery-01.txt,

From: [email-masked] (Scott O. Bradner)
Date: Mon, 28 Jan 2008 23:19:21 -0500 (EST)

does the 01 version answer the comments people had about the -00 version?

(one last check before forwarding the document to the IESG)

Scott

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/opsawg

---

From: "Bert Wijnen" <[email-masked]>
Date: Thu, 31 Jan 2008 13:00:35 +0100

Sorry for being late.

I have a few questions/comments

- Should there not be a "updates to RFC3411" section that
  summarizes the changes/additions/updates?

- I believe that the localEngineID is to be used ONLY as
  a contextEngineID. So the localEngineID '8000000006'H
  I believe CAN NOT and SHOULD NOT ever be used as a
  snmpEngineID in the msgAuthoritativeEngineID field in
  the securityParameters of the USM. All other snmpEngineIDs
  (I believe) can be used for both contextEngineID and 
  msgAuthoritativeEngineID.

  I think that this should be made very clear in the document.
  There is currently no discussion about this at all.

- IANA considerations.
  I think it would be usefull to state/add that RFC3411 basically
  did define the registry for snmpEngineID formats, and in fact that
  registry exists at
     http://www.iana.org/assignments/snmp-number-spaces
  It is pointed from the main page
     http://www.iana.org/numbers.html#S
  On the line that states:
     SnmpEngineID Formats RFC3411 Standards track document (section 6.3) 

  But RFC3411 was not explicit in telling IANA to record the
  initial assignments made by RFC3411 into that registry. It only 
  told IANA that they can assign values in the range 6-127. It is goodness
  that this document instructs IANA to add to the registry the values
  that were already assigned in RFC3411.

Bert Wijnen 

> -----Oorspronkelijk bericht-----
> Van: Scott O. Bradner [mailto:[email-masked]]
> Verzonden: dinsdag 29 januari 2008 5:19
> Aan: [email-masked]
> Onderwerp: [OPSAWG] Re: OPSAWG]
> I-DAction:draft-ietf-opsawg-snmp-engineid-discovery-01.txt, 
> 
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Jan 2008 17:33:08 +0100

>   summarizes the changes/additions/updates?

Is it sufficient if I add the following sentence to the introduction,
just before the requirements language blurb:

   This document updates RFC 3411 [RFC3411] by clarifying the IANA rules
   for the maintenance of the SnmpEngineID format registry.
 
>   There is currently no discussion about this at all.

Good point. My proposal is the following change:

OLD:

   The localEngineID value always provides access to the default context
   of an SNMP engine. 

NEW:

   The localEngineID value always provides access to the default context
   of an SNMP engine.  Note that the localEngineID value is intended to
   be used as a contextEngineID.  It MUST NOT be used as a value in the
   msgAuthoritativeEngineID field in the securityParameters of the User-
   based Security Model (USM) [RFC3414].

>   that were already assigned in RFC3411.

My proposal is to add another paragraph to the IANA considerations
section explaining the situation and to slightly reword the rest. Here
is the proposed new text:

4.  IANA Considerations

   RFC 3411 requested IANA to create a registry for SnmpEngineID
   formats.  However, RFC 3411 did not ask IANA to record the initial
   assignments made by RFC 3411 nor did RFC 3411 spell out the precise
   allocation rules.  To address this issue, the following rules are
   hereby established.

   IANA has to maintain a registry for SnmpEngineID formats.  The first
   four octets of an SnmpEngineID carry an enterprise number while the
   fifth octet in a variable length SnmpEngineID value, called the
   format octet, indicates how the following octets are formed.  The
   following format values were allocated in [RFC3411]:

     Format    Description                     References
     -------   -----------                     ----------
          0    reserved, unused                 [RFC3411]
          1    IPv4 address                     [RFC3411]
          2    IPv6 address                     [RFC3411]
          3    MAC address                      [RFC3411]
          4    administratively assigned text   [RFC3411]
          5    administratively assigned octets [RFC3411]
       6-127   reserved, unused                 [RFC3411]
     128-255   enterprise specific              [RFC3411]

   IANA can assign new format values out of the originally assigned and
   reserved number space 1-127.  For new assignments, a specification is
   required as per [RFC2434].

   This document requested the following assignment:

     Format    Description                     References
     -------   -----------                     ----------
          6    local engine                     [RFCXXXX]

     [RFC Ed.: replace XXXX with RFC number assigned to the document]

Let me know whether these changes address your concerns.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Bert Wijnen" <[email-masked]>
Date: Thu, 31 Jan 2008 18:02:24 +0100

Thanks Juergen. Inline

Bert Wijnen 

> Van: Juergen Schoenwaelder [mailto:[email-masked]]
> Verzonden: donderdag 31 januari 2008 17:33
> Aan: Bert Wijnen
> CC: Scott O. Bradner; [email-masked]
> Onderwerp: Re: [OPSAWG] Re:
> OPSAWG]I-DAction:draft-ietf-opsawg-snmp-engineid-discovery-01.txt,
> 
> 

In general, it is one of our WG chairs (Scott) who really wants such
a section. I think the above is correct.
The remainder of the document is describing contextEngineDiscovery
but that is stand-alone I think. 
So I can live with your addition.

>    based Security Model (USM) [RFC3414].

That is good. I think it also implies that it can never be the value
of snmpEngineID.0, right? Probably good to add that too.

>      Format    Description                     References

I think that is for new assignments by IANA, right.
Values between 128-255 inclusive do not need an specification in the
sense of RFC3434, do they? It is always good if such specs are available
somewhere, but we should not mandate them to be public, should we?

>      Format    Description                     References

Good.

Bert

---

From: "David Harrington" <[email-masked]>
Date: Thu, 31 Jan 2008 12:25:11 -0500

Hi 

comments inline

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Thursday, January 31, 2008 11:33 AM
> To: Bert Wijnen
> Cc: [email-masked]
> Subject: Re: [OPSAWG] Re: 

I don't think this updates RFC3411; it supplements RFC3411.
I would not liek to go to the RFC search page and see "RFC3411 Updated
by XXXX" beasue i think that would be misleading.
I would prefer

   This document provides rules for the maintenance of the 
   IANA registry for SnmpEngineID formats [RFC3411].
 
>    based Security Model (USM) [RFC3414].

USM will not prevent it being used thi sway. What happens if an
attacker does use it there? Does this create a security vulnerability?
Does it actually matter? Must USM be updated to not allow this?