2008/9/14 Valentin Nechayev <[EMAIL PROTECTED]>:
>> 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
>
>> The "security" offered by point 2 (matching the sent-by) is really
>> inefficient.
> I understand you, but please don't name it "security". Transaction
> matching rules don't give real security, they protect against
> non-intentional collisions.
Ok, I just say "security" since 17.2.3 says also "malicious":
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.
>> 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.
>
> This have some sense (but we shall say again - not in security
> context). Imagine two different NATs and two agents behind them,
> both on address 192.168.1.1, and with monotonic branch numeration
> (z9hG4bK1, z9hG4bK2, z9hG4bK3...) If rule is "compare sent-by",
> their branches will mix.
It expected that branch value is so random and big that it can't be
repeated, isn't? However I think we can expect that there will be
never two identical branch values coming from same public IP at the
same time.
> Correct matching shall take all four
> known identifiers (sent-by.host, sent-by.port, received, rport),
> and I'm unsure it was really correct to drop all another
> identifiers from matching (according to RFC2543);
> as minimum, we
> can add call-id, from_tag and CSeq number to matching, because
> none other rule allows to change them inside transaction.
Sure, but wouldn't make it too much "expensive"?
Thanks a lot.
--
Iñaki Baz Castillo
<[EMAIL PROTECTED]>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
