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

On 08/07/2015 2:39 PM, Fred Baker (fred) wrote:
>
>> On Jul 6, 2015, at 7:08 PM, Erik Kline <ek@google.com> 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.

Tom Taylor
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>