Subject: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ?

From: Flemming Andreasen <[email-masked]>
Date: Thu, 10 Mar 2011 21:14:44 -0500

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]

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 11 Mar 2011 11:18:04 +0100

Flemming,

According to my records, this went through WGLC a couple of years ago, so perhaps the silence is due to the fact the WG believes the document is finished. What exactly is the situation - were there unresolved comments from WGLC? I am not offering to contribute actively on this - just curious.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Flemming Andreasen
> Sent: 11 March 2011 02:15
> To: mmusic
> Subject: [MMUSIC] Continued WG interest in SDP offer/answer 
> with middleboxes ?
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 11 Mar 2011 11:46:43 -0500

Good question John. A WGLC was issued back in May 2009, and a few minor 
comments were received on the list. A new version was issued 
subsequently, however I don't know if that resolved all comments. In any 
case, given this was almost two years ago, I think we will need to go 
through this again to move the document forward, and we need a new 
author to drive that as well since the current authors are no longer 
working on the draft, hence the question to the list. My impression is 
that the document is pretty close to being done, so I'm not expecting 
this to be a lot of work or taking a long time, however we need WG 
interest and a few active participants (author + reviewers) to get to 
the finish line.

Thanks

-- Flemming

On 3/11/11 5:18 AM, Elwell, John wrote:
>
> Flemming,
>
> According to my records, this went through WGLC a couple of years ago, 
> so perhaps the silence is due to the fact the WG believes the document 
> is finished. What exactly is the situation - were there unresolved 
> comments from WGLC? I am not offering to contribute actively on this - 
> just curious.
>
> John
>
>

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 11 Mar 2011 11:47:24 -0500

I am willing to be a reviewer - since I have worked on middle-boxes in a past life.

Peter Musgrave

On 2011-03-11, at 11:46 AM, Flemming Andreasen wrote:

> Good question John. A WGLC was issued back in May 2009, and a few minor comments were received on the list. A new version was issued subsequently, however I don't know if that resolved all comments. In any case, given this was almost two years ago, I think we will need to go through this again to move the document forward, and we need a new author to drive that as well since the current authors are no longer working on the draft, hence the question to the list. My impression is that the document is pretty close to being done, so I'm not expecting this to be a lot of work or taking a long time, however we need WG interest and a few active participants (author + reviewers) to get to the finish line. 
> 
> Thanks 
> 
> -- Flemming 
> 
> 
>

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Fri, 11 Mar 2011 12:10:43 -0500

Now that I know Peter is reviewing, I'd be willing to author and get it across the finish line.  ;-)

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 12 Mar 2011 08:40:39 +0100

Hi,

I am willing to review.

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Flemming Andreasen [[email-masked]]
Sent: Friday, March 11, 2011 6:46 PM
To: Elwell, John
Cc: mmusic
Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with middleboxes ?

Thanks

-- Flemming

Flemming,

John

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

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 14 Mar 2011 12:13:38 +0530

I'm willing to be reviewer of this draft as I'm working in one such
middle-box
 
Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Gonzalo Salgueiro (gsalguei)
Sent: Friday, March 11, 2011 10:41 PM
To: Peter Musgrave
Cc: Flemming Andreasen (fandreas); John Elwell; mmusic
Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer
withmiddleboxes ?

Now that I know Peter is reviewing, I'd be willing to author and get it
across the finish line.  ;-) 

Gonzalo

	I am willing to be a reviewer - since I have worked on
middle-boxes in a past life. 

	Peter Musgrave

		Good question John. A WGLC was issued back in May 2009,
and a few minor comments were received on the list. A new version was
issued subsequently, however I don't know if that resolved all comments.
In any case, given this was almost two years ago, I think we will need
to go through this again to move the document forward, and we need a new
author to drive that as well since the current authors are no longer
working on the draft, hence the question to the list. My impression is
that the document is pretty close to being done, so I'm not expecting
this to be a lot of work or taking a long time, however we need WG
interest and a few active participants (author + reviewers) to get to
the finish line. 
		
		Thanks 
		
		-- Flemming 

			Flemming,
			
			According to my records, this went through WGLC
a couple of years ago, so perhaps the silence is due to the fact the WG
believes the document is finished. What exactly is the situation - were
there unresolved comments from WGLC? I am not offering to contribute
actively on this - just curious.
			
			John

			> We currently have a MMUSIC milestone for
"considerations for
			> using SDP
			>
			> which expired in January 2011. There hasn't
been much
			> discussion on this
			> 2) You are willing to actively contribute to
and/or author
			> this document.

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 14 Mar 2011 12:25:28 +0530

I am interested in seeing this draft cross the finish line as well and
willing to be a reviewer. If Gonzalo needs any additional help, I'll be
glad to provide.
 
Muthu
 
From: Parthasarathi R (partr) 
Sent: Monday, March 14, 2011 12:14 PM
To: Gonzalo Salgueiro (gsalguei); Peter Musgrave
Cc: Flemming Andreasen (fandreas); John Elwell; mmusic; Muthu ArulMozhi
Perumal (mperumal)
Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answer
withmiddleboxes ?

Thanks
Partha

 
Gonzalo

I am willing to be a reviewer - since I have worked on middle-boxes in a
past life. 
 
Peter Musgrave

Thanks 

-- Flemming 

John

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 14 Mar 2011 19:17:43 +0530

I would be interested too in reviewing this draft and providing any help
in taking this draft across the finish line.

Regards,

Ram

---------- Forwarded message ----------
From: Muthu ArulMozhi Perumal (mperumal) <[email-masked]>
Date: 14 March 2011 12:25
Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer
withmiddleboxes ?
To: "Parthasarathi R (partr)" <[email-masked]>, "Gonzalo Salgueiro
(gsalguei)" <[email-masked]>, Peter Musgrave
<[email-masked]>
Cc: "Flemming Andreasen (fandreas)" <[email-masked]>, John Elwell
<[email-masked]>, mmusic <[email-masked]>

Muthu

Thanks

Partha

Gonzalo

Peter Musgrave

Thanks 

-- Flemming 

Flemming,

John

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 15 Mar 2011 07:52:26 +0530

The draft has lot of good recommendation which helps middlebox implementer to implement without impacting other feature interactions. Some of my initial comments are as follows: 

1) Introduction: Para 3 last line: STUN shall be added explicitly. Middlebox may drop STUN packet itself.
2) Sec 4.1.1: single-stage commit shall be done irrespective whether it is offer&answer on 18x/200.
3) Sec 4.1.2: explicit resource reservation parameter is preferred to shown in SDP. In case I understand correctly,this callflow is mentioned related to RFC 3312.
4) Sec 4.1.2: step 5 & step 6 does not seems to be preferred approach because MIDCOM agent is different from basic offer/answer model. whether it is expected that UAS will not send any media till 200 OK is received.
5) Sec 5: The text  shall be added to make more clarity- "These middle boxes are termed as Session Border controller by some vendors".  
6) General comment: signaling forking handling by middle-boxes shall be highlighted. Because it is the one another complex activity in offer/answer during the dialog establishment.
7) Sec 8: There is need of more analysis and description on security consideration as most of the middle box like firewall drop packets (even STUN packet) in the defensive mode. It is better to provide more details which give confidence for middle-box implementers
9) Lot of text is based on IMS/ETSI implementation. It may be preferred to include the issues involved in basic SIP/SDP based middle boxes as well.

Thanks

Partha

From: [email-masked] on behalf of Ram Mohan R (rmohanr)
Sent: Mon 3/14/2011 7:17 PM
To: Flemming Andreasen (fandreas); mmusic; Gonzalo Salgueiro (gsalguei)
Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answerwithmiddleboxes ?

I would be interested too in reviewing this draft and providing any help in taking this draft across the finish line.

Regards,

Ram

---------- Forwarded message ----------
From: Muthu ArulMozhi Perumal (mperumal) <[email-masked]>
Date: 14 March 2011 12:25
Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ?
To: "Parthasarathi R (partr)" <[email-masked]>, "Gonzalo Salgueiro (gsalguei)" <[email-masked]>, Peter Musgrave <[email-masked]>
Cc: "Flemming Andreasen (fandreas)" <[email-masked]>, John Elwell <[email-masked]>, mmusic <[email-masked]>

I am interested in seeing this draft cross the finish line as well and willing to be a reviewer. If Gonzalo needs any additional help, I'll be glad to provide.

Muthu

From: Parthasarathi R (partr) 
Sent: Monday, March 14, 2011 12:14 PM
To: Gonzalo Salgueiro (gsalguei); Peter Musgrave
Cc: Flemming Andreasen (fandreas); John Elwell; mmusic; Muthu ArulMozhi Perumal (mperumal)
Subject: RE: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ?

I'm willing to be reviewer of this draft as I'm working in one such middle-box

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gonzalo Salgueiro (gsalguei)
Sent: Friday, March 11, 2011 10:41 PM
To: Peter Musgrave
Cc: Flemming Andreasen (fandreas); John Elwell; mmusic
Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer withmiddleboxes ?

Gonzalo

Peter Musgrave

Thanks 

-- Flemming 

Flemming,

John

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Mar 2011 19:38:46 -0700

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

> 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 ?
>

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Mon, 14 Mar 2011 23:37:07 -0400

Thanks Dan. I'd like others to weigh in but your comments regarding use of SIP B2BUA instead of SIP ALG seems reasonable to me.

BTW - As we jumpstart efforts to resurrect this draft, I'd like to try and get some group feedback. The intent is coming to a consensus on what we think is left to do with this draft in order to progress it.

Regards,

Gonzalo

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 15 Mar 2011 11:50:58 +0530

SIP B2BUA is better than SIP ALG. All the functionality mentioned in the
draft comes under SIP B2BUA in the generic term.I'm fine with the
terminology.
 
But SIP B2BUA has other functionality like 3PCC handling as well. I'm
not very sure whether B2BUA will be acceptable to everybody or will the
usage of B2BUA increase the scope of this draft... 
 
Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Gonzalo Salgueiro (gsalguei)
Sent: Tuesday, March 15, 2011 9:07 AM
To: Dan Wing (dwing)
Cc: Flemming Andreasen (fandreas); 'mmusic'
Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer
withmiddleboxes ?

Thanks Dan. I'd like others to weigh in but your comments regarding use
of SIP B2BUA instead of SIP ALG seems reasonable to me. 

BTW - As we jumpstart efforts to resurrect this draft, I'd like to try
and get some group feedback. The intent is coming to a consensus on what
we think is left to do with this draft in order to progress it.

Regards,

Gonzalo

	The draft uses the term "SIP ALG", which at least does not fit
my

	
	d

		-----Original Message-----

		From: [email-masked]
[mailto:[email-masked]] On

		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

		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

		2) You are willing to actively contribute to and/or
author this

		document.

		Thanks

		mmusic mailing list

		[email-masked]

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 15 Mar 2011 02:33:14 -0400

Partha - 

While I agree with you on the precision and scope of the term, B2BUA is a closer shade of gray than ALG.

Gonzalo

On Mar 15, 2011, at 2:20 AM, Parthasarathi R (partr) wrote:

> SIP B2BUA is better than SIP ALG. All the functionality mentioned in the draft comes under SIP B2BUA in the generic term.I'm fine with the terminology.
>  
> But SIP B2BUA has other functionality like 3PCC handling as well. I'm not very sure whether B2BUA will be acceptable to everybody or will the usage of B2BUA increase the scope of this draft... 
>  
> Thanks
> Partha
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Mar 2011 07:43:41 +0100

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

> 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

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 15 Mar 2011 15:24:01 +0530

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 09:53:22 -0700

> Behalf Of Christer Holmberg
> Sent: Monday, March 14, 2011 11:44 PM
> To: 'Dan Wing'; 'Flemming Andreasen'; 'mmusic'

See below, where I searched for "ALG" in existing RFCs.  It seems
that "ALG" is pretty well entrenched to describe the operation in
a NAT or firewall, which does not have packets sent directly to
the IP address of the NAT or firewall.  RFC2101 is the first strong
definition, and used the term 'pure ALG' and 'transparent ALG'.
(I have not seen 'pure'/'transparent' used before I did this
grep through the RFCs, so I am not suggesting that this MMUSIC draft 
adopt that terminology.) 

> on other things, like media. A SIP ALG contains a SIP B2BUA.

But the draft already separates the two.  The draft currently says the 
SIP ALG only pertains to SIP, and a separate function ("middlebox") 
pertains to media.  See Figure 1 of
draft-ietf-mmusic-media-path-middleboxes-03 
which shows:

                     SIP     +-----------------+     SIP
         +-----+  Signaling  |     SIP ALG     |  Signaling  +-----+
         | UAC |<----------->+-----------------+<----------->| UAS |
         +-----+             |   MIDCOM Agent  |             +-----+
            ^                +-----------------+                ^
            |                         ^                         |
            |          Policy rule(s) | and NAT bindings        |
            |                         v                         |
            |      Media       +-------------+       Media      |
            +----------------->|  Middlebox  |<-----------------+
                               +-------------+

Changing "SIP ALG" in that diagram to "SIP B2BUA" would still fit
your definition.

-d

-----

grep "\bALG\b" rfc*.txt
rfc0759.txt:  14     ENCRYPT   CODE(1),COUNT(3),ALG-ID(1),
rfc1410.txt:PEM-ALG    PEM - Algorithms, Modes, and Identifiers Elective
1
423*
rfc1500.txt:PEM-ALG    PEM - Algorithms, Modes, and Identifiers Elective
1
423
rfc1540.txt:PEM-ALG    PEM - Algorithms, Modes, and Identifiers Elective
1
423
rfc1600.txt:PEM-ALG    PEM - Algorithms, Modes, and Identifiers Elective
1
423
rfc1610.txt:PEM-ALG    PEM - Algorithms, Modes, and Identifiers Elective
1
423
rfc1720.txt:PEM-ALG    PEM - Algorithms, Modes, and Identifiers Elective
1
423
rfc1780.txt:PEM-ALG    PEM - Algorithms, Modes, and Identifiers Elective
1
423
rfc1800.txt:PEM-ALG    PEM - Algorithms, Modes, and Identifiers Elective
1
423
rfc1880.txt:PEM-ALG    PEM - Algorithms, Modes, and Identifiers Elective
1
423
rfc1920.txt:PEM-ALG    PEM - Algorithms, Modes, and Identifiers Elective
1
423
rfc1991.txt:      0   2   RND(n bytes)   0  ALG(1 byte)  DEK(k bytes)
CSUM(2 by
tes)
rfc1991.txt:   ALG refers to the algorithm byte for the secret key algorithm
use
d to
rfc1991.txt:   ALG.  For the IDEA encryption algorithm, type byte 1, the DEK
is
16
rfc2000.txt:PEM-ALG    PEM - Algorithms, Modes, and Identifiers Elective
1
423
rfc2025.txt:2.1 Integrity Algorithm (I-ALG):
rfc2025.txt:2.2 Confidentiality Algorithm (C-ALG):
rfc2025.txt:2.3 Key Establishment Algorithm (K-ALG):
rfc2025.txt:         context.  The keys used for C-ALG and any keyed I-ALGs
(for

rfc2025.txt:            K-ALG cannot be used with unilateral authentication
in
rfc2025.txt:2.4 One-Way Function (O-ALG) for Subkey Derivation Algorithm:
rfc2025.txt:         Having established a context key using the negotiated
K-ALG
,
rfc2025.txt:         the longest key needed by any agreed C-ALG or keyed
I-ALG,
and
rfc2025.txt:         within the K-ALG parameters).
rfc2025.txt:         long.  If 512-bit RSAEncryption is the K-ALG in use
then th
e
rfc2025.txt:         the K-ALG in use then the context key is the result of
the
rfc2025.txt:         allowing negotiation of the O-ALG OWF during the
context
rfc2025.txt:   C-ALG over the established context, and the integrity
algorithms
rfc2025.txt:   selected by the target become ones that may be used for I-ALG
ove
r
rfc2025.txt:   list that it supports).  Note that any C-ALG and I-ALG may be
use
d
rfc2025.txt:   algorithm).  If this K-ALG is unacceptable to the target then
the

rfc2025.txt:   chooses a 2-pass K-ALG such as dhKeyAgreement), the initiator
wil
l
rfc2025.txt:   offers a set of possible O-ALGs (only a single O-ALG if no
respon
se
rfc2025.txt:   is expected).  The (single) O-ALG chosen by the target
becomes th
e
rfc2025.txt:   or all of I-ALG, C-ALG, K-ALG, and O-ALG.
rfc2025.txt:   unilateral authentication no negotiation of K-ALG can be done
(th
e
rfc2025.txt:   target either accepts the K-ALG and context key given by the
rfc2025.txt:   two-pass K-ALG offered by the initiator and, again, can be
reques
ted
rfc2025.txt:              -- key estb. parameter corresponding to first
K-ALG in
 set
rfc2025.txt:              -- unilateral authen. if the K-ALG in use does not
pro
vide
rfc2025.txt:              -- mandatory hashing procedure MD5 (in MANDATORY
I-ALG
;
rfc2025.txt:   } -- for C-ALG (see Section 5.2 for discussion of QOP)
rfc2025.txt:       -- for I-ALG (see Section 5.2 for discussion of QOP)
rfc2025.txt:       -- to allow negotiation of K-ALG
rfc2025.txt:             -- key-estb-req (if init. used a 2-pass K-ALG), or
(2)
the
rfc2025.txt:             -- key-estb-req corresponding to the K-ALG supplied
in
rfc2025.txt:             -- to the first K-ALG supplied in initiator's
key-estb-
id,
rfc2025.txt:                 -- (if target selected a 2-pass K-ALG)
rfc2025.txt:              -- unilateral authen. if the K-ALG in use does not
pro
vide
rfc2025.txt:              -- mandatory hashing procedure (in MANDATORY
I-ALG;
rfc2101.txt:      (ALG). Such a device acts as a termination point for the
rfc2101.txt:      to explicitly establish communication with the ALG that
rfc2101.txt:      ALG.
rfc2101.txt:      Another form of ALG makes communication through the ALG
rfc2101.txt:      "transparent" ALG, Ua would not be required to establish
expli
cit
rfc2101.txt:      connectivity to the ALG first, before starting to
communicate
with
rfc2101.txt:      communicating via an ALG involves changes to the network
heade
r.
rfc2101.txt:      An ALG could be used only at the beginning of a session
for th
e
rfc2101.txt:      purpose of authentication, after which the ALG goes away
and
rfc2101.txt:      described in RFC1631 is a device that has both the NAT and
ALG

rfc2101.txt:      a transparent ALG.
rfc2101.txt:      This is in contrast with an ALG that can support only the
rfc2101.txt:      applications coded into the ALG.
rfc2101.txt:      and ALG functionality in a single device could be used to
over
come
rfc2101.txt:      addresses, and would resort to the ALG functionality when
deal
ing
rfc2101.txt:      connection, but would use the ALG functionality to deal
with t
he
rfc2101.txt:      the device does not support the application via the ALG
rfc2101.txt:      communicating through either an ALG or a NAT. Since IP
Securit
y,
rfc2101.txt:      end-to-end, it is not clear how an ALG or NAT could modify
rfc2101.txt:      running a NAT or ALG probably needs to run two DNS
servers, on
e
rfc2101.txt:      inside and one outside the NAT or ALG, giving different
answer
s to
rfc2101.txt:      presumably not be valid across a NAT/ALG boundary, so we
must
rfc2154.txt:   SIG ALG         The signature algorithm for the Router Public
Key
.
rfc2182.txt:   an Application Layer Gateway (ALG).  Such a device would
understa
nd
rfc2182.txt:   of the firewall.  A server implemented in an ALG will usually
be
such
rfc2196.txt:   only subsections of the protocol.  For example, an ALG for
FTP ca
n
rfc2200.txt:PEM-ALG    PEM - Algorithms, Modes, and Identifiers Elective
1
423
rfc2300.txt:PEM-ALG    PEM - Algorithms, Modes, and Identifiers Elective
1
423
rfc2400.txt:PEM-ALG    PEM - Algorithms, Modes, and Identifiers Elective
1
423
rfc2500.txt:PEM-ALG    PEM - Algorithms, Modes, and Identifiers
1
423
rfc2600.txt:PEM-ALG    Privacy Enhancement for Internet Electronic Mail
14
23
rfc2663.txt:   across realms, even with an ALG (defined below in section
2.9)
rfc2663.txt:2.9. Application Level gateway (ALG)
rfc2663.txt:   different realm transparently. An ALG may interact with NAT
to se
t up
rfc2663.txt:   address resolution. A DNS-ALG must be employed in conjunction
wit
h
rfc2663.txt:   Specifically, the DNS-ALG must be capable of translating
private
rfc2663.txt:   to Host-X, it issues a DNS query for Host-X. A DNS-ALG
intercepts
 the
rfc2663.txt:   DNS query, and in the response returned to Host-A the DNS-ALG
rfc2663.txt:   ALG modifies addresses (e.g., as in the case of Twice-NAT),
rfc2663.txt:   devoted to describing how FTP is supported on NAT devices.
FTP A
LG
rfc2663.txt:   response are an IP address and a TCP port in ASCII. An FTP
ALG is

rfc2663.txt:   The ALG must also update NAT with appropriate data session
tuples
 and
rfc2663.txt:   used by the ALG to correct the TCP sequence and acknowledge
numbe
rs.
rfc2663.txt:   not uncommon for an SNMP specific ALG to reside on a NAT
router t
o
rfc2663.txt:   to find NAT, ALG and firewall functions co-exist to provide
secur
ity
rfc2694.txt:   or indirectly (through the internal name servers). Using
DNS-ALG
rfc2694.txt:   headers of the DNS packet and notify DNS-ALG to perform DNS
paylo
ad
rfc2694.txt:   changes. DNS-ALG would interact with NAT and use NAT state
rfc2694.txt:    Figure 2: NAT & DNS-ALG in the translation path of DNS
packets
rfc2694.txt:   ALG implementations. Note, it is possible for a committed
address

rfc2694.txt:   is 198.76.29.1. DNS-ALG would use this temporary binding to
modif
y
rfc2694.txt:4. DNS payload modifications by DNS-ALG
rfc2694.txt:   headers of a DNS packet, DNS-ALG is responsible for updating
the
DNS
rfc2694.txt:   response. No changes are required to be made by DNS-ALG to
the He
ader
rfc2694.txt:   within the zone without intervention from NAT and DNS-ALG, so
lon
g as
rfc2694.txt:   hence will not be subject to consideration by DNS-ALG.
rfc2694.txt:   of scope for DNS-ALG (as described in section 7).
rfc2694.txt:   the DNS-ALG to be 0.
rfc2694.txt:    Figure 3: DNS-ALG operation in Bi-Directional NAT setup
rfc2694.txt:    Figure 4: DNS-ALG operation in Twice-NAT setup
rfc2694.txt:7. DNS-ALG limitations and Future Work
rfc2694.txt:   DNS-ALG. At best, DNS-ALG would be able to transform secure
dnsse
c
rfc2694.txt:   ALG, NAT and IPsec gateway (providing secure tunneling
service) a
re
rfc2694.txt:   resident on the same device, DNS-ALG will have access to the
IPse
c
rfc2694.txt:   security association keys.  The preceding section, "DNS-ALG
rfc2694.txt:   Further, with DNS-ALG, there is a possibility of denial of
servic
e
rfc2700.txt:PEM-ALG    Privacy Enhancement for Internet Electronic Mail
1
423
rfc2709.txt:   application level gateway (ALG) to make the payload
meaningful in

rfc2709.txt:   both realms. However, applications that require assistance of
an
ALG
rfc2709.txt:   they require assistance of an ALG or not, can benefit from
IPsec
rfc2709.txt:   policies administered based on private realm addressing. An
ALG w
ill
rfc2709.txt:   subject to any NAT processing. IKE-ALG simply translates
select
rfc2709.txt:   match. The following diagram illustrates how an IKE-ALG
process
rfc2709.txt:   IKE-ALG may need to request NAT to set up address bindings
and/or

rfc2709.txt:   sessions are negotiated. In the case the ALG is unable to
setup t
he
rfc2709.txt:   necessary address bindings or transport bindings, IKE-ALG
will no
t be
rfc2709.txt:   | (IPsec  | IPC-NAT MAPs             | IKE-ALG |
rfc2709.txt:   Figure 5. IKE-ALG translates Security policies, using NAT
Maps.
rfc2765.txt:      boundary of the cloud, or to use Application Layer
Gateways (A
LG)
rfc2765.txt:      on dual nodes at the cloud's boundary.  The ALG solution
is le
ss
rfc2765.txt:      also less robust since an ALG box is likely to be a single
poi
nt
rfc2766.txt:      2.4 Application Level Gateway
(ALG)...........................
  5
rfc2766.txt:   4. Use of DNS-ALG for Address
assignment.........................
  8
rfc2766.txt:   6. FTP Application Level Gateway (FTP-ALG)
Support...............
 14
rfc2766.txt:   hosts by using DNS for address resolution. A DNS-ALG
[DNS-ALG] mu
st
rfc2766.txt:   name to address mapping.  Specifically, the DNS-ALG must be
capab
le
rfc2766.txt:2.4 Application Level Gateway (ALG)
rfc2766.txt:   Application Level Gateway (ALG) [NAT-TERM] is an application
spec
ific
rfc2766.txt:   is application unaware and does not snoop the payload. ALG
could
work
rfc2766.txt:4. Use of DNS-ALG for Address Assignment
rfc2766.txt:   In any case, the DNS-ALG's principle of operation described
in th
is
rfc2766.txt:   more than one query - reply pairs. The DNS-ALG SHOULD, in
that ca
se,
rfc2766.txt:   traverse through the NAT-PT router. The DNS-ALG on the NAT-PT
dev
ice
rfc2766.txt:   server on the V6 network to the V4 node, the DNS-ALG once
again
rfc2766.txt:   DNS-ALG intercepts and translates the "A" query to "AAAA" or
"A6"

rfc2766.txt:   translated by the DNS-ALG to:
rfc2766.txt:   The DNS-ALG also holds the mapping between
FEDC:BA98::7654:3210 a
nd
rfc2766.txt:   queries for nodes residing in the V6 network causing the
DNS-ALG
to
rfc2766.txt:   for DNS-ALG intervention. Otherwise, the queries will cross
the V
6
rfc2766.txt:   domain and are subject to DNS-ALG intervention.  We recommend
rfc2766.txt:   Since Node-C may have IPv6 and/or IPv4 addresses, the DNS-ALG
on
the
rfc2766.txt:   NAT-PT. The DNS-ALG then, translates the reply adding the
appropr
iate
rfc2766.txt:   section on FTP-ALG describes the changes FTP-ALG would make
to FT
P
rfc2766.txt:6. FTP Application Level Gateway (FTP-ALG) Support
rfc2766.txt:   address and TCP port information for the data session, an
FTP-ALG
 is
rfc2766.txt:   node. FTP-ALG, facilitating transparent FTP between V4 and V6
nod
es,
rfc2766.txt:   session and uses PORT or PASV command, the FTP-ALG will
translate

rfc2766.txt:   commands, the FTP-ALG will simply translate the parameters to
the
se
rfc2766.txt:   If a V6 host originates the FTP session, however, the FTP-ALG
has
 two
rfc2766.txt:   approaches to pursue. In the first approach, the FTP-ALG will
lea
ve
rfc2766.txt:   In the second approach, the FTP-ALG will translate the
command
rfc2766.txt:   forwarding to the target V6 nodes.  However, the FTP-ALG
would be

rfc2766.txt:   reflect the new payload size. A table is used by the FTP-ALG
to
rfc2766.txt:   Application Layer Gateways (ALG) need to be incorporated to
provi
de
rfc2766.txt:   NAT-PT, in its simplest form, without the support of DNS-ALG,
rfc2766.txt:   NAT-PT  combined  with a DNS-ALG provides bi-directional
connecti
vity
rfc2766.txt:   Section 7.5 of this document states that the DNS-ALG can not
be
rfc2766.txt:   [DNS-ALG]  Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A.
rfc2767.txt:   NOTE: This action is similar to that of the DNS ALG
(Application
rfc2775.txt:   gateways (ALGs) or proxies. Furthermore, the ALG or proxy
must be

rfc2800.txt:PEM-ALG    Privacy Enhancement for Internet Electronic Mail:
1
423
rfc2845.txt:         Algorithm Name   SAMPLE-ALG.EXAMPLE.
rfc2845.txt:   initial value should be "HMAC-MD5.SIG-ALG.REG.INT".
Algorithm na
mes
rfc2845.txt:   defined in RFC 2434. The algorithm name
HMAC-MD5.SIG-ALG.REG.INT
rfc2847.txt:   2.3.2.  RECOMMENDED Integrity Algorithms (I-ALG) . . . . . .
. .
. 7
rfc2847.txt:   md5WithRSAEncryption, the REQUIRED Key Establishment (K-ALG),
rfc2847.txt:   Integrity (I-ALG) and One-Way Functions for Subkey Derivation
(O-
ALG)
rfc2847.txt:   *    Integrity algorithms (I-ALG)
rfc2847.txt:           ALG that returns a zero length bit string regardless
of t
he
rfc2847.txt:           The HMAC-SHA1 algorithm is not a mandatory SPKM-3
I-ALG M
AC
rfc2847.txt:   *    Confidentiality algorithm (C-ALG).
rfc2847.txt:        ALG because it is much slower than cast5CBC. One set of
rfc2847.txt:   *    Key Establishment Algorithm (K-ALG)
rfc2847.txt:   *    One-Way Function for Subkey Derivation Algorithm (O-ALG)
rfc2847.txt:        sha1 is a MANDATORY O-ALG in SPKM-3:
rfc2847.txt:2.3.2.  RECOMMENDED Integrity Algorithms (I-ALG)
rfc2847.txt:   the lack of a target certificate, it MUST use the NULL-MAC
I-ALG
rfc2847.txt:   Because RFC 2025 requires that the RSAEncryption K-ALG be
present
,
rfc2847.txt:   the RSAEncryption K-ALG algorithm. It is also free to use an
algI
D
rfc2847.txt:   to 1 if the only K-ALG in the key-estb-set field of
Req-contents
is
rfc2847.txt:   The SPKM-3 target MUST NOT use a NULL-MAC I-ALG; it MUST use
a
rfc2847.txt:   will use the first C-ALG (privacy), and I-ALG (integrity)
algorit
hms
rfc2847.txt:   choice of cast5CBC as the MANDATORY C-ALG for SPKM-3 is
advisable
.
rfc2900.txt:PEM-ALG    Privacy Enhancement for Internet Electronic Mail:
1
423
rfc2956.txt:   NAT even with an ALG.
rfc2956.txt:   limited deployability, and/or require ALG support in NATs.
rfc2962.txt:   This document describes an SNMP application layer gateway
(ALG),
rfc2962.txt:   SNMP ALG.  Specifically, when using SNMPv3's authentication
and
rfc2962.txt:   ALG.
rfc2962.txt:   This document describes the ALG (Application Level Gateway)
for t
he
rfc2962.txt:   mapped from one group to another.  The SNMP ALG is a specific
cas
e of
rfc2962.txt:   An SNMP ALG allows network management stations to manage
multiple

rfc2962.txt:   or SNMP ALG, is a technique in which the payload of SNMP
packets
rfc2962.txt:   needed.  In this context, an SNMP ALG can be an additional
compon
ent
rfc2962.txt:   assumed to have a fixed IP address.  Thus, SNMP ALG should
only b
e
rfc2962.txt:   A typical scenario where SNMP ALG is deployed as part of NAT
is
rfc2962.txt:   |Regional Router|-----------------|Stub Router w/NAT and SNMP
ALG
|
rfc2962.txt:               Figure 1: SNMP ALG in a NAT configuration
rfc2962.txt:                         | SNMP ALG      |-----|Management
device|
rfc2962.txt:     Figure 2: Using external SNMP ALG to manage two private
network
s
rfc2962.txt:   An SNMP ALG is required to scan all the payload of SNMP
packets,
to
rfc2962.txt:   In many cases the router may be unable to handle SNMP ALG and
ret
ain
rfc2962.txt:   SNMP ALG outside the router, as described in Figure 2.
rfc2962.txt:   A basic SNMP ALG is an SNMP ALG implementation in which only
IP
rfc2962.txt:   SNMP ALG therefore does not need to be MIB aware.
rfc2962.txt:   An advanced SNMP ALG is an SNMP ALG implementation which is
capab
le
rfc2962.txt:   types. This implies that an advanced SNMP ALG is MIB aware.
rfc2962.txt:   network (i.e. the addressing realm).  The SNMP ALG described
in t
his
rfc2962.txt:   sufficient information that an advanced SNMP ALG which
understand
s
rfc2962.txt:   A NAT unfriendly textual convention requires that an SNMP
ALG, wh
ich
rfc2962.txt:   An SNMP ALG should provide transparent IP address translation
to
rfc2962.txt:   management applications.  An SNMP ALG must be compatible with
the

rfc2962.txt:   provided by the SNMP protocol.  A fully transparent SNMP ALG
must
 be
rfc2962.txt:   The SNMP ALG requires bi-directional NAT devices enroute,
that
rfc2962.txt:   a single SNMP ALG, the external addresses assumed by each of
the
NAT
rfc2962.txt:   A general SNMP ALG must be capable to translate IP addresses
in
rfc2962.txt:   SNMP ALG must reassemble IP packets which contain SNMP
messages.
 The
rfc2962.txt:   A basic SNMP ALG is an SNMP ALG implementation in which only
IP
rfc2962.txt:   basic SNMP ALG implementation parses an ASN.1/BER encoded
SNMP pa
cket
rfc2962.txt:   Once an IpAddress has been detected, the SNMP ALG checks the
rfc2962.txt:   The basic SNMP ALG does not require knowledge of any MIBs
since i
t
rfc2962.txt:   easy to implement.  A basic SNMP ALG does not change the
overall
rfc2962.txt:   However, a basic SNMP ALG is only able to translate IPv4
addresse
s in
rfc2962.txt:   ALG is not capable to translate IP addresses in objects that
are
rfc2962.txt:   basic SNMP ALG is restricted to the first out of the four
possibl
e
rfc2962.txt:   An advanced SNMP ALG is an SNMP ALG implementation which is
capab
le
rfc2962.txt:   types.  Hence, an advanced SNMP ALG may be able to
transparently
map
rfc2962.txt:   This implies that an advanced SNMP ALG must be MIB aware.
rfc2962.txt:   An advanced SNMP ALG must maintain an OBJECT IDENTIFIER (OID)
rfc2962.txt:   conceptual table is a required feature of an advanced SNMP
ALG.
IP
rfc2962.txt:   example shows that an advanced SNMP ALG may change the
overall pa
cket
rfc2962.txt:   Another effect of an advanced SNMP ALG is that it changes the
rfc2962.txt:   incorrectly report agents behind an advanced SNMP ALG as
broken S
NMP
rfc2962.txt:   size of the SNMP packet.  A basic SNMP ALG does therefore
never
rfc2962.txt:   An advanced SNMP ALG may change the size of an SNMP packet
since
a
rfc2962.txt:   receiver can handle.  An SNMP ALG which increases the size of
an
SNMP
rfc2962.txt:   anymore.  Thus, an advanced SNMP ALG may cause some SNMPv3
rfc2962.txt:   applications is not an achievable task.  The basic SNMP ALG
descr
ibed
rfc2962.txt:   base type.  Such an SNMP ALG achieves only very limited
transpare
ncy
rfc2962.txt:   SNMP ALG in place.
rfc2962.txt:   An advanced SNMP ALG described in Section 4.2 achieves better
rfc2962.txt:   transparency.  However, an advanced SNMP ALG can only claim
to be

rfc2962.txt:   understood by the advanced SNMP ALG implementation and for a
give
n
rfc2962.txt:   against unauthorized access.  Thus, an SNMP ALG must have
access
to
rfc2962.txt:   invalidating them.  Furthermore, the SNMP ALG must track any
key
rfc2962.txt:   Finally, an SNMP ALG only deals with SNMP traffic and does
not mo
dify
rfc2962.txt:   is occurring, even in the presence of an SNMP ALG.
rfc2962.txt:   (Just replace the box SNMP ALG with a box labeled SNMP PROXY
in
rfc2962.txt:   Furthermore, an SNMP ALG does not need to have knowledge of
the
rfc2962.txt:   However, the usage of SNMP ALG introduces new problems when
SNMPv
3
rfc2962.txt:   and auth/priv) can only be processed by an SNMP ALG which
support
s
rfc2962.txt:   the keys in use.  Furthermore, as keys may be updated, the
SNMP A
LG
rfc2962.txt:   SNMP ALG which maintains the keys for a set of SNMP engines
is a
rfc2962.txt:   An SNMP ALG implementation which maintains lists of
(localized) k
eys
rfc2962.txt:   use these keys.  An SNMP ALG implementation which maintains
passw
ords
rfc2962.txt:   SNMP ALG implementation must be properly secured so that
people w
ho
rfc2962.txt:       limited transparency provided by a basic SNMP ALG.  Basic
SNM
P
rfc2962.txt:       advanced SNMP ALG is much more complex and less
efficiency th
an a
rfc2962.txt:       basic SNMP ALG. An advanced SNMP ALG may break the
lexicograp
hic
rfc2962.txt:   A basic SNMP ALG as described in Section 4.1 was implemented
for
rfc2962.txt:   described in Figure 2, where SNMP ALG was combined with the
NAT
rfc2962.txt:   an internal contradiction caused by a basic SNMP ALG since
the
rfc2993.txt:    7.2.  ALG
complexity............................................
. 14
rfc2993.txt:   configured application specific gateways (ALG's), endpoints
can w
ork
rfc2993.txt:   ALG - Application Layer Gateway: inserted between application
pee
rs
rfc2993.txt:   NAT/ALG - combines ALG functions with simple NAT.  Generally
more

rfc2993.txt:   DNS/ALG -  a special case of the NAT/ALG, where an ALG for
the DN
S
rfc2993.txt:   Firewall - access control point that may be a special case of
an
ALG,
rfc2993.txt:   arbitrarily inserted.  Unlike an ALG, the application on at
least
 one
rfc2993.txt:     pair of hosts communicating through either an ALG or a NAT.
rfc2993.txt:   machines, the processing and I/O capabilities of the NAT/ALG
devi
ce
rfc2993.txt:   While RSIP addresses the transparency and ALG issues, for the
rfc2993.txt:   OSPF ALG it would actually be possible to route across a NAT
rfc2993.txt: 7.2.  ALG complexity
rfc2993.txt:   NAT/ALG was to be one or more devices at each physical
location,
and
rfc2993.txt:   the data stream carries an IP address; the central collector
or A
LG
rfc2993.txt:   As noted in the RFC-2694 [15], the DNS/ALG cannot support
secure
DNS
rfc2993.txt:   It is also the case that DNS/ALG will break any modified,
signed
rfc2993.txt:   modified by the DNS/ALG if it had access to the source
authentica
tion
rfc2993.txt:   this key, to maintain source authenticity.  So NATs that use
DNS/
ALG
rfc2993.txt:     Embedding the DNS server, or a DNS ALG in the NAT device
will
rfc2993.txt:     appropriate ALG or establish a VPN to isolate the
application f
rom
rfc2993.txt:   - If the environment uses secure DNS records, the DNS/ALG
will
rfc2993.txt:   justifications to registries        or DNS/ALG
rfc2993.txt:                                       DNS/ALG breaks DNSsec
replies

rfc2993.txt:   these technologies, NAT and the DNS/ALG work-around, hinder
rfc2993.txt:   effects from all applications. While this solves the ALG
issues,
it
rfc2999.txt:This document describes the ALG (Application Level Gateway) for
the
SNMP
rfc3000.txt:PEM-ALG    Privacy Enhancement for Internet Electronic Mail:
1
423
rfc3022.txt:   and alterations.  FTP is the most popular ALG resident on NAT
rfc3022.txt:   devices.  Applications requiring ALG intervention must not
have t
heir
rfc3022.txt:   payload encoded, as doing that would effectively disables the
ALG
,
rfc3022.txt:   unless the ALG has the key to decrypt the payload.
rfc3022.txt:   "TU Ports", "ALG" and others, used throughout the document,
may b
e
rfc3022.txt:   ALG to monitor the control session payload to determine the
ensui
ng
rfc3022.txt:   data session parameters.  FTP ALG is an integral part of most
NAT

rfc3022.txt:   The FTP ALG would require a special table to correct the TCP
sequ
ence
rfc3022.txt:   outbound from a private domain, DNS ALG may be obviated from
use
in
rfc3027.txt:   4.0 Protocols that can work with the aid of an ALG
............
8
rfc3027.txt:   transparency.  Unlike NAT, the function of ALG is application
rfc3027.txt:   ALG may be able to provide work around in some cases.  But,
if th
e
rfc3027.txt:   with a DNS-ALG might be able to offer the necessary
application l
evel
rfc3027.txt:   payload is not encrypted, an ALG may in some cases be able to
pro
vide
rfc3027.txt:   across realms.  The complexity of ALG depends on the
application
rfc3027.txt:   NAT device supports DNS-ALG.  Examples of Peer-to-peer
applicatio
ns
rfc3027.txt:   Alternately, an ALG may be required to interact with NAT to
keep
the
rfc3027.txt:   Kerberos 4 tickets are encrypted.  Therefore, an ALG cannot
be
rfc3027.txt:   not to let NAT drop the address binding.  Alternately, an ALG
wil
l
rfc3027.txt:   Therefore, an ALG cannot be written.
rfc3027.txt:      because they can easily be spoofed.  NAT and DNS-ALG
cannot wo
rk
rfc3027.txt:   NAT device might solicit the help of an ALG to replace the IP
add
ress
rfc3027.txt:   without requiring an ALG.  But, this approach increases the
secur
ity
rfc3027.txt:   available.  As the ALG tampers with the IP addresses it will
also
 not
rfc3027.txt:4.0 Protocols that can work with the aid of an ALG
rfc3027.txt:   Say, an FTP client is in a NAT supported private network.  An
FTP
 ALG
rfc3027.txt:   impossible for an ALG to update the IP addresses in the
command
rfc3027.txt:   FTP protocol, eliminating further processing through ALG, if
the
rfc3027.txt:   an RSVP-ALG must be able to replace the IP addresses based
upon t
he
rfc3027.txt:   an RSVP-ALG will not work when RSVP Integrity Object is used.
rfc3027.txt:   resolutions.  A DNS-ALG would be required to perform address
to n
ame
rfc3027.txt:   conversions on DNS queries and responses.  [DNS-ALG]
describes DN
S-
rfc3027.txt:   ALG
rfc3027.txt:   application specific session.  As a result, DNS-ALG will be
requi
red
rfc3027.txt:   server for external name lookup.  No ALG is required when the
nam
e
rfc3027.txt:   cryptographic keys, an SMTP-ALG may be used to translate the
IP
rfc3027.txt:   NAT alone, without the ALG.  This can cause problems when
debuggi
ng
rfc3027.txt:   would require a SIP-ALG.
rfc3027.txt:   significance when traversing a NAT.  Thus a SIP-ALG would
need th
e
rfc3027.txt:   As an alternative to an SIP-ALG, SIP supports a proxy server
whic
h
rfc3027.txt:   device.  A work around for this would be for the ALG to
examine t
he
rfc3027.txt:   control session.  Alternately, the ALG could simply redirect
all
rfc3027.txt:   For bi-Directional NAT, you will not need an ALG.
Bi-directional
 NAT
rfc3027.txt:   (This makes it particularly difficult for the ALG, which will
be
rfc3027.txt:   encrypted, it is impossible for the ALG to decipher the data
stre
am,
rfc3027.txt:   through a NAT device, an H.323-ALG will be required to
examine th
e
rfc3027.txt:   ALG would have to be cognizant of the various gateway
discovery
rfc3027.txt:   cases, as described in [SNMP-ALG], an SNMP ALG may be used to
rfc3027.txt:   addresses.  Such an ALG assumes static address mapping and
bi-
rfc3027.txt:   conventions) understood by the SNMP-ALG implementation and
for a
rfc3027.txt:   optionally privacy) is enabled, unless the ALG has access to
secu
rity
rfc3027.txt:   require an ALG for the games to work transparently through
rfc3027.txt:   [SNMP-ALG]   Raz, D., Schoenwaelder, J. and B. Sugla, "An
SNMP
rfc3027.txt:   [DNS-ALG]    Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A.
rfc3102.txt:   requires the presence of an application layer gateway (ALG)
withi
n
rfc3102.txt:   with an ALG for FTP, which transmits IP addresses and port
number
s on
rfc3102.txt:   if an RSIP ALG is installed.  The RSIP data flow, however,
will h
ave
rfc3103.txt:   will require an application layer gateway (ALG) for any
protocol
that
rfc3234.txt:   accompanied by an ALG (Application Level Gateway - see
below).  I
t
rfc3234.txt:   In practice, SIIT and NAT-PT will both need an associated ALG
and

rfc3234.txt:   ALG; another (less common) name for them is a TLG.  As with
ALGs,

rfc3234.txt:   may be distinct, this is in practice very similar to a NAT
plus A
LG.
rfc3235.txt:   an Application Level Gateway (ALG) may still permit operation
of
the
rfc3235.txt:   protocol.  Depending on the encoding used in a protocol, an
ALG m
ay
rfc3235.txt:   that the ALG design may be simple and automated.  ALGs
typically
rfc3235.txt:   the ALG should be simple and not require excessive
computation or

rfc3235.txt:   NAT (and thus can require ALG support) are also issues for
firewa
lls.
rfc3235.txt:   new application or service, the requirement for an ALG will
limit

rfc3235.txt:   same host IP address may not function without an ALG.
rfc3235.txt:   any other simple TCP connection, and so an ALG is not
required.
rfc3235.txt:   private realm.  Through use of a DNS-ALG [RFC2694], lookups
are
rfc3235.txt:   devices, Bi-directional NAT devices (in conjunction with
DNS-ALG)
 are
rfc3257.txt:   Application Layer Gateway (ALG) which will intelligently
translat
e
rfc3278.txt:   ALG].
rfc3278.txt:   [PKI-ALG]    Bassham, L., Housley R. and W. Polk, "Algorithms
and

rfc3300.txt:PEM-ALG    Privacy Enhancement for Internet Electronic Mail:
1
423
rfc3303.txt:2.6. ALG
rfc3303.txt:   middlebox function.  An ALG examines application traffic in
trans
it
rfc3303.txt:   An ALG may be a co-resident with a middlebox or reside
externally
,
rfc3303.txt:   MIDCOM agents are entities performing ALG functions,
logically
rfc3303.txt:   ALG.
rfc3303.txt:   session tuples for which the agent is authorized to act as
ALG),
rfc3303.txt:   session tuples for which the agent is authorized to act as
ALG),
rfc3338.txt:   there isn't a DNS ALG as in NAT-PT, so there is no
interference w
ith
rfc3424.txt:   be dropped by the NAT anyway, because there's no ALG.)
rfc3489.txt:   an ALG, or MIDCOM.
rfc3600.txt:PEM-ALG    Privacy Enhancement for Internet Electronic Mail:
1
423
rfc3654.txt:   MAY support other high touch functions (e.g., NAT, ALG).
rfc3665.txt:       3.5.  Session Through a SIP ALG. . . . . . . . . . . . .
. .
. 46
rfc3665.txt:   ALG                          alg1.atlanta.example.com
192.0.2.
128
rfc3665.txt:3.5.  Session Through a SIP ALG
rfc3665.txt:   Alice             ALG           Proxy 2            Bob
rfc3665.txt:   Alice completes a call to Bob through a ALG (Application
Layer
rfc3665.txt:   Gateway) and a SIP Proxy.  The routing through the ALG is
rfc3665.txt:   that the media stream setup is not end-to-end - the ALG
terminate
s
rfc3665.txt:   both media streams and bridges them.  This is done by the ALG
rfc3665.txt:   F1 INVITE Alice -> SIP ALG
rfc3665.txt:   F2 INVITE SIP ALG -> Proxy 2
rfc3665.txt:   F3 100 Trying SIP ALG -> Alice
rfc3665.txt:   /* SIP ALG prepares to proxy data from port 192.0.2.128/2000
to
rfc3665.txt:   F5 100 Trying Proxy 2 -> SIP ALG
rfc3665.txt:   F7 180 Ringing Proxy 2 -> SIP ALG
rfc3665.txt:   F8 180 Ringing SIP ALG -> Alice
rfc3665.txt:   F10 200 OK Proxy 2 -> SIP ALG
rfc3665.txt:   F11 200 OK SIP ALG -> Alice
rfc3665.txt:   /* The ALG prepares to proxy packets from 192.0.2.128/
rfc3665.txt:   F12 ACK Alice -> SIP ALG
rfc3665.txt:   F13 ACK SIP ALG -> Bob
rfc3665.txt:   /* RTP streams are established between Alice and the ALG and
rfc3665.txt:   between the ALG and B*/
rfc3665.txt:   F14 BYE Alice -> SIP ALG
rfc3665.txt:   F15 BYE SIP ALG -> Bob
rfc3665.txt:   F16 200 OK Bob -> SIP ALG
rfc3665.txt:   F17 200 OK SIP ALG -> Alice
rfc3700.txt:PEM-ALG    Privacy Enhancement for Internet Electronic Mail:
1
423
rfc3890.txt:   ALG  - Application Level Gateway.
rfc3890.txt:   2. The SDP has been changed by an Application Level Gateway
(ALG)
.
rfc3923.txt:   o  The SHA-1 message digest as specified in [CMS-ALG] section
2.1
.
rfc3923.txt:      specified in [CMS-ALG] section 3.2.
rfc3923.txt:   o  The RSA (PKCS #1 v1.5) key transport, as specified in
[CMS-ALG
]
rfc3923.txt:   [CMS-ALG]     Housley, R., "Cryptographic Message Syntax
(CMS)
rfc4028.txt:   SIP Network Address Translator (NAT) Application Level
Gateway (A
LG)
rfc4028.txt:   [6].  The ALG embedded in a NAT will need to maintain state
for t
he
rfc4038.txt:   translated by NAT-PT DNS-ALG.  In some cases, one might be
tempte
d to
rfc4162.txt:   [SEED-ALG].  The SEED homepage,
rfc4162.txt:   [SEED-ALG]   Park, J., Lee, S., Kim, J., and J. Lee, "The
SEED
rfc4215.txt:   ALG         Application Level Gateway
rfc4215.txt:      1. Separate the DNS ALG from the NAPT-PT node (in the
"IPv6 to

rfc4226.txt:   IDEAL.  We denote ALG as either HOTP or HOTP-IDEAL for the
purpos
e of
rfc4226.txt:   K for ALG.  Both maintain a counter C, initially zero, and
the us
er
rfc4226.txt:   authenticates itself by sending ALG(K,C) to the server.  The
latt
er
rfc4226.txt:   ALG(K,i) for some i in the range C,...,C + s-1, where s is
the
rfc4226.txt:   algorithm ALG is being used, knowing the system design, and
knowi
ng
rfc4226.txt:   ALG: K x {0,1}^c --> R.
rfc4226.txt:      A = ALG(K,C)
rfc4226.txt:         If A == ALG(K,i) then Win = TRUE; C = i + 1
rfc4472.txt:      8.1. NAT-PT with DNS-ALG
.....................................
..18
rfc4472.txt:8.1.  NAT-PT with DNS-ALG
rfc4472.txt:   The DNS-ALG component of NAT-PT [RFC2766] mangles A records
to lo
ok
rfc4635.txt:   HMAC-MD5.SIG-ALG.REG.INT name for authentication codes using
the
HMAC
rfc4635.txt:   ALG.REG.INT, based on MD5 [RFC1321].
rfc4635.txt:   The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers
are

rfc4635.txt:      Mandatory      HMAC-MD5.SIG-ALG.REG.INT
rfc4787.txt:         the NAT administrator to enable or disable each ALG
separat
ely.
rfc4787.txt:      standards track specifications that define an ALG can
update t
his
rfc4787.txt:         the NAT administrator to enable or disable each ALG
separat
ely.
rfc4852.txt:   Application Layer Gateway (ALG) between the incompatible
hosts.
rfc4852.txt:   diverse transition mechanisms.  For example, an ALG
collocated wi
th
rfc4924.txt:      proxies.  Furthermore, the ALG or proxy must be updated
whenev
er a
rfc4924.txt:   implementations.  No matter how well an ALG is implemented,
barri
ers
rfc4924.txt:   "transparent ALG" is a contradiction in terms.
rfc4961.txt:   Gateway (ALG) functionality.  Such NATs require that
endpoints us
e
rfc4966.txt:   2.  Issues Unrelated to an DNS-ALG . . . . . . . . . . . . .
. .
.  7
rfc4966.txt:   3.  Issues Exacerbated by the Use of DNS-ALG . . . . . . . .
. .
. 13
rfc4966.txt:   4.  Issues Directly Related to Use of DNS-ALG  . . . . . . .
. .
. 16
rfc4966.txt:     4.4.  DNS-ALG and Multi-Addressed Nodes  . . . . . . . . .
. .
. 19
rfc4966.txt:   o  Issues with NAT-PT DNS ALG (Application Layer Gateway) in
RFC
2766
rfc4966.txt:      [DNS-ALG-ISSUES]
rfc4966.txt:   o  NAT-PT DNS ALG Solutions [DNS-ALG-SOL]
rfc4966.txt:   Layer Gateway (ALG) for DNS (referred to as DNS-ALG in this
docum
ent)
rfc4966.txt:   NAT-PT could avoid the use of the DNS-ALG.
rfc4966.txt:   passed to the hosts in the absence of the DNS-ALG.
Therefore, th
is
rfc4966.txt:   document assumes that the DNS-ALG is an integral part of
NAT-PT;
rfc4966.txt:   accordingly, issues with the DNS-ALG must be considered as
issues
 for
rfc4966.txt:   Note that issues not specifically related to the use of the
DNS-A
LG
rfc4966.txt:   o  Issues that are independent of the use of a DNS-ALG and
are,
rfc4966.txt:   o  Issues that are exacerbated by the use of a DNS-ALG and
are,
rfc4966.txt:         ALG to create address mappings with limited lifetimes
means

rfc4966.txt:   o  Issues that result from the use of a DNS-ALG and are,
therefor
e,
rfc4966.txt:      *  Address selection issues and resource consumption in a
DNS-
ALG
rfc4966.txt:      *  Limitations on DNS security capabilities when using a
DNS-A
LG.
rfc4966.txt:2.  Issues Unrelated to an DNS-ALG
rfc4966.txt:   the consequences as part of the description of the FTP ALG.
Simi
lar
rfc4966.txt:   Assuming that the NAT-PT contains a colocated ALG for one of
the
rfc4966.txt:   relevant protocols, the ALG could replace the embedded IP
address
es
rfc4966.txt:   SCTP will need an associated "ALG" -- actually a Transport
Layer
rfc4966.txt:   naively implemented DNS-ALG could create such bindings from
spoof
ed
rfc4966.txt:3.  Issues Exacerbated by the Use of DNS-ALG
rfc4966.txt:   DNS-ALG in the NAT-PT to provide the mapped address needed to
rfc4966.txt:   IPv6 router for the site so that the DNS-ALG is able to
examine a
ll
rfc4966.txt:   These constraints are described in more detail in
[DNS-ALG-ISSUES
].
rfc4966.txt:   [DNS-ALG-SOL] proposes a solution for flows initiated from
the IP
v6
rfc4966.txt:   addresses would also use the NAT-PT DNS-ALG.
rfc4966.txt:   point of failure in the network.  The addition of the DNS-ALG
in
rfc4966.txt:   Using the DNS-ALG to create address bindings requires that
the
rfc4966.txt:   Additionally, the DNS-ALG needs to determine the initial
lifetime
 of
rfc4966.txt:   be determined heuristically.  The DNS-ALG does not know which
rfc4966.txt:   an extended ALG (which has all the issues discussed in
Section 2.
1)
rfc4966.txt:   The use of the DNS-ALG in NAT-PT introduces another
vulnerability

rfc4966.txt:   [DNS-ALG-ISSUES] exploits the use of DNS queries traversing
NAT-P
T to
rfc4966.txt:   [DNS-ALG-SOL] proposes to mitigate the DoS attack by using
Access

rfc4966.txt:4.  Issues Directly Related to Use of DNS-ALG
rfc4966.txt:   [DNS-ALG-ISSUES] discusses NAT-PT DNS-ALG issues with regard
to
rfc4966.txt:   address selection.  As specified in [RFC2766], the DNS-ALG
return
s
rfc4966.txt:   [DNS-ALG-SOL] proposes a solution that involves modification
to t
he
rfc4966.txt:   o  When a DNS AAAA query traverses the NAT-PT DNS-ALG, the
NAT-PT

rfc4966.txt:         it returns them.  The DNS-ALG then forwards this
response t
o
rfc4966.txt:         The NAT-PT DNS-ALG will intercept the error or empty
return
 and
rfc4966.txt:         IPv4 address, the ALG creates a binding and synthesizes
a
rfc4966.txt:      passing through a DNS ALG because the NAT-PT may have to
make
two
rfc4966.txt:   selection that is identified in [DNS-ALG-ISSUES].
Applications h
ave
rfc4966.txt:   no way of knowing that the IPv6 address returned from the
DNS-ALG
 is
rfc4966.txt:   through the NAT-PT DNS-ALG, the DNS-ALG will translate the
respon
se
rfc4966.txt:   happens because the DNS-ALG specified in [RFC2766] operates
rfc4966.txt:   state about queries passed through the DNS-ALG, and hence to
resp
ond
rfc4966.txt:4.4.  DNS-ALG and Multi-Addressed Nodes
rfc4966.txt:   these addresses.  Since the DNS-ALG in the NAT-PT has no
knowledg
e
rfc4966.txt:   to authenticate DNS responses.  The DNS-ALG modifies DNS
query
rfc4966.txt:   Workarounds have been proposed, such as making the DNS-ALG
behave

rfc4966.txt:   [DNS-ALG-ISSUES]  Durand, A., "Issues with NAT-PT DNS ALG in
rfc4966.txt:   [DNS-ALG-SOL]     Hallingby, P. and S. Satapati, "NAT-PT DNS
ALG
rfc4973.txt:       BIT CSPF - A CSPF algorithm support TLV
TE-NODE-TLV-CSPF-ALG
rfc4973.txt:   TE-NODE-TLV-CSPF-ALG             Section 8.1.2.3  0x8003
rfc5055.txt:   The algorithm identifier for SHA-1 is imported from
[PKIX-ALG].
It
rfc5055.txt:   defined in [PKIX-ALG] and [PKIX-ALG2], but other signature
algori
thms
rfc5055.txt:   certificate [PKIX-1].  Supported algorithms are defined in
[PKIX-
ALG]
rfc5055.txt:   specified in [PKIX-ALG].  SCVP servers that support
serverPublicK
eys
rfc5055.txt:   [PKIX-ALG]    Bassham, L., Polk, W., and R. Housley,
"Algorithms
and
rfc5245.txt:   If an ALG is SIP aware but not ICE aware, ICE will work
through i
t as
rfc5245.txt:   long as the ALG correctly modifies the SDP.  A correct ALG
rfc5245.txt:   o  The ALG does not modify the m and c lines or the rtcp
attribut
e if
rfc5245.txt:      depends on the state of the ALG:
rfc5245.txt:         If the ALG already has a binding established that maps
an
rfc5245.txt:         values in the m and c lines or rtcp attribute, the ALG
uses

rfc5245.txt:         If the ALG does not already have a binding, it creates
a ne
w
rfc5245.txt:   prevents the ALG from manipulating the SDP messages and
interferi
ng
rfc5245.txt:   to provide "generic" ALG functionality.  These generic ALGs
hunt
for
rfc5274.txt:   SignedData (see [CMS-ALG]).  Entities MAY verify other
signature
rfc5274.txt:   SignedData (see [CMS-ALG]).  Other signatures algorithms MAY
be u
sed
rfc5274.txt:   EnvelopedData (see [CMS-ALG]).  All entities SHOULD support
RSA-O
AEP
rfc5274.txt:   [CMS-ALG]          Housley, R., "Cryptographic Message Syntax
(CM
S)
rfc5382.txt:   Gateway (ALG) behavior that may interfere with NAT traversal.
rfc5382.txt:      ALG is left unspecified because of legacy concerns: as of
writ
ing
rfc5382.txt:      passive (PASV) mode by default and require an ALG to
traverse
rfc5382.txt:   privacy reasons or for ALG support) must ensure that TCP
packets
with
rfc5389.txt:   but misguided attempt at providing a generic ALG function.
Such
rfc5480.txt:   (ECC).  It updates RFC 3279 [PKI-ALG].  This document
specifies t
he
rfc5480.txt:   [PKI-ALG] and [PKI-ADALG], even though the associated text is
rfc5480.txt:   unaffected.  By updating all of the ASN.1 from [PKI-ALG] in
this
rfc5480.txt:     -- Note that in [PKI-ALG] the secp192r1 curve was referred
to a
s
rfc5480.txt:   The security considerations in [PKI-ALG] apply.
rfc5480.txt:   As noted in [PKI-ALG], the use of MD2 and MD5 for new
application
s is
rfc5480.txt:   Value [PKI-ALG].  If an implementation needs to use these
options
,
rfc5480.txt:   [PKI-ALG]    Bassham, L., Polk, W., and R. Housley,
"Algorithms a
nd
rfc5480.txt:   -- Note that in [PKI-ALG] the secp192r1 curve was referred to
as
rfc5597.txt:   needed for an Application Level Gateway (ALG) to function
properl
y.
rfc5753.txt:   static-static DH, which is specified in [CMS-ALG].
Ephemeral-sta
tic
rfc5753.txt:   specified jointly in the documents [CMS-ALG] and [CMS-DH].
rfc5753.txt:   [PKI-ALG].
rfc5753.txt:   in [CMS-ALG] and [CMS-SHA2].
rfc5753.txt:   in [PKI-ALG].
rfc5753.txt:   [CMS-ALG] and [CMS-AES].
rfc5753.txt:   algorithms are found in [CMS-ALG] and [CMS-AES].  The content
rfc5753.txt:   algorithms are found in [CMS-ALG] and [HMAC-SHA2].
rfc5753.txt:   ECDSA-Sig-Value is specified in [PKI-ALG].  Within CMS,
ECDSA-Sig
-
rfc5753.txt:   the elliptic curve domain parameters specified by [PKI-ALG].
rfc5753.txt:   [CMS-ALG], [CMS-AUTHENV], [CMS-DH], [CMS-SHA2], [FIPS180-3],
rfc5753.txt:   lists curves [PKI-ALG] for the key sizes.
rfc5753.txt:   sizes and message digest algorithms.  It also lists curves
[PKI-A
LG]
rfc5753.txt:   [CMS-ALG]      Housley, R., "Cryptographic Message Syntax
(CMS)
rfc5753.txt:   [PKI-ALG]      Turner, S., Brown, D., Yiu, K., Housley, R.,
and T
.
rfc5753.txt:   -- From [PKI-ALG]
rfc5753.txt:   -- From [CMS-ALG]
rfc5753.txt:   -- Message Digest Algorithms: Imported from [PKI-ALG] and
[RSAOAE
P]
rfc5753.txt:   -- Signature Algorithms: Imported from [PKI-ALG]
rfc5753.txt:   -- Key Wrap Algorithms: Imported from [CMS-ALG] and [CMS-AES]
rfc5753.txt:   -- Content Encryption Algorithms: Imported from [CMS-ALG]
rfc5753.txt:   -- Originator Public Key Algorithms: Imported from [PKI-ALG]
rfc5753.txt:   -- [PKI-ALG]
rfc5753.txt:   --   commented out in [PKI-ALG]  implicitCurve   NULL
rfc5753.txt:   --   commented out in [PKI-ALG]  specifiedCurve
SpecifiedECDomai
n
rfc5753.txt:   --   commented out in [PKI-ALG]  ...
rfc5753.txt:-- ECDSA Signature Value: Imported from [PKI-ALG]
rfc5753.txt:-- [PKI-ALG]
rfc5753.txt:--   commented out in [PKI-ALG] implicitCurve   NULL
rfc5753.txt:--   commented out in [PKI-ALG] specifiedCurve
SpecifiedECDomain
rfc5753.txt:--   commented out in [PKI-ALG] ...
rfc5780.txt:     3.6.  Detecting a Generic Application Level Gateway (ALG)
. .
. 11
rfc5780.txt:3.6.  Detecting a Generic Application Level Gateway (ALG)
rfc5780.txt:   to provide "generic" ALG functionality.  These generic ALGs
hunt
for
rfc5780.txt:   not match, there is a NAT with a generic ALG in the path.
This t
est
rfc5857.txt:      [CRYPTO-ALG] (or its successor).
rfc5857.txt:   [CRYPTO-ALG] Manral, V., "Cryptographic Algorithm
Implementation
rfc5858.txt:      [CRYPTO-ALG] (or its successor).
rfc5858.txt:   [CRYPTO-ALG]  Manral, V., "Cryptographic Algorithm
Implementation

rfc5912.txt:   -- Note that in [PKI-ALG] the secp192r1 curve was referred to
as
rfc6071.txt:   IKE-ALG (Application Level Gateway) that translates policies
from

rfc759.txt:  14     ENCRYPT   CODE(1),COUNT(3),ALG-ID(1),
rfcxx00.txt:PEM-ALG    Privacy Enhancement for Internet Electronic Mail:
1
423

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 16 Mar 2011 13:02:46 +0100

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

> Of Parthasarathi R (partr)
> Sent: 15 March 2011 09:54
> To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen (fandreas);
> mmusic

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 16 Mar 2011 18:15:19 +0530

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

> Behalf Of Parthasarathi R (partr)
> To: Christer Holmberg; Dan Wing (dwing); Flemming Andreasen 
> (fandreas); mmusic
> 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).
> 

> 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
> 
> 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
> 
> Behalf Of Dan Wing
> 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
> "ALG", and packets are sent from the IP address of the SIP "ALG".  
> This functionality is most often called a "server"

> functions common in NATs, which _do_ sometimes have SIP ALGs 
> implemented in them.
> 

> B2BUA, at least as best I understand the definition of a B2BUA, so 
> B2BUA seems best.
> 
> d
> 
>

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 16 Mar 2011 13:49:25 +0100

Hi Christer,

I can also help with a review.

After a quick check, it appears that references to IETF drafts need to
be updated.
3GPP has standardised protocols for the Ix and Iq reference points in
the mean time, and references to the related stage 2 and stage 3 specs
should also be added (Ix: TS 29.162, TS 29.238; Iq: TS 23.334, TS
29.234)

Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Christer Holmberg
Sent: Saturday, March 12, 2011 8:41 AM
To: Flemming Andreasen; Elwell, John
Cc: mmusic
Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with
middleboxes ?

Hi,

I am willing to review.

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] On Behalf Of
Flemming Andreasen [[email-masked]]
Sent: Friday, March 11, 2011 6:46 PM
To: Elwell, John
Cc: mmusic
Subject: Re: [MMUSIC] Continued WG interest in SDP offer/answer with
middleboxes ?

Thanks

-- Flemming

Flemming,

John

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 29 Mar 2011 19:27:38 +0530

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.

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 30 Mar 2011 11:22:12 +0200

> 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

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

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 31 Mar 2011 16:30:55 +0530

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.

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

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 31 Mar 2011 16:34:11 +0530

|should cause any issues for the draft I think.

Meant shouldn't cause any issues for the draft I think -:)

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Muthu ArulMozhi Perumal
|(mperumal)
|Sent: Thursday, March 31, 2011 4:31 PM
|To: Dan Wing (dwing); Parthasarathi R (partr); DRAGE, Keith (Keith);
Christer Holmberg; Flemming
|Andreasen (fandreas); mmusic
|Subject: Re: [MMUSIC] Continued WG interest in
SDPoffer/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.
|
|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

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 31 Mar 2011 16:13:05 +0200

> Sent: Thursday, March 31, 2011 1:01 PM
> To: Dan Wing (dwing); Parthasarathi R (partr); DRAGE, Keith (Keith);
> Christer Holmberg; Flemming Andreasen (fandreas); mmusic
> 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

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 31 Mar 2011 20:11:50 -0400

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

---

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

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.

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Apr 2011 08:57:46 +0200

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

> use-cases/deployments -- if we want to make it, then I think
> it would be a scope creep.
>
> Muthu
>
> |> 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
> |>>
> |>> |> changes to how RFC 3303 describes it.
> |>> |
> |>> |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
> |>> |>
> |>> |> |Fig 1 of
> draft-ietf-mmusic-media-path-middleboxes-03.txt exactly
> |>> fits