Hi Julien,
I'll have to the check the reference in more detail. Surely, shared
private keys at the server side are certainly one possibility, but the
compromise of a single host would then compromise the entire group?
I was originally thinking that the IP address of rendezvous server would
identify the group, but admit this can be somewhat limiting. For
instance, an additional parameter in the I1 could identify the group.
Clearly, multicast is outside of the scope of this WG, but I was
considering if the specifications are future proof with such an approach
since now the opportunistic base exchange is always terminated at the
rendezvous server.
P.S. I'll automatically assume this discussion shouldn't affect the
specs at all if this topic doesn't gather too much discussion (and it's
quite a late in process, anyway).
On 03/29/2013 01:36 AM, Julien Laganier wrote:
Hi,
HIP anycast would need a HIT to identify the members of the anycast
group, wouldn't it?
So why not have a key pair generated for the group, and the HIT
derived from the public key be the anycast HIT. One could then use the
group anycast key pair to sign authorization certificates granting
membership into the group. Similar concept has been explored for IPv6
multicast and anycast group in:
CASTELLUCCIA, C. AND MONTENEGRO, G. 2003. Securing group management in
ipv6 with cryptographically
generated addresses. In The Eighth IEEE Symposium on Computers and
Communications
(ISCC’2003).
--julien
On Tue, Nov 27, 2012 at 1:38 AM, Miika Komu <[email protected]> wrote:
Hi,
opportunistic mode with the help of a rendezvous server could be used for
implementing HIP-based anycast. The current RVS specification does not allow
this:
http://tools.ietf.org/html/draft-ietf-hip-rfc5204-bis-02
4.3.1. Processing Outgoing I1 Packets
An initiator SHOULD NOT send an opportunistic I1 with a NULL
destination HIT to an IP address that is known to be a rendezvous
server address, unless it wants to establish a HIP association with
the rendezvous server itself and does not know its HIT.
I think we could specify either a flag in the base exchange or alternatively
a special HIT encoding for the "NULL" destination HIT in the I1. What do you
think?
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
