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

Re: (IPng) More Endpoint Attributes



> From: Theodore Ts'o <tytso@MIT.EDU>
...
> In any case, it certainly seems clear, as we have both observed, that
> trying to encode this information in the SAID is the wrong place to do
> this.  (I believe the right place is in the IPv4 or IPv6 options field,
> ala IPSO.)  In any case, this palces this functionality out of scope of
> IPSEC.

Given what little time I've thought on this I generally agree.
Encoding end-to-end attributes as options of some header
contained within the authentication header makes sense.
Indeed encrypting those options might be desirable.
However such options can not be used to make routing decisions.
I guess a 32-bit SAID probably provides as much rope as
routers will be able to handle for the next few years.

Making all routing security decision based on SAID might give less
flexable routing than comes with IPSO/RIPSO/CIPSO but this is due to
making it more abstract.  The abstraction means off the self routers
could handle it.  Clearly the abstract is better in this case.

I hope that encoding endpoint attributes as inner protocol options
doesn't mean we have to replicate the option definitions for UDP, TCP,
and every other protocol we ever define.

I'd like to see some of this reflected in the architecture document.
It may be there by inference but it should be explicitly stated that
endpoint attributes should be carried as options of headers within the
AH payload using a not yet specified mechanism.

I'd really like to see how this all fits together with
	a key management protocol,
	an endpoint security attribute negotiation/translation protocol,
	an endpoint security attribute option specification, and
	a policy routing mechanism.

Dean Throop		throop@dg-rtp.dg.com