Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib - SMI violation?

["ietfdbh" <[e-mail]>]

Hi,

natAddrPortBindLocalAddr - the one being deprecated - is redefined in the
new document. The original had InetAddress syntax with no range; the new doc
adds a range (thereby redefining the range).
I think this violates SMI rules (but it deserves checking to be sure).

David Harrington
[e-mail]
[phone]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
ietfdbh
Sent: Friday, May 31, 2013 9:48 AM
To: 'Simon Perreault'; 'Dave Thaler'
Cc: [e-mail]; [e-mail]
Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib

Hi,

Three things.

1) A while back, I suggested that, if you are deprecating all of the NAT-MIB
in rfc4008, that it would be better to do this as a separate document from
the NEW-NAT-MIB (or whatever the new module gets called). Simon asked me to
get consensus from the MIB Doctors.

I checked with the MIB Doctor list, and only got one reply - from Juergen,
who apparently recommended a single document. His response:
" I have probably been pushing them into this because at the beginning it
was not really clear why the existing NAT-MIB is fatally flawed such that it
needs a complete replacement. If the behave WG has meanwhile reached
consensus that indeed the existing NAT-MIB is fatally flawed and needs a
complete replacement, then indeed what you suggest makes sense. I assume the
WG has checked with those who have implementations of the existing NAT-MIB
(if any) that they agree on a need for a complete new MIB."

2) Since deprecated objects are not obsoleted, I think new security
considerations might be called for relating to the deprecated objects -
especially if there are security implications of implementing BOTH the
current and deprecated objects. 

Some NMS applications will support only the old MIB module; others may
support only the new MIB module. Some agents will want to implement both, to
make their devices manageable from either type of NMS application. Some NMS
applications will want to support both, to deal with both legacy and new
agents. 

MIB modules often make information available that could potentially be used
by attackers. 
Are there particular risks involved in exposing the information of these two
NAT-MIBs in combination? 
Are there potential risks associated with the potential confusion of looking
at a NAT from the different perspectives used by these two NAT MIB
approaches?

3) I notice there is no "Operational Considerations" section. I wonder if
one is called for here, because operators may be faced with NMS applications
and/or agents that support both the deprecated and the new MIB module. What
should operators (and NMS applications) do with this potentially conflicting
information? What should they explicitly NOT do? E.g., What assumptions
should they NOT make about the relationships between specific objects in the
old and new versions?

My impression is that the old and the new MIB modules might be appropriate
depending on the environment in which they exist, and the old MIB is
implemented (to whatever degree of compliance) in existing legacy devices,
so simply saying "never use the old MIB" is not going to be an acceptable
approach. 

David Harrington
[e-mail]
[phone]
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Simon Perreault
Sent: Friday, May 31, 2013 3:51 AM
To: Dave Thaler
Cc: [e-mail]; [e-mail]
Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib

Le 2013-05-30 21:38, Dave Thaler a écrit :
>>> 4) The MIB compiler I used complained about this:
>>>> natMappingPool OBJECT-TYPE
>>>>       SYNTAX NatPoolId (0|1..4294967295)
>>> Because of
>>>> NatPoolId ::= TEXTUAL-CONVENTION
>>>>       SYNTAX Unsigned32 (1..4294967295)
>>>
>>> That is, NatPoolId does not allow 0, and so natMappingPool cannot 
>>> add it and still use the NatPoolId syntax.
>>
>> Hmmmm... Would it be OK if I changed natMappingPool to an Unsigned32?
>>
>> natMappingPool OBJECT-TYPE
>>       SYNTAX Unsigned32 (0|1..4294967295)
>
> Yes, but you should remove the range restriction since that's the full
range.
> So just
>          SYNTAX Unsigned32

Right. Removed.

> I see you added in the security considerations section:
>>       Note: This section only applies to objects with current status.
>>       For deprecated objects, please refer to the Security
>>       Considerations section from [RFC4008].
>
> However that doesn't make sense in my opinion unless we make RFC4008 a
> Normative (not informative) reference.   But I would prefer keeping it as
> an informative reference so it can be obsoleted.   So I disagree with the
> quoted limitation.

Hmmm... So what should we do instead? Keeping in mind that the security
considerations in 4008 aren't up to today's standards.

a) Copy the security section verbatim from 4008. Add a preamble saying
something like "These considerations apply to the deprecated elements. 
Others may apply, use at your own risk."

b) Create brand new security considerations for deprecated elements.

c) ???

Simon
_______________________________________________
Behave mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/behave