Re: [sipcore] Comments on draft-ietf-sipcore-keep-05

[Adam Roach <[e-mail]>]

  On 10/13/10 10:28 AM, Christer Holmberg wrote:
> Hi,
>
>>>> a) Any downstream SIP entity, beyond the adjacent downstream peer
>>>> node, can modify the Via header identifying the local node
>>>> and thus cause the local node to send keepalives to its adjacent
>>>> peer (at high rates) if the peer does not support
>>> ...
>>> Nothing was added regarding a),because entities can always
>>> check that, before forwarding responses, the the Via header field
>>> hasn't been tempered with.
>> The purpose of the "Security Considerations" section is to
>> warn implementors about things they need to take into
>> consideration to avoid security problems. Shouldn't the
>> document at least suggest that implementations validate the
>> Via header field to prevent this kind of attack?
> Fair enough.
>
> I can add the following text:
>
>     "Downstream SIP entities can modify Via header fields identifying other SIP entities,
>     and cause keepalives to be sent (at hight rates) to entities that do not not support
>     the keepalive mechanism. SIP entities can prevent this, when a SIP response is received,
>     by validating that Via headers have not been modified in a way which would cause such
>     sending of keepalives."

That's good, but I think we can improve it by more clearly calling out 
what the implementations need to look for:

"Downstream SIP entities can modify Via header fields identifying other 
SIP entities,
and cause keepalives to be sent (at high rates) to entities that do not 
not support
the keepalive mechanism. SIP entities can prevent this, when a SIP 
response is received,
by examining their own Via header field to determine that downstream 
entities have
not added a 'keep' parameter or set an existing 'keep' parameter to a 
value not supported
by the implementation."

/a