> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dan Wing > Sent: 29 October 2008 18:45 > To: 'Victor Pascual Ávila' > Cc: [email protected] > Subject: Re: [Sip] submission of a new I-D: "Dialog Event > foRIdentityVErification" > > > > > > -----Original Message----- > > From: Victor Pascual Ávila [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, October 29, 2008 4:16 AM > > To: Dan Wing > > Cc: [email protected] > > Subject: Re: [Sip] submission of a new I-D: "Dialog Event > > foRIdentityVErification" > > > > Hi Dan, > > Please, see my comments inline. > > > > On Wed, Oct 29, 2008 at 4:42 AM, Dan Wing <[EMAIL PROTECTED]> wrote: > > >> 2008/10/28 Dan Wing <[EMAIL PROTECTED]>: > > >> > Here is another return routability check, > > >> > > http://tools.ietf.org/html/draft-wing-sip-e164-rrc-01#section-3.1 > > >> > (My I-D expired due to lack of interest.) > > >> > > >> It uses RFC 4474, certificates... is it really feasible in > > >> this real world? > > > > > > No, it doesn't use RFC4474. The steps merely show where > an RFC4474 > > > signature could be performed. If no RFC4474 signatures are > > > being created, or validated, those steps are the 'null operation' > > > (not performed). Without those steps, it is remarkably similar > > > to DERIVE. > > > > > >> IMHO "Dialog Event foR Identity VErification" is the > more feasible > > >> solution at the moment. > > > > > > The differences are minor. > > > > The Return Routability Check (RRC) determines if a domain rightfully > > 'owns' an E.164 phone number, but DOES NOT prevent an attacker from > > presenting a forged "From" header field. > > > > As an example: > > > > INVITE sip:[EMAIL PROTECTED] SIP/2.0 > > From: +14085551234 > > <sip:[EMAIL PROTECTED];user=phone>;tag=9fxced76sl > > To: Victor <sip:[EMAIL PROTECTED]> > > Call-ID: [EMAIL PROTECTED] > > Contact: <sip:[EMAIL PROTECTED]> > > Content-Type: application/sdp > > Content-Length: ... > > > > [SDP not shown] > > > > Where iptel.org owns the +14085551234 number. > > > > Section 3.2: > > -The SUBSCRIBE should be immediately acknowledged > > -A NOTIFY should be immediately created and sent > > > > > > Moreover IMO: > > - it requires the use of signatures (or RFC4474): see > > Sections 3, 3.1 and 3.2 > > As I said previously: if there is no signature service, this > is the null > operation. The UA is competely incapable of causing or > forcing its domain to > generate an RFC4474 signature, anyway, so it's impossible for a UA to > 'require' such a signature. > > > - it is defined to be used only with e164-based SIP URIs > > > > In short, this is a good document but, as I mentioned before, ONLY > > determines if a domain rightfully 'owns' an E.164 phone number, it > > doesn't ask "are you calling me?" > > Easily added; draft-wing-sip-e164-rrc-01 currently reads: > > 3.2. Authentication Service or Calling Endpoint Operation > > The steps described in this section can be performed by the > authentication service or by the calling endpoint. > > The authentication service or the calling endpoint, upon > receiving a > SUBSCRIBE for the return-routability event package, performs the > following steps: > > 1. The SUBSCRIBE should be immediately acknowledged with a 200 Ok > ^ > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > INSERT "If there is another active INVITE dialog, which has not > received its 200 Ok, then" > > message. > ^ > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > INSERT "If there is not another active INVITE dialog, an error > response is sent (e.g., 4xx), and processing stops." > > 2. A NOTIFY should be immediately created, containing the same > application/return-routability-nonce copied from the SUBSCRIBE. > This NOTIFY contains a To and Request-URI which match > the From of > the SUBSCRIBE. > > 3. This NOTIFY is sent. > > 4. The RFC4474 authentication service, operating at the > domain, will > create a signature over the NOTIFY. This is used by the remote > domain's verification service (see Section 3.1). > > > I'm not interested in having a competing proposal, though, or arguing > nits about which 4xx response code is most appropriate. > > We should be arguing about larger issues, such as the value > of proving > someone is actually originating a call. Without that, we cannot have > reliable whitelists or reliably blacklists, which are the foundations > for authorizing incoming SIP requests. > > I support draft-kuthan-sip-derive-00, and hope the WG can devote > time and energy to improving and standardizing it to work well > across a variety of networks. [JRE] I agree. This must include networks that contain B2BUAs/SBCs.
John _______________________________________________ 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
