Subject: Proposed change to DIAMETER header

From: Pat Calhoun <[email-masked]>
Date: Wed, 10 Jan 2001 08:12:51 -0800 (PST)

All,

The method the protocol is currently specified, it requires that an
implementation walk through each AVP, looking for the ICV AVP in order to
perform the necessary replay and authentication checks. What this means is
that there is a significant amount of work required to ensure that the packet
is in fact authentic. This does not bode well for denial of service attacks.

So I would like to propose adding the ICV-Offset to the DIAMETER header, as
shown below:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |RADIUS PCC=254 |  Flags  | Ver |         Message Length        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Identifier                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Command-Code                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           Vendor-ID                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          ICV-Offset                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  AVPs ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-

[...]

[ed: and something like (actual words will change):]

ICV-Offset
	The ICV-Offset contains the number of octets from the start
of the DIAMETER header where the ICV AVP can be found. When the ICV
is computed, this field MUST be set to zero. If no ICV was added to
the packet, the value of the ICV-Offset field MUST be zero.

The above change makes it MUCH easier for implementations to authenticate
the packet before parsing through all AVPs in the message.

Do people think this is a worthwhile change? I believe this will make the
protocol less prone to denial of service attacks.

Thanks,

PatC

---

From: "Jari Arkko" <[email-masked]>
Date: Thu, 11 Jan 2001 20:51:32 +0200

> So I would like to propose adding the ICV-Offset to the DIAMETER header, as

I don't care that much either way, but I would just note a couple of
things:

  1) The MAC calculation is in any case heavier than any reasonable ICV
       attribute seeking operation, so I don't really know if this buys that
       much.

       Or perhaps you are simplifying the DIAMETER hardware
       ICV engine design for the next SPARC station ;-)

  2) If I would program a server, I would make a separate small
      piece of code to look for the ICV for received packets; don't
      think more than a simple loop is required since the ICV hopefully
      couldn't be inside any AVP groups, and no XML data dictionaries
      need to be consulted either.

 3) If there's an ICV offset in the header, somebody's going to have
     to go and check later that it corresponds to the actual place
    of the attribute. Also, before the ICV is checked we need to
    ensure it falls within the bounds of the message. Unnecessary
    complexity.

[In any case, I'd rather have statically keyed IPsec as a MUST than
the AVP, since that would be useful for encryption as well as integrity,
and would benefit more apps at the same time.  And again, many
DIAMETER uses I see would be in the v6 domain and there IPsec
exists anyway...]

Jari