I am in agreement here. There are plenty of ways to hijack a registration without forging a flow-token. We could just remove the entire Record-Route/Path stack (depending on whether we're hijacking a dialog, or a registration), and substitute one of our own, bypassing any logic at the proxies entirely. If the network is set up in such a way that doing so would prevent requests from being successfully forwarded, we could always remove the flow-token from the last hop, and insert a Record-Route/Path header field value that would cause stuff to be routed anywhere we please.

I suppose if the edge-proxy _only_ accepts Route headers with flow tokens (ie, Route headers without will just cause the request to fail), and bypassing the edge-proxy is impossible (ie, the network, including endpoints, is configured to forward all traffic to the edge proxy regardless of what is in the Route headers), cryptographic protection of flow tokens would help. But, in the general case, it will not afford us any meaningful protection. We need to rely on something like TLS (which, conveniently enough, outbound makes it easy to do).

Best regards,
Byron Campen


DRAGE, Keith (Keith) wrote:
(As WG chair)
We now have a new version of outbound. There hasn't exactly been a
flurry of comments since it was posted - does that mean it is now ready
for WGLC.
It has agenda time at the next IETF meeting, with a view to starting
WGLC not long after that meeting. If you believe there are issues with the current version of this document, then you need to post them to the
list, so that they can be either resolved there, or addressed in the
meeting.

I never received an explanation of what kind of attacks could be avoided by an edge proxy using an algorithm that generates flow tokens that "cannot be modified by attackers" (section 5.2 of outbound-09).

This was the last e-mail in the thread the last time I brought it up on the list :

http://www1.ietf.org/mail-archive/web/sip/current/msg18336.html.

This leads me to think that either

  1) the security threats haven't been addressed properly

or

2) that there in fact was no security threat so the requirement for an edge proxy to generate flows that "cannot be modified by attackers"
     is just unnecessary, and should therefor be removed
or

3) there really _is_ something that gets significantly better by this
     requirement, and it should simply be explained in the draft.

/Fredrik


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to