Re: [Dime] Defining a new Application for mip6-split ?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Dime] Defining a new Application for mip6-split ?
I would prefer using the existing application, and
adding optional AVPs to carry information related
to the IKEv2 (and possibly MIPv6) service, and possibly
some additional values for the NAS-Port-Type field.
One of the reasons why an existing application would
be preferred is that then a AAA server that does not
care about the type of service can be used without
changes. Yet servers that do care can look at the
AVPs and make more detailed authorization
decisions.
RFC 3588 states that "Creation of a new application
should be viewed as a last resort." and that "In order
to justify allocation of a new application identifier,
Diameter applications MUST define one Command Code,
or add new mandatory AVPs to the ABNF." Note that
mandatory AVPs can be viewed in different ways,
and that we should not be too strict about them.
For instance, Framed-Protocol is an optional AVP in
RFCs 4005 and 4072. Yet, you could argue that if you
are doing PPP then you need to use this attribute and
set it to PPP. But that didn't make the attribute mandatory.
Do we have a similar situation for the IKEv2/MIPv6
attributes and values? They are not necessary from
the NASREQ/EAP perspective, but in the specific context
you need to use the attributes. In my mind, this does not
make the attributes mandatory from a Diameter
application point of view. If we start creating
new applications for every different situation,
we'll have lots of applications and interoperability
problems. Its better to add new optional AVPs and
describe in text when they should be used. The
only exception that I see is security related AVPs
that must be understood by the other side or else
the session should be terminated.
See also
http://www.arkko.com/publications/draft-arkko-radext-multi-service-decisions-02.txt
for related discussion about Service-Type, NAS-Port-Type,
and so on.
--Jari
_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.