Subject: [RRG] Identifiers & Security Associations

From: Randall Atkinson <[email-masked]>
Date: Sun, 25 May 2008 17:49:45 -0700

Earlier, Brian Carpenter wrote:
% Don't forget that the address is today also an essential part of
% the data for a cryptographic protection of an end to end session.

Only because we did not (and still don't) have good non-topological
identifiers.  I knew this was a problem for IPsec Security Associations
way back in the early 90s (15+ years ago).  IPsec SAs bind to
IP addresses *only* because the Internet Architecture lacked a
sufficiently rich set of namespaces.

I'll note that web sites are usually thoughtful enough to issue
their X.509v3 certificates bound to fully-qualified domain names,
instead of to specific IP addresses, so that *any* IP address
for that FQDN will work with the one certificate.  (Arguably
this implies a stronger need for DNSsec, but that is out of
scope for this list.)

% In that role it could of course be replaced by some ID inserted
% at a level above IP (as it is in IPSEC over UDP, in effect), but we
% have to provide that at the same time as architecturally removing
% e2e addressing. And if you do that *except* by inserting an alternative
% 32 or 128 bit e2e quantity that looks just like an IP address, you
% create unthinkable amounts of disturbance to upper layer running code.

That claim is NOT obvious to me.

Fixing IPsec SAs to use some new non-topological ID would affect
the ESP/AH code inside the kernel, which could be updated automatically.
It also would affect the IKE code, which also could be updated
automatically.

However, most applications use the IPsec extensions to Sockets API
that NRL initially developed (a sub-optimal API admittedly, but that is
still what most IPsec-aware applications use) -- and that API would
NOT be affected in any way obvious to me.  So I do NOT think that
application software would be affected by the change.

With respect to SSL/TLS, see the other comments above.  So I don't
think existing web applications would need to change either.

Perhaps you were thinking of some security approach other than
IPsec or SSL/TLS ??

Cheers,

Ran
[email-masked]

--
to unsubscribe send a message to [email-masked] 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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 May 2008 13:45:49 +1200

> Earlier, Brian Carpenter wrote:
...
> That claim is NOT obvious to me.

...
> Perhaps you were thinking of some security approach other than

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.

Note, I *fully agree that "good non-topological identifiers" are
what we should use; I'm only concerned about how to get there from
here without a deployment problem that is just as hard as the IPv6
deployment problem.

   Brian

---

From: Randall Atkinson <[email-masked]>
Date: Sun, 25 May 2008 19:09:56 -0700

> Perhaps you were thinking of some security approach other than

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
[email-masked]

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 26 May 2008 15:48:52 -0700 (PDT)

>I'm only concerned about how to get there from here without a deployment >problem

If you give ISPs as well as all end users a number of id's to name interfaces and such, there might be no need to change sw in hosts. Routers will get their own names too. Host Name + Router Name + Router Locator = IP Address as it is today. Hence there is no need to change the routing. I.e. what is left is to provide a flat names' set and a separate hierarchical locators' set, right?

Thank you,

Peter

--- On Sun, 5/25/08, Brian E Carpenter <[email-masked]> wrote:

> From: Brian E Carpenter <[email-masked]>
> Subject: Re: [RRG] Identifiers & Security Associations
> To: "Randall Atkinson" <[email-masked]>
> Cc: "IRTF Routing RG" <[email-masked]>
> Date: Sunday, May 25, 2008, 9:45 PM