Wojciech,
> IPAuth-4 Must allow for authorization purposes the use of any
> additional identifiers that may be available, eg MAC address, Option82
> circuit-id.
> PRESENTED ANSWER: Yes. MAC address is already available on the IP
> messages that carry PANA. PANA does not prevent use of Option 82 with
> DHCP.
> ISSUE: There is a fundamental problem in this assessment in that it
> assumes that DHCP Option 82 authentication will happen *separately* from
> PANA authentication or that somehow a mechanism will be implemented that
> allows PANA authentication to retrieve some cached DHCP option info
> (more on this later). This is either effectively double authentication
> with double the Radius messaging load, or a significant complication for
> BRASes. It is contrary to the spirit of the requirement which says that
> at (single) authentication additional parameters like client MAC address
> and/or Option 82 must be available.
There does not have to be two RADIUS calls.
If the pre-PANA address is configured via DHCP (as opposed to being a
link-local address), then the Option 82 is made available to the
authenticator but that does not trigger RADIUS call. Instead, RADIUS call is
triggered when the PANA starts. So, the RADIUS call triggered by PANA can
convey both the circuit ID and also carry out the EAP authentication.
If the pre-PANA address is a link-local address, then again PANA triggers
the RADIUS call. And this time AAA can deliver the expected Option 82 value
to the network. RADIUS is not triggered during the DHCP that follows PANA.
The expected value is checked against the incoming DHCP message's Option 82
and verified.
> IPAuth-6 Must fit into TR-101 operational model
> PRESENTED ANSWER: Although we do not see any issues there, IETF does not
> have the expertise to fully evaluate this requirement.
> ISSUE: The TR-101 operational model, as any DSL operator's model,
> revolves around a familiar access protocol toolset composed primarily
> of; PPP, PPPoE, DHCP, Radius. Introducing a totally new protocol,
> coupled with additional device configuration, etc, to this mix has a
> fair bit of operational impact on an operator. This is a very pragmatic
> issue, but very relevant. PANA clearly suffers from this issue, and it
> doesn't require specific expertise to see this.
You are saying a new protocol is a no-no. I don't see that requirement
anywhere.
> IPAuth-9 Should be simple to implement on client (PC or CPE)
> PRESENTED ANSWER: Yes Implementation does not require changes to the
> operating system. Open source implementation available.
> ISSUE: I believe there are overlooked OS impacts here. PANA requires
> that a short, but not too short, temporary DHCP ip address lease for
> authentication be granted before the second post-PANA DHCP lease is
> granted.
As we said, this is not a MUST. There are other options. But to give you the
full list:
1. PaC configures a link-local address, or
2. PaC configures a short-lease DHCP address
2.a. That address is same as what the PaC will use after successful
authentication, or
2.b. PaC will be configured a new IP address after successful
authentication.
> The OS must be able to handle this IP address and config change
> without disrupting applications above. If the temporary IP address lease
> is presented to the OS for use by applications other than PANA, and then
> shortly thereafter revoked, visible disruptions to applications may
> occur as sockets are reset, applications which received (or did not
> receive) proper config information in the first DHCP lease may not
> receive or be able to handle this config change without some timeouts,
> etc. (think about what happens to some OSes when you try to move from
> one subnet to another and receive a new DHCP lease). Bottom line, the IP
> address to IP address and lease to lease transition has a lot of
> potential for race conditions that could affect applications on the OS.
> One way to mitigate this would be to not present the first DHCP lease
> information to any application other than EAP, but of course this likely
> requires OS changes.
1 and 2a have no problem.
2b requires the OS to hide the interface from applications. I worked on
Solaris TCP/IP development. I know Solaris has a way to mark an interface
hidden -- so that it does not appear to the applications that does not know
it exists. I can see if other OSes have similar features. OSes which has
this capability can also use 2b without impacting applications.
>
> IPAuth-14 Must allow for authentication and download of
> subscriber service profile before service IP address is assigned
> PRESENTED ANSWER: Yes PANA requires an IP address be configured prior
> to authentication (a IPv4/IPv6 link-local, or a short-lease DHCP
> address), but allows the "service IP address" be assigned after
> authentication.
> ISSUE: As discussed on the int-area thread, assigning IP addresses
> (temporary ones) for authentication purposes and then changing them does
> not fit the operational model of DSL, breaks the security mechanisms
> used in the access network,
Can you point to the text that we are breaking?
And also explain how DHCPv6 that runs with link-local IPv6 address is not a
problem (by now I asked this question at least 3 times here and there -- no
answer....)
> and requires that the BRAS and client OS be
> resilient to on-the-fly IP address changes.
Already explained above.
> Also possibly the DSLAM and
> L2 aggregation switches.
Thanks.
Alper
>
> Regards,
> Woj.
>
>
> > -------- Original Message --------
> > Subject: DSLF Requirement analysis
> > Date: Thu, 6 Dec 2007 03:38:50 +0200
> > From: Alper Yegin <[EMAIL PROTECTED]>
> > To: <[email protected]>
> > CC: 'W. Mark Townsley' <[EMAIL PROTECTED]>, 'Jari Arkko'
> > <[EMAIL PROTECTED]>
> >
> >
> >
> > In the spirit of analyzing the DSLF's Subscriber Authentication
> > Requirements as presented through a liaison letter on May 25, 2007, we
>
> > discussed the following material during IETF 70 PANA WG meeting.
> >
> > http://www3.ietf.org/proceedings/07dec/slides/pana-3.ppt
> >
> > We have reached consensus among the PANA WG members present in the
> > room. In order to make this an official WG consensus, we are running
> > this by the WG via mailing list.
> >
> > If you have any feedback, please send an e-mail on the mailing list by
>
> > December 11, 2007 Tuesday 6pm PT.
> >
> > If there is no objection, IETF PANA WG will send a liaison letter to
> > DSLF based on this consensus.
> >
> > - IETF PANA WG Chairs
> >
> >
> >
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
