Subject: Re: [MMUSIC] Continued WG interest inSDPoffer/answerwithmiddleboxes?

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 1 Apr 2011 17:42:21 +0530

Does 3GPP have similar issues in getting signaling protocols that
operate on the media path (ICE, DTLS etc) though their SBCs? Do they
have any recommendations to make them work better?

thanks,
Muthu 

|-----Original Message-----
|From: Christer Holmberg [mailto:[email-masked]]
|Sent: Friday, April 01, 2011 12:28 PM
|To: Muthu ArulMozhi Perumal (mperumal); Hadriel Kaplan; mmusic
|Subject: RE: [MMUSIC] Continued WG interest
inSDPoffer/answerwithmiddleboxes?
|
|Hi,
|
|>The main goal of the draft as it seems to claim is to
|>describe the desirable behaviors of middleboxes and signaling
|>protocols that operate on the media path, to aid in
|>firewall/NAT traversal. It looks like an extension of RFC
|>3303 whose focus is also firewall and NAT traversal
|>use-cases. The draft claims that the architecture/functions
|>it describes is used in IMS and specified in 3GPP, TISPAN and
|>PacketCable specs -- if it true, then this is where the
|>recommendations in the draft would be useful I think.
|
|3GPP already specifies NAT traversal etc behavior for their "SBCs".
|
|Regards,
|
|Christer
|
|> However, it doesn't look it would be useful for all B2BUA/SBC
|> use-cases/deployments -- if we want to make it, then I think
|> it would be a scope creep.
|>
|> Muthu
|>
|> |-----Original Message-----
|> |From: [email-masked] [mailto:[email-masked]] On
|> Behalf Of Hadriel Kaplan
|> |Sent: Friday, April 01, 2011 5:42 AM
|> |To: mmusic
|> |Subject: Re: [MMUSIC] Continued WG interest inSDP
|> offer/answerwithmiddleboxes?
|> |
|> |
|> |Howdy,
|> |I read the draft, and also found the use of the term "ALG" to be
|> confusing and annoying.  It's not
|> |just rfc3303 which defines an ALG as being in a inline/NAT
|> type device
|> - lots of the user market uses
|> |the term ALG for inline type as well. (it's basically a derogatory
|> term)  One "SBC" vendor I know of
|> |arguably had a real SIP ALG, but they went defunct years ago.
|> |
|> |Then again, the drawings actually show the SIP-ALG+middlebox not
|> changing the SDP at all, so maybe
|> |they do mean ALG.
|> |
|> |But anyway... I don't mean to sound negative, but what's the
|> purpose of
|> this document?  What do we
|> |think it's going to achieve if it's published as an RFC?
|> |The only "output" of this document are four "preliminary
|> recommendations".  Of those four, I'd argue
|> |three of them are now wrong or misleading, and the remaining one is
|> unlikely to occur/help.  It also
|> |claims to describe the impact on ICE, but doesn't; claims to propose
|> mechanisms to mitigate latching,
|> |but doesn't; doesn't describe the issues with middleboxes
|> and forked or
|> moved calls on early in-band
|> |media signaling; and uses terminology from ancient history (ie, RFC
|> 3303).
|> |
|> |So what's the point of this doc again?
|> |
|> |-hadriel
|> |
|> |
|> |
|> |On Mar 31, 2011, at 10:13 AM, Dan Wing wrote:
|> |
|> |>> -----Original Message-----
|> |>> From: Muthu ArulMozhi Perumal (mperumal)
|> [mailto:[email-masked]]
|> |>> Sent: Thursday, March 31, 2011 1:01 PM
|> |>> To: Dan Wing (dwing); Parthasarathi R (partr); DRAGE,
|> Keith (Keith);
|> |>> Christer Holmberg; Flemming Andreasen (fandreas); mmusic
|> |>> Subject: RE: [MMUSIC] Continued WG interest in SDP
|> |>> offer/answerwithmiddleboxes?
|> |>>
|> |>> I agree with your interpretation of what an SBC is. However, the
|> reason
|> |>> why I don't find anything wrong in the use of ALG in
|> |>> draft-ietf-mmusic-media-path-middleboxes is because it describes
|> |>> firewall and NAT traversal functions that are typically
|> implemented
|> as
|> |>> ALGs, except that these functions are decoupled into a
|> MIDCOM agent
|> and
|> |>> a middle box. In addition RFC 3303 goes on to say
|> (section 2.8) that
|> |>> MIDCOM agents are entities performing ALG functions, logically
|> external
|> |>> to a middlebox. It even says these agents can reside on a proxy.
|> |>> Perhaps, draft-ietf-mmusic-media-path-middleboxes can replace the
|> ALG
|> |>> in
|> |>> Figure 1 with "ALG/B2BUA/SBC" -- should cause any issues for the
|> draft
|> |>> I think.
|> |>
|> |> If Figure 1 was modified to show a NAT or firewall, it could
|> reasonably
|> |> use the term ALG with those devices.
|> |>
|> |> But when showing an SBC, which is smack in the middle of
|> Figure 1, it
|> |> cannot accurately call the SBC a "SIP ALG", as it does right now.
|> |>
|> |> -d
|> |>
|> |>
|> |>> Muthu
|> |>>
|> |>> |-----Original Message-----
|> |>> |From: Dan Wing (dwing)
|> |>> |Sent: Wednesday, March 30, 2011 2:52 PM
|> |>> |To: Muthu ArulMozhi Perumal (mperumal); Parthasarathi R (partr);
|> |>> 'DRAGE, Keith (Keith)'; 'Christer
|> |>> |Holmberg'; Flemming Andreasen (fandreas); 'mmusic'
|> |>> |Subject: RE: [MMUSIC] Continued WG interest in SDP
|> |>> offer/answerwithmiddleboxes?
|> |>> |
|> |>> |> -----Original Message-----
|> |>> |> From: Muthu ArulMozhi Perumal (mperumal)
|> [mailto:[email-masked]]
|> |>> |> Sent: Tuesday, March 29, 2011 3:58 PM
|> |>> |> To: Parthasarathi R (partr); DRAGE, Keith (Keith); Christer
|> |>> Holmberg;
|> |>> |> Dan Wing (dwing); Flemming Andreasen (fandreas); mmusic
|> |>> |> Subject: RE: [MMUSIC] Continued WG interest in SDP
|> |>> |> offer/answerwithmiddleboxes?
|> |>> |>
|> |>> |> It looks to me that draft-ietf-mmusic-media-path-middleboxes
is
|> just
|> |>> an
|> |>> |> extension of RFC 3303 -- while the later describes the
|> middlebox
|> |>> |> communication architecture and framework, the former describes
|> some
|> |>> of
|> |>> |> the desirable behaviors of these middleboxes and protocols
that
|> |>> operate
|> |>> |> on the media path unspecified in the later.  RFC 3303 defines
|> what
|> |>> an
|> |>> |> ALG is and it doesn't forbid packets being addressed to the
ALG
|> at
|> |>> the
|> |>> |> IP layer.
|> |>> |>
|> |>> |> <snip>
|> |>> |> 2.6. ALG
|> |>> |> Application Level Gateways (ALGs) are entities that
|> possess the
|> |>> |> application specific intelligence and knowledge of an
|> associated
|> |>> |> middlebox function.  An ALG examines application traffic in
|> transit
|> |>> |> and assists the middlebox in carrying out its function.
|> |>> |>
|> |>> |> ALGs are different from proxies.  ALGs are not visible to
|> end-hosts,
|> |>> |> unlike the proxies which are relay agents terminating sessions
|> with
|> |>> |> both end-hosts.  ALGs do not terminate sessions with
|> either end-
|> |>> host.
|> |>> |> Instead, ALGs examine, and optionally modify,
|> application payload
|> |>> |> content to facilitate the flow of application traffic
|> through a
|> |>> |> middlebox.
|> |>> |>
|> |>> |> 2.8. MIDCOM Agents
|> |>> |> MIDCOM agents are entities performing ALG functions, logically
|> |>> |> external to a middlebox.
|> |>> |>
|> |>> |> The packets may be addressed to the agent node at the IP
layer.
|> |>> |> Alternatively they may not be addressed to the agent node, but
|> may
|> |>> be
|> |>> |> constrained by other factors to flow through it.
|> |>> |> </snip>
|> |>> |>
|> |>> |> So, I don't see anything wrong in the use of ALG in
|> |>> |> draft-ietf-mmusic-media-path-middleboxes, unless we
|> plan to make
|> |>> |> changes to how RFC 3303 describes it.
|> |>> |
|> |>> |3303 is quite clear, in exactly the text you quoted in the
|> paragraph
|> |>> |starting with "ALGs are different from proxies", that
|> ALGs aren't
|> |>> |visible to hosts and ALGs don't terminate sessions.
|> |>> |
|> |>> |An SBC is certainly visible to the end host, for both the SIP
|> |>> |signaling and the RTP media -- the end host is sending
|> packets to
|> |>> |the SBC's IP address and receiving packets from the SBC's IP
|> |>> |address.
|> |>> |
|> |>> |-d
|> |>> |
|> |>> |
|> |>> |> Muthu
|> |>> |>
|> |>> |> |-----Original Message-----
|> |>> |> |From: [email-masked]
[mailto:[email-masked]]
|> On
|> |>> |> Behalf Of Parthasarathi R (partr)
|> |>> |> |Sent: Wednesday, March 16, 2011 6:15 PM
|> |>> |> |To: DRAGE, Keith (Keith); Christer Holmberg; Dan Wing
(dwing);
|> |>> |> Flemming
|> |>> |> Andreasen (fandreas); mmusic
|> |>> |> |Subject: Re: [MMUSIC] Continued WG interest in SDP
|> |>> |> offer/answerwithmiddleboxes?
|> |>> |> |
|> |>> |> |Keith,
|> |>> |> |
|> |>> |> |Sorry in case "media" word in my mail mislead you.
|> Dan explains
|> in
|> |>> |> |another mail thread
|> |>> |>
|> |(http://www.ietf.org/mail-archive/web/mmusic/current/msg08577.html)
|> |>> |> why
|> |>> |> |SIP ALG is not appropriate and B2BUA is more appropriate for
|> this
|> |>> |> draft.
|> |>> |> |
|> |>> |> |
|> |>> |> |Fig 1 of
|> draft-ietf-mmusic-media-path-middleboxes-03.txt exactly
|> |>> fits
|> |>> |> |your definition of B2BUA as it involves only SIP &
|> SDP and media
|> is
|> |>> |> |defined as middlebox.
|> |>> |> |
|> |>> |> |I have mentioned as kind of B2BUA because the draft
|> concentrates
|> on
|> |>> |> |callflow where one side of B2BUA acts as UAC and other side
|> always
|> |>> |> acts
|> |>> |> |as UAS. IMO, the draft currently does not address B2BUA 3PCC
|> |>> callflows
|> |>> |> |specific issues. In the current scope of draft is
|> continued for
|> the
|> |>> |> |draft, the new definition may be required or draft text has
to
|> |>> clarify
|> |>> |> |the scope.
|> |>> |> |
|> |>> |> |Thanks
|> |>> |> |Partha
|> |>> |> |
|> |>> |> |-----Original Message-----
|> |>> |> |From: DRAGE, Keith (Keith)
|> [mailto:[email-masked]]
|> |>> |> |Sent: Wednesday, March 16, 2011 5:33 PM
|> |>> |> |To: Parthasarathi R (partr); Christer Holmberg; Dan Wing
|> (dwing);
|> |>> |> |Flemming Andreasen (fandreas); mmusic
|> |>> |> |Subject: RE: [MMUSIC] Continued WG interest in SDP
|> offer/answer
|> |>> |> |withmiddleboxes?
|> |>> |> |
|> |>> |> |The only definition of B2BUA that I know of comes in RFC 3261
|> (sort
|> |>> |> of)
|> |>> |> |where the scope is limited to SIP. So a UA acts in
|> one or more
|> |>> |> |directions as a SIP UA. Whatever else it does is outside the
|> |>> |> definition.
|> |>> |> |That I believe matches with what Christer is saying.
|> |>> |> |
|> |>> |> |If you want something that defines what it does with
|> media, then
|> |>> you
|> |>> |> |need something that defines that, but using the term
|> B2BUA to do
|> |>> that
|> |>> |> is
|> |>> |> |probably not the best choice.
|> |>> |> |
|> |>> |> |Regards
|> |>> |> |
|> |>> |> |Keith
|> |>> |> |
|> |>> |> |> -----Original Message-----
|> |>> |> |> From: [email-masked]
|> [mailto:[email-masked]]
|> On
|> |>> |> |> Behalf Of Parthasarathi R (partr)
|> |>> |> |> Sent: 15 March 2011 09:54
|> |>> |> |> To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen
|> |>> |> |> (fandreas); mmusic
|> |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP
|> offer/answer
|> |>> with
|> |>> |> |> middleboxes?
|> |>> |> |>
|> |>> |> |> Christer,
|> |>> |> |>
|> |>> |> |> AFAIK, There is no restriction in terms of SIP
|> B2BUA to handle
|> |>> |> |> signaling only and it is upto the implementation to decide.
|> Also,
|> |>> |> this
|> |>> |> |
|> |>> |> |> draft does not have restriction that SIP B2BUA and media
|> server
|> |>> has
|> |>> |> to
|> |>> |> |
|> |>> |> |> be co-exist in the same device. The draft talks about the
|> |>> scenario
|> |>> |> |> wherein SIP B2BUA communicates with media server
|> using Megaco
|> |>> |> (H.248).
|> |>> |> |>
|> |>> |> |> As I mentioned in other mail thread, ALG does not look
|> |>> appropriate
|> |>> |> and
|> |>> |> |
|> |>> |> |> the draft is talking only about the specific type
|> of B2BUA. In
|> |>> real
|> |>> |> |> deployment, Few vendors named these sort of B2BUA
|> as "Session
|> |>> Border
|> |>> |> |> Controller or SBC" as well. SBC may not accepted in IETF as
|> SBC
|> |>> does
|> |>> |> |> lot more. In case there is a need to have different name
for
|> |>> these
|> |>> |> |> kind of SIP B2BUA entity to avoid the confusion, Let us
work
|> it
|> |>> out.
|> |>> |> |>
|> |>> |> |> Thanks
|> |>> |> |> Partha
|> |>> |> |>
|> |>> |> |> -----Original Message-----
|> |>> |> |> From: [email-masked]
|> [mailto:[email-masked]]
|> On
|> |>> |> |> Behalf Of Christer Holmberg
|> |>> |> |> Sent: Tuesday, March 15, 2011 12:14 PM
|> |>> |> |> To: Dan Wing (dwing); Flemming Andreasen
|> (fandreas); 'mmusic'
|> |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP
|> offer/answer
|> |>> with
|> |>> |> |> middleboxes?
|> |>> |> |>
|> |>> |> |>
|> |>> |> |> Hi Dan,
|> |>> |> |>
|> |>> |> |> In my definition of an ALG packets can be sent
|> directly to its
|> IP
|> |>> |> |> address.
|> |>> |> |>
|> |>> |> |> In my opinion, SIP B2BUA only focuses on SIP, while an ALG
|> also
|> |>> |> |> focuses on other things, like media. A SIP ALG
|> contains a SIP
|> |>> B2BUA.
|> |>> |> |>
|> |>> |> |> Regards,
|> |>> |> |>
|> |>> |> |> Christer
|> |>> |> |>
|> |>> |> |> -----Original Message-----
|> |>> |> |> From: [email-masked]
|> [mailto:[email-masked]]
|> On
|> |>> |> |> Behalf Of Dan Wing
|> |>> |> |> Sent: 15. maaliskuuta 2011 4:39
|> |>> |> |> To: 'Flemming Andreasen'; 'mmusic'
|> |>> |> |> Subject: Re: [MMUSIC] Continued WG interest in SDP
|> offer/answer
|> |>> with
|> |>> |> |> middleboxes ?
|> |>> |> |>
|> |>> |> |> The draft uses the term "SIP ALG", which at least
|> does not fit
|> my
|> |>> |> |> definition of an ALG.  An ALG doesn't have packets sent
|> directly
|> |>> to
|> |>> |> |> its IP address; it does its job stealthily without
awareness
|> of
|> |>> one
|> |>> |> |> (or
|> |>> |> |> both) of the sessoin endpoints.  In contrast, the function
|> |>> described
|> |>> |> |> in draft-ietf-mmusic-media-path-middleboxes
|> |>> |> |> is different -- packets are always sent to the IP address
of
|> the
|> |>> SIP
|> |>> |> |> "ALG", and packets are sent from the IP address of the SIP
|> "ALG".
|> |>> |> |> This functionality is most often called a "server"
|> |>> |> |> or a "proxy" -- not an ALG.
|> |>> |> |>
|> |>> |> |> This distinction is important because this draft is closely
|> |>> related
|> |>> |> to
|> |>> |> |
|> |>> |> |> functions common in NATs, which _do_ sometimes have
|> SIP ALGs
|> |>> |> |> implemented in them.
|> |>> |> |>
|> |>> |> |> So ... can we change "SIP ALG" to something like "SIP
proxy"
|> |>> |> |> or "SIP user agent" or "SIP Back-to-Back User
|> Agent"?  Really,
|> it
|> |>> is
|> |>> |> a
|> |>> |> |
|> |>> |> |> B2BUA, at least as best I understand the definition of a
|> B2BUA,
|> |>> so
|> |>> |> |> B2BUA seems best.
|> |>> |> |>
|> |>> |> |> d
|> |>> |> |>
|> |>> |> |>
|> |>> |> |> > -----Original Message-----
|> |>> |> |> > From: [email-masked]
|> [mailto:[email-masked]]
|> |>> On
|> |>> |> |> > Behalf Of Flemming Andreasen
|> |>> |> |> > Sent: Thursday, March 10, 2011 6:15 PM
|> |>> |> |> > To: mmusic
|> |>> |> |> > Subject: [MMUSIC] Continued WG interest in SDP
|> offer/answer
|> |>> with
|> |>> |> |> > middleboxes ?
|> |>> |> |> >
|> |>> |> |> > We currently have a MMUSIC milestone for
|> "considerations for
|> |>> using
|> |>> |> |> > SDP
|> |>> |> |>
|> |>> |> |> > offer/answer with middleboxes". The latest draft
|> for this WG
|> |>> item
|> |>> |> is
|> |>> |> |> >
|> |>> |> |> >      draft-ietf-mmusic-media-path-middleboxes-03.txt
|> |>> |> |> >
|> |>> |> |> > which expired in January 2011. There hasn't been much
|> |>> discussion
|> |>> |> on
|> |>> |> |> > this topic for a while, and the current draft authors are
|> not
|> |>> |> |> > planning
|> |>> |> |>
|> |>> |> |> > continued work on the draft, so we need new authors if we
|> are
|> |>> to
|> |>> |> |> > continue with this WG item. Please let us know if
|> |>> |> |> > 1) You are still interested in this deliverable
|> |>> |> |> > 2) You are willing to actively contribute to and/or
author
|> this
|> |>> |> |> > document.
|> |>> |> |> >
|> |>> |> |> > Thanks
|> |>> |> |> >
|> |>> |> |> >          Flemming & Miguel [MMUSIC chairs]
|> |>> |> |> >
|> |>> |> |> >
|> |>> |> |> > _______________________________________________
|> |>> |> |> > mmusic mailing list
|> |>> |> |> > [email-masked]
|> |>> |> |> > https://www.ietf.org/mailman/listinfo/mmusic
|> |>> |> |>
|> |>> |> |> _______________________________________________
|> |>> |> |> mmusic mailing list
|> |>> |> |> [email-masked]
|> |>> |> |> https://www.ietf.org/mailman/listinfo/mmusic
|> |>> |> |> _______________________________________________
|> |>> |> |> mmusic mailing list
|> |>> |> |> [email-masked]
|> |>> |> |> https://www.ietf.org/mailman/listinfo/mmusic
|> |>> |> |> _______________________________________________
|> |>> |> |> mmusic mailing list
|> |>> |> |> [email-masked]
|> |>> |> |> https://www.ietf.org/mailman/listinfo/mmusic
|> |>> |> |_______________________________________________
|> |>> |> |mmusic mailing list
|> |>> |> [email-masked]
|> |>> |> |https://www.ietf.org/mailman/listinfo/mmusic
|> |>
|> |> _______________________________________________
|> |> mmusic mailing list
|> |> [email-masked]
|> |> https://www.ietf.org/mailman/listinfo/mmusic
|> |
|> |_______________________________________________
|> |mmusic mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/mmusic
|> _______________________________________________
|> mmusic mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/mmusic
|>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 1 Apr 2011 08:16:10 -0400

On Mar 31, 2011, at 10:48 PM, Muthu ArulMozhi Perumal (mperumal) wrote:

> The main goal of the draft as it seems to claim is to describe the
> desirable behaviors of middleboxes and signaling protocols that operate
> on the media path, to aid in firewall/NAT traversal. It looks like an
> extension of RFC 3303 whose focus is also firewall and NAT traversal
> use-cases. The draft claims that the architecture/functions it describes
> is used in IMS and specified in 3GPP, TISPAN and PacketCable specs -- if
> it true, then this is where the recommendations in the draft would be
> useful I think.

When you say "to aid in firewall/NAT traversal", I assume you mean when the SIP+middlebox device *is* the firewall/NAT, right?  You do NOT mean when a SIP+middlebox device is out in the network, helping the UA traverse a Firewall/NAT in-between it and the UA? (what is normally called "Hosted NAT Traversal" or "Far-end NAT traversal" by vendors)

I ask because the former case of being the NAT is not the same as the latter case.  Latching and most of the policies described in this draft do not typically apply to the former case, but do to the latter.  ICE behaves differently for the two cases.  SBCs, as well as the 3GPP and TISPAN variants, are of the latter variety, not the former.  And they don't need an RFC to tell them anything, because it's not something they don't already know.  What's worse, it's actually wrong or misleading in some of its recommendations.

The draft conflates the two cases, probably because RFC 3303 did as well because it is a really old RFC from back when the whole SIP middlebox market began.  And the draft is wrong about ICE because it was written before ICE was published.  "Extending" 3303 with this draft is useless at best, or harmful at worst, unless it gets a serious re-write.  My 2 cents anyway.

-hadriel

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 1 Apr 2011 14:47:15 +0200

For ICE: 3GPP terminates it as an SBC.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Muthu ArulMozhi Perumal (mperumal)
Sent: Friday, April 01, 2011 2:12 PM
To: Christer Holmberg; Hadriel Kaplan; mmusic
Subject: Re: [MMUSIC] Continued WG interest
inSDPoffer/answerwithmiddleboxes?

thanks,
Muthu 

|-----Original Message-----
|From: Christer Holmberg [mailto:[email-masked]]
|Sent: Friday, April 01, 2011 12:28 PM
|To: Muthu ArulMozhi Perumal (mperumal); Hadriel Kaplan; mmusic
|Subject: RE: [MMUSIC] Continued WG interest
inSDPoffer/answerwithmiddleboxes?
|
|Hi,
|
|>The main goal of the draft as it seems to claim is to describe the 
|>desirable behaviors of middleboxes and signaling protocols that 
|>operate on the media path, to aid in firewall/NAT traversal. It looks 
|>like an extension of RFC
|>3303 whose focus is also firewall and NAT traversal use-cases. The 
|>draft claims that the architecture/functions it describes is used in 
|>IMS and specified in 3GPP, TISPAN and PacketCable specs -- if it true,

|>then this is where the recommendations in the draft would be useful I 
|>think.
|
|3GPP already specifies NAT traversal etc behavior for their "SBCs".
|
|Regards,
|
|Christer
|
|> However, it doesn't look it would be useful for all B2BUA/SBC 
|> use-cases/deployments -- if we want to make it, then I think it would

|> be a scope creep.
|>
|> Muthu
|>

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 2 Apr 2011 08:37:06 -0400

ICE doesn't go through 3GPP systems, and DTLS/SRTP is non-existent in 3GPP networks.
-hadriel

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 6 Apr 2011 16:01:03 +0530

|When you say "to aid in firewall/NAT traversal", I assume 
|you mean when the SIP+middlebox device *is* the firewall/NAT, 
|right?  You do NOT mean when a SIP+middlebox device is out in 
|the network, helping the UA traverse a Firewall/NAT in-between 
|it and the UA? (what is normally called "Hosted NAT Traversal" 
|or "Far-end NAT traversal" by vendors)

Yes, primarily the former use-case. However, the draft also described
the later (see section 5).

|I ask because the former case of being the NAT is not the same
|as the latter case.  Latching and most of the policies described
|in this draft do not typically apply to the former case, but do 
|to the latter.

The draft does make this clear in section 5.1:

<snip>
If the middlebox supports the traversal of residential NATs, it applies
a technique called "media latching": The destination IP address of
packets forwarded by the middlebox in the outbound direction is derived
from the source IP address of packets received in the inbound direction.
This overrides a destination address possibly configured by the MIDCOM
agent.
</snip>

Overall, IMHO the recommendations in the draft seem useful to the kind
of architecture/problems it describes. However, whether it applies to
current deployments is something I am not sure. The draft claims such
middleboxes are for instance the TISPAN A-BGF/C-BGF/I-BGF and the 3GPP
IMS Access Gateway..perhaps this was long ago?

Muthu

|-----Original Message-----
|From: Hadriel Kaplan [mailto:[email-masked]]
|Sent: Friday, April 01, 2011 5:46 PM
|To: Muthu ArulMozhi Perumal (mperumal)
|Cc: mmusic
|Subject: Re: [MMUSIC] Continued WG interest
inSDPoffer/answerwithmiddleboxes?
|
|
|On Mar 31, 2011, at 10:48 PM, Muthu ArulMozhi Perumal (mperumal) wrote:
|
|> The main goal of the draft as it seems to claim is to describe the
|> desirable behaviors of middleboxes and signaling protocols that
operate
|> on the media path, to aid in firewall/NAT traversal. It looks like an
|> extension of RFC 3303 whose focus is also firewall and NAT traversal
|> use-cases. The draft claims that the architecture/functions it
describes
|> is used in IMS and specified in 3GPP, TISPAN and PacketCable specs --
if
|> it true, then this is where the recommendations in the draft would be
|> useful I think.
|
|When you say "to aid in firewall/NAT traversal", I assume you mean when
the SIP+middlebox device *is*
|the firewall/NAT, right?  You do NOT mean when a SIP+middlebox device
is out in the network, helping
|the UA traverse a Firewall/NAT in-between it and the UA? (what is
normally called "Hosted NAT
|Traversal" or "Far-end NAT traversal" by vendors)
|
|I ask because the former case of being the NAT is not the same as the
latter case.  Latching and most
|of the policies described in this draft do not typically apply to the
former case, but do to the
|latter.  ICE behaves differently for the two cases.  SBCs, as well as
the 3GPP and TISPAN variants,
|are of the latter variety, not the former.  And they don't need an RFC
to tell them anything, because
|it's not something they don't already know.  What's worse, it's
actually wrong or misleading in some
|of its recommendations.
|
|The draft conflates the two cases, probably because RFC 3303 did as
well because it is a really old
|RFC from back when the whole SIP middlebox market began.  And the draft
is wrong about ICE because it
|was written before ICE was published.  "Extending" 3303 with this draft
is useless at best, or harmful
|at worst, unless it gets a serious re-write.  My 2 cents anyway.
|
|-hadriel

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 6 Apr 2011 13:01:26 +0200

There's a basic issue with the draft related to lacking definitions.
Fig.1 provides the considered network architecture, but the involved entities/functions are not sufficiently defined.
Thus, clause 2 should be extended by terminology for
1) Middlebox
2) MIDCOM agent
3) SIP ALG

The first two terms are loosely defined by a reference to RFC 3234 in clause 1.
However, RFC 3234 is rather a "catalogue" of all possible IP-IP gateway variants, other than an IP router. Such a high-level definition is inappropriate in my understanding.
And therefore: any comparison to TISPAN or 3GPP defined "middleboxes" will fail. Their functionality is precisely given by H.248 profile specifications.

The reference to RFC 3234 could be replaced/extended by RFC 5189, the protocol semantics.
The defined content of the MIDCOM SNMP MIB provides then a more precise reference to supported capabilities.

[BTW: I'm not aware of any MIDCOM middlebox product in operation in IP networks. Or does someone know an example?]

With respect to "SIP ALG" (3), and due to the fact that this discussion is about SDP Offer/Answer:
I could imagine some value of this draft if e.g. the mapping/conversion of SIP-embedded SDP elements to the MIDCOM-Middlebox protocol would be described.
Support of remote NAT-traversal is just one example function.
The existing signalling flows are too high level.

Further: the SDP mapper between SIP call control signalling and MIDCOM middlebox signalling could be again
a) concrete, i.e. specific to RFC 5189, thus a SIP/SDP-to-SNMP mapping function; or
b) generic, independent of any concrete middlebox control protocol.

Albrecht

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Muthu ArulMozhi 
> Perumal (mperumal)
> Sent: Mittwoch, 6. April 2011 12:31
> To: Hadriel Kaplan
> Cc: mmusic
> you mean when 
> |the SIP+middlebox device *is* the firewall/NAT, right?  You 
> do NOT mean 
> |when a SIP+middlebox device is out in the network, helping the UA 
> |traverse a Firewall/NAT in-between it and the UA? (what is normally 
> |called "Hosted NAT Traversal"
> Yes, primarily the former use-case. However, the draft also 
> described the later (see section 5).
> 
> |latter case.  Latching and most of the policies described in 
> this draft 
> |do not typically apply to the former case, but do to the latter.
> 
> If the middlebox supports the traversal of residential NATs, 
> it applies a technique called "media latching": The 
> destination IP address of packets forwarded by the middlebox 
> in the outbound direction is derived from the source IP 
> address of packets received in the inbound direction.
> This overrides a destination address possibly configured by 
> the MIDCOM agent.
> </snip>
> 
> Overall, IMHO the recommendations in the draft seem useful to 
> the kind of architecture/problems it describes. However, 
> whether it applies to current deployments is something I am 
> not sure. The draft claims such middleboxes are for instance 
> the TISPAN A-BGF/C-BGF/I-BGF and the 3GPP IMS Access 
> Gateway..perhaps this was long ago?
> 
> Muthu
> 
> you mean when