gabriel montenegro wrote:
>
> Brian E Carpenter wrote:
>
> > Pekka Nikander wrote:
> > ...
> > > Step 1. Detect if the client wants to use the default
> > > authorization mechanism, i.e. RR, or something
> > > stronger.
> >
> > gabriel montenegro wrote:
> > ....
> > >
> > > Think of "strong" addresses as expressing 2 things to the peer:
> > >
> > > "(1) I do not engage in redirection operations on my address, or, if I do,
> > > (2) I only do so with cryptographically strong mechanisms in which I will
>prove to your
> > > satisfaction that I do have authorization to use that address"
> >
> > I agree that embedding this semantics in the address is a way of achieving Step 1.
> > But after reading lots of mail, and a preview (thanks!) of Gabriel's draft,
> > I'm still stuck, as Tony Hain seems to be, on why this is the only way.
>
> It's not. We added some text at the beginning of section 3.2 of the draft to mention
> other ways of doing it, but we may have missed one to clarify your question above.
> But I have a question for you: when you say that it's enough to put
> the bit in the packet (instead of the address) which of the two are you
> implying?:
>
> 1. Don't see what residual threats there are.
> 2. I see the residual threats, but I think we can live with them.
>
> If it's 2, then, cool, we can agree to disagree, end of thread.
> If it's 1, then we can continue.
I think it's
3. I see the residual threats, and I think it's illusory to believe
that overloading the address significantly reduces them
(for why, see Tony Hain's messages of the last couple of days).
BTW you are of course correct to insist on the non-existence of an
effective PKI for this domain.
Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
