Subject: RE: [Sipping] new draft on session policies in SIP

From: David Oliver <[email-masked]>
Date: Fri, 21 Jun 2002 11:24:12 -0500

Henry,

STUN is probably the best thing available for now, providing you can get
STUN in your client, locate a STUN server, and STUN can traverse your
provider's NAT.

In the longer term, clients should only need to do minimal work in
traversing NATs and firewalls, i.e. substituting addresses into SDP. Even
with IPv6, firewalls will still be an issue.

Returning to the hotel example, consider a user (hotel guest), who wishes to
set up a wideband (full screen) video conference, which would use a sizeable
portion of the hotel's Internet connection. To ensure reliable operation,
the user would reserve (and arrange to pay for - this is a hotel) the
resources ahead of time, by accessing the hotel's web site, or indirectly
through the hotel staff. Managing this via the hotel's Middleware-aware
Proxy is much more realistic than configuring the client for this one time
event.

Regards,

David C. Oliver
Principal Engineer
SecureLogix Corp
Email: [email-masked] <mailto:[email-masked]>
Tel:   210.402.9669
Fax:   210.402.6996 

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]]
Sent: Thursday, June 20, 2002 4:48 PM
To: 'David Oliver'; 'Jonathan Rosenberg'; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] new draft on session policies in SIP

> A much better solution would be for the ISP to provide a 
> NAT-managing SIP proxy as part of their service, allowing 
> simple NAT-aware SIP clients to traverse their NAT.

Yes, that would be ideal, but unfortunately may not be in the cards any
time soon for users having DSL provided by a LEC.
Is there any other alternative to STUN for such DSL subscribers?
(I don't believe there is).

Thanks, Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of David Oliver
> Sent: Thursday, June 20, 2002 8:19 AM
> To: 'Henry Sinnreich'; David Oliver; 'Jonathan Rosenberg'; 
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] new draft on session policies in SIP
> 
> 
> Broadband users behind NATs can be in the worst of all 
> worlds; they are neither "protected" from the open Internet 
> by an MIS department, nor do they have unrestricted access to it.
> 
> Some STUN-enabled SIP clients will be able to get through the 
> NAT, but it doesn't work in all cases. It also requires the 
> user to acquire access to a STUN server, which may be an 
> issue for non-technical personal users. STUN is advertised as 
> a stop-gap solution.
> 
> A much better solution would be for the ISP to provide a 
> NAT-managing SIP proxy as part of their service, allowing 
> simple NAT-aware SIP clients to traverse their NAT. This 
> seems a reasonable duty of the ISP, in the same way that an 
> apartment owner would provide all residents a key, when the 
> owner places a lock on the main door.
> 
> Regards,
> 
> David C. Oliver
> Principal Engineer
> SecureLogix Corp
> Email: [email-masked] <mailto:[email-masked]>
> Tel:   210.402.9669
> Fax:   210.402.6996 
> 
> 
> -----Original Message-----
> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Wednesday, June 19, 2002 5:00 PM
> To: 'David Oliver'; 'Jonathan Rosenberg'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] new draft on session policies in SIP
> 
> 
> >The appropriate place for this is the proxy server nearest the
> >NAT: configuration and administration are normally the same as the
> NAT's,
> 
> DSL and cable users may be behind a NAT in the C.O. where 
> they can have absolutely no control. What alternative to 
> STUN, if any do you recommend?
> 
> Thanks, Henry
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > On Behalf Of David Oliver
> > Sent: Wednesday, June 19, 2002 1:06 PM
> > To: 'Jonathan Rosenberg'; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [Sipping] new draft on session policies in SIP
> > 
> > 
> > I agree that clients must be NAT-aware.
> > 
> > SDP endpoints generally only have numeric IP addresses (a
> > protocol design practice which has been recommended against 
> > for many years, but which is necessitated by the prevalence 
> > of NAT), so either a transparent ALG is needed to traverse 
> > their NAT, or they need to be aware of the NAT.
> > 
> > Transparent ALGs have the severe limitation that they cannot
> > work with encrypted data, and many users require their 
> > conversations to be private.
> > 
> > Arbitrary NAT awareness by clients is problematic, as clients
> > are likely to be small embedded hosts (e.g. net-phones), 
> > which cannot be easily configured to work with different 
> > NATs, and protocols such as STUN do not work in all cases. 
> > This is especially important for essentially untrusted guest 
> > users, such as in hotels or airport hospitality suites.
> > 
> > The best solution is to make the client aware of the
> > existence of NATs, while limiting the impact on the client to 
> > a simple address replacement protocol. The appropriate place 
> > for this is the proxy server nearest the
> > NAT: configuration and administration are normally the same 
> > as the NAT's, it can be trusted by the NAT (especially 
> > important for guest users), and has minimal administrative 
> > impact as Midcom protocols appear and stabilize to replace ad 
> > hoc and proprietary solutions.
> >
> <...>
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 21 Jun 2002 13:24:20 -0500

David,

> STUN is probably the best thing available for now, providing 
> you can get STUN in your client, locate a STUN server, and 
> STUN can traverse your provider's NAT.

I understand some devices, such as the snom SIP phone have STUN support

http://www.snomag.de/index1_en.htm

Nicolas-Peter?

Maybe it is a good idea to include STUN support into the requirements
for SIP devices?

Henry

> Sent: Friday, June 21, 2002 11:24 AM
> To: 'Henry Sinnreich'; David Oliver; 'Jonathan Rosenberg'
> Cc: [email-masked]
> STUN is probably the best thing available for now, providing 
> you can get STUN in your client, locate a STUN server, and 
> STUN can traverse your provider's NAT.
> 
> In the longer term, clients should only need to do minimal 
> work in traversing NATs and firewalls, i.e. substituting 
> addresses into SDP. Even with IPv6, firewalls will still be an issue.
> 
> Returning to the hotel example, consider a user (hotel 
> guest), who wishes to set up a wideband (full screen) video 
> conference, which would use a sizeable portion of the hotel's 
> Internet connection. To ensure reliable operation, the user 
> would reserve (and arrange to pay for - this is a hotel) the 
> resources ahead of time, by accessing the hotel's web site, 
> or indirectly through the hotel staff. Managing this via the 
> hotel's Middleware-aware Proxy is much more realistic than 
> configuring the client for this one time event.
> 
> Regards,
> 
> David C. Oliver
> Principal Engineer
> SecureLogix Corp
> Yes, that would be ideal, but unfortunately may not be in the 
> cards any time soon for users having DSL provided by a LEC. 
> Is there any other alternative to STUN for such DSL 
> subscribers? (I don't believe there is).
> 
> Thanks, Henry
> 
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of David Oliver
> protocol 
> > > design practice which has been recommended against for 
> many years, 
> > > but which is necessitated by the prevalence of NAT), so either a 
> > > transparent ALG is needed to traverse their NAT, or they 
> need to be 
> > > aware of the NAT.
> > > 
> > > Transparent ALGs have the severe limitation that they cannot work 
> > > with encrypted data, and many users require their 
> conversations to 
> > > be private.
> > > 
> > > Arbitrary NAT awareness by clients is problematic, as clients are 
> > > likely to be small embedded hosts (e.g. net-phones), 
> which cannot be 
> > > easily configured to work with different NATs, and 
> protocols such as 
> > > STUN do not work in all cases. This is especially important for 
> > > essentially untrusted guest users, such as in hotels or airport 
> > > hospitality suites.
> > > 
> > > The best solution is to make the client aware of the existence of 
> > > NATs, while limiting the impact on the client to a simple address 
> > > replacement protocol. The appropriate place for this is the proxy 
> > > server nearest the
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
>