Re: [savi] SAVI FCFS & Logging

[Jean-Michel Combes <[e-mail]>]

Hi,

To move forward the document ASAP, any additional comments about this
topic must be sent before next Tuesday.

Thanks in advance.

Best regards.

JMC.

2011/3/31 Eric Levy-Abegnoli <[e-mail]>:
> Le 31/03/2011 02:18, Jean-Michel Combes a écrit :
>>
>> Hi,
>>
>> I am in favor of the addition of such a text: logging could clearly help.
>> Now, I would like to have feedback from the WG and especially from
>> people implementing SAVI to know if logging could be easily
>> implementing (i.e. with no expensive extra-cost): that would determine
>> whether make that normative or not.
>
> I support the addition. That has been #1 requirement from many organizations
> I dealt with deploying SAVI or IPSG solutions.
> Not particular issue implementation-wise.
> Eric
>>
>> Best regards.
>>
>> JMC.
>>
>> 2011/3/5 Joel M. Halpern<[e-mail]>:
>>>
>>> I asked the SAVI FCFS the question below.  In response they quite
>>> reasonably
>>> asked that I provide text.  Following the note excerpt is the suggestion
>>> on
>>> placement and text.  THe text could include a reference to the savi
>>> threats
>>> document.  I was not sure if that would be helpful, so I left it out.
>>>  Also,
>>> as logging is basically an internal activity, I have written this
>>> suggestion
>>> as non-normative text.
>>>
>>>> El 05/03/11 6:45, Joel M. Halpern escribió:
>>>>>
>>>>> Looking at the traceability issues we raise in the threats document,
>>>>> and looking at the uses I see people wanting to make of SAVI for
>>>>> SLAAC, should we put some descriptive (not normative) text into SAVI
>>>>> FCFS that talks about loggin?
>>>>>
>>>>> I wanted to check with you folks directly before raising this on the
>>>>> list.
>>>>>
>>>>> Thank you,
>>>>> Joel
>>>
>>> I would suggest adding a section between 2.4 and 2.5 (i.e., it would be
>>> 2.5,
>>> and the current 2.5 SAVI enforcement perimeter would become 2.6.)
>>> ---------
>>> 2.x SAVI Logging
>>>
>>> While the primary goal of SAVI is simply to prevent improper use of IP
>>> addresses, a secondary goal is to assist in traceability for determining
>>> who
>>> an imp-roper actor is.  For example, if a remote site reports that a DoS
>>> (or
>>> component of a DDoS) is coming from the SAVI site, SAVI enforcement can
>>> be a
>>> useful component in a response.
>>>
>>> In order to support these and other similar activities, it is a good idea
>>> if
>>> SAVI devices perform logging of the creation, modification, or removal of
>>> address bindings.  Any protocol support, such as SYSLOG support for
>>> sending
>>> those logs to a common server, would be a topic for a future separate
>>> document.
>>> -----
>>> If instead we want to make that normative, we could put a SHOULD in and
>>> put
>>> this in section 3.2.6 instead.
>>>
>>> In addition, it would seem useful to add a short paragraph in the
>>> security
>>> considerations section.  (If Denial of service attacks and Residual
>>> threats
>>> were 4.1 and 4.2, then I would would att this as 4.3 Security Logging)
>>> -------------
>>> In order to improve the integration of SAVI into an overall security
>>> environment, and enable response to additional indirect security issues
>>> which SAVI can help ameliorate, it is helpful if SAVI systems log the
>>> creation, modification, and deletion of binding entries.
>>> ---------
>>> I realize this basically duplicates the 2.x text.  I think it deserves
>>> mention in the security considerations, because it is a security
>>> consideration.  But I don't think that should be the first occurrence.
>>> If the duplication is bothersome, then just use the 2.x text.
>>>
>>> Thank you,
>>> Joel
>>> _______________________________________________
>>> savi mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/savi
>>>
>> _______________________________________________
>> savi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/savi
>>
>
>