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

[Christer Holmberg <[e-mail]>]

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.

Ok, you are probably right.

>> 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.

We simply say that one must re-use the connection, similar to Outbound (and other mechanisms).

Regards,

Christer