From nobody Mon May 12 11:44:37 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181101A0745 for ; Mon, 12 May 2014 11:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sTsr6mugQp6 for ; Mon, 12 May 2014 11:44:32 -0700 (PDT) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5911A077C for ; Mon, 12 May 2014 11:44:32 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wm4so8546961obc.4 for ; Mon, 12 May 2014 11:44:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9dcbJoBXxvZH0Btt1YAhQHZFuBMkgeAKVCIhcRzDflI=; b=ZQAPf04JsO15OqJkVuNuTaelS/EPeq5Wz9UkCxQvF4+Nyps2p++9HlyH+U4P7p+Xq1 RkIIi+kq3QCvHwK83TMWOObTVV5xqxvF6ipiD2rHhVZz90yDufizwoi2CKbWcgfclDHx QycygLbTOjQYKsQrsrsRut8EmPsOvKei6lrU503DYg4zlTZHwvW62v0yLoKhiftvPvNQ SC1TpIqv82pGS1GvwkEe8KfqI32qSo77my7rQyLmrbgodKT6SFqeY7Hrr8FOvlhw1OyB WrLA3vgkFBAAREVvyvcyQB7F95tB9kQYhkXlgATrwvN9jE89RMJEc/jBZOD/JH9tn41T sUAQ== X-Gm-Message-State: ALoCoQnF9VZDiaXrjg1lKzXXHpfTBtw5WRv0ZLVRO0DxnhGOpVdx4Ho8Pp4fWI2XQ9wrfXch4sza MIME-Version: 1.0 X-Received: by 10.60.92.170 with SMTP id cn10mr5995715oeb.76.1399920266398; Mon, 12 May 2014 11:44:26 -0700 (PDT) Received: by 10.60.136.231 with HTTP; Mon, 12 May 2014 11:44:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 May 2014 20:44:26 +0200 Message-ID: From: Richard Barnes To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=047d7b33d31e31625904f93856bd Archived-At: http://mailarchive.ietf.org/arch/msg/straw/FPj0KqKHQwFCaMeXiJe6mRlC0kQ Cc: draft-ietf-straw-sip-traceroute@tools.ietf.org, straw@ietf.org Subject: Re: [straw] AD review of draft-ietf-straw-sip-traceroute-02 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 18:44:35 -0000 --047d7b33d31e31625904f93856bd Content-Type: text/plain; charset=UTF-8 Hey Hadriel, Are you OK with the below text for 3.2? If so, I'll mark us as agreed, and send this on to LC. --Richard On Fri, Apr 11, 2014 at 10:48 PM, Richard Barnes wrote: > On Fri, Apr 11, 2014 at 4:22 PM, Hadriel Kaplan > wrote: > >> >> On Apr 11, 2014, at 3:29 PM, Richard Barnes wrote: >> >> > If B2BUAs implement this spec as-is, then they'll see Max-Forwards: 0 >> and answer the call -- they don't know whether this is part of a traceroute >> or not. So if a legacy UAC sends out a normal, non-traceroute, INVITE with >> loopback, and it happens to time out at one of these B2BUAs, and the UAC >> doesn't know to check for the Reason header for this value (because it's >> legacy), then it ends up talking to the B2BUA instead of the UAS. >> >> Good point. So that's another benefit then. B2BUAs solve call failure >> problems they didn't even know existed. >> ;) >> >> Actually, getting back to serious mode, that could happen even without >> this draft. Max-Forward handling in B2BUAs has always been undefined >> behavior until the loopback draft, afaik. > > > Good point. I did not have this in mind. > > > > It seems like in order to resolve this, you need to either: >> > 1. Require UACs that use loopback to check for Reason (and thus update >> RFC 6849) >> >> I'm fine with that. Another option is to re-title this draft to be >> "Media-Loopback Usage in SIP" and add some text about that in general too. >> >> >> > 2. Add some consent flag to the INVITE so that the B2BUA can tell >> traceroutes from other INVITEs >> >> It won't help solve the problem you raised fully - it will help if all >> B2BUAs along the path implement this draft, but not if they just implement >> RFC 6849. Because they can still answer calls based on policy, and >> Max-Forwards=0 technically doesn't apply to them as a UAS unless they also >> implement the loopback draft. >> > > How about this in 3.2? > > """ > The mechanism defined in this document could cause B2BUAs to send a 200 > response to an INVITE that is not part of a traceroute. In such cases, the > UAC would believe that it was exchanging media with the end UAS, when in > reality it is talking to an intermediate B2BUA. The UAC can recognize this > situation by examining the Reason header. It is RECOMMENDED that UACs > implementing RFC 6849 perform this check. (Note that this problem is not > introduced by this document, since the behavior of B2BUAs with regard to > Max-Forwards has been undefined until the publication of > [I-D.ietf-straw-b2bua-loop-detection].) > """ > > > >> >> -hadriel >> >> > --047d7b33d31e31625904f93856bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Hadriel,

Are you OK with the below = text for 3.2? =C2=A0If so, I'll mark us as agreed, and send this on to = LC.

--Richard


On Fri, Apr 11, 2014 at 10:48 PM, Richard Ba= rnes <= rlb@ipv.sx> wrote:
On Fri, Apr 11, 2014 at 4:22 PM, Hadriel Kaplan <hadri= el.kaplan@oracle.com> wrote:

On Apr 11, 2014, at 3:29 PM, Richard Barnes <rlb@ipv.sx> wrote:

> If B2BUAs implement this spec as-is, then they'll see Max-Forwards= : 0 and answer the call -- they don't know whether this is part of a tr= aceroute or not. =C2=A0So if a legacy UAC sends out a normal, non-tracerout= e, INVITE with loopback, and it happens to time out at one of these B2BUAs,= and the UAC doesn't know to check for the Reason header for this value= (because it's legacy), then it ends up talking to the B2BUA instead of= the UAS.

Good point. So that's another benefit then. B2BUAs solve call fai= lure problems they didn't even know existed.
;)

Actually, getting back to serious mode, that could happen even without this= draft. Max-Forward handling in B2BUAs has always been undefined behavior u= ntil the loopback draft, afaik.

Good point. =C2=A0I did not have this in mind.
=C2=A0

> It seems like in order to resolve this, you need to either:
> 1. Require UACs that use loopback to check for Reason (and thus update= RFC 6849)

I'm fine with that. =C2=A0Another option is to re-title this draf= t to be "Media-Loopback Usage in SIP" and add some text about tha= t in general too.


> 2. Add some consent flag to the INVITE so that the B2BUA can tell trac= eroutes from other INVITEs

It won't help solve the problem you raised fully - it will help i= f all B2BUAs along the path implement this draft, but not if they just impl= ement RFC 6849. Because they can still answer calls based on policy, and Ma= x-Forwards=3D0 technically doesn't apply to them as a UAS unless they a= lso implement the loopback draft.

How about this in 3.2?
"""
The mechanism defined in this docu= ment could cause B2BUAs to send a 200 response to an INVITE that is not par= t of a traceroute. =C2=A0In such cases, the UAC would believe that it was e= xchanging media with the end UAS, when in reality it is talking to an inter= mediate B2BUA. =C2=A0The UAC can recognize this situation by examining the = Reason header. =C2=A0It is RECOMMENDED that UACs implementing RFC 6849 perf= orm this check. =C2=A0(Note that this problem is not introduced by this doc= ument, since the behavior of B2BUAs with regard to Max-Forwards has been un= defined until the publication of [I-D.ietf-straw-b2bua-loop-detection].) = =C2=A0
"""

=C2=A0

-hadriel



--047d7b33d31e31625904f93856bd--