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

[Paul Kyzivat <[e-mail]>]

Christer Holmberg wrote:
> Hi,
> 
>>>>> 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.
> 
> That is true, and at least from my experience that is also how entities providing NAT traversal (with or without outbound) work.
> 
>>>> 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.
> 
> Yes.
> 
> So, there are two options:
> 
> 1. We say that, for TCP, a connection re-use must be used.
> 2. We mandate the support of the connection re-use spec (RFC 5923).
> 
> I guess the only difference between 1) and 2) is that 2) would require the usage of the "alias" parameter, defined in 5923, while 1) means that support of keep-alive implicitly also indicates support of connection re-use.

While rfc5923 allows bidirectional reuse of a TLS connection, it does 
not for a naked TCP connection. In case of TCP you are forced to open a 
separate connection in each direction, which presumably won't work in 
the cases where this draft is interesting.

> Section 6 talks about connection reuse. But, we will most likely have to modify (or even remove) the section, based on above.
> 
>> I think you are talking about much the same, unless you are restricting to UDP.
> 
> Absolutely not :)

Then perhaps you are talking about something that is impossible.

	Thanks,
	Paul