Subject: [AAA-WG]: Steve's Comments (RE: Evaluation: draft-ietf-aaa-diameter - Diameter Base Protocol to Proposed Standard)

From: <[email-masked]>
Date: Tue, 3 Dec 2002 15:45:58 +0200

Hi, 

Finishing this up.

> 3	What purpose is served by the T bit?  Given that the underlying
> 	network may be duplicating packets -- a few months ago, I was
> 	seeing up to 90% duplicates on my local loop, with no apparent
> 	ill effects on the stack -- why is there some advantage to
> 	trying to convey that information in Diameter?  It almost makes
> 	sense if set only when the application has switched peers before
> 	the retranmission, though it's still not clear to me what 
> 	the receiver of such a message would do with the information.

It is about application level retransmisions, not network duplicates.

>	Should the spec indicate that the reserved bits MUST be ignored
>	by receivers, rather than sending an error?  It makes it hard to
>	start using those bits, given the current language.  "Be liberal
>	in what you receive", etc.

Yes, agreed.

> 4.1	Same comment about the reserved bits.

OK

> 4.6	Why is the flag "MAY Encr" when confidentiality is mandatory?
> 
> 	What is the SHLD NOT column?  It's never used in that table.
> 
> 	I don't see the reasoning for some of the settings of that
> 	flag.  For example, I would think that the authentication- and
> 	authorization-related flags would require protection, to guard
> 	against deletion to prevent the operation from taking place,
> 	or to spoof the result.  This also illustrates confusion between
> 	the need for integrity protection vs. confidentiality.  It
> 	would be good to give some general guidance, for the benefit
> 	of people defining Diameter applications.

Any suggestions from the list on this one?

> 5.2, search rule 3.2, last paragraph:  Unless I'm misreading 
> something,
> 	it says that the domain suffixes SHOULD and need not match
> 	the original query.

Fixed.

> 	3.3 should probably be numbered 4.
> 
> 	Discuss DNSsec?  What TLS or IPsec certificates should be 
> 	checked for?  More specifically:  the peer discovery mechanisms
> 	MUST be tied to a security authorization model.  Each peer to
> 	which a node speaks must be authorized for some role.  The
> 	Diameter implementation must have some list of credentials
> 	that are acceptable *for this role*.  That point should probably
> 	be discussed here, and possibly in the Security section as well.
> 	(Note that suitable checking in this fashion relegates DNSsec
> 	issues to availability, and not even much of that -- an attacker
> 	can't impersonate a legimate peer, because it lacks the right
> 	credentials.)  

This is all cleaned up, according to text sent by Bernard.
 
> 5.3	May CER or CEA messages be relayed?

No.
 
> 5.3.1	Why is the IP address in the message, when it should be
> 	available via the local incarnation of getpeername()?
> 
> 5.6.4	What is a "hanging octet"?

Old reference to Florida 2000 elections & hanging chads ...

> 6.1.8	Proxy-Info has security implications, and probably requires an
> 	embedded HMAC with a node-local key.

What should be said, something like:

  Proxy-Info AVP has certain security implications and SHOULD contain an
  embedded HMAC with a node-local key.

Is that sufficient or do we need more detail?

> 8.3	The RAA message is curious, and perhaps the answer to my 
> 	question is in another AAA document.  That said -- in general,
> 	something like a NAS can't do user authentication by itself.
> 	Instead, it's going to use Diameter facilities to send something
> 	upstream.  Ultimately, it's the Diameter server that is going to
> 	make the decision.  That suggests that reauthenticate is more
> 	of a command from the server to the client, where the server 
> 	will, at some point, issue a disconnect message.  The current
> 	model seems to suggest a sequence of
> 
> 		server->client: RAR
> 		client->server: authentication info } repeated
> 		server->client: authentication info }
> 		client->server: success/failure
> 
> 	In other words, there's a nested exchange.  Is that intended?
> 	What Session-ID should be used?  Will Diameter implementations
> 	be confused by that sort of sequence?  There's a state machine
> 	lurking in the background here, I think.

We discussed this at IETF 55 and I think the conclusion was that the
authentication was hop-by-hop.

> 9	I'm concerned that I don't see a way for a server to detect
> 	a total ordering of accounting records for a session.  This
> 	would be useful, for example, when processing interim records.
> 	The situation I'm concerned about is as follows.  Suppose a 
> 	client sends an interim record to a proxy or relay agent.  The
> 	upstream link from the agent is experiencing a transient
> 	problem.  Or perhaps the agent crashes and reboots, but has
> 	stored the pending records in non-volatile storage.  In the
> 	meantime, the client sends another interim message via another
> 	path, either because it suspects a failure or because it is 
> 	using multiple peers for load-sharing.  This second record
> 	can be received first.  I suspect that the easiest solution is
> 	to require that Accounting-Record-Number be monotonically
> 	increasing within a session.

This is recommended in 9.8.3 already.
 
> 13	Is there some document that discusses the end-to-end (and I mean
> 	that literally here) Diameter authorization model?  I know that
> 	it was discussed in the WG, but I don't see anything on that 
> 	here.  What's I'm looking for -- somewhere -- is some discussion
> 	on how, say, a NAS "knows" that it will be paid when an 
> 	authorization comes from five proxies away.

Also discussed in Atlanta that is hop by hop.  There probably is still
a need for a better discussion of the model.

> 14	Non-ascii hyphens (which shouldn't be there anyway)

OK

John

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Dec 2002 18:23:08 +0200

>>4.6	Why is the flag "MAY Encr" when confidentiality is mandatory?

This name has caused enough confusion, let's change it. Let's just
call it "Encryption" and then let the explanation in 4.6 explain
what it means.

>>	What is the SHLD NOT column?  It's never used in that table.

I guess its there just for consistence, for the possibility that
some AVP, some day, would have a rule about flags that involved
SHLD NOT. We do NOT have any in the base, but for consistence
perhaps all the Diameter specs should have the table in the same
format.

Anyways, I'm fine with removing this or keeping it.

>>	authorization-related flags would require protection, to guard

Just to make sure I understand the question right: s/flags/AVPs/?

> Any suggestions from the list on this one?

Its a good question. I guess the main concern with "MAY Encr" column
settings has been to protect user-related information such as user
names. Some of the other information, such as type of auth/authz event
may be necessary for intermediate agents. This kind of background should
be stated in the base spec (but it isn't at the moment I think). Is
there a specific AVP that appears to have a wrong setting?

Jari