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.
-gabriel
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
