El Jueves, 30 de Octubre de 2008, Dean Willis escribió: > On Oct 30, 2008, at 2:43 PM, Jiri Kuthan wrote: > > I'm wondering if other WG participants would agree with me that > > "verifying > > who is sending me this SIP request is who he claims to be in the > > simplest > > possible way (i.e., without other protocols and infrastructures) by > > reverse > > lookup" would be an appropriate goal. > > Leaving aside the question of whether the success of the DERIVE RRC > answer's the question you've asked above (I don't think it does; it > merely verifies that the a node reachable at the AOR to which the > request is attributed has particular knowledge of the SIP request in > question), let's ask if we understand the unintended consequences. > > There are fundamental assumptions in this sort of RRC model that the > node initiating the dialog request is in fact reachable by some sort > of AOR, and that this is the AOR that will be presented in the request > as that of its originator. This is not universally true. > > Envision a presence-enabled call controller (PECC) employed by Alice. > Alice wants to call Bob, whenever Alice and Bob are both on-line. > > So PECC subscribes to Alice and Bob. > > Eventually Alice and BOb are both on-line, so PECC sets up the call. > > What's in the From" going to Bob? It's probably Alice's AOR, as PECC > is working on her behalf, and there's some reason to think that Bob is > willing to accept calls from Alice. But PECC cannot REGISTER as Alice, > for obvious reasons. > > Bob uses DERIVE, and sends a SUBSCRIBE to Alice that references the > dialog that is between PECC and Bob. > > Can Alice's UA respond appropriately? I think not. > > There are other ways to construct the type of application I'm talking > about, that might work with DERIVE. Do we want to force a redesign of > SIP applications so that return-routability to the originating AOR is > required? This might not be a bad thing, but I think it is a very > primal thing, and is potentially quite disruptive to application > scenarios. That might be OK, but we need to understand the > consequences before we go down that road.
Hi, While your explanation makes sense, it seems to conclude that the simple mechanism described in DERIVE should not be considered due to some "exotic" scenarios in which it could fail (mostly in presence of border controller). But I'm sure that any other sender verification proposals appearing in this thread (as other drafts) also doesn't cover all the possible scenarios. At least, DERIVE seems useful in most common cases, and it just requires devices supporting RFC 4235. Of course, the presence of border controllers and B2BUA's always break any divine topology full of proxies defined in any RFC. DERIVE is not an exception. So people involved in IETF can accept a simple and feasible solution as the current proposal, or just drop it and wait for other proposals full of certificate usage, bidirectional authentication and more stuff that will be never feasible in the real world. But this is just my opinion. Of course you could be right. Thanks. -- Iñaki Baz Castillo _______________________________________________ Sip mailing list https://www.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
