Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path

[Paul Kyzivat <[e-mail]>]

Christer Holmberg wrote:
> Hi Paul,
> 
>>> Some proposed new text based on your comment regarding symmetric path.
>> I think the statements you have added below seem reasonable as far as
>> they go, but they only go half way. They say nothing about what the
>> *recipient* of keepalives must do when sending requests. 
> 
> That is meant to be covered by the text I suggetsed for section 4.4. It says that the receiver of keep-alives must send messages towards the sender of those keep-alives using the address and port from where the keep-alives arrived.

I don't think that is sufficient for TCP. AFAIK it actually has to be on 
the same connection. So for instance, if it attempted to open a new 
connection in the reverse direction to the same address and port, it 
would quite probably fail.

>> And I have a strong suspicion this is pretty far along toward reinventing -outbound-.
> 
> I don't agree. Symmetric routing wasn't invented by Outbound. It is used in NAT scenarios even if you don't use Outbound, in order to ensure that messages pass NATs. 
> 
> For example, entities providing NAT traversal using anchoring/latching use symmetric routing.
> 
> We also already have mechanisms like rport to request symmetric response routing.

In the case of TCP this comes down to connection reuse, which is covered 
by outbound on the edge, and by the connection-reuse draft elsewhere.

I think you are talking about much the same, unless you are restricting 
to UDP.

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> 
> 
>> -----------------
>>
>>>>>> Section 4.2.2:
>>>>>>
>>>>>> IIUC, the keepalive is associated with a flow as defined in 5626.
>>>>>> Hence it isn't appropriate to use this negotiation mechanism on a
>>>>>> registration that doesn't specify a flow. I don't see that stated anywhere.
>>>>>>
>>>>>> (If there was no flow, what would the keepalive state be associated
>>>>>> *with*?)
>>>>> The second paragraph describes the case when outbound is
>>>>> used, and when you do have flows.
>>>>>
>>>>> The generic procedure is described in the first paragraph
>>>>> of the section, and it does not talk about flows - it talks
>>>>> about registrations.
>>>> I don't see how that works (in the non-outbound case):
>>>>
>>>> The purpose of these keepalives is to keep a nat binding open.
>>>> But that is only useful if the neighboring node then uses
>>>> that path to send outbound requests. What is there in the keep draft that even
>>>> *talks* about that?
>>>>
>>>> If the keepalives are sent via TCP, then the neighbor will
>>>> have to use that same TCP connection for outbound requests in order to gain any
>>>> benefit from the keepalive. If the keepalives are send via UDP, then
>>>> the neighbor will have to send requests symmetrically from the
>>>> address/port on which the keepalives are received.
>>> That's a good point.
>>>
>>> I have probably been assuming that the symmetric path usage
>>> is part of the keep-alive mechanism itself, defined in
>>> outbound, so there is no need to repeat that.
>>>
>>> But, I guess that it is actually part of the outbound
>>> mechanism, so we would need to say that it applies also to
>>> entities that are willing to send and/or receive keep-alives.
>>>
>>> -----------------
>>>
>>>> If you were to specify that, wouldn't it begin to duplicate outbound?
>>> It would duplicate that specific requirement of Outbound, yes.
>>>
>>> But, it's still not a duplication of the whole Outbound
>>> mechanism. For example, registrar support is still not required.
>>>
>>> And, the keep mechanism can be used between any two SIP entities.
>> For section 4.3, I suggest the following text:
>>
>>       "A SIP entity that has negotiated sending of keep-alives associated with a registration (registration flow if Outbound is used) MUST be prepared to receive
>>       SIP messages (requests and responses) associated with the registration from the receiver of the keep-alives on the same IP port:address
>>       from where the keep-alives are sent. Likewise, a SIP entity that has negotiated sending of keep-alives associated with a dialog
>>       MUST be prepared to receive SIP messages associated with the dialog from the receiver of the keep-alives on the same IP port:address from
>>       where the keep-alives are sent."
>>
>> For section 4.4, I suggest the following text:
>>
>>       "A SIP entity that has negotiated receiving of keep-alives associated with a registration (registration flow if Outbound is used) MUST
>>       send SIP messages (requests and responses)  associated with the registration towards the sender of the keep-alives using the IP address:port
>>       from where the keep-alives where received. Likewise, a SIP entity that has negotiated receiving of keep-alives associated with a dialog MUST
>>       send SIP messages associated with the dialog towards the sender of the keep-alives using the IP address:port from where the keep-alives where received."
>>
>> Regards,
>>
>> Christer