Subject: [Ietf-behave] RE: WG Review: Behavior Engineering for Hindrance Avoidance (beha ve) (fwd)

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 24 Sep 2004 16:59:05 -0700 (PDT)

Spencer,

I agree that there are parallels between Session Border Controllers (SBCs)
and NATs - the most striking being that the SIP community is in the same
phase of denial about SBCs that the Internet community once went through
with NATs. People in the SIP community are loathe to specify what an SBC is;
there's just a general sentiment that SBCs are evil intermediaries, and if
we codify them, we'll surely further their adoption. Sounds familiar,
doesn't it.

However else one might "benefit" from a NAT deployment, the primary reason
for the existence of NAT is IPv4 address conservation. It is in this context
that residences, for example, with no particular need for network-layer
policy enforcement, are burdened with NATs. SBCs exist for a number of
reasons - ironically, SBCs are frequently used for firewall/NAT traversal
(since they act as media relays), and if NATs went away, some of the reasons
for SBCs might go away as well. They rewrite the Contact header for two
reasons, generally - as a part of their NAT traversal function, or in order
to maintain their presence as a policy control point for SIP session
signaling. 

I guess on balance, I think the problem of NATs and the problem of SBCs are
separable problems - getting good behavioral guidance for NATs would help a
number of applications (not just VoIP, but things like real-time Internet
gaming, and so on), and might decrease the number of SBCs out there. Maybe
we should say this: BEHAVE should reserve the right to recharter at a later
time to look at other sorts of intermediaries that are harassing real-time
applications on the Internet. For a first morsel to bite off, though, I
think NATs are a mouthful.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Spencer Dawkins [mailto:spencer@xxxxxxxxxxxxx]
> Sent: Friday, September 24, 2004 6:08 AM
> To: iesg@xxxxxxxx
> Cc: IETF Behave Mailing List
> Subject: Re: WG Review: Behavior Engineering for Hindrance Avoidance
> (behave) (fwd)
> 
> 
> Dear IESG,
> 
> On Fri, 17 Sep 2004, The IESG wrote:
> > A new IETF working group has been proposed in the Transport Area. The
IESG has
> > not made any determination as yet. The following description was
submitted,
> > and is provided for informational purposes only. Please send your
comments to
> > the IESG mailing list (iesg@xxxxxxxx) by September 24.
> 
> My apologies for responding at the last second...
> 
> I happen to agree with the current charter, as far as it goes.
> 
> I also note that there's a fascinating discussion (thread starts at 
> http://www1.ietf.org/mail-archive/web/sip/current/msg10349.html on 
> "GRUU and things that rewrite contacts", about the impact of Session 
> Border Controllers on new features in SIP.
> 
> If I understand the meta-goal for BEHAVE, it's "write a BCP so NAT 
> vendors stop breaking VoIP" (since classic TCP-based client-server 
> protocols work passably well on NAT/ALGs).
> 
> BEHAVE declined the privilege (I think correctly) of defining BCP 
> behavior for ALGs in general, but I expect that while BEHAVE 
> is fixing 
> NATs, the Internet will deploy SBCs with behavior just as destructive 
> for VoIP as NATs, and we'll be back doing "Son of BEHAVE" in five 
> years (and arguing whether it's worth doing, because of all the SBCs 
> that are built into wireless APs, etc.). We could sidestep that agony 
> by attacking the problem now (or "immediately after finishing a BCP 
> for NATs", if you are worried about defocusing BEHAVE.
> 
> Maybe BEHAVE isn't the right WG to think about SBCs, but there sure 
> are a lot of BEHAVE participants I recognize from 
> SIP/SIPPING/SIMPLE/XCON... I would hate to see them wasting 
> their time 
> if we move from "can't deploy because of broken NAT behavior" to 
> "can't deploy because of broken SBC behavior".
> 
> Spencer 
> 
> 
>