Brian,
1. Host-to-router notification protocol (this is taken care of by
changes to mld proposed in draft-haberman-ipngwg-host-anycast)
2. Security: at a minimum some form of authentication to allow
routers to determine if hosts are allowed to join an anycast
Steve,
I think this is a very good writeup, but it's missing
the security considerations section :-)/2
Thinking for 5 minutes about intermediaries vs. not and security
it isn't obvious to me that one is better than the other.
A few points:
- A solution with an intermediary requires on the
Erik,
Erik Nordmark wrote:
Brian,
1. Host-to-router notification protocol (this is taken care of by
changes to mld proposed in draft-haberman-ipngwg-host-anycast)
2. Security: at a minimum some form of authentication to allow
routers to determine if hosts
[EMAIL PROTECTED] wrote:
- node with anycast address(*) participating routing exchange
pros: deployable now, routing protocol has mechanisms for
protecting against malicious route injection (sometimes
they are just use IPsec...)
cons: some
In message [EMAIL PROTECTED], Erik Nordm
ark writes:
Steve,
I think this is a very good writeup, but it's missing
the security considerations section :-)/2
Thinking for 5 minutes about intermediaries vs. not and security
it isn't obvious to me that one is better than the other.
A few points:
[playing catchup]
Does this (paraphrased) assessment seem correct? I wouldn't
want 3GPP to
mandate a behaviour that they would believe contributed to
identity privacy
but, based on some other procedure, did not.
= But the person tracking would have to know
that the host
Hi Thomas,
Does this (paraphrased) assessment seem correct? I wouldn't
want 3GPP to
mandate a behaviour that they would believe contributed to
identity privacy
but, based on some other procedure, did not.
= But the person tracking would have to know
that the
With regards to this, I think we came to agreement on new text for
the section, something that would look like this:
I'm OK with this.
My comment was really more to do with this:
I saw a privacy comment in the past (sorry, can't source the
original author) that suggested that because
Actually, I will have to let on to a little secret. I have been
looking at an option for anycast that looks strikingly similar to the
Home Address option in MIPv6. The idea is that a server responding to
an anycast query will put the anycast address in this option and its
own unicast
Yes and no, and a lot depends on the trust relationships between seeker
S, intermediary I, and target T. And whether or not N*M is a
significant issue depends on the relative values of N and M, and the
frequency of contact.
The latter is easier to see. If a member of set S has
[EMAIL PROTECTED] wrote:
Actually, I will have to let on to a little secret. I have been
looking at an option for anycast that looks strikingly similar to the
Home Address option in MIPv6. The idea is that a server responding to
an anycast query will put the anycast address in this
In message [EMAIL PROTECTED], Erik Nordm
ark writes:
Yes and no, and a lot depends on the trust relationships between seeker
S, intermediary I, and target T. And whether or not N*M is a
significant issue depends on the relative values of N and M, and the
frequency of contact.
The
12 matches
Mail list logo
