RE: [RRG] Identifiers & Security Associations

[Randall Atkinson <rja@extremenetworks.com>]

Earlier, Ran wrote:
> Perhaps you were thinking of some security approach other than
> IPsec or SSL/TLS ??

Later, Brian wrote:
% I think we don't know. Certainly the known cases are
% IPsec and TLS.  We could trawl in RFCs 3789 through 3796
% for others, but that wouldn't catch non-IETF protocols.

IPsec and TLS are *not* problems in this regard.
- TLS uses FQDNs normally, not IP addresses.
- IPsec can be updated in a backwards-compatible and
  incrementally deployable way.  Actually, the code changes
  are pretty straight-forward and should be very small.

We can make this problem arbitrarily difficult by deciding
that we are not allowed to make any changes to anything.

I would prefer not to do that, since the whole point here
is to propose some new architectural approach/enhancements
to the IETF.

IF we limit our Identifier+Security Association concerns to
    the set of known protocols (including IETF protocols, but
     also whatever else I know about),

THEN
   I cannot find any application or protocol that will prevent
reasonable deployment of a new Identifier *due to changing
IP address to some new (tbd) Identifier inside the Security
Associations*.


If someone else has a specific known security protocol that
currently has SAs bound to IP addresses and that would
necessarily break *in a non-incrementally deployable way*,
please speak up.


Unless some specific issue is identified soon, I think this is
really not an issue that this group needs to dwell on further.

Cheers,

Ran
rja@extremenetworks.com


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg