internet-drafts@ietf.org · Tue, 07 Aug 2012 00:33:59 -0700

A PCP client must know the Fully Qualified Domain Name (FQDN) of a
   PCP server, before it can communicate with the later in order to
   perform the relevant PCP functions.
A PCP client must know how to contact the PCP server, either by the Fully Qualified Domain Name (FQDN) of it
   or by its IP address, before it can communicate with it in order to
   perform the relevant PCP functions.
  In order to make use of this option, this document assumes
   appropriate name resolution means (e.g., Section 6.1.1 of [RFC1123])
   are available on the host client.

Name is a domain name (as per Section 3.1 of [RFC1035]) that
      contains one or more labels.  In particular, a PCP Server name may be
      structured as DNS qualified name or be composed of strings such as
      can be passed to getaddrinfo (Section 6.1 of [RFC3493]), including
      address literals, etc.
When the co-located DHCPv6 server receives
   a DHCPv6 message containing the PCP Server Option, it SHALL use the
   name returned in the RADIUS attribute as defined in this memo to
   populate the DHCPv6 PCP Server option defined in [I-D.ietf-pcp-dhcp]
The Figure 2 illustrates how the RADIUS protocol and DHCPv6 work
   together to accomplish PCP client configuration when DHCPv6 is used
   to provide connectivity to the user.
The Figure 2 illustrates how the RADIUS protocol and DHCPv6 work
   together to accomplish PCP client configuration when IPoE & DHCPv6 are used
   to provide connectivity to the user.
The difference between this message flow and previous one is that in
   this scenario the interaction between NAS and AAA/ RADIUS Server is
   triggered by the DHCPv6 Solicit message received by the NAS from the
   B4 acting as DHCPv6 client, while in case of a PPP Session the
   trigger is the PPP LCP Config Request message received by the NAS.
The difference between this message flow and previous one is that in
   this scenario the interaction between NAS and AAA/ RADIUS Server is
   triggered by the DHCPv6 Solicit message received by the NAS from the
   PCP client acting as DHCPv6 client, while in case of a PPP Session the
   trigger is the PPP LCP Config Request message received by the NAS.
If the NAS does not receive the PCP server name attribute in the
   Access-Accept it MAY fallback to a pre-configured default tunnel
   name, if any.  If the NAS does not have any pre-configured default
   tunnel name or if the NAS receives an Access-Reject, the PCP client
   can not be configured by the NAS.
If the NAS does not receive the PCP server name attribute in the
   Access-Accept it MAY fallback to a pre-configured default PCP server
   name, if any.  If the NAS does not have any pre-configured default
   PCP Server name or if the NAS receives an Access-Reject, the PCP client
   can not be configured by the NAS.
 The scenario with PPP Session and IPv4 only connectivity does not
   require the DHCP protocol: the whole configuration of the client is
   performed by PPP.  This case is out of scope of this document because
   in order to complete the configuration of the PCP client a new PPP
   IPC option would be required.
Regards,
Tassos

Hello Tassos,
   Thanks for your comments.
The scenario we had in mind when we wrote this document is similar to the one you have just described, but the PCP is not on the BNAS it is external in the Service Provider's network and we want to be able to have subscribers of the same NAS using different PCP servers. The reason why we would like to use radius is because we would like to be able to tie together the PCP server information with the subscriber's profile stored in the Radius server.
If we don't have RADIUS part, we need to pre-provision the NAS with the PCP Server name, to be used in the DHCP option for each subscriber/group of subscribers. Please see attached slides.
If you think that more explanations are needed in order to clarify the use case we can add more text in the draft.

Thanks
Roberta

-----Original Message-----
From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Tassos Chatzithomaoglou
Sent: venerdì 3 agosto 2012 0.51
To: radext@ietf.org
Subject: [radext] draft-maglione-pcp-radius-ext-04

I am thinking of a similar implementation in our network, but after
looking at the doc i couldn't find any clear example of usage.

i.e. If you can define a PCP server locally on the NAS (DHCP server),
why do you want to supply it through radius too?

In our case, we want to differentiate service per subscriber or group of
subscribers (in terms of port mappings) and also have the capability to
have subscribers of the same NAS use different PCP servers in the future
(this also helps in testing a new PCP server by a limited number of
subscribers).

So, do you think a paragraph could be added regarding actual use cases
of this attribute?

--
Tassos

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

A new version of I-D, draft-perez-radext-radius-fragmentation-03.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 03
Title:		 Support of fragmentation of RADIUS packets
Creation date:	 2012-08-07
WG ID:		 Individual Submission
Number of pages: 17
URL:             http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-03.txt
Status:          http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation
Htmlized:        http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-03

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS packets that exceed the 4 KB limit.

The IETF Secretariat

Hi Tassos,
It=A1=AFs good to h=
ear you are interested in this topic. 
Thanks for reviewin=
g the document and providing us your feedback.Before updating the=
 draft with your comments I would like to wait for the finalization of draf=
t-ietf-pcp-dhcp so that we can synch up with the decision taken on that doc=
ument.
Does it make sense =
for you?
Thanks and best reg=
ards.
Roberta =

From: Tassos Chatzithomaoglou [mailto:achatz@forthnetgroup.gr]=

Sent: venerd=A8=AC 3 agosto =
2012 17.58

To: Maglione Roberta

Cc: radext@ietf.org

Subject: Re: [radext]
draft-maglione-pcp-radius-ext-04

Thanks for the answer Roberta. This is also what i had in mind.

imho, a paragraph should be added explaining the use cases, so the purpose =
of
this attribute is better understood.

Also, i did a quick review of the doc and i have a few comments to make, mo=
stly
semantics.

Since draft-ietf-pcp-dhcp defines that the OPTION_PCP_SERVER option can inc=
lude
multiple PCP Server Domain Names, wouldn't it be appropriate for this doc t=
o
use this behavior too?

Also, although the above draft instructs to use a name, generally speaking =
PCP
doesn't require a domain name. So

A PCP client must know the Fully Qualified Domain Name (FQDN) of a
 =
;  PCP server, before it can communicate with the later in order to
 =
;  perform the relevant PCP functions.

A PCP client must know how to contact the PCP server, either by the F=
ully Qualified Domain Name (FQDN) of it
=
 =
;  or by its IP address, before it can communicate with it in order to=
 =
;  perform the relevant PCP functions.

A note like the following should be added in the beginning:

  In order to make use of this option, this document assumes
 =
;  appropriate name resolution means (e.g., Section 6.1.1 of [RFC1123])
 =
;  are available on the host client.

Under terminology, this should probably be added.<=
/p>

Name is a domain name (as per Section 3.1 of [RFC1035]) that
 =
;     contains one or more labels.  In particular,=
 a PCP Server name may be
 =
;     structured as DNS qualified name or be composed o=
f strings such as
 =
;     can be passed to getaddrinfo (Section 6.1 of [RFC3493]), including
 =
;     address literals, etc.

When the co-located DHCPv6 server receives =
;  a DHCPv6 message containing the PCP Server Option, it SHALL use the=
 =
;  name returned in the RADIUS attribute as defined in this memo to
 =
;  populate the DHCPv6 PCP Server option defined in [I-D.ietf-pcp-dhcp]

I worry about the SHALL wording here.

I would prefer to have it user configurable (MUST) on the NAS and if enable=
d,
then used (MUST).

Figure 2, if i understand it correctly, refers to IPoE sessions, so it prob=
ably
should be rephrased.

The same applies to figure 3 too.

Also:

The Figure 2 illustrates how the RADIUS protocol and DHCPv6 work=
 =
;  together to accomplish PCP client configuration when DHCPv6 is used=
 =
;  to provide connectivity to the user.

The Figure 2 illustrates how the RADIUS protocol and DHCPv6 work=
 =
;  together to accomplish PCP client configuration when IPoE & DHC=
Pv6 are used
 =
;  to provide connectivity to the user.

The difference between this message flow and previous one is that in<=
o:p>
 =
;  this scenario the interaction between NAS and AAA/ RADIUS Server is=
 =
;  triggered by the DHCPv6 Solicit message received by the NAS from th=
e
 =
;  B4 acting as DHCPv6 client, while in case of a PPP Session the=
 =
;  trigger is the PPP LCP Config Request message received by the NAS.<=
o:p>

The difference between this message flow and previous one is that in<=
o:p>
 =
;  this scenario the interaction between NAS and AAA/ RADIUS Server is=
 =
;  triggered by the DHCPv6 Solicit message received by the NAS from th=
e
 =
;  PCP client acting as DHCPv6 client, while in case of a PPP Session =
the
 =
;  trigger is the PPP LCP Config Request message received by the NAS.<=
o:p>

If the NAS does not receive the PCP server name attribute in the=
 =
;  Access-Accept it MAY fallback to a pre-configured default tunnel
 =
;  name, if any.  If the NAS does not have any pre-configured def=
ault
 =
;  tunnel name or if the NAS receives an Access-Reject, the PCP client=
 =
;  can not be configured by the NAS.

If the NAS does not receive the PCP server name attribute in the=
 =
;  Access-Accept it MAY fallback to a pre-configured default PCP serve=
r
 =
;  name, if any.  If the NAS does not have any pre-configured def=
ault
 =
;  PCP Server name or if the NAS receives an Access-Reject, the PCP cl=
ient
 =
;  can not be configured by the NAS.

 The scenario with PPP Session and IPv4 only connectivity does n=
ot
 =
;  require the DHCP protocol: the whole configuration of the client is=
 =
;  performed by PPP.  This case is out of scope of this document =
because
 =
;  in order to complete the configuration of the PCP client a new PPP<=
o:p>

 =
;  IPC option would be required.

the above should probably be PPP IPCP option.

PCP-Server-Name is referenced many times in all lower-case letters. Probabl=
y
it's better to make it all the same.

Regards,
Tasso=
s

On 2/8/2012 4:06 =A6=CC=A6=CC, Maglion=
e Roberta wrote:

Hello Tassos,
 =
;  Thanks for your comments.
The s=
cenario we had in mind when we wrote this document is similar to the one yo=
u have just described, but the PCP is not on the BNAS it is external in the=
 Service Provider's network and we want to be able to have subscribers of t=
he same NAS using different PCP servers. The reason why we would like to us=
e radius is because we would like to be able to tie together the PCP server=
 information with the subscriber's profile stored in the Radius server.
If we=
 don't have RADIUS part, we need to pre-provision the NAS with the PCP Serv=
er name, to be used in the DHCP option for each subscriber/group of subscri=
bers. Please see attached slides.
If yo=
u think that more explanations are needed in order to clarify the use case =
we can add more text in the draft.
=

Thank=
s
Rober=
ta
=

-----=
Original Message-----
From:=
 radext-bounces@ietf.org [mailto:radext-bounces@ietf.org]=
 On Behalf Of Tassos Chatzithomaoglou
Sent:=
 venerd=A8=AC 3 agosto 2012 0.51
To: <=
a
href=3D"mailto:radext@ietf.org">radext@ietf.org
Subje=
ct: [radext] draft-maglione-pcp-radius-ext-04=

I am =
thinking of a similar implementation in our network, but after
looki=
ng at the doc i couldn't find any clear example of usage.=
=

i.e. =
If you can define a PCP server locally on the NAS (DHCP server),=
why d=
o you want to supply it through radius too?<=
pre>=

In ou=
r case, we want to differentiate service per subscriber or group of
subsc=
ribers (in terms of port mappings) and also have the capability to
have =
subscribers of the same NAS use different PCP servers in the future
(this=
 also helps in testing a new PCP server by a limited number of
subsc=
ribers).
=

So, d=
o you think a paragraph could be added regarding actual use cases
of th=
is attribute?
=

--
Tasso=
s
=

_____=
__________________________________________
radext@ietf.org
https://www.ietf.org/=
mailman/listinfo/radext
=

Quest=
o messaggio e i suoi allegati sono indirizzati esclusivamente alle persone =
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla con=
oscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate =
ricevuto questo documento per errore siete cortesemente pregati di darne im=
mediata comunicazione al mittente e di provvedere alla sua distruzione, Gra=
zie.
=

This =
e-mail and any attachments is confidential and may contain privileged infor=
mation intended for the addressee(s) only. Dissemination, copying, printing=
 or use by anybody else is unauthorised. If you are not the intended recipi=
ent, please delete this message and any attachments and advise the sender b=
y return e-mail, Thanks.
=

Dear authors,

Here is my review. Mainly editorial

- Radius -> RADIUS

- In section 2.1 and section 2.5

OLD:

   DHCPv6 [RFC3315] provides a mechanism to assign one or more or non-
   temporary IPv6 addresses to hosts. 

NEW 
   DHCPv6 [RFC3315] provides a mechanism to assign one or more non-
   temporary IPv6 addresses to hosts. 

- Extend "IPv6CP" something meaningful: PPP's IP v6 Control protocol

- Section 2.3
OLD:
   This document specifies the RADIUS attribute that allows the AAA
   system to provision the announcement by the NAS of a specific Route
   Information Option to an accessing host. 

NEW:
   This document specifies the RADIUS attribute that allows the AAA
   server to provision the announcement by the NAS of a specific Route
   Information Option to an accessing host. 

- Section 2.4
DHCPv6-PD expands to prefix delegation
   The DNS-Server-IPv6-Address Attribute contains the IPv6 address of a
   recursive DNS server. This attribute MAY be included multiple times
   in Access-Accept packets, when the intention is for a NAS to announce
   more than one recursive DNS address to an RG/host. 
   This Attribute contains the name of an assigned pool that SHOULD be
   used to select an IPv6 delegated prefix for the user.  If a NAS does
   not support multiple prefix pools, the NAS MUST ignore this
   Attribute. 

What is the user? It's confusing with the end user.
However, section 3.3 mentions: 
   This Attribute specifies a prefix (and corresponding route) for the
   user on the NAS, ...

So maybe the solution is:
OLD:

   This Attribute contains the name of an assigned pool that SHOULD be
   used to select an IPv6 delegated prefix for the user.  

NEW:

   This Attribute contains the name of an assigned pool that SHOULD be
   used to select an IPv6 delegated prefix for the user on the NAS.  

Same remark for the section 3.5
OLD:
   This Attribute contains the name of an assigned pool that SHOULD be
   used to select an IPv6 address for the user.
NEW:
   This Attribute contains the name of an assigned pool that SHOULD be
   used to select an IPv6 address for the user on the NAS.

- Section 3.4 
   If a NAS does not support multiple prefix pools, the NAS MUST 
   ignore this Attribute. 

I'm confused by the "multiple"

   In order to =
permit non-EAP aware RADIUS proxies to forward =
the
   Access-Request packet, if the NAS =
initially sends an
   =
EAP-Request/Identity message to the peer, the NAS MUST copy =
the
   contents of the Type-Data field of =
the EAP-Response/Identity received
   =
from the peer into the User-Name attribute and MUST include =
the
   Type-Data field of the =
EAP-Response/Identity in the User-Name
   =
attribute in every subsequent Access-Request.  
   When decoration =
is utilized, the EAP peer provides the decorated =
NAI
   within the EAP-Response/Identity, =
and as described in [RFC3579], the
   NAS =
copies the decorated NAI included in the =
EAP-Response/Identity
   into the =
User-Name attribute included within the access request.  =
As
   the access request transits the =
roaming relationship path, AAA
   proxies =
determine the next hop based on the realm included within =
the
   User-Name attribute, in the =
process, successively removing =
decoration
   from the NAI included in =
the User-Name attribute.  In contrast, =
the
   decorated NAI included within the =
EAP-Response/Identity encapsulated
   in =
the access request remains untouched.  As a result, when =
the
   access request arrives at the AAA =
home server, the decorated NAI
   =
included in the EAP-Response/Identity may differ from the =
NAI
   included in the User-Name =
attribute (which may have some or all =
of
   the decoration removed).  For =
the purpose of identity verification,
   =
the EAP server utilizes the NAI in the User-Name attribute, =
rather
   than the NAI in the =
EAP-Response/Identity.
     =
; It is RECOMMENDED that the Identity Response be used primarily =
for
      routing purposes =
and selecting which EAP method to use.  =
EAP
      Methods SHOULD =
include a method-specific mechanism for =
obtaining
      the =
identity, so that they do not have to rely on the =
Identity
      =
Response.  Identity Requests and Responses are sent in =
cleartext,
      so an =
attacker may snoop on the identity, or even modify or =
spoof
      identity =
exchanges.  To address these threats, it is =
preferable
      for an =
EAP method to include an identity exchange that =
supports
      per-packet =
authentication, integrity and replay protection, =
and
      =
confidentiality.  The Identity Response may not be the =
appropriate
      identity =
for the method; it may have been truncated or =
obfuscated
      so as to =
provide privacy, or it may have been decorated =
for
      routing =
purposes.  Where the peer is configured to only =
accept
      =
authentication methods supporting protected identity =
exchanges,
      the peer =
MAY provide an abbreviated Identity Response (such =
as
      omitting the =
peer-name portion of the NAI [RFC2486]).  For =
further
      discussion =
of identity protection, see Section 7.3.
   It is possible for=
 more than one Peer-Id to be exported by an EAP=0A=
   method.  For example=2C a peer certificate can contain more than one=0A=
   peer identity=3B in a tunnel method=2C peer identities can be=0A=
   authenticated within both an outer and inner exchange=2C and these=0A=
   identities could be different in type and contents.  For example=2C an=
=0A=
   outer exchange could provide a Peer-Id in the form of a Relative=0A=
   Distinguished Name (RDN)=2C whereas an inner exchange could identify=0A=
   the peer via its NAI or MAC address.  Where EAP keying material is=0A=
   determined solely from the outer exchange=2C only the outer Peer-Id(s)=
=0A=
   are exported=3B where the EAP keying material is determined from both=0A=
   the inner and outer exchanges=2C then both the inner and outer=0A=
   Peer-Id(s) are exported by the tunnel method.=0A=

Subject:	New Version Notification for draft-perez-radext-radius-fragmentation-03.txt
Date:	Tue, 07 Aug 2012 00:33:59 -0700
From:	internet-drafts@ietf.org
To:	alex@um.es
CC:	aland@networkradius.com, gabilm@um.es, diego@tid.es, pereniguez@um.es, rafa@um.es