Subject: [Hipsec] Anonymous HIs

From: Philip Matthews <[email-masked]>
Date: Wed, 5 Sep 2007 16:32:40 -0400

draft-ietf-hip-base-08 contains the following text:

    5.1.2.  HIP Controls

       The HIP Controls section conveys information about the  
structure of
       the packet and capabilities of the host.

       The following fields have been defined:

          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          | | | | | | | | | | | | | | | |A|
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       A - Anonymous:   If this is set, the sender's HI in this  
packet is
          anonymous, i.e., one not listed in a directory.  Anonymous HIs
          SHOULD NOT be stored.  This control is set in packets R1  
and/or
          I2.  The peer receiving an anonymous HI may choose to  
refuse it.

What directory is meant? DNS? Or something else?
Is there some way to check if a HIT really is anonymous?

- Philip

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

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 6 Sep 2007 06:08:26 +0300

>       The following fields have been defined:

You may consider this as an anachronism, as anonymous HIs haven't  
really been fully developed.  See RFC 4423 Sections 5 and 11 for the  
background.  But, personally, I'm happy that the hook for that is  
still there.  :-)

The directories referred to is basically any directory.  Anonymous  
HIs are meant to be used "once" and thrown away.

No, there is no way to check if a HIT really is anonymous or not.

--Pekka

---

From: Philip Matthews <[email-masked]>
Date: Thu, 6 Sep 2007 13:04:57 -0400

As you may be aware, the HIP-HOP proposal (draft-matthews-p2psip-hip- 
hop) is proposing to create peer-to-peer overlays using HIP. In HIP- 
HOP, the HIT is also a peer ID used to identify a peer in the  
overlay. Peers might be things like SIP phones or laptops without a  
DNS entry.  In our view, they are quite likely to be located behind a  
NAT (at least in the short term). So are these "anonymous" HIs? What  
are the important properties of an "anonymous" HI that causes them to  
be treated differently?

- Philip

On 5-Sep-07, at 23:08 , Pekka Nikander wrote:

> really been fully developed.  See RFC 4423 Sections 5 and 11 for  
> the background.  But, personally, I'm happy that the hook for that  
> is still there.  :-)
>

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 6 Sep 2007 21:13:07 +0300

If I've understood the HIP-HOP goals right, the peers will have long- 
lived HIs that will be stored in the DHT.  From the present  
discussion point of view, that DHT could be classified as a  
"directory", since they allow one to look up information related to  
the HI.  Hence, those HIs wouldn't be "anonymous".

On the other hand, if when making a P2PSIP call I were to decide to  
make a new HI, in order to not to reveal my permanent HI to the  
callee, that new HI would be an anonymous HI.  Presumably, I would  
destroy the HI after that one call.

I thought the background thinking was clear enough in RFC 4423, but  
perhaps it isn't?

--Pekka

On 6 Sep 2007, at 20:04, Philip Matthews wrote:

> As you may be aware, the HIP-HOP proposal (draft-matthews-p2psip- 
> hip-hop) is proposing to create peer-to-peer overlays using HIP. In  
> HIP-HOP, the HIT is also a peer ID used to identify a peer in the  
> DNS entry.  In our view, they are quite likely to be located behind  
> a NAT (at least in the short term). So are these "anonymous" HIs?  
> What are the important properties of an "anonymous" HI that causes  
> them to be treated differently?
>
> - Philip
>

---

From: Philip Matthews <[email-masked]>
Date: Fri, 7 Sep 2007 08:25:32 -0400

Right now, the thought is that peers will use the same HI as long as  
they are in the overlay, and each peer potentially will have some  
credentials that indicate that it is allowed to join the overlay. We  
are currently looking more closely at this to understand the security  
implications of it. A user Fred that is "logged" that is located at  
the peer with HIT X would then be registered in the DHT as "fred@X".  
So from what you say, X would not be considered an "anonymous" HIT?

I understand your description of an anonymous HIT that is used for  
one call.

I had looked at RFC 4423, but the discussion seemed to rely on some  
background info that I didn't have. My suggestion would be to insert  
a couple of paragraphs into draft-ietf-hip-base that more fully  
describes the concept. I would be happy to help with preparing this  
text.

A couple more questions about this concept. As I understand it, this  
bit is just informational to the host that receives it. The only  
protocol action the receiving host can take is to reject the request  
to set up the HIP association. Is this correct? What prevents a host  
from lying about this setting? How does this proposal avoid the  
security flaws of the Evil Bit proposal (RFC 3514)?

- Philip

On 6-Sep-07, at 14:13 , Pekka Nikander wrote:

> If I've understood the HIP-HOP goals right, the peers will have  
> long-lived HIs that will be stored in the DHT.  From the present  
>> hip-hop) is proposing to create peer-to-peer overlays using HIP.  
>> In HIP-HOP, the HIT is also a peer ID used to identify a peer in  
>> the overlay. Peers might be things like SIP phones or laptops  
>> without a DNS entry.  In our view, they are quite likely to be  
>> located behind a NAT (at least in the short term). So are these  
>> "anonymous" HIs? What are the important properties of an  
>> "anonymous" HI that causes them to be treated differently?
>>
>> - Philip
>>
>>>>          SHOULD NOT be stored.  This control is set in packets  
>>>> R1 and/or
>>> the background.  But, personally, I'm happy that the hook for  
>>> that is still there.  :-)
>>>
>>> The directories referred to is basically any directory.   
>>> Anonymous HIs are meant to be used "once" and thrown away.
>>>

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 7 Sep 2007 15:49:27 +0300

On 7 Sep 2007, at 15:25, Philip Matthews wrote:

> Right now, the thought is that peers will use the same HI as long  
> as they are in the overlay, and each peer potentially will have  
> some credentials that indicate that it is allowed to join the  
> overlay. We are currently looking more closely at this to  
> understand the security implications of it. A user Fred that is  
> "logged" that is located at the peer with HIT X would then be  
> registered in the DHT as "fred@X". So from what you say, X would  
> not be considered an "anonymous" HIT?

Right.

> I understand your description of an anonymous HIT that is used for  

Not necessarily.  In some other context, you might even use an  
anonymous HI for several years, but most probably only for one  
specific purpose.

> background info that I didn't have. My suggestion would be to  
> insert a couple of paragraphs into draft-ietf-hip-base that more  
> fully describes the concept. I would be happy to help with  
> preparing this text.

Well, unfortunately the base spec is now almost past IESG and  
entering the RFC Editor's queue.  Hence, I think we don't want such a  
text added but perhaps rather a separate draft clarifying the issue.   
Or what does the WG think?  Adding such text might endanger of having  
to circulate the draft again through the IESG.

> A couple more questions about this concept. As I understand it,  
> this bit is just informational to the host that receives it.

Yes.

> The only protocol action the receiving host can take is to reject  
> the request to set up the HIP association. Is this correct?

Basically, yes.  Other than that, the host may not want to "remember"  
the anonymous HI afterwards; see RFC 4423 Section 5.2.
See also the fourth paragraph of Section 13, Security Considerations.

> What prevents a host from lying about this setting? How does this  
> proposal avoid the security flaws of the Evil Bit proposal (RFC 3514)?

Well, while there is no way to check if a HI is anonymous, a host may  
certainly check that a HI *is* registered (i.e. not anonymous), if it  
can infer the registry from the context.  That is, while you cannot  
attribute an anonymous HI to anyone (at least in theory), you may  
have a policy that requires all non-anonymous HIs to be attributable.

--Pekka

>> "directory", since they allow one to look up information related  
>> to the HI.  Hence, those HIs wouldn't be "anonymous".
>>
>> On the other hand, if when making a P2PSIP call I were to decide  
>> to make a new HI, in order to not to reveal my permanent HI to the  
>> I thought the background thinking was clear enough in RFC 4423,  
>> but perhaps it isn't?
>>
>> --Pekka
>>
>>>> You may consider this as an anachronism, as anonymous HIs  
>>>> haven't really been fully developed.  See RFC 4423 Sections 5  
>>>> and 11 for the background.  But, personally, I'm happy that the  
>>>> hook for that is still there.  :-)
>>>>

---

From: Philip Matthews <[email-masked]>
Date: Fri, 7 Sep 2007 09:34:37 -0400

On 7-Sep-07, at 08:49 , Pekka Nikander wrote:

> Basically, yes.  Other than that, the host may not want to  
> "remember" the anonymous HI afterwards; see RFC 4423 Section 5.2.
Do you really mean section 5.2 "Storing Host Identifiers in DNS"? I  
don't  see anything in there about remembering HIs.

> Well, while there is no way to check if a HI is anonymous, a host  
> may certainly check that a HI *is* registered (i.e. not anonymous),  
> if it can infer the registry from the context.  That is, while you  
> cannot attribute an anonymous HI to anyone (at least in theory),  
> you may have a policy that requires all non-anonymous HIs to be  
> attributable.

If I understand you, under this policy the host rejects anonymous HIs  
and all non-anonymous HIs that it cannot verify. So why is the A bit  
helpful?

The only case I can see where an A bit would be helpful is if a host  
would accept both anonymous and non-anonymous HIs. For non-anonymous  
HIs, it verified that they are indeed in the appropriate registry,  
which is assumed to be an expensive operation, hence the desire to  
avoid this check for HIs which are anonymous. It then does something  
different with two types of HIs, but I am not sure what that  
different thing would be. However, I can see problems with this too:  
what about a DoS attack where hosts set the A bit incorrectly to  
force extra work on the receiver?

- Philip

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 8 Sep 2007 21:55:11 +0300

Philip,

I don't think this discussion is very useful.  The "anonymous" bit is  
there as a placeholder or hook for additional privacy, as RFC 4423  
tries to explain.  Whether that is really useful or not, I cannot  
really say, as the method has not been fully developed.

You may be right that it doesn't help even in the non-attack case;  
otoh, it may help a responder not to bother checking in some cases.

I think that the intention is clear -- if not, we apparently have a  
disconnect in our mental minds.  For a starter, I think that privacy  
is mostly an economic issue, not so much a civil rights issue.  In  
other words, my thinking there is quite much influenced by Andrew  
Odlyzko's work.  Hence, to me anonymity is not just something nice to  
have but something that is absolutely necessary for the electronic  
market places to work in the long run.  But that is a long story, and  
I don't know if we should go there here.

I also think that as the bit stays today, it is most probably  
insufficient.  More or less the same as with opportunistic mode --  
there is just too little in the spec to be really useful.  But I  
think it is a good placeholder for future developments, just like the  
opportunistic mode.

--Pekka

On 7 Sep 2007, at 16:34, Philip Matthews wrote:

>> may certainly check that a HI *is* registered (i.e. not  
>> anonymous), if it can infer the registry from the context.  That  
>> is, while you cannot attribute an anonymous HI to anyone (at least  
>> in theory), you may have a policy that requires all non-anonymous  
>> HIs to be attributable.
>
> If I understand you, under this policy the host rejects anonymous  
> HIs and all non-anonymous HIs that it cannot verify. So why is the  
> A bit helpful?
>
> The only case I can see where an A bit would be helpful is if a  
> host would accept both anonymous and non-anonymous HIs. For non- 
> anonymous HIs, it verified that they are indeed in the appropriate  
> registry, which is assumed to be an expensive operation, hence the  
> desire to avoid this check for HIs which are anonymous. It then  
> does something different with two types of HIs, but I am not sure  
> what that different thing would be. However, I can see problems  
> with this too: what about a DoS attack where hosts set the A bit  
> incorrectly to force extra work on the receiver?
>
> - Philip
>