Subject: [AAA-WG]: Issue #254

From: Mark Eklund <[email-masked]>
Date: Sun, 27 Jan 2002 00:08:22 -0500 (EST)

Issue #254 requests specific information on how IPsec must be used be
added.  I vote to decline this request.

Setting in stone what aspects of IPsec may and may not be used is well
beyond what Diameter should specify.  Future enhancements of IPsec or
discoveries in the failures in the IPsec algorithm may make these
specifications worthless.  If there is a need to specify what level of
security Diameter IPsec conforms to, an RFC entitled something like,
"Recommended Minimum IPsec usage for Diameter" should be created.
Then you can say you are RFC12345 conformant.  If someone comes out
with more secure recommendations, another RFC can be created.

-mark

P.S. I do vote to spell IPsec correctly in the Diameter drafts as this
issue also suggests.

---

From: "Jari Arkko" <[email-masked]>
Date: Sun, 27 Jan 2002 08:48:02 +0200

> beyond what Diameter should specify.  Future enhancements of IPsec or

Aren't we doing the same thing already for TLS?

Jari

---

From: "Jari Arkko" <[email-masked]>
Date: Sun, 27 Jan 2002 08:57:00 +0200

> Aren't we doing the same thing already for TLS?

And I'm continuing my own comment.... the reason we are doing this in
either case is interoperability, ensuring that DIAMETER nodes become
interoperable with each other. We can go a little beyond TLS/IPsec
interoperability requirements because we know the specific use case
for them. I think this is needed.

As to further developments, they may indeed occur. However, please
remember our recommendation is the *minimum* what must be implemented.
We don't necessarily have to re-publish our recommendation in the RFC
if something new comes along; smart network managers will deploy it.
Only when our recommendation starts to get so old that vendors have trouble
find that old stuff any more, then we are going to get complaints and have
to re-issue the recommendation for DIAMETERv2...

Jari

---

From: Mark Eklund <[email-masked]>
Date: Mon, 28 Jan 2002 10:52:23 -0500

Jari,

Correct me if I'm wrong, but isn't there a fundamental difference in
TLS and IPsec?  An application MUST be aware of TLS to make a TLS
connection to another peer.  As far as I know, the application is
ignorant of the IPsec between it and its peer.

It just feel that specifying how to configure IPsec is similar to
saying that Diameter MUST be run over Gigabit Ethernet.  It just seems
to me an administrative policy decision.

But if you are in favor of giving guidelines to IPsec and feel that
you can predict the minimum security level every domain needs for
their hop by hop security, I have no problem with guidelines being
added.  I honestly got lost in the 55 lines of guidelines with 10
MUSTS, 6 SHOULDS and 4 MAYS suggested in issue #254.

-mark

---

From: Jari Arkko <[email-masked]>
Date: Mon, 28 Jan 2002 18:07:29 +0200

> to me an administrative policy decision.

You are in part right, but I think the crucial issue here is if
the Diameter spec is referencing a specific piece of underlying
technology, then we need to worry about *how* that is used and
how much we expect from it. For instance, we have no need to
state that Diameter MUST be run over gigabit ethernet or fast
ethernet, but SHOULD NOT be run over regular ethernet. Now, for
security we do find a reason to state that you MUST run diameter
with either IPsec or TLS. In that sense TLS and IPsec are similar
in our context that both are being mandated by us.

> MUSTS, 6 SHOULDS and 4 MAYS suggested in issue #254.

Very much agree. Perhaps the text is an overkill. I would actually
prefer some simpler statement. A long time ago I think I proposed
something like MUST implement IPsec architecture [ref] and the ESP protocol
[ref], with required support for at least the SHA1 and 3DES algorithms [ref].
MAY implement IKE [ref]. Bernard, do you think we could come up with a
shorter statement?

Jari

---

From: Mark Eklund <[email-masked]>
Date: Mon, 28 Jan 2002 11:42:20 -0500

Coming up with a shorter statement sounds good to me.  Are there any
other drafts that do something similar that we can leverage their
wording?

-mark