Subject: RE: [AAA-WG]: issue: real-time duplicate detection andproposedchange.

From: <[email-masked]>
Date: Wed, 16 Oct 2002 06:56:47 +0300

Hi Pat,

> A new AVP may be a better approach, but now requires that the
> application be involved in the message retransmission engine... not a
> great idea. 

As I understood, there had been discussion that an AVP could
be used, but the same concern that the application would
be involved in the retransmission was thought to be an ugly 
hack.

> However, your point on end-to-end made me think that if an
> intermediate agent retransmits the packet, it must set the 
> 'D' bit, and this could break e2e packet hash/signature.

So it needs to be done end-to-end or not at all?

John

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 15 Oct 2002 20:19:35 -0700 (PDT)

> So it needs to be done end-to-end or not at all?

I think Pat's point was that the "D" but would need to be considered
mutable in any MICs calculated E2E. Transmission layer security is not an
issue since this doesn't prevent an agent from setting the "D" bit.

My reading of the CMS Security application (correct me if I'm wrong) is
that none of the MICs would cover the "D" bit, so it seems to me that this
is not an issue.

Or am I missing something? If so, can someone point out the specific
section and page # (and draft) that describes what would be broken by
setting the "D" bit in an intermediate agent?

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Oct 2002 07:47:53 +0300

> setting the "D" bit in an intermediate agent?

That page doesn't exist.

I think that the CMS application, when ready, should include the command
code and other stuff from the header (otherwise you'll see attacks where
you have the same protected AVPs, but replace resource allocation request with
accounting request etc). As this text in the CMS application is being
developed, we could take care of not including the D bit there.

 > So it needs to be done end-to-end or not at all?

Duplicates can happen end-to-end and middle-to-end. For the D-bit to be
useful, it has to be set in all places that can generate duplicates. So,
we really need to handle it even in proxies (if at all)!

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 15 Oct 2002 21:06:29 -0700 (PDT)

> That page doesn't exist.

OK. I thought I was missing something.

> developed, we could take care of not including the D bit there.

Sure, because it's mutable.

So does that mean that no existing functionality if broken by the "D" bit?

---

From: Pat Calhoun <[email-masked]>
Date: 16 Oct 2002 05:45:58 +0000

> be involved in the retransmission was thought to be an ugly 
correct. So my preference is to have the base protocol handle this
feature.

> So it needs to be done end-to-end or not at all?
Not if the bit is defined as a muteable (sp?) field, meaning that it is
always set to zero prior to any form of hashing.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: 16 Oct 2002 05:47:22 +0000

> issue since this doesn't prevent an agent from setting the "D" bit.
Correct.

> setting the "D" bit in an intermediate agent?

Ah, perhaps I've been away for too long, and the CMS draft doesn't cover
the message header. In which case, I slowly crawl back under my rock.

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 16 Oct 2002 04:49:32 -0700 (PDT)

> the message header. In which case, I slowly crawl back under my rock.

Thanks for crawling out -- you helped us find a bug in CMS :)

The CMS draft SHOULD cover portions of the header (to avoid cut and paste
attack) but does not. I will file an issue on this.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 16 Oct 2002 09:35:08 -0400

> be involved in the retransmission was thought to be an ugly 

Please see my reply to Pat:

  I think retransmission after rebooting based on stored
  unacknowlegded accounting records is a task of the application (the
  diameter engine should process them as new requests for which new
  End-to-End Identifiers are to be assigned), while retransmission
  after _normal_ failover/failback is a task of the retransmission
  engine.  Better to make a distinction between those two cases.

In the former case, the application would have to 
involve the retransmission and AVP could cover this case.

The latter case is covered by using the combination of End-to-End
Identifiers and Origin-Host AVP, which is the 
detection scheme that is mandatory used for all applications.
If performance is the concern, the time-based window scheme that 
is also used in the D-bit scheme can also be used.

Based on this analysis, I still wondor why D-bit is needed 
in the header.

Yoshihiro Ohba