[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposed changes to ISAKMP/Oakley

  Ran,

> The Proxy-ID is the identity of the entity that is performing outbound
> IPsec on behalf of the originator of the IP packet.  The Proxy-ID is
> *NOT* the identity of the original cleartext IP packets.  If Dan's
> document defines Proxy-ID differently, then it has changed the years-old 
> definition of the term Proxy-ID and we should correct this before RFC. 

Well, ahh, uummm, the proxy-id, as defined in the document, is the identity
that the ISAKMP peer is proxying (ouch) for. Whether that breaks years-old
definitions or not, that's the way it's written.

Granted this doesn't jive quite well with the PF_KEY notion of a "proxy
sockaddr" but I've known that for a while. PF_KEY also only defines a single
"proxy". That's a limitation as well. So the naming of ISAKMP/Oakley is
1) different; and 2) more powerful than PF_KEY. 

> Please lets not change the standard terminology in the middle of things. :-)

I don't particularly like "proxy identities". If you have a different term
I'd be happy to entertain a change. But I think whether it's called blah or 
foo or proxy id, the information passed in those payloads is the identities 
for whom this negotiation is performed and not the identity of the ISAKMP 
peer. The peer's identity is determined by the cookies in the ISAKMP header. 
This doesn't mean that a compliant implementation can't take this blob-- of 
foo or blah or "proxy identity"-- and map it into the PF_KEY proxy sockaddr 
field (although since PF_KEY only allows a single sockaddr for this purpose 
I wonder how that mapping is done).

This seems to be a semantic issue which can be solved by changing terminology
somewhere. If anybody has any ideas-- either for PF_KEY or ISAKMP/Oakley--
now's the time....

> Please note that I won't buy products that lack an administrative knob
> permitting me to cause the implementation to refuse all requests with
> a Source-ID of 0.0.0.0/32.  I might or might not be a majority, but
> I'm sure I'm not entirely alone.  In general, vendors that want to sell
> lots of product will let the box administrators have lots of policy knobs.

Fine. I know a certain router vendor which can satisfy this capability
(hint: it's the one that's not selling to that copying company). A user has 
the ability to specify which traffic requires which policy. But is the 
semantics of what a "proxy" is a determining factor of what you'll buy or is 
the functionality the determining factor?

  Dan.
Follow-Ups: References: