Re: [sipcore] draft-ietf-sipcore-sec-flows-01: technical issues

> -----Original Message-----
> From: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of Cullen Jennings
> Sent: Wednesday, January 27, 2010 10:01 AM
> To: Olle E. Johansson
> Cc: SIPCORE
> Subject: Re: [sipcore] draft-ietf-sipcore-sec-flows-01: 
> technical issues
> 
> 
> On Jan 8, 2010, at 5:36 AM, Olle E. Johansson wrote:
> 
> > 
> > During the tests we had at SIPit in New Hampshire we 
> discovered that without an IP address in the certificate, 
> most TLS scenarious with record-route/route headers pointing 
> to IP addresses would fail. Either avoiding IP addresses in 
> record-route/route or having IP address for the server in the 
> cert are working solutions to this issue. 
> > 
> > IP in SAN certs is propably the fast way forward, but also 
> gives a headache in solutions where you have multiple IP 
> addresses in a "clustered" environment. It just feels wrong 
> to me to have non-DNS data like IP address within the cert.
> 
> You are complete right that what goes in the record route 
> needs to match what is in the cert. However, it is difficult 
> to get cert signed by a well known CA that has an IP address 
> in it so the obvious solution is don't put IP addresses in 
> your record-route. If a particular proxy, say with a host 
> name of say proxy22, in the example.com domain wants to 
> record route, the easiest thing to deploy in my opinion is 
> putting proxy22.example.com in the record route. Or if you 
> are a domain with only one proxy, you could just put 
> example.com in the record route. In the simple one proxy 
> case, then all you need is a cert with example.com and in the 
> more complex case you might want a cert with both example.com 
> and proxy22.example.com. Hope that makes sense. The other 
> problem with IPs in certs is when you want to renumber the 
> network or move a machine, you might need new certs.

Or an IPv6/IPv4 translator is between the SIP client and
its server.  http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07
talks a bit about the problem, but doesn't bring TLS into the
picture.

Let's _please_ not use IPv4 address literals, except where
we already have to use them (SDP).

-d

> There is 
> likely some cases where IP in certs make sense but my opinion 
> is that in most case, using DNS names is eas
>  ier. 
> 
> Cullen <in my individual contributor role>
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore