Alper,
for some reason this reply did not make it into my inbox, so I'm
re-posting it from the web archive and continuing inline... Woj>
[Pana] RE: DSLF Requirement analysis
* To: "'Wojciech Dec \(wdec\)'" <wdec at cisco.com>, <pana at
ietf.org>
* Subject: [Pana] RE: DSLF Requirement analysis
* From: "Alper Yegin" <alper.yegin at yegin.org>
* Date: Fri, 7 Dec 2007 20:33:11 +0200
* Cc: "'Mark Townsley \(townsley\)'" <townsley at cisco.com>, 'Jari
Arkko' <jari.arkko at piuha.net>
* In-reply-to:
<[EMAIL PROTECTED]>
* List-help: <mailto:[EMAIL PROTECTED]>
* List-id: Protocol for carrying Authentication for Network Access
<pana.ietf.org>
* List-post: <mailto:[email protected]>
* List-subscribe: <https://www1.ietf.org/mailman/listinfo/pana>,
<mailto:[EMAIL PROTECTED]>
* List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/pana>,
<mailto:[EMAIL PROTECTED]>
* Thread-index:
Acg3qrpcpTCbqQAJTkSq+3+4uj3tFgAK4myQABTOtoAAB/qrYAAHX63wACROlKA=
Wojciech,
I see some times your points are digressing from what the requirements
are
talking about. We shall discuss other things separately in order to keep
the
focus on the requirements. I'm not saying they are not important; I'm
saying
those discussions outside the scope of the requirements do not impact
the
response IETF PANA WG is preparing in response to requirements.
Woj> The assessment of whether the requirements are met or not, in a
reasonable manner, is the main point of the issues I described. I don't
see how you can say that I am digressing by providing insight into the
requirements, especially since I have been involved in the work at the
DSLF. I'm not against the PANA WG formulating such an assessment, but it
should be reasonable and insightful. The one presented currently isn't.
Furthermore the fact that several equipment vendors have alerted you to
the issues with a possible implementation and use of PANA as an
authentication mechanism for IP Sessions in a DSL environment (the
purpose of these requirements) should be seen as alarming. The WG is
choosing to ignore this. The landscape (including that of the IETF) is
littered with technologies, done by smart people, but which fail because
of precisely such issues. Claiming they don't exist doesn't help.
DSLF is free to expand the requirements and request PANA WG to work on
it.
In fact I'm hearing that members are taking additional requirements to
next
week's DSLF meeting.
> > > 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.
>
> So this avoidance of double authentication relies on what I refer to
> above as a dedicated mechanism that retrieves cached circuit-id info.
BRAS learns the Option 82 via DHCP and Home AAA learns via RADIUS. What
dedicated mechanism are you referring to?
Woj> There needs to be a dedicated mechanism is the one whereby some
software component on the BRAS needs to pick up info from the
sw-component "caching" circuit-id info, when PANA is ready, and shoot
off the result to AAA. All this coupling and coordination of components
is bad news for session bring up time, troubleshooting, etc.
> It seems that this mechanism is likely to be more complex, and more
> operationally impacting then I originally thought due to the coupling
> between DHCP and PANA. The extra complexity stems from the need to
keep
> (on the BRAS) track of at least; pre-PANA hosts that have not
> authenticated; pre-PANA hosts that have authenticated; post-PANA hosts
> that have authenticated; pre-PANA addressing assignments; post-PANA
> addressing assignment. This swapping of each host from one state to
the
> other is enough to radically impact the session bring-up rate of any
> BRAS. This is a comment that has been expressed by all BRAS vendors,
and
> somehow keeps getting ignored.
We followed up on that thread in int-area list. Have you read it? Please
indicate where you disagree on that threat. Meanwhile, your above points
are
diverging from the requirement.
Woj> There is nothing diverging in saying that the way PANA claims to
meet this requirement comes at a significant cost of complexity (to both
a BRAS, and to an operator), which is what is failed to be considered;
PANA has no way of carrying circuit-id info defined today, and requires
an assorted tightly coupled mechanism to be in place to meet the
requirement.
> Furthermore the need for an operator to be able to understand,
> configure, maintain and troubleshoot this mechanism, besides the added
> overhead of having to use the extra pre-PANA pools, is what impacts
> operations adversely. Based on my work with operational departments I
> can say that this mix is enough to dissuade many.
> I do not agree that PANA currently satisfies this requirement and my
> ISSUE with the assessment still stands.
> >
> > 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.
>
> Not sure what you mean by "AAA delivers the expected Option-82 to the
> network"? AAA expects to hear that value from the network device, not
> the other way round.
Let me be a bit more elaborate on that. AAA client on the BRAS learns
the
expected value (or values??) from AAA server during network access
authentication. DHCP follows access authentication. During DHCP, BRAS
learns
the used value from network device (DSLAM, etc.) via DHCP. And BRAS does
the
comparison to see if they match.
Woj> This is indeed very novel. So in fact the first trip to the AAA
server triggered by PANA delivers the circuit-id to the BRAS in the AAA
response. Then DHCP triggers local Authorization at the BRAS. This is
even more tight coupling of mechanism in evidence, also requiring an
operator to make changes to Radius. The answer to another requirement
actually claims that no Radius changes are needed!
> In any case, the local link address option is a non
> starter for IPv4. PANA does not satisfy this requirement.
You should explain why IPv4 link-local is a non-starter.
Woj> A couple of non trivial issues:
- Show me any SP using it for anything in broadband? (Link local has
been defined for small networks)
- Doesn't work in shared VLAN model where host-host L2 forwarding is
disabled (the conflict resolution mechanism doesn't work)
- Requires more changes on Access node to enable forwarding
>
> >
> >
> > > 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.
>
> Perhaps if the equipment vendors were to pay operators to deploy,
> maintain and troubleshoot (i.e. effectively out source operations)
then
> adding new protocols becomes a non issue. Any other arrangement is
> operationally impacting, which comes down to increased costs for the
> operator. The desire to remove PPP (an extra protocol) is a reverse
> example of this. I see no way that adding new protocol (like PANA) can
> claim not to increase it. Again, PANA does not match this requirement.
Requirement has nothing to do with whether a new protocol can be added
or
not. Again, completely missing such a requirement. If you have issues
with
the requirements, you shall convince DSLF to modify it?
Woj> Try this exercise. The requirement states: Must fit into TR-101
operational model. Read TR-101, draw an operational model and see what
components come up. I assure you that things like managing pre-PANA
pools, handling pre-PANA authentication failures, configuring PANA,
dealing with link local addressing, etc, will not be there, nor will you
find any operator currently managing this items. It doesn't take a
wealth of knowledge to see that PANA is a new operational item, and the
assessment presented is not correct.
> > > 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.
>
> As stated earlier; local link addressing is a non starter (it doesn't
> even convey circuit-id, besides being something of a esoteric
substance
> for IPv4).
Discussed above.
> Then, 2a does not meet the criteria of assigning a useful IP
> address after authentication.
Yes, option 2a's applicability is limited to those deployments/scenarios
that do not rely on AAA-delivered IP address. [There's a workaround to
this
issue if DSLF is willing to accept going to AAA twice: Once for during
DHCP;
second time during PANA]
Woj> One of the problems in the assessment is that it appears to respond
to different requirements with different PANA deployment models (there
are at least three - 1, 2a and 2b). Since an operator will only use one
of these, the assessment should clarify which one is assumed in each
case.
> And all of 2, as mentioned earlier, due to
> the short DHCP leases are OS impacting.
Nothing to do with the OS. It's a configuration on the DHCP server to
set
the lease time.
Woj> But the client is affected, eg DHCP stack... The assessment claims
no such impact is there.
> Finally, this link actually reveals the truth about the unsuitability
of
> DHCP-short leases on at least one popular OS platform (other
> implementations deriving from RFC 1541 are likely to have similar
> issues):
> http://support.microsoft.com/kb/158016
It's talking specifically about "Microsoft Windows NT DHCP Service". Is
complying with "Microsoft Windows NT DHCP Service" deployment guidelines
part of DSLF requirements? Can you figure out the technical essence,
necessity of what they are saying? They even say "Additionally, a DHCP
Administrator may want to assign a shorter lease time to scopes with low
ratios of available addresses. Setting the lease time shorter in both
these
cases will increase the availability of addresses."
Woj> The above link simply points out something that DHCP practitioners
and several operators have known for some time; short leases don't quite
work in reality. The answer to this requirement claims that besides PANA
there is no other impact on the client, well I differ especially
whenever mention of DHCP short leases is made (and it is made quite
often)
> > > 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.
>
> That's an assertion to which you're entitled, but based on the
> previously presented arguments I disagree. OSes are impacted, 1 is a
> no-go, and 2 introduces unnecessary complexity on the BRAS.
>
> >
> > 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.
>
> Not everyone runs Solaris... Your statement contradicts the answer the
> PANA WG gave to this requirement, yet you don't admit so. Allow me to
> quote "Yes Implementation does not require changes to the operating
> system.
I gave Solaris as an example that I'm familiar with. We need to check
other
OSes if they support the same. If the same feature is available, it is
usable this way. If not, it's still OK -- see Yoshi's response.
Woj> A better thing would be to acknowledge that using PANA may require
the use of a new DHCP stack on the client alongside it, thus is client
impacting.
> Open source implementation available.". The open source topic is
> a red herring, as it all depends on what conditions are attached to
it,
> and the policy of the implementers for using open source...
www.opendiameter.org Project includes PANA implementation. Do you see
something in that implementation such that it shall not qualify as "open
source"? If so, we can reconsider making such a statement.
Woj> I'll leave that to lawyers. My point was that one shouldn't use the
"open source is here" argument when answering the requirement "Must be
simple to implement ...", because you have no way of knowing whether
people will choose the open source software or not.
> > > 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?
>
> Please check the IETF70 SAVI BOF material. In the pre-PANA DHCP
> short-lease case IP traffic will flow between the client and the BRAS
> before authentication. This is enough to have broken a common L2
> security mechanism, or require changes on the DSLAMs/Access-Nodes.
> Again, this requirement is not fulfilled by PANA without resorting to
> mechanisms that are un-realistic (and most likely broken)
Can you, please, answer this question that I'm asking you for the 2nd
time
and other DHCP-auth supporters for the 4th time: Whatever problems you
are
seeing with the client being configured with an IP address before it is
authenticated, how does it work with DHCPv6 given that the client is
configured with IPv6 link-local address before it initiates DHCPv6?
Woj> You seem to have a personal obsession with DHCP-Auth that is
clouding your judgment, and seemingly the assessment statement. Nowhere
do I mention DHCP-Auth in this thread and my comments are strictly about
the PANA WG's assessment of the DSLF Requirements; take them as a cue on
what's missing in PANA.
Regarding your question: Configuring an IP address on the client before
authentication requires a significant change to the L2 security
mechanisms utilized today by operators today, as well as BRAS changes,
etc. Have a look at SAVI. I'm making a very specific IPv4 statement here
and if you look at the vast majority of SPs, that's what they're using
today. The assessment of the PANA WG for this requirement assumes that
it's ok to configure such IP addresses. I'm saying that this is not ok.
-Woj.
Alper
>
> -Woj.
>
> >
> > 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 <alper.yegin at yegin.org>
> > > > To: <pana at ietf.org>
> > > > CC: 'W. Mark Townsley' <townsley at cisco.com>, 'Jari Arkko'
> > > > <jari.arkko at piuha.net>
> > > >
> > > >
> > > >
> > > > 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
Pana at ietf.org
https://www1.ietf.org/mailman/listinfo/pana
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
