Hi, RFC 3261 section 17.2.3 says:
------------------------------
The request matches a transaction if:
1. the branch parameter in the request is equal to the one in the
top Via header field of the request that created the
transaction, and
2. the sent-by value in the top Via of the request is equal to the
one in the request that created the transaction, and
3. the method of the request matches the one that created the
transaction, except for ACK, where the method of the request
that created the transaction is INVITE.
This matching rule applies to both INVITE and non-INVITE transactions
alike.
The sent-by value is used as part of the matching process because
there could be accidental or malicious duplication of branch
parameters from different clients.
------------------------------
The "security" offered by point 2 (matching the sent-by) is really
inefficient. As all you know, using UDP the response is sent to the
address in "received" parameter (if it was added) so any malicious
user can send a request from a NATted host with any spooofed sent-by
(since the reply will be sent to the public source address). Also,
using TCP or SCTP the reply is sent using the same connection,
regardless of the sent-by value.
So I really wonder why this kind of pseudo-security is included in RFC
3261, IMHO it would be just better if useless steps and mechanims like
this weren't appear in the 3261.
BTW, some time ago there was here a thread about if a server
transaction should allow retransmissions (requests matching 17.2.3)
from a different address. The conclusion was "no" due to security
reasons (an attacker could forward the replies to him if he sends a
spoofed retransmission of any other request).
So, don't you think that point 2 of 17.2.3 should just dissapear since
it just offers false security? Instead of this I'd prefer to read
something as:
2. the source address of the request is equal to the source
address of the
request that created the transaction.
Am I right? Thanks a lot for comments.
--
Iñaki Baz Castillo
<[EMAIL PROTECTED]>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
