headers
Joe | 1 Jul 2006 02:22
Picon
Gravatar

SIP Transport Selection Question

Under the Clients section 3261 states:

"If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 congestion controlled transport protocol, such as TCP."

Is this for "requests" (INVITE, etc.) only? What if an INVITE were sent as UDP but a response (200 OK) were to come back with extra headers which breached the MTU? Must the node sending the OK switch the transport to TCP? Is this optional?

Regards,
Joe

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 0 comments |
headers
Cullen Jennings | 2 Jul 2006 03:02
Picon
Favicon
Gravatar

Re: I-D ACTION:draft-ietf-sip-outbound-04.txt


On Jun 29, 2006, at 3:28 PM, Jeroen van Bemmel wrote:

> We've had some VERY long and extensive discussions on this  
> (starting with http://www1.ietf.org/mail-archive/web/sip/current/ 
> msg13677.html) but the draft is still not addressing some of the  
> issues that were raised
>
> 1) The UAC needs a positive indication that the selected proxy can  
> indeed handle STUN packets without choking on them. It is not  
> sufficient if the URI it is configured with says 'keepalive=stun',  
> that's a wish but no guarantee.
>
>

Why is this a wish not a guarantee? I'm under the impression that  
devices that follow the RFCs should not have problems with this. I  
understand the argument that we might want DHCP or DNS to be a way to  
discover this configuration information but I think either of theses  
systems, not to mention the config-framework, can be used to get an  
URI. Keep in mind the thing that drove us to this approach - sig- 
comp. We need sig-comp to work too so however we deal with the  
approach for configuration of the URI so it has the sig-comp tag will  
also work for this. These options were discussed several times - at  
one point I was proposing a DNS scheme but I got the input that it  
could and should be separated.

>
> 2) Section 5.3: the Edge Proxy MUST Record-Route dialog forming  
> INVITE requests that it forwards over the flow towards the UA  
> (reverse direction is not strictly necessary, but probably common  
> too). If it does not do this, an ACK for 2xx cannot arrive. For  
> incoming SUBSCRIBE it might work without (the NOTIFY could create a  
> direct flow towards the target or some other proxy, using the local  
> socket as a Contact), but then there would be an issue with keeping  
> that flow alive (the STUN question). Probably safer to say that (in  
> addition to MUST for INVITE) "the Edge Proxy SHOULD Record-Route  
> all dialog-forming requests it forwards to the UA"

This could be one way to solve the problem -  others are possible  
too. I don't think this is in scope for outbound. I don't think  
outbound does anything that makes it so this solution (or some of the  
other proposed ones) can't be used. A long time ago, outbound got  
stuck in a huge rat hole of trying to define how every system should  
form it's high reliability and high availability solutions. That was  
too big a task to take on so I am happy to leave it out of scope as  
long as people can build good system.

>
> 3) The Proxy-Require mechanism we have discussed could be useful to  
> UACs that want to ensure that a selected edge proxy supports  
> outbound, aborting if not.
>

I'll let Rohan reply to this but I don't think I see what problem it  
solves.

> 4) (minor remark) Perhaps some words could be added that the UAC  
> SHOULD perform keepalives when configured to do so, even if it  
> detects that there is no NAT. There could be a transparent firewall  
> device that needs to be kept open.
>

I agree this is the behavior we want  - I thought it already more or  
less said that. It  does not suggest detecting if their is a NAT  
there at all - if the URI has the tag, you do keep alive.

> Regards,
>
> Jeroen

I'm sorry my time is limited on this right now but I'm reading a ton  
of documents and posting comments so forgive me as I suffer from a  
response implosion problem.

Cullen <my crazy comments as an individual only>

>
>
>
>
>
>
> ----- Original Message ----- From: <Internet-Drafts <at> ietf.org>
> To: <i-d-announce <at> ietf.org>
> Cc: <sip <at> ietf.org>
> Sent: Wednesday, June 28, 2006 12:50 AM
> Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt
>
>
>> A New Internet-Draft is available from the on-line Internet-Drafts  
>> directories.
>> This draft is a work item of the Session Initiation Protocol  
>> Working Group of the IETF.
>>
>> Title : Managing Client Initiated Connections in the
>>                          Session Initiation Protocol (SIP)
>> Author(s) : C. Jennings, R. Mahy
>> Filename : draft-ietf-sip-outbound-04.txt
>> Pages : 34
>> Date : 2006-6-27
>>
>> The Session Initiation Protocol (SIP) allows proxy servers to
>>   initiate TCP connections and send asynchronous UDP datagrams to  
>> User
>>   Agents in order to deliver requests.  However, many practical
>>   considerations, such as the existence of firewalls and Network
>>   Address Translators (NATs), prevent servers from connecting to User
>>   Agents in this way.  This specification defines behaviors for User
>>   Agents, registrars and proxy servers that allow requests to be
>>   delivered on existing connections established by the User  
>> Agent.  It
>>   also defines keep alive behaviors needed to keep NAT bindings open
>>   and specifies the usage of multiple connections.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-04.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> i-d-announce-request <at> ietf.org with the word unsubscribe in the  
>> body of the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- 
>> announce
>> to change your subscription settings.
>>
>>
>> Internet-Drafts are also available by anonymous FTP. Login with  
>> the username
>> "anonymous" and a password of your e-mail address. After logging in,
>> type "cd internet-drafts" and then
>> "get draft-ietf-sip-outbound-04.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> mailserv <at> ietf.org.
>> In the body type:
>> "FILE /internet-drafts/draft-ietf-sip-outbound-04.txt".
>>
>> NOTE: The mail server at ietf.org can return the document in
>> MIME-encoded form by using the "mpack" utility.  To use this
>> feature, insert the command "ENCODING mime" before the "FILE"
>> command.  To decode the response(s), you will need "munpack" or
>> a MIME-compliant mail reader.  Different MIME-compliant mail readers
>> exhibit different behavior, especially when dealing with
>> "multipart" MIME messages (i.e. documents which have been split
>> up into multiple messages), so check your local documentation on
>> how to manipulate these messages.
>>
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>
>
> ---------------------------------------------------------------------- 
> ----------
>
>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors <at> cs.columbia.edu for questions on current sip
>> Use sipping <at> ietf.org for new developments on the application of sip
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sipping <at> ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 5 comments |
headers
Cullen Jennings | 2 Jul 2006 19:02
Picon
Favicon
Gravatar

Re: Comments on rosenberg-sip-identity-coexistence


On Jun 30, 2006, at 12:57 PM, Hadriel Kaplan wrote:

>
>> From: Cullen Jennings [mailto:fluffy <at> cisco.com]
>>
>> I think one of the major reason for creating PAI was to provide
>> malicious call trace for anonymous calls. I don't think it was for
>> dealing with spoofing the From header. If that was the goal, we could
>> have solved it just by having device that ends up inserting the PAI
>> just reject any request that has spoofed From headers.
>
> I agree with you, but it is used for detecting suspicious From  
> headers even
> for non-anonymous calls.  Obviously if the proxy inserting the PAI  
> _knows_ a
>> From is spoofed, it could/should reject it.  But if the proxy does  
>> _not_
> know whether the From is spoofed or not, it just doesn't insert the  
> PAI.
> For example, ingress proxy receives a request from another domain -  
> if it
> trusts the domain it passes the PAI (or inserts one).  If it does  
> not trust
> the domain, it removes PAI, but doesn't want to reject the request  
> (else it
> wouldn't accept requests from such untrusted domains to begin with).

I see your point, I can see how a proxy that is deciding not to  
remove a PAI might not know a From was spoofed. I don't see how a  
proxy that was going to *insert* a PAI would know what to put in the  
PAI and not be able to know if a PAI was spoofed. 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 2 comments |
headers
Cullen Jennings | 2 Jul 2006 19:17
Picon
Favicon
Gravatar

Re: Comments on rosenberg-sip-identity-coexistence


On Jun 30, 2006, at 2:59 PM, Hadriel Kaplan wrote:

> More inline...
>
>> -----Original Message-----
>> From: Cullen Jennings [mailto:fluffy <at> cisco.com]
>>
>> case 2) ingress B2B on terminating domain - this is fairly easy too.
>> This B2BUA resigns the incoming request. To do this it uses a cert
>> that has a wildcard for all domain - the UAS need to be configured to
>> have this cert in it root trust list. What the UAS is doing here is
>> delegating that it trust any name that the
>>   B2BUA trusts. This is the sort of trust delegation one wants to be
>> able to make.
>
> I don't know how practical that is to do on the UASs.  It seems to  
> me like
> most UASs simply trust whatever their proxy tells them, and that  
> should be
> ok if we can guarantee what their proxy tells them is true. (a big IF)

For UA that don't do Identity, I think what I proposed works with no  
changes to them. For UAs that do do Identity, they need to have a  
list or root certs they trust. It seems like when you are determining  
what the UA trusts you are setting up this list. Again, in this case  
I don't see what does not work about my proposal.

>
> If a b2bua before that proxy but in the same trust domain verified the
> identity, and can somehow tell the proxy it verified the identity,  
> and even
> tell the UAS it did as well, why do more?  That's what the PAI  
> does.  It may
> not be what it was supposed to do, but it's what it seems to now.
>

So in the case of an anonymous call where the real caller identity is  
in the PAI for malicious call trace reasons, what are you proposing  
to do. Does the proxy strip the PAI before sending it to the UAS?   
How would the proxy know? Do you deliver the PAI to the UA - this  
would violate privacy laws in Europe. I don't see how this would work.

>
>> case 3) a B2BUA in a transit provider between the originating and
>> terminating domain. There are two very different cases here - one is
>> where the transit provider is an intermediate in providing PSTN
>> termination services and using E.164 addresses. For example some
>> company, contracts its PSTN termination from say MCI who for numbers
>> in Australia perhaps uses Telstra. The company wants to see the phone
>> number asserted by MCI, not Telstra  - it is MCI they trust and can
>> make an authorization decision based on. They have no idea who
>> Telstra is so whatever telstra wants to claim is useless for the
>> company. The point is, whatever things Telstra might assert to MCI,
>> the company wants MCI to make an assertion that the company can use
>> for it authorization decision. In these cases the transit B2BUA needs
>> to resign things.
>
> And that's the rub.  The real use/value of Identity, IMHO, is for the
> transit case - period.  Within a domain or between just 2, and  
> there are
> other ways to trust, except for the really paranoid.  But the  
> longer the
> trust chain of transits is, the greater the probability the chain  
> is broken.
>
>
> When I looked at the original identity draft I thought ok - the  
> b2bua/proxy
> egress can be the signer and the ingress b2bua/proxy can be the  
> verifier.
> Of course then I immediately thought if the 2 domains are connected  
> by just
> those 2 elements, why bother doing the signing/verifying for a  
> single hop
> that is going to be TLS/IPSEC anyway??  Use the PAI you already have.
>
> But for transit cases: it requires the transit domain(s) to either  
> (1) not
> muck with contact, call-id, and bodies, or (2) support identity,  
> and to
> somehow re-sign with something that the verifier in the next domain 
> (s) will
> accept, which goes back to hop-by-hop trust kinda.  But changing  
> (1) or (2)
> is out of the local (and final) domain's control to change - they  
> need the
> transit domain(s) to change, and that's a much bigger hurdle.
>
>

Ok, I am done't think I am manging to explaim myself. Say A has a  
contract with B and B has a crontract with C. Now a call arrives at  
C, it seem that C wants a assertion to be made by B. Anything A says  
to C is clsoe to useless because C has no clue who A even is. I guese  
I feel like we need to sort out the requirements for what we want in  
a transit case and then we might be able to figure out a solution.

>> As a last note, I do think there are workable solutions for the B2BUA
>> case. Having UA accept message with a bad Identity header but that
>> have a PAI seriously breaks Identify. One of the key things that
>> Identity provides is a close to end to end integrity for the bodies.
>
> Yes, it signed the body, and contact, but I consider that its fatal  
> flaw.
> It should have stuck with the From (and Date and whatever else it  
> thinks is
> needed for a reasonable nonce).  The body I know is a hard one to  
> not sign
> (it's so tempting!).  But sign the contact?  What does that have to  
> do with
> identity?
>
>
>> This breaks this and we have no other good way to provide this. What
>> I am suggesting above provides a way to keep this integrity property
>> so that no device can tamper with the integrity other than devices
>> that the UAS or UAC explicitly trusts to tamper with the integrity. I
>> think this is a fairly important property and achievable.
>
> What about just splitting it into 2 Identity headers/signatures?   
> One for
> the From and nonce-ish stuff, the other for the body and same nonce- 
> ish
> stuff.  If a middle-man wants to modify the body, he verifies and  
> re-signs
> that second signature, or if the middle-man is unaware of identity  
> then the
> next one can decide what to do with a bad signature for a body but  
> good
> signature for From.
>

The From itself has no intrinsic value - what you are trying to sign  
is that some body came from the person in the From header. If the  
 From header and it's signature can be cut and paste from one message  
to another, Identity would fail to solve any security problems.

> So when the final UAS gets it (or its domain verifier) she says  
> "hmmm... the
>> From was definitely signed by the URI domain company.com, but this  
>> body is
> signed by provider.com who I trust... ok, I can trust that", vs. "I  
> see
> company.com signed the From but the body was broken... this is  
> suspicious".
> This way a b2bua can change the body but doesn't have to have a  
> certificate
> matching the From-uri domain to do so, and the UAS can decide if  
> it's kosher
> for the b2bua-domain to change the body, while also verifying the  
> From is of
> the right domain.  I haven't thought it through, but it sounds ok.

You are proposing almost exactly the same thing I am. The way you are  
thinking of handling the body, just use that handling for both.

>
> -hadriel

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 8 comments |
headers
Jeroen van Bemmel | 2 Jul 2006 19:21
Picon

Re: I-D ACTION:draft-ietf-sip-outbound-04.txt

Cullen,

see inline

Best regards,

Jeroen

----- Original Message ----- 
From: "Cullen Jennings" <fluffy <at> cisco.com>
To: "Jeroen van Bemmel" <jbemmel <at> zonnet.nl>
Cc: <sip <at> ietf.org>
Sent: Sunday, July 02, 2006 3:02 AM
Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt

>
> On Jun 29, 2006, at 3:28 PM, Jeroen van Bemmel wrote:
>
>> We've had some VERY long and extensive discussions on this  (starting 
>> with http://www1.ietf.org/mail-archive/web/sip/current/ msg13677.html) 
>> but the draft is still not addressing some of the  issues that were 
>> raised
>>
>> 1) The UAC needs a positive indication that the selected proxy can 
>> indeed handle STUN packets without choking on them. It is not  sufficient 
>> if the URI it is configured with says 'keepalive=stun',  that's a wish 
>> but no guarantee.
>>
>>
>
> Why is this a wish not a guarantee?

Because the configuration may be wrong, ie the entity that provisioned the 
URI thinks the element supports outbound, but in fact it does not. There can 
be various reasons for this, like invalid manual provisioning, some edge 
proxy is replaced with one that does not support outbound and someone 
forgets to update DNS, etc

I expect you will see a lot of what I'd call "opportunistic outbound": 
implementations that add 'keepalive=stun' to the URI for registration, in 
the hope that it is supported. There is nothing in the current spec to 
prevent this, but I believe it should be discouraged (that is, the sending 
of STUN packets multiplexed on SIP ports to hosts for which support is 
unknown).

> I'm under the impression that  devices that follow the RFCs should not 
> have problems with this. I  understand the argument that we might want 
> DHCP or DNS to be a way to  discover this configuration information but I 
> think either of theses  systems, not to mention the config-framework, can 
> be used to get an  URI. Keep in mind the thing that drove us to this 
> approach - sig- comp. We need sig-comp to work too so however we deal with 
> the  approach for configuration of the URI so it has the sig-comp tag will 
> also work for this. These options were discussed several times - at  one 
> point I was proposing a DNS scheme but I got the input that it  could and 
> should be separated.
>

I suppose a similar argument applies to sigcomp: it should have been 
prevented that implementations try it towards hosts that are not known to 
support it. A difference may be that sigcomp is also used in the first 
request, while STUN can be postponed

A second reason for providing such a 'keepalive confirmation' is that it 
also allows cases where the registrar / edge proxy is able to determine that 
keep-alives are in fact not needed (eg because it has authorative knowledge 
that there is no NAT or firewall in between). Not including 'keepalive=stun' 
would avoid unnecessary traffic. (note that perhaps a different mechanism 
would be more appropriate, eg "keepalive=not-needed" instead, to distinguish 
between not supported and not needed)

>>
>> 2) Section 5.3: the Edge Proxy MUST Record-Route dialog forming  INVITE 
>> requests that it forwards over the flow towards the UA  (reverse 
>> direction is not strictly necessary, but probably common  too). If it 
>> does not do this, an ACK for 2xx cannot arrive. For  incoming SUBSCRIBE 
>> it might work without (the NOTIFY could create a  direct flow towards the 
>> target or some other proxy, using the local  socket as a Contact), but 
>> then there would be an issue with keeping  that flow alive (the STUN 
>> question). Probably safer to say that (in  addition to MUST for INVITE) 
>> "the Edge Proxy SHOULD Record-Route  all dialog-forming requests it 
>> forwards to the UA"
>
> This could be one way to solve the problem -  others are possible  too. I 
> don't think this is in scope for outbound. I don't think  outbound does 
> anything that makes it so this solution (or some of the  other proposed 
> ones) can't be used. A long time ago, outbound got  stuck in a huge rat 
> hole of trying to define how every system should  form it's high 
> reliability and high availability solutions. That was  too big a task to 
> take on so I am happy to leave it out of scope as  long as people can 
> build good system.
>

I agree that the way in which high reliability/availability is done should 
be left to implementations. However, I don't see how ACK for 2xx could 
arrive without Record-Route (the contents of the R-R URI, and wheteher it is 
used for flow mapping is an implementation issue. However, I think its use 
should be mandated).

>>
>> 3) The Proxy-Require mechanism we have discussed could be useful to  UACs 
>> that want to ensure that a selected edge proxy supports  outbound, 
>> aborting if not.
>>
>
> I'll let Rohan reply to this but I don't think I see what problem it 
> solves.
>

It ensures early abortion of the registration process if outbound is not 
supported. As it is currently defined, a UAC has no way of determining 
whether an edge-proxy supports outbound (the flag in the provisioned URI 
makes it very likely, but not guaranteed)

A second usage of a Proxy-Require mechanism is perhaps out of scope for 
outbound, but related to keep-alive (which, as others have pointed out, 
should perhaps be separated). Consider an UAC behind NAT that sends an 
INVITE. Note that it could manage perfectly well without outbound support 
(it could simply not REGISTER), but it would need to keep the flow towards 
its peer open. If it is somehow able to determine that the peer does not 
support STUN, and it cannot use TCP keepalive, what should it do? One way 
could be to ask a proxy that supports keepalives to stay in the signaling 
path. It need not be the same proxy used for registration (but it might well 
be). For this scenario, the UAC would need a way to ask the proxy to provide 
keep-alive services. "Proxy-Require: keep-alive" would be one way; semantics 
would be that the proxy MUST Record-Route such a request (as discussed in a 
parallel thread, another reason is that the ACK might contain the same 
Proxy-Require)

>> 4) (minor remark) Perhaps some words could be added that the UAC  SHOULD 
>> perform keepalives when configured to do so, even if it  detects that 
>> there is no NAT. There could be a transparent firewall  device that needs 
>> to be kept open.
>>
>
> I agree this is the behavior we want  - I thought it already more or  less 
> said that. It  does not suggest detecting if their is a NAT  there at 
> all - if the URI has the tag, you do keep alive.
>

and if there is no such tag, it MUST NOT do keep alive (or at least not 
STUN, TCP keepalives would be harmless) ?

>
>> Regards,
>>
>> Jeroen
>
> I'm sorry my time is limited on this right now but I'm reading a ton  of 
> documents and posting comments so forgive me as I suffer from a  response 
> implosion problem.
>
> Cullen <my crazy comments as an individual only>
>
>>
>>
>>
>>
>>
>>
>> ----- Original Message ----- From: <Internet-Drafts <at> ietf.org>
>> To: <i-d-announce <at> ietf.org>
>> Cc: <sip <at> ietf.org>
>> Sent: Wednesday, June 28, 2006 12:50 AM
>> Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-04.txt
>>
>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>> This draft is a work item of the Session Initiation Protocol  Working 
>>> Group of the IETF.
>>>
>>> Title : Managing Client Initiated Connections in the
>>>                          Session Initiation Protocol (SIP)
>>> Author(s) : C. Jennings, R. Mahy
>>> Filename : draft-ietf-sip-outbound-04.txt
>>> Pages : 34
>>> Date : 2006-6-27
>>>
>>> The Session Initiation Protocol (SIP) allows proxy servers to
>>>   initiate TCP connections and send asynchronous UDP datagrams to  User
>>>   Agents in order to deliver requests.  However, many practical
>>>   considerations, such as the existence of firewalls and Network
>>>   Address Translators (NATs), prevent servers from connecting to User
>>>   Agents in this way.  This specification defines behaviors for User
>>>   Agents, registrars and proxy servers that allow requests to be
>>>   delivered on existing connections established by the User  Agent.  It
>>>   also defines keep alive behaviors needed to keep NAT bindings open
>>>   and specifies the usage of multiple connections.
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-04.txt
>>>
>>> To remove yourself from the I-D Announcement list, send a message to
>>> i-d-announce-request <at> ietf.org with the word unsubscribe in the  body of 
>>> the message.
>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- announce
>>> to change your subscription settings.
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP. Login with  the 
>>> username
>>> "anonymous" and a password of your e-mail address. After logging in,
>>> type "cd internet-drafts" and then
>>> "get draft-ietf-sip-outbound-04.txt".
>>>
>>> A list of Internet-Drafts directories can be found in
>>> http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>
>>> Internet-Drafts can also be obtained by e-mail.
>>>
>>> Send a message to:
>>> mailserv <at> ietf.org.
>>> In the body type:
>>> "FILE /internet-drafts/draft-ietf-sip-outbound-04.txt".
>>>
>>> NOTE: The mail server at ietf.org can return the document in
>>> MIME-encoded form by using the "mpack" utility.  To use this
>>> feature, insert the command "ENCODING mime" before the "FILE"
>>> command.  To decode the response(s), you will need "munpack" or
>>> a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>> exhibit different behavior, especially when dealing with
>>> "multipart" MIME messages (i.e. documents which have been split
>>> up into multiple messages), so check your local documentation on
>>> how to manipulate these messages.
>>>
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>>
>>
>>
>> ---------------------------------------------------------------------- 
>> ----------
>>
>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol
>>> Use sip-implementors <at> cs.columbia.edu for questions on current sip
>>> Use sipping <at> ietf.org for new developments on the application of sip
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors <at> cs.columbia.edu for questions on current sip
>> Use sipping <at> ietf.org for new developments on the application of sip 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 3 comments |
headers
Cullen Jennings | 2 Jul 2006 19:44
Picon
Favicon
Gravatar

Re: I-D ACTION:draft-ietf-sip-outbound-04.txt


On Jul 2, 2006, at 10:21 AM, Jeroen van Bemmel wrote:

>
>>> 4) (minor remark) Perhaps some words could be added that the UAC   
>>> SHOULD perform keepalives when configured to do so, even if it   
>>> detects that there is no NAT. There could be a transparent  
>>> firewall  device that needs to be kept open.
>>>
>>
>> I agree this is the behavior we want  - I thought it already more  
>> or  less said that. It  does not suggest detecting if their is a  
>> NAT  there at all - if the URI has the tag, you do keep alive.
>>
>
> and if there is no such tag, it MUST NOT do keep alive (or at least  
> not STUN, TCP keepalives would be harmless) ?

I'm sympathetic to what you are saying as I had originally proposed  
that it be allowed to do this - I pointed out the a SIP server would  
reject the message. Lots of people felt strongly that we should not  
send STUN messages to SIP servers that did not support it. The issue  
came up in some WG meeting - there was strong consensus that we  
should not send keep alive to things that did not support them. 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 0 comments |
headers
Cullen Jennings | 2 Jul 2006 19:59
Picon
Favicon
Gravatar

Re: I-D ACTION:draft-ietf-sip-outbound-04.txt


On Jul 2, 2006, at 10:21 AM, Jeroen van Bemmel wrote:

>>> 1) The UAC needs a positive indication that the selected proxy  
>>> can indeed handle STUN packets without choking on them. It is  
>>> not  sufficient if the URI it is configured with says  
>>> 'keepalive=stun',  that's a wish but no guarantee.
>>>
>>>
>>
>> Why is this a wish not a guarantee?
>
> Because the configuration may be wrong, ie the entity that  
> provisioned the URI thinks the element supports outbound, but in  
> fact it does not. There can be various reasons for this, like  
> invalid manual provisioning, some edge proxy is replaced with one  
> that does not support outbound and someone forgets to update DNS, etc

Well totally ignoring anything to do with outbound - I don't really  
see how this is different from when someone configure the proxy as  
foo.com when it is supposed to be bar.com

I do think it is important to get sip so that a user might configure  
an AOR name and password and everything else just happens but that is  
the point of the config framework. I agree configuration is a  
nightmare today and we need to make it easier.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 1 comment |
headers
Jeroen van Bemmel | 2 Jul 2006 20:41
Picon

Re: I-D ACTION:draft-ietf-sip-outbound-04.txt

>> Because the configuration may be wrong, ie the entity that  provisioned 
>> the URI thinks the element supports outbound, but in  fact it does not. 
>> There can be various reasons for this, like  invalid manual provisioning, 
>> some edge proxy is replaced with one  that does not support outbound and 
>> someone forgets to update DNS, etc
>
> Well totally ignoring anything to do with outbound - I don't really  see 
> how this is different from when someone configure the proxy as  foo.com 
> when it is supposed to be bar.com
>

Conceptually not so different, but there would be a good chance that foo.com 
would either accept nothing or SIP on common SIP ports. The problem is that 
STUN is sent to the same port. Were it a different port, then the risk would 
be much lower. The combination of non-SIP (even binary) and same port makes 
it troublesome.

> I do think it is important to get sip so that a user might configure  an 
> AOR name and password and everything else just happens but that is  the 
> point of the config framework. I agree configuration is a  nightmare today 
> and we need to make it easier.

Easier and more foolproof, and more easy to debug / trace when/where things 
go wrong. For all of this, explicit confirmation of outbound support helps. 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 0 comments |
headers
Cullen Jennings | 2 Jul 2006 21:55
Picon
Favicon
Gravatar

draft-ietf-sip-gruu-09


This looks good - a few comments - all very trivial

Does this update 3261? If so, nice if header on first page had that

Section 3 - Long lived definition. I'm really not sure what it means  
to say that a GRUU has a long life than any of the registrations or  
that it is viable for every. I'm not sure it changes behavior of  
anything. Is the important property that if the same AOR/Instance  
registers two different times it gets the same AOR? Anyways, I can  
live with the text exactly as is but I was not getting why it was  
important.

Figure 1: On the diagonal arrow between GRUU and contact, I think the  
end near contact should have "0..1" and the end near the GRUU should  
have "0..n" - right now this is swapped.

Section 6, page 12, 4th para or so ... you are talking about mid- 
dialog requests. Might be nice to mention how a transaction stateful  
proxy knows if something is a middialog request or not.

Section 6, last para before section 7. I'm not sure I get how  
anything behaves differently from an unbound GRUU that exists vs the  
GRUU does not exist. Again, i don't have some huge problem with  
current text but when I read it, it makes me wonder if there is some  
difference which I should understand.

Section 7.1.1.1 - There has been some problems with the way 3261  
allowed a user to install forwarding rules using a REGISTER request.  
Part of the problem is that it allows an amplification attack on  
someone else that did not provide any consent. It makes me wonder if  
now that we have the consent framework moving forward, do we really  
want to continue down this path. I realize this is pretty orthogonal  
problem to GRUU.

Section 8.1.1 - 2nd para. You have "However, that AOR will be  
rewritten ..." - I found this hard to follow. Is it the request URI?  
I'm not sure how to fix but you might want to have a read of the end  
of that para and see if it is all clear to you.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 7 comments |
headers
Jeroen van Bemmel | 2 Jul 2006 22:10
Picon

Re: I-D ACTION:draft-ietf-sip-outbound-04.txt

Something more about Proxy-Require for outbound:

>>
>> 3) The Proxy-Require mechanism we have discussed could be useful to  UACs 
>> that want to ensure that a selected edge proxy supports  outbound, 
>> aborting if not.
>>
>
> I'll let Rohan reply to this but I don't think I see what problem it 
> solves.
>

There's another, more fundamental reason for this. The draft defines an 
option-tag which can occur in Supported, Require, Proxy-Require, and 
Unsupported headers. For each of these cases the semantics and expected 
behavior should be defined, either in this draft or implicitly (eg based on 
RFC3261)

Without stating otherwise, the default behavior for Proxy-Require would be: 
return 420 Bad Extension if not understood, else process as defined for that 
feature. In particular, for the current draft a proxy would not remove the 
Proxy-Require header from the request it forwards. So if an UAC adds 
Proxy-Require, it means that every proxy on the path must support it.

This is not required nor desired, hence we'd better state explicitly that a 
proxy needs to remove any Proxy-Require: outbound when forwarding

Regards,

Jeroen 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
Permalink | Reply | 0 comments |

Gmane