Subject: [MMUSIC] Question on ICE: Why allow FQDNs for candidate addresses?

From: Philip Matthews <[email-masked]>
Date: Thu, 12 Apr 2007 11:50:01 -0400

Jonathan:

ICE-15 allows the address of a candidate to be specified using a FQDN  
rather than an IP address:

   <connection-address>:  is taken from RFC 4566 [10].  It is the IP
       address of the candidate, allowing for IPv4 addresses, IPv6
       addresses and FQDNs.  An IP address SHOULD be used, but an FQDN
       MAY be used in place of an IP address.  In that case, when
       receiving an offer or answer containing an FQDN in an a=candidate
       attribute, the FQDN is looked up in the DNS using an A or AAAA
       record, and the resulting IP address is used for the remainder of
       ICE processing.

What is the motivation for allowing this?
I am concerned that this makes an implementation more complex,
and I would like to know why we think this is important.

- Philip

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Apr 2007 18:07:07 -0400

I added this a long time back to address some concerns around privacy. 
The idea was if an enterprise, say, didn't want to reveal its private 
addresses to the outside world, the agent could use dynDNS or something 
similar in conjunction with somewhat randomized hostnames, i.e., 
f7asff.enterprise.com. In the outgoing offer, this would be unresolvable 
by anyone except someone within the same enterprise. Furthermore, if the 
agent used a different hostname for every call, things would be 
uncorrelatable to the outside world (beyond coming from the same 
enterprise).

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Philip Matthews <[email-masked]>
Date: Wed, 25 Apr 2007 16:13:37 -0400

I can vaguely see how this might work. But are there people who  
actually want to do this?
Moreover, are there not other ways to achieve the same effect?
1) Use an SBC to remove host candidates when signaling outside the  
enterprise, OR
2) Look at the AoR that you are signaling -- if the domain part does  
not match your domain
     (or perhaps a short list of domains), then remove all the host  
candidates from the SDP.
[I believe that, from ICE-10 onwards, the need to include host  
candidates to "support" other
candidates has gone away -- e.g., ICE-08 required you to include the  
host candidate that
generated a peer-reflexive candidate]

Anyway, if we decide this is a good feature, then I think it should  
be described in the security
considerations section and/or Appendix B.

- Philip

On 24-Apr-07, at 18:07 , Jonathan Rosenberg wrote:

> I added this a long time back to address some concerns around  
> privacy. The idea was if an enterprise, say, didn't want to reveal  
> its private addresses to the outside world, the agent could use  
> dynDNS or something similar in conjunction with somewhat randomized  
> hostnames, i.e., f7asff.enterprise.com. In the outgoing offer, this  
> would be unresolvable by anyone except someone within the same  
> enterprise. Furthermore, if the agent used a different hostname for  
> every call, things would be uncorrelatable to the outside world  
> (beyond coming from the same enterprise).
>
> -Jonathan R.
>
> Philip Matthews wrote:
>
>> Jonathan:
>> ICE-15 allows the address of a candidate to be specified using a  
>> FQDN  rather than an IP address:

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 25 Apr 2007 19:20:42 -0700

>enterprise,

I hope not :-)

Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2007 3:14 PM
To: Jonathan Rosenberg
Cc: [email-masked]
Subject: [MMUSIC] Re: Question on ICE: Why allow FQDNs for
candidateaddresses?

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Thu, 26 Apr 2007 07:56:39 -0400

I agree. Solution 2 is nicer.
But the real question is: who cares in the first place?
After all, there is a NAT (or a NAT/FW) in front of the network.
- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Apr 2007 13:33:25 -0400

inline.

> actually want to do this?

Not sure. It was one of those things where, it seemed like it could be 
useful, and wasn't much harm in having it there. We already allow 
hostnames in SDP.

> 1) Use an SBC to remove host candidates when signaling outside the  

Henry commented on this one ;)

>     (or perhaps a short list of domains), then remove all the host  

Not so easy to do. Doesn't work with phone numbers. Doesn't work with 
call forwarding (I call joe@outside that forwards to bob@inside). It 
makes an assumption, and ICE tries to avoid those.

> generated a peer-reflexive candidate]

Right.

> 
> Anyway, if we decide this is a good feature, then I think it should  be 
> described in the security

I'm not sure its useful for this 'feature' (preventing private addresses 
from departing the enterprise). Not even sure anyone needs it. Its never 
been clear what attack it actually mitigates. Hostname in the candidate 
line was more a placeholder for future work. Also, as I said, it was 
consistent with SDP overall which allows hostnames, even in the c line.

As such, I'd rather just leave it as is, rather than guess at how it 
might get used for an enterprise use case. All the justification we 
really need is that this is how SDP already works.

-JOnathan R.

---

From: Philip Matthews <[email-masked]>
Date: Thu, 26 Apr 2007 14:15:41 -0400

On 26-Apr-07, at 13:33 , Jonathan Rosenberg wrote:
>
>
> I'm not sure its useful for this 'feature' (preventing private  
> addresses from departing the enterprise). Not even sure anyone  
> needs it. Its never been clear what attack it actually mitigates.  
> Hostname in the candidate line was more a placeholder for future  
> work. Also, as I said, it was consistent with SDP overall which  
> allows hostnames, even in the c line.
>
> As such, I'd rather just leave it as is, rather than guess at how  
> it might get used for an enterprise use case. All the justification  
> we really need is that this is how SDP already works.
>

Cullen posted a message to the BEHAVE list today which seems relevant  
to this discussion. I have copied it below. It seems to argue in  
favor of what you are suggesting. I remain uncertain about this, but  
I have not yet read the draft he references.  However, I would still  
argue that IF we do think we should do this, it should warrant a  
mention in the Security Considerations section.

Perhaps Cullen would like to comment on this?

- Philip

==== Message from BEHAVE list below ====

> On Apr 24, 2007, at 6:06 AM, Philip Matthews wrote:
>
>
>> Does anyone see a good reason why a NAT _should not_ decrement the  
>> TTL field
>> (other than the "try to be invisible" argument)?
>> Are there security implications to this question?
>>
>
> I think so - an important security property is the properties  
> described in the "Privacy and Topology Hiding" section of draft- 
> ietf-v6ops-nap-06 (note this draft has been approved and will be an  
> RFC soon).  Requiring decrement of TTL would reveal internal  
> topology information which is a big deal in cases where you are  
> trying to hide if you are currently in europe of US for privacy  
> reasons. Obviously lots of NATs are deployed where people don't  
> care about topology hiding but this is a big concern in some  
> deployments.
>
> I can't imagine how requiring that NATs do, or don't, decrement the  
> TTL will help the P2PSIP stuff much but perhaps I am just not  
> seeing the importance.
>
> Cullen <with my individual hat on>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 26 Apr 2007 12:19:46 -0700

I'm a bit behind on my ICE reading but I sort of assumed that ICE  
would not be saying anything about IP packet level TTLs. Anyways -  
the approach of using a DNS name that resolves differently inside the  
enterprise vs outside as a privacy mechanism always seemed fraught  
with danger and I've never been a big fan of it but I don't really  
care one way or the other about FQDN in the SDP. Does seem like it  
would give us a nice place holder for future extensibility.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Apr 2007 15:41:28 -0400

Right - this is my point.

So I still don't want to mention anything in security considerations 
since thats just a potential use for it. The main point I am saying is 
that this is just consistent with SDP. I don't want to open a massive 
can of worms with fancy DNS usages in a security considerations section. 
That would be a guaranteed DISCUSS and it would be for no reason.

-Jonathan R.

Cullen Jennings wrote:

> 
> I'm a bit behind on my ICE reading but I sort of assumed that ICE  would 
> not be saying anything about IP packet level TTLs. Anyways -  the 
> approach of using a DNS name that resolves differently inside the  
> enterprise vs outside as a privacy mechanism always seemed fraught  with 
> danger and I've never been a big fan of it but I don't really  care one 
> way or the other about FQDN in the SDP. Does seem like it  would give us 
> a nice place holder for future extensibility.
>

---

From: Philip Matthews <[email-masked]>
Date: Fri, 27 Apr 2007 13:49:16 -0400

OK.
My concern was simply over the additional implementation complexity.
However, if no one else is concerned about this, then I am OK with it.
However, if there is someone who has an ICE implementation that does not
support an FQDN instead of an IP address in this position, it would be
useful for them to speak up.
Otherwise, I am willing to let this go.
- Philip

On 26-Apr-07, at 15:41 , Jonathan Rosenberg wrote:

> So I still don't want to mention anything in security  
> considerations since thats just a potential use for it. The main  
> point I am saying is that this is just consistent with SDP. I don't  
> want to open a massive can of worms with fancy DNS usages in a  
> security considerations section. That would be a guaranteed DISCUSS  
> and it would be for no reason.
>
> -Jonathan R.
>
> Cullen Jennings wrote:
>
>> would not be saying anything about IP packet level TTLs. Anyways  
>> -  the approach of using a DNS name that resolves differently  
>> inside the  enterprise vs outside as a privacy mechanism always  
>> seemed fraught  with danger and I've never been a big fan of it  
>> but I don't really  care one way or the other about FQDN in the  
>> SDP. Does seem like it  would give us a nice place holder for  
>> future extensibility.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Apr 2007 19:41:48 -0400

OK, thanks. I'll consider this one closed unless someone objects.

-Jonathan R.

Philip Matthews wrote:

>> since thats just a potential use for it. The main  point I am saying 
>> is that this is just consistent with SDP. I don't  want to open a 
>> massive can of worms with fancy DNS usages in a  security 
>> considerations section. That would be a guaranteed DISCUSS  and it 
>> would be for no reason.
>>
>> -Jonathan R.
>>
>> Cullen Jennings wrote:
>>
>>> the approach of using a DNS name that resolves differently  inside 
>>> the  enterprise vs outside as a privacy mechanism always  seemed 
>>> fraught  with danger and I've never been a big fan of it  but I don't 
>>> really  care one way or the other about FQDN in the  SDP. Does seem 
>>> like it  would give us a nice place holder for  future extensibility.