Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon

From: Patrice Calhoun <[email-masked]>
Date: Mon, 2 Apr 2001 13:12:24 -0700 (PDT)

> It seems obvious to me too but I see a loophole in the current drafts since
> the command specification in the extension documents contain "* [ AVP ]" to
> indicate that any other AVP may be present (including a mandatory
> vendor-specific AVP). I dislike conformance battles with other vendors so
> how about adding the following text to the Extension-Id AVP description to
> keep us honest:
> 
> "A Diameter peer that includes an Extension-Id AVP in the DRI SHALL support
> the functionality described in the associated extension using only the
> commands defined in the extension and without the addition of mandatory
> vendor-specific AVPs."

That sounds a little harsh, but what does the WG think about Mark's proposed
text?

PatC

---

From: "Mark Jones" <[email-masked]>
Date: Tue, 3 Apr 2001 09:28:02 -0400

Fredrik,

> I don't like the proposed text. If a vendor would like to add a
> mandator avp
> it will not necessarily cause interoperability problems since the
> receiving
> node will responde with a MRI with a failed avp indicating what was not
> understood. It is then up to the sender to make the decision to
> try without
> that avp if it is willing to let the user have the service
> without the extra
> feature provided by the mandatory avp.
>

My text was not intended to prohibit what you suggest. A peer could still
send a message with vendor-specific AVPs, get back an MRI and re-send the
message containing only the AVPs described in the associated extension. In
this case, the sender does still "support the functionality described in the
associated extension using only the commands defined in the extension and
without the addition of mandatory vendor-specific AVPs". But in addition, it
supports a vendor enhanced version and tries that one first.

Does the following text help clarify my intentions?

   A Diameter peer that includes an Extension-Id AVP in the DRI SHALL
support
   the functionality described in the associated extension using only the
   commands defined in the extension and without the addition of mandatory
   vendor-specific AVPs. The same Diameter peer MAY suppport a
vendor-specific
   version of the functionality in addition to but not instead of that
described
   in the extension.

BTW, in your example, if the receiver did not understand AVPs from vendor
[x], it would not have advertised support for vendor [x] (using
Supported-Vendor-Id=[x]) in its DRI. This AVP should significantly reduce
the number of MRIs being sent.

Regards,
       Mark

---

From: Patrice Calhoun <[email-masked]>
Date: Tue, 3 Apr 2001 07:15:20 -0700 (PDT)

My thoughts too, but remember that if you send a standards track command, with
a vendor-specific AVP marked Mandatory, you will ONLY interoperate with
yourself.

PatC
> I don't like the proposed text. If a vendor would like to add a mandator avp
> it will not necessarily cause interoperability problems since the receiving
> understood. It is then up to the sender to make the decision to try without
> that avp if it is willing to let the user have the service without the extra
> /Fredrik
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]On Behalf
> >Of Patrice Calhoun
> >Sent: den 2 april 2001 22:12
> >To: Mark Jones
> >Cc: Patrice Calhoun; David Spence; [email-masked];
> >[email-masked]
> >Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @
> >Connectathon
> >
> >

---

From: Patrice Calhoun <[email-masked]>
Date: Tue, 3 Apr 2001 07:21:53 -0700 (PDT)

> supports a vendor enhanced version and tries that one first.

But you specifically wanted text in the Extension-Id that would prevent a
manufacturer from advertising the extension in question if they did the above.

PatC

---

From: "Mark Jones" <[email-masked]>
Date: Tue, 3 Apr 2001 10:47:00 -0400

> manufacturer from advertising the extension in question if they

No. The text I proposed was intended to prohibit advertising an extension id
if the sender ONLY supported the extension through the use of additional
mandatory vendor-specific AVPs.

For example, if a Diameter peer is capable of operating in two modes: basic
(using extension draft commands/AVPs only) and enhanced (using additional
mandatory vendor-specific AVPs) then it should be able to advertise support
of the extension. If is only supports the enhanced mode then it should not
advertise support for the extension.

Regards,
       Mark

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 3 Apr 2001 17:00:54 +0200

but if it require the special avp to be present from certain users but not
all, what should be advertised then?

/Fredrik

>From: Mark Jones [mailto:[email-masked]]
>Sent: den 3 april 2001 16:47
>To: Patrice Calhoun; Mark Jones
>Cc: Fredrik Johansson; David Spence; [email-masked];
>[email-masked]

---

From: "Mark Jones" <[email-masked]>
Date: Tue, 3 Apr 2001 11:20:16 -0400

> all, what should be advertised then?

If the device requires a MANDATORY vendor-specific AVP (="special AVP") in
order to support the functionality described in an extension (for a single
user or all users) then it SHALL not advertise support for the extension id.

Regards,
       Mark

---

From: Patrice Calhoun <[email-masked]>
Date: Tue, 3 Apr 2001 08:27:26 -0700 (PDT)

> user or all users) then it SHALL not advertise support for the extension id.

not the standards track extension id, but some other one allocated by the
manufacturer through IANA. Right?

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 3 Apr 2001 09:37:27 +0200

/Fredrik

---

From: "Mark Jones" <[email-masked]>
Date: Tue, 3 Apr 2001 13:00:48 -0400

> But my point was that if you don't advertise anything, you don't receive
> anything. So a kludged Mobile IP extension (as you describe above) would
> *still* have to be advertised via a new Extension-Id.
>

Agreed. But my point was that my kludged HA should not be advertising
support for the standards track Mobile IP extension draft. Instead it should
be advertising support for the vendor's "Kludged Mobile IP extension". Do we
agree on this?

Regards,
       Mark

---

From: "Mark Jones" <[email-masked]>
Date: Tue, 3 Apr 2001 13:52:07 -0400

> That is *exactly* what I said earlier.
>

Sorry, Pat. I had misunderstood from your earlier email that you were
suggesting  standards track extensions were treated somehow differently from
vendor extension drafts in the use of the Extension-Id. On re-reading the
email, I think we were in violent agreement from that point on.

Getting back to the proposed text for the Extension-Id AVP description, let
me try to summarise my understanding with an example:

- Device A from Vendor X always sends the HAA with AVPs described in
standards track Mobile IP extension (id=4).

- Device B from Vendor Y always sends HAA with AVPs described in standards
track Mobile IP extension PLUS a mandatory vendor Y specific AVP as
described in "Y's Mobile IP Extension" (id=123).

- Device C from Vendor Z is capable of supporting two modes depending on the
capabilities of the peer as advertised in the DRI. 1) HAA with AVPs
described in standards track; 2) HAA with AVPs described in standards track
Mobile IP extension PLUS a mandatory vendor Y specific AVP.

So the DRIs from these clients contain:

- Device A: Extension-Id=4
- Device B: Extension-Id=123
- Device C: Supported-Vendor-Id=Y; Extension-Id=4; Extension-Id=123

Device B SHALL NOT send a DRI with Extension-Id=4.

The following text added to the description for the Extension-Id was
intended to re-enforce this:

Regards,
       Mark

---

From: Patrice Calhoun <[email-masked]>
Date: Tue, 3 Apr 2001 09:40:23 -0700 (PDT)

> Wrong, unless my assumptions about the standards track extensions are
> incorrect. I assume the standards track extensions represent the baseline
> functionality for interoperability in a given problem domain. If my
> FA/AAAF/AAAH/HA all claim to support the MobileIP extension I should be able
> to "authenticate, authorize and collect accounting information for services
> rendered to a mobile node" regardless of the which vendor provided each
> component.
> 
> If my HA claims to support the MobileIP extension but actually inserts a
> mandatory vendor-specific AVP in the HAA command then I have a problem. I
> complain to the HA vendor who insists his device is compliant with the
> MobileIP draft and directs my attention to the "* [AVP]" in the HAA command
> format which implies he can add his mandatory vendor-specific AVP if he
> chooses. Of course, he is willing to sell me another AAAH which does support
> his mandatory vendor-specific AVP in the HAA.

So, if a manufacturer had the plain vanilla Mobile IP extension, and the
Vendor Z one, two extension-ids would be required. If the peer did not
advertise the vendor specific extension id, then the plain one would be used
with the Diameter peer.

This is the way the protocol works, and is much better than try A, then if it
fails, try B. no?

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 3 Apr 2001 20:05:42 +0200

Then we're two that missunderstod Pat :-)

I agree that vendor C should be able to advertise both extensions, and then
it is up to C's policy to decide from which users it mandates the presens of
the mandatory vendor extension. But I can not read that from your suggested
text.

/Fredrik

---

From: Patrice Calhoun <[email-masked]>
Date: Tue, 3 Apr 2001 10:00:49 -0700 (PDT)

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Tue, 3 Apr 2001 13:16:22 -0700 (PDT)

ok, I believe that there seems to be concensus to add clarifying language to
the spec stating that advertising an extension *requires* that the messages
defined in the spec do not include AVPs marked as mandatory that weren't
specific in the said extension.

The biggest question is whether this really belongs in the Extension-Id
section, or a new section that describes extensions.

BTW, the best place for this would have been the framework document, but we
decided to kill this spec at the last IETF. In the process of doing this, I
will need to pull in the terminology, but was there anything else that needed
to be moved to the base?

PatC

---

From: "Mark Jones" <[email-masked]>
Date: Tue, 3 Apr 2001 16:18:54 -0400

> the mandatory vendor extension. But I can not read that from your

Actually my text was meant to re-enforce the "Device B SHALL NOT send a DRI
with Extension-Id=4" part since that was the loophole I saw in the
extensions drafts. I just included Device C to confirm we were in synch on
the standards track vs vendor extensions affair.

If example I gave is clearer, I can tidy it up a little and we can include
that under the Extension-Id description?

Regards,
       Mark

---

From: "Mark Jones" <[email-masked]>
Date: Tue, 3 Apr 2001 12:34:39 -0400

Regards,
       Mark

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 4 Apr 2001 09:06:48 -0700

I think that this makes sense:

	1. An extension is by definition a series of commands, plus
         the AVPs that relate to those commands, as described in
         the BNF.

      2. Advertising an extension also implies advertisement of
         the AVPs for that extension, as described in the BNF.

	3. You can send other AVPs in those commands, but only
         the ones included in the BNF may have the 'M' bit set.
         Additional AVPs MUST NOT have the 'M' bit set, including
         vendor-specific AVPs.

      4. This implies that if an AVP needs to be mandatory (such
         as security-related AVPs like filter-rules, filterid,
         tunnel AVPs, etc.) then either it is included in the
         base spec or an extension or its use is PROHIBITED.

I'd vote for having a section at the beginning of the base
document that describes the DIAMETER extensiblity model in
detail. This would include not only the extensions mechanism,
but also the model for adding AVPs (e.g. data modeling), and
new authentication mechanisms (EAP).

In terms of the framework document, I don't think that the
existing document is terribly useful. So it might just make
sense to add the required introductory text to the base
document and let the framework doc expire.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Patrice Calhoun
Sent: Tuesday, April 03, 2001 1:16 PM
To: Fredrik Johansson
Cc: Mark Jones; Patrice Calhoun; David Spence; [email-masked];
[email-masked]
Subject: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @
Connectathon)

BTW, the best place for this would have been the framework document, but we
decided to kill this spec at the last IETF. In the process of doing this, I
will need to pull in the terminology, but was there anything else that
needed
to be moved to the base?

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 5 Apr 2001 10:32:19 +0200

>         base spec or an extension or its use is PROHIBITED.

Ok, this works fine if the sender knows what the receiver is capable of, but
what about these scenarios:

1. A FA advertise support for MIP (4), AAAF advertise that it can handle
everything (*), AAAH believes that it can send the vendor specific
extension, but the FA can not interprete the AMA correctly.

In this case the result will be that the FA will reject the AMA with a MRI
saying what AVP that was not understood, i.e. the same as it would have been
if the AVP was mandatory but without extension id.

2. A FA advertise that it is capable of supporting extension 4 (MIP) and a
vendor specific ext (say 7). This is sent to AAAF. AAAF in its turn
advertise that it is capable of supporting MIP (4). So now it is not
possible for AAAH to send a AMA back with some vendor specific ext allthough
the FA would be able to interpret it.

The problem here is that there is no way to distinguish between capabilities
as a proxy and as a non-proxy server. This would be solved if AAAF could
advertise that it undertands MIP for local actions and everything for
proxying.

Allthough this only solves one of the problmes, I suggest that we add a new
<Proxy-Extension-Id AVP> saying that this is a capability that the sender
can handle as a proxy.

/Fredrik

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 5 Apr 2001 07:14:30 -0700 (PDT)

All,

Below is the proposed text that I have added to the -02 candidate that
describes what a Diameter extension is.

Please send any comments,

PatC
----

2.3  Diameter Extensions

   As previously mentioned, the Diameter base protocol does not operate
   on its own, but requires appplication-specific extensions, commonly
   referred to as Diameter extensions. A Diameter extension is a
   specification that defines one or more Diameter Command-Codes, the
   expected AVPs in an ABNF [31] grammar (see section 3.2), and MAY also
   define new AVPs.

   Every Diameter Extension specification MUST have an IANA assigned
   Extension-Id value (see section 6.1.3). This Extension-Id is
   advertised during the capabilities exchange phase (see section 6.0).
   Advertising support of a particular extension implies that the
   receiver support all of the Command Codes, and the AVPs specified in
   the associated ABNF, described in the specification.

   An implementation MAY add arbitrary AVPs to any command defined in an
   extension, including vendor-specific AVPs. However, such AVPs MUST
   NOT have the M(andatory) bit set. An implementation that adds AVPs
   not specified in a command's ABNF, and sets the AVP's M(andatory) bit
   MUST NOT advertise support of the extension.

   An implementation MAY support both a proprietary version of an
   extension by requesting an IANA extension identifier (see section
   17.3), while supporting the original extension. During the
   capabilities exchange, a Diameter node could know whether it should
   send the prorietary version, or the standards one, by inspecting the
   extensions advertised by the peer.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 5 Apr 2001 16:40:47 +0200

>But which extensions would you advertise for proxying? If 90% of your
>existing peers advertise support for an extension, do you advertise that
>extension to new peers when they connect?

For proxying I would advertise wildcard, i.e. I'm willing to receive any
extension and try to find a peer to proxy it to. If a do not find one, I'll
have to reply with a suitable error code.

>
>> Correct. As you point out, capabilities negotiation is really about
>> finding the sub-set of capabilities that is usable along the path
>> from the home server to the NAS, not just on the next hop.
>>
>
>Capabilities exchange in proxy scenarios is way beyond what can be
>accomplished with the humble DRI as defined in the current draft so I vote
>we avoid this particular rat-hole at this point. The DRIs only represent a
>capabilites snapshot anyway. For any Diameter peer in the role of routing
>proxy, the capabilities list is dynamic since a new peer may come online
>which supports additional extensions. Since DRIs are exchanged only on
>establishment of the transport connection, there is no way to inform
>existing peers of the additional capabilities.
>
>The Extension-Id AVP as currently defined in the draft advertises locally
>supported
>extensions. Lets keep this definition and leave capability
>exchange in proxy
>scenarios as the subject of some future Enhanced Capability Exchange
>extension.

So, do you allways assume that a proxy does not care what extensions it
forwards? Or do we say that a company having two sites can not use vendor
specific extensions between its sites unless the ISP it is useing supports
the same vendor specific extensions?

/Fredrik

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 5 Apr 2001 07:46:21 -0700 (PDT)

> >Let's think this through carefully.
> >
> >If, as you state, a NAS has to know the capabilities of *all*
> >proxies towards
> >the home server, this will require a whole lot of messaging (a
> >traceroute like
> >message). This was *never* intended to be supported in Diameter.
> 
> Agree
> 
> >
> >The original intent of Diameter was to know the peer's capabilities, so a
> >message could be sent to it, and then it is responsible for
> >finding a next hop
> >for the message.
> >
> >btw, what we are trying to support here, is a NAS, with vendor proprietary
> >extensions, going through a set of proxies that don't understand the
> >extension, to a home that does. What, btw, are the chances of a
> >NAS and a home
> >server supporting a vendor proprietary extension, but not the
> >proxies in the
> >middle.
> >
> 
> Why would this be so unlikely? Two companies (or one company, two sites)
> using a ISP that does not support the company specific extension isn't that
> unlikely. Remember an access node might as well be a FA :-)

If that's the case, then I would expect the AAA server to ALSO support the
proprietary extension, right?

If this is confined within a domain, then it is easily rectified by ensuring
that all of the boxes are from the same manufacturer. We are talking about
cases here where there is a mix if vendors in a large inter-domain network.
The chances of both end diameter nodes being of the same manufacturer, while
the rest of the middle from another, is low (and doesn't seem like a problem
that really needs to be solved).

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 5 Apr 2001 08:24:35 -0700 (PDT)

> extensions. Lets keep this definition and leave capability exchange in proxy

It has occured to me that this functionality could be piggy backed on top of
the E2E messages defined in the strong crypto I-D, with relative ease.

PatC

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 5 Apr 2001 06:15:40 -0700

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 5 Apr 2001 11:41:11 -0400

> have to reply with a suitable error code.

I understand but that would be your policy and I may implement a different
one hoping to reduce the number of replies with errors. I don't think we
should dictate this policy in the base protocol so I'm happy with the text
in the current draft as is.

Regards,
       Mark

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 5 Apr 2001 07:23:08 -0700 (PDT)

If, as you state, a NAS has to know the capabilities of *all* proxies towards
the home server, this will require a whole lot of messaging (a traceroute like
message). This was *never* intended to be supported in Diameter. 

The original intent of Diameter was to know the peer's capabilities, so a
message could be sent to it, and then it is responsible for finding a next hop
for the message.

btw, what we are trying to support here, is a NAS, with vendor proprietary
extensions, going through a set of proxies that don't understand the
extension, to a home that does. What, btw, are the chances of a NAS and a home
server supporting a vendor proprietary extension, but not the proxies in the
middle.

I would argue that this is not a problem that needs to be solved.

PatC

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 5 Apr 2001 10:34:01 -0400

Regards,
       Mark

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 5 Apr 2001 16:34:50 +0200

Agree

/Fredrik

---

From: Mark Eklund <[email-masked]>
Date: Fri, 6 Apr 2001 01:28:58 -0400 (EDT)

Pat,

With the your new Diameter Extensions statements about the
mandatory avp, does the following still hold true in section 4.1
of draft-ietf-aaa-diameter-01.txt.

      Unless otherwise noted, AVPs will have the following default AVP
      Flags field settings:
         The 'M' bit MUST be set. The 'V' bit MUST NOT be set.

Also, is the following interpretation correct? Since
Service-Type and Idle-Timeount are not listed in the ABNF of
AA-Answer in draft-ietf-aaa-diameter-nasreq-01.txt, it would be
a violation of the protocol to advertise support of NASREQ and
set the mandatory bit in the above attributes in an AA-Answer.

-mark

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 5 Apr 2001 23:48:39 -0700

>proprietary extension, right?

Remember, the proxy may be serving a large number of servers, all with 
different capabilities. I think that there may be some optimizations
that can be made for this case.

Let's say that [email-masked] has a dialup account with
a roaming association that handles many types of Internet access,
including Mobile IP, dialup, etc. However, Nortel's DIAMETER server
does not support the Mobile IP extension. 

Dave will connect to the FA which will talk to a proxy that is 
capable of doing anything, and therefore will advertise wildcard
capabilities. However, the request when proxied to Nortel will
result in an error because the required capabilities are not present.

One would hope that this same result would not be repeated on 
every attempt, but rather that the capabilities of the Nortel
server would be cached by the proxy for some TTL. Therefore on
the next attempt, the proxy would NOT advertise wildcard capabilites
for a request to a destination realm whose capabilities it has cached.
Instead, it will advertise the capabilities appropriate to that
particular destination realm. 

Does this make sense?

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 5 Apr 2001 23:48:46 -0700

>message). This was *never* intended to be supported in Diameter.

Agreed that the NAS is not the place to handle this. The DIAMETER model is
essentially one where the NAS acts as a "stub resolver" in many respects,
offloading more sophisticated issues of destination resolution, capabilities
caching, etc. to the proxy.

>extension, to a home that does.

Yes, this is a good model -- the proxy should not have to understand the
extension to respond appropriately, and I suspect that proxies that
display any sophistication in this regard will mostly do so to implement
policy (e.g. I'm a broker whose billing system can't handle Mobile IP yet).
However, doing realm-based capabilities caching doesn't require that
kind of knowledge on the proxy.

>What, btw, are the chances of a NAS and a home server supporting a
>vendor proprietary extension, but not the proxies in the
>middle.

Pretty high, I would think -- though I would argue that we should assume
that proxies do not have to understand extensions to do their job so
that it wouldn't matter. The reason that a proxy would announce non-wildcard
capabilities would most likely have to do with policy -- not implementation
of extensions, since in practice, a proxy shouldn't need to have any
additional
code to implement extensions.

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 6 Apr 2001 05:43:46 -0700 (PDT)

>          The 'M' bit MUST be set. The 'V' bit MUST NOT be set.

Yes.

> set the mandatory bit in the above attributes in an AA-Answer.

ok, looks like I have a bit of work in that extension. The service-type and
idle-timeout SHOULD have been present. If you read the text in section 3.1.1,
it states that additional AVPs will have to be present that are defined in
section 2.0, 6.0 and 7.0. There is no easy way to make the ABNF because of the
fact that the AAR is used for framed, non-framed and tunneling access. It
sounds like we have a couple of options:

1. Define a new message for each framed, non-framed and tunneling. Although
this seems heavyweight, it is VERY simple to encode the ABNF, and makes the
protocol alot cleaner. It makes the set of AVPS that must be present very
predictable. This would be me preferred approach.

2. Have multiple sets of ABNF, one for each type.

3. Leave it as-is, with the pointer to the sections that contain the AVPs, and
an english representation of the ABNF rules (as it is right now).

Preferences?

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 6 Apr 2001 06:48:54 -0700 (PDT)

> section 2.0, 6.0 and 7.0. There is no easy way to make the ABNF because of
> the fact that the AAR is used for framed, non-framed and tunneling access. It
> 3. Leave it as-is, with the pointer to the sections that contain the AVPs,
> and an english representation of the ABNF rules (as it is right now).

All,

Just a little more on my proposed option 1 above. I realize that it is rather
late in the game to make such a change, but the more I think about it, the
more sense it seems to make.

First, the extension is heavily inspired on RADIUS, hence the single commands
for framed, non-framed and tunneling. Given that I tried to keep as much
RADIUS as possible, I decided to follow this logic. However, as any RADIUS
developer knows, the protocol does get kinda ugly when trying to figure out
what AVPs need to be present, based on the access method (ppp, telnet, etc).

In fact, each one of these are separate services. Providing telnet services is
vastly different from PPP access, but RADIUS tried to make it look the same by
having a single command code.

So my proposal would be for the base protocol to have the following command
codes defined:

Framed-Auth-Request/Framed-Auth-Answer/Framed-Auth-Ind
Non-Framed-Auth-Request/Non-Framed-Auth-Answer/Framed-Auth-Ind

Given that EAP does operate differently, I still would like to keep EAP as
separate command codes.

Unfortunately, I don't think that we can split up tunnling from framed,
because it is possible for the NAS to think PPP is being provided, but the
server returns tunneling attributes. So the above two would still make it
cleaner.

So, does the WG think that the above would lead to a cleaner ABNF definition,
and a better protocol, or should I leave it as-is?

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 6 Apr 2001 07:03:06 -0700 (PDT)

> that can be made for this case.

correct.

> result in an error because the required capabilities are not present.

correct.

> particular destination realm. 

I don't understand what you mean by advertising on the next attempt.
Advertising is done when the link is brought up only. I believe what you meant
the say is that the proxy will cache the fact that the Nortel server doesn't
support Mobile IP, at least until the link goes down again.

Then you state that a proxy will NOT advertise services for a particular
realm. The protocol doesn't currently allow proxies to advertise services for
a particular realm. This was intentional. Doing so would be a HUGE protocol
effort, and not one that is really that worth while, IMHO.

Perhaps one day if this really becomes an issue, we can revise the protocol
accordingly.

PatC

---

From: Barney Wolff <[email-masked]>
Date: Fri, 6 Apr 2001 14:31:43 -0400

Pat, the real world intrudes.  It is perfectly possible today with
RADIUS for a user to log in non-framed and have the server say
that the service to be provided is framed.  Lots of people do that
to accomodate token cards, for example.

I have no problem with separate ABNF for the two cases, but it must
be possible to step up to framed at any reasonable point in the
dialog.

Barney

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 6 Apr 2001 11:37:10 -0700 (PDT)

ok, then I retract my previous proposal :(

Thanks Barney,

PatC

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 7 Apr 2001 11:39:35 -0700

>in the current draft as is.

If possible, I think it would be desirable to at least articulate the range
of acceptable behaviors.

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 7 Apr 2001 11:35:37 -0700

>the E2E messages defined in the strong crypto I-D, with relative ease.

In general, it's desirable to avoid adding features to the spec, if
possible.
So first, I'd like to understand how the existing spec handles these kind
of situations. It seems to me that we have the following functionality:

1. The DRI message can negotiate capabilities when a connection starts up.
   This is useful so that peers can know each other's capabilities right
   from the start.

2. Error messages in the case where a client sends a command to a server
   that does not support it. For example, if a proxy advertises wildcard
   capabilities, but the DIAMETER server can't do MOBILEIP, then a NAS
   needing to use the MOBILEIP extension will receive an error back, right?

So my question has to do with the pros and cons of the existing
functionality
and how it is supposed to work. I think we could use some more language in
the spec, describing the capabilities negotiation functionality in more
detail.

For example, whether the error message returned to the NAS should
include the Extension-Id AVP, and what the NAS should do with such
an error message.

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 9 Apr 2001 06:57:05 -0700 (PDT)

> In general, it's desirable to avoid adding features to the spec, if

agreed.

>    This is useful so that peers can know each other's capabilities right

This is correct, but keep in mind that a few Diameter messages are *not*
proxiable, and DRI is one of them.

>    needing to use the MOBILEIP extension will receive an error back, right?

Correct, and this is returned as a per-hop error. So if the home server
returns such an error stating that it cannot support the extension, the
downstream proxy will attempt to re-route the message to another server within
the home domain. Of course, this isn't much of a problem because home servers
typically do not advertise wildcards. If no servers in the home domain can
support Mobile IP, then an error would be returned to the NAS.

Of course, should a proxy also be a home server, and advertise wildcard, then
it would receive a Mobile IP message, return a per-hop error, and the same
procedure as above would be followed.

So in the first case, since the home servers explicitely advertise support for
Mobile IP, there is no problem. In the latter case, it would require a
downstream proxy to send it to more than one server before finding a server
that supports Mobile IP.

Again, the protocol supports the first case very well, and the second is also
supported, but not as efficiently. This is a drawback from advertising
wildcard, but it doesn't break the protocol.

> include the Extension-Id AVP, and what the NAS should do with such

This language is already there, and doesn't belong in the capabilities
exchange, but rather in the hop-by-hop errors section (and is present in
section 9.0). Please let me know if additional language is required in that
section.

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Apr 2001 07:36:10 -0700 (PDT)

> the home domain. 

I presume that the proxy would have used the DRI message in setting up
connections with the servers within the home domain, right? So presumably,
wouldn't it know what the capabilities were? I guess this might happen if
a connection weren't already up, in which case the proxy would have to
bring one up with the home domain. 

> downstream proxy to send it to more than one server before finding a server

And if there is no server that supports Mobile IP, then an error is passed
back from the proxy to the NAS, right? Question: given that the proxy has
now investigated the capabilities of the domain in question, wouldn't it
be able to respond right away to future requests? How long do the
negotiated capabilities remain in effect? For the life of the
connection? Is there some TTL associated with them?

Also, does it make sense for the proxy to pass back to the NAS the list of
extensions that *are* supported within the domain in question? In other
words, should it pass back an Extension-Id AVP along with the error
message?

> section 9.0). Please let me know if additional language is required in that

This is a case where there needs to be a section giving an overview of how
the protocol functions so that the behavior is described. You can leave
the detailed descriptions in individual sections if you like, but having
an overview somewhere would be helpful.

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 9 Apr 2001 07:00:50 -0700 (PDT)

> If possible, I think it would be desirable to at least articulate the range

ok, but a possible problem comes to mind with the above. It is not possible to
know whether a particular server is the "home" server for a given domain. So
when caching such information, how do you know whether you are caching what
the next hop server has told you, or what it received from an upstream server?

So caching has its own problems, since it is possible for the next hop server
to have lost contact with a set of servers in the home domain, and caching
information locally will ensure that these new servers will never get to
provide services through the caching server.

So, unless it is possible to know whether a server is a home server or not,
caching is probably a bad idea.

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Apr 2001 07:40:13 -0700 (PDT)

> provide services through the caching server.

Yes. If you cache you also need a TTL. 

The question is whether multiple transmissions are necessary each time you
have message with inappropriate capabilities. You could send a lot of
unnecessary traffic that way. Since proxies are already presumably
maintaining routing tables, one wonders if those tables might also not
contain capabilities for the domains in question.

---

From: "Alexander Hagen" <[email-masked]>
Date: Tue, 10 Apr 2001 08:36:33 -0700

At the 49th IETF a UML model was discussed and an obscure (i.e. not in
Google) URL provided. I am trying to make a collection of RFC related UML
models and would like to find it.

If anyone is interested in looking at the UML model collection once it is
finished (no promises) let me know and I will send you a pointer.

Alexander Hagen
Senior Research Engineer
Development and Prototyping
DoCoMo Communications Laboratories USA, Inc. (DoCoMo USA Labs)
  181 Metro Drive, Suite 300, San Jose, CA 95110, USA
  TEL :+1-408-573-1050 (Main)     FAX : +1-408-573-1090 (Main)
  TEL: +1-408-451-4706 (Direct)
E-mail: [email-masked]
Web: http://www.docomo-usa.com

---

From: David Spence <[email-masked]>
Date: Tue, 10 Apr 2001 17:18:00 -0400

Here it is:

   http://www.interlinknetworks.com/otherdocs/nasmodel.html

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.