Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability

[Erik Kline <[e-mail]>]

On 9 July 2015 at 08:10, Tom Taylor <[e-mail]> wrote:
> On 08/07/2015 2:39 PM, Fred Baker (fred) wrote:
>>
>>
>>> On Jul 6, 2015, at 7:08 PM, Erik Kline <[e-mail]> wrote:
>>>
>>> Some of this could also serve as input to motivate a SAVI document
>>> defining a basic logging protocol.
>>>
>>> I still believe that if there where a trivially deployable logging
>>> methodology that captured
>>>
>>>     {IP address, timestamp, rfc7039#section-3.2 binding context}
>>>
>>> tuples, or even the full data structure entry described in
>>> rfc6620#section-3.1, then the auditing objectives could be well and
>>> truly met.
>>>
>>> I think this is still one large unmet need.  (not necessarily a v6ops
>>> matter, perhaps)
>>
>>
>> Operational requirements for such could be a v6ops project, and probably a
>> quick one. You're correct that a protocol development probably belongs in a
>> protocol WG. Calling out the binding anchor makes sense, but some of those
>> (the port on an Ethernet switch to which a host attaches, the security
>> association between a host and the base station on wireless links) don't
>> have obvious portable names (if I say that a given security association is
>> number 27 in the AP's table, that's meaningful to the AP, but I'm not sure
>> it's meaningful to an operator coming in after the fact).
>>
>> I find myself wondering whether this might get rolled up with some other
>> logging operation, such as for stateful NATs. It begins to sound a lot like
>> a record that associates a set of elements together (a 3-tuple or 5-tuple
>> for a session with a MAC Address and a port number and a time stamp, logged
>> only if the source IP address isn't mapped to the MAC address of interest,
>> perhaps) that is emitted for a reason beyond "it was seen".
>>
>> Would IPFIX, in some incarnation, address this?
>>
>> I'll let you write that :-)
>>
>>
>
> We have both SYSLOG and IPFIX drafts in progress for NATs. They've been held
> up waiting for the NAT MIB to be finished. (The latter is now in the RFCEd
> Q.) We could look at adding these logs if you want, subject to your
> requirements.

Sounds good to me.  :-)

I think that as long as the format of the binding anchor is extensible
and a minimally useful version is readily available that should
suffice to get started.

I don't know what's normal here: either extensible within an existing
type (i.e. adding fields to a mythical 802Dot11BindingAnchor format)
or extensible by creating new types (i.e.
802Dot11BindingAnchorWithRfc5841PacketMood).