From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= <[EMAIL PROTECTED]>
Hi, imagine a UAC sending a request that arrives to UAS from
IP_A:port_A. Later the UAC closes the TCP connection or UDP link
and resend the *same* request (same "branch", "sent-by" and
"method") from IP_B:port_B. If UAC is behind NAT then "Via"
"received" and "rport" parameters would be different in both
identical requests.
Is it a valid retransmission?
I believe that the correct answer is "no".
We've seen plenty of discussion on the difficulties that ensue if we
consider this a valid retransmission.
The fundamental problem is that the two requests will be sent from
different addresses/ports, and so should have different "sent-by"
parts in their first Via headers. The problems happen if we allow
them to have the same branch parameter value.
It is clear from RFC 3261 section 8.1.1.7 that the sent-by part of the
Via and the branch parameter part are added as a unit to the message,
that is, the branch parameter value must be new.
And in every SIP element I've seen, when it changes address, port, or
(more usually) transport to resend a request, it creates a new branch
value.
Now... what makes the problem *interesting* is the slightly different
question:
Hi, imagine a UAC sending a request that arrives to UAS from
IP_A:port_A. Later the UAC closes the TCP connection or UDP link
and resend the *same* request (same "branch", "sent-by" and
"method") from IP_A:port_A (again). If UAC is behind NAT then "Via"
"received" and "rport" parameters could be different in both
identical requests because the outgoing port from the NAT is
different. That is, although the UAC *sent* the request from the
same address/port (and so used the same branch value), the
recipient sees it *coming from* a different address/port.
Is it a valid retransmission?
It seems that we must allow this.
The consistent strategies for dealing with this are:
The processes of 18.2.2 uses the *most recent* "received" and "rport"
parameter values that have been seen for this transaction.
If multiple values for "received" and/or "rport" have been seen
for this transaction, 18.2.2 uses only the 4th choice, that is to
send directly to the sent-by address.
The first option seems to provide the most reliability, although it is
subject to spoofing. (Although SIP is otherwise subject to disruption
by any element that can read the contents of passing SIP messages
anyway.)
The second option seems to be more robust against spoofing, but fails
if the sent-by addresses are not globally routable (which will happen
in about 100% of the cases with NATs, since almost all SIP elements
can only process IP addresses as sent-by addresses).
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
