Subject: [Pana] Re: DSLF Requirement analysis

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Thu, 6 Dec 2007 18:10:30 +0100

Hi Alper, Pana WG,

on looking through the assessment of PANA against the DSLF requirements,
which I have participated in laying down at the DSLF, I have to express
a good number of issues wrt to the conclusions/justifications presented.
I really cannot agree with statements put forward in the conclusion
statement.
The main issues specifically are:

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. 

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.

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. 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.

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, and requires that the BRAS and client OS be
resilient to on-the-fly IP address changes. Also possibly the DSLAM and
L2 aggregation switches.

Regards,
Woj.

> -------- Original Message --------
> Subject: 	DSLF Requirement analysis
> Date: 	Thu, 6 Dec 2007 03:38:50 +0200
> From: 	Alper Yegin <[email-masked]>
> To: 	<[email-masked]>
> CC: 	'W. Mark Townsley' <[email-masked]>, 'Jari Arkko' 
> <[email-masked]>
> 
> 
> 
> 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-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: "Curtis Sherbo" <[email-masked]>
Date: Thu, 6 Dec 2007 09:23:19 -0800

As a member of the DSL Forum, I second this analysis.  I think it is
fine to present a proposal in a liaison, but I agree that the
requirements below are not met as presented in the Analysis.

Regards,
Curtis Sherbo 

-----Original Message-----
From: Wojciech Dec (wdec) [mailto:[email-masked]] 
Sent: Thursday, December 06, 2007 9:11 AM
To: Alper Yegin; [email-masked]
Cc: Mark Townsley (townsley); Jari Arkko
Subject: [Pana] Re: DSLF Requirement analysis

Hi Alper, Pana WG,

Regards,
Woj.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 6 Dec 2007 23:49:19 +0200

Wojciech,

> 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.

> 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.

> 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

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.

> 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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 7 Dec 2007 04:06:44 -0500

On Thu, Dec 06, 2007 at 06:10:30PM +0100, Wojciech Dec (wdec) wrote:
(snip)
> information to any application other than EAP, but of course this likely

I don't understand why this is an issue.  IP address change after
launching applications can happen in many situations (e.g., change
from link-local address to global address, change from CoA to HoA upon
successful Mobile IP registration, change from using a physical
interface address to tunnel inner address upon IPsec tunnel
establishment for VPN, etc).  IP address change is something OS and
applications have to deal with, regardless of whether PANA is used or
not, and I think many OSes and applications already deal with it.

Yoshihiro Ohba

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 7 Dec 2007 13:03:53 +0100

Alper, 

your reply does not contain any new items that change my disagreement
wrt to the PANA assessment. The issue appears to be in the effort to
ignore, or severely short change, the additional operational costs that
PANA is bound to introduce, along with the impact to existing devices
due to the extra complexity. 

> From: Alper Yegin [mailto:[email-masked]] 
> Sent: 06 December 2007 13:49
> To: Wojciech Dec (wdec); [email-masked]
> Cc: Mark Townsley (townsley); 'Jari Arkko'
> Subject: RE: DSLF Requirement analysis
> 
> Wojciech,
> 
> > 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.
> 
> 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. 
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. 
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. In any case, the local link address option is a non
starter for IPv4. PANA does not satisfy this requirement.

> > PRESENTED ANSWER: Although we do not see any issues there, 
> IETF does 
> > not have the expertise to fully evaluate this requirement.
> > 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.

> 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

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). Then, 2a does not meet the criteria of assigning a useful IP
address after authentication. And all of 2, as mentioned earlier, due to
the short DHCP leases are OS impacting.
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

> > 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
> > 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 
> > information to any application other than EAP, but of course this 
> > likely requires OS changes.
> 

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. 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...

> > (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,
> 

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)

-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.
> 
> > > Requirements as presented through a liaison letter on May 
> 25, 2007, 
> > > we
> > 
> > > If you have any feedback, please send an e-mail on the 
> mailing list 
> > > by
> >

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 7 Dec 2007 20:33:11 +0200

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.

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.

> 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? 

> 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. 

> 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.

> In any case, the local link address option is a non

You should explain why IPv4 link-local is a non-starter.

> 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?

> 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]

> And all of 2, as mentioned earlier, due to

Nothing to do with the OS. It's a configuration on the DHCP server to set
the lease time.

> 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 availible addresses. Setting the lease time shorter in both these
cases will increase the availiblity of addresses."

> 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.

> Open source implementation available.". The open source topic is

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.

> 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?

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 7 Dec 2007 13:37:52 -0500

I have a feeling that the two things are mixed in the discussion : (i)
whether a requirement is satisfied, and (ii) how complex a solution
would be to satisfy the requirement.  I suggest we focus on (i).  I
have a problem with discussing (ii) here, because it tends to be based
on additional unwritten requirements such as "number of states" and
"troubleshoot" and I cannot agree on arguments based on unwritten
requirements.

Yoshihiro Ohba

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Fri, 7 Dec 2007 19:54:34 +0100

The list of requirements is the only material available from the DSL Forum and we should stay focus on!

Actually I refer to a previous mail that I sent on this topic on the Intarea ML:
 (snip)

"Now, one "could" say that the PANA protocol specification is "quite"
stable as a Proposed Standard RFC is available ;) Therefore, the question is quite simple: why do not simply reconsider the use of PANA in DSL environment? The proposed alternative, i.e. DHCP-based authentication, that is for the moment only an individual submission at IETF, will have anyway impacts on the DHCP client, the DHCP server and DSL network node behaviours if the goal is to have EAP in DHCP. And the proposed alternative do not explain why the current possible solution(s) don't fulfil the DSL Forum requirements... And I'm not sure that there is a direct link between the existing use of the DHCP option 82 in DSL network leads seamlessly to DHCP-EAP...

At least, a pragmatic approach within IETF would be to see how PANA can fulfill DSL forum security requirements, see if there is some functionality gaps, see if this gap could be fulfilled with within PANA or with possible add-on solutions and if not, see other alternatives should be investigated. Only because IETF has already defined "the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks."

I support the actual ongoing work in the PANA WG to clarify the fact that PANA, as a candidate protocol, is fulfilling DSL requirements. It is not said that PANA is the ultimate solution for DSL networks. It is just said that the PANA protocol should be considered as serious candidate protocol.

And I agree with the current content of the slides.

Lionel

> -----Message d'origine-----
> De : Yoshihiro Ohba [mailto:[email-masked]] 
> Envoyé : vendredi 7 décembre 2007 19:38
> À : [email-masked]
> Cc : Mark Townsley (townsley); Jari Arkko
> Objet : Re: [Pana] RE: DSLF Requirement analysis
> 
> I have a feeling that the two things are mixed in the 
> discussion : (i) whether a requirement is satisfied, and (ii) 
> how complex a solution would be to satisfy the requirement.  
> I suggest we focus on (i).  I have a problem with discussing 
> (ii) here, because it tends to be based on additional 
> unwritten requirements such as "number of states" and 
> "troubleshoot" and I cannot agree on arguments based on 
> unwritten requirements.
> 
> Yoshihiro Ohba
> 
> 
>

---

From: "Julien Bournelle" <[email-masked]>
Date: Mon, 10 Dec 2007 09:25:41 +0100

Hi all,

 I second lionel. PANA fulfills DSL Forum requirements and should be
considered as a serious candidate.

 Regards,

 Julien Bournelle

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 10 Dec 2007 13:04:13 +0100

Hi all,

I cannot be more agree with Lionel's comments here. I support the 
consensus taken in PANA WG and the content of the slides.

Best regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Depto. Ing. de la Info. y las Comunicaciones
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 10 Dec 2007 08:36:48 -0500

Hi all,

I agree with the PANA analysis as well. I think PANA fits the DSL Forum 
requirements quite cleanly. Additionally, the proposed alternative, 
i.e.; DHCP-based authentication would essentially be a remake of 
functionality that PANA already possess with the dis-advantage of having 
DHCP and authentication tightly coupled. So, it just common sense to 
consider PANA as an alternative. The claim that DHCP solution is less 
intrusive does'nt make sense to me either, since your going to have to 
modify the DHCP client and server implementation regardless. This is 
probably more disruptive than just adding another protocol on top of an 
existing IP stack; i.e. PANA. I maybe stating the obvious but it 
certainly is better from an architecture stand point not to create a 
monolithic do it all protocol from DHCP.

regards,
Victor Fajardo

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 11 Dec 2007 12:56:29 +0100

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-masked]>
    * List-help: <mailto:[email-masked]?subject=help>
    * List-id: Protocol for carrying Authentication for Network Access
<pana.ietf.org>
    * List-post: <mailto:[email-masked]>
    * List-subscribe: <https://www1.ietf.org/mailman/listinfo/pana>,
<mailto:[email-masked]?subject=subscribe>
    * List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/pana>,
<mailto:[email-masked]?subject=unsubscribe>
    * 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.

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.

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. 

> network"? AAA expects to hear that value from the network device, not

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!

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

> 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.

Discussed above. 

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. 

> 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.

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)

> quote "Yes Implementation does not require changes to the operating

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.

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.

> 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

> > > > 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>
> > > >
> > > >
> > > >

Pana at ietf.org

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 11 Dec 2007 14:53:37 +0200

> off the result to AAA. 

There is already such code extracting the Option 82 content from DHCP
message and "shooting off" to AAA with RADIUS, right?

> All this coupling and coordination of components

You need to substantiate such claims with technical points. Otherwise not
sure what purpose such claims serve, especially repeating them...

> actually claims that no Radius changes are needed!

"Must re-use existing SP Authentication infrastructure (use Radius Database)
..."

What we are talking about is carrying the already defined RADIUS attribute
(the one used for transporting Option 82 payload) from AAA server to the
client, as opposed to what's already done now: from AAA client to the
server. This does not touch the RADIUS database at all.

> been defined for small networks)

You need to point out a specific problem. Saying that it is not used so it
shall never be used does not make any sense.

> disabled (the conflict resolution mechanism doesn't work)

Why not? So, you won't allow use of IPv6 link-locals either? If there are
real problems how do you expect IPv6 to work at all?

> - Requires more changes on Access node to enable forwarding

Again, just a claim without any technical explanation is not useful for this
discussion.

> Woj> But the client is affected, eg DHCP stack... The assessment claims

You must have a different definition for "OS impacting." By no definition of
"OS impacting" one would think that sending a different lifetime value in a
variable field would impact the "operating system", or "protocol stack".

> people will choose the open source software or not.

It's their decision. We are just providing them information.

> clouding your judgment, and seemingly the assessment statement. Nowhere

Please stay away from making such judgments and personal comments on this
mailing list.

> it's ok to configure such IP addresses. I'm saying that this is not ok.

Where does the requirement say "it is not OK"? 
We are going with the official DSLF requirements. I don't see a requirement
like what you are saying. Rather than expressing your own requirements and
your own interpretations, please seek DSLF to amend and expand the current
requirements. That'd be more productive for all of us.

Alper

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 11 Dec 2007 16:39:38 +0100

First off, am I correct in assuming that you agree with the other issues
you chose not to comment on and that you will be taking action to amend
the assessment on these points specifically:

---snip---

and inline...

> Sent: 11 December 2007 12:54
> Subject: RE: [Pana] Re: DSLF Requirement analysis
> 
> > BRAS learns the Option 82 via DHCP and Home AAA learns via RADIUS. 
> > What dedicated mechanism are you referring to?
> > 
> There is already such code extracting the Option 82 content 
> from DHCP message and "shooting off" to AAA with RADIUS, right?

Woj> Right, all in an atomic operation.

> 
> > All this coupling and coordination of components is bad news for 
> > session bring up time, troubleshooting, etc.
> 
> You need to substantiate such claims with technical points. 
> Otherwise not sure what purpose such claims serve, especially 
> repeating them...

Woj> I take it you're refusing to accept the fact that vendors
experienced with building these products have concerns with what this
technology involves. 

> > > 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.
> > > > 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 
> > > 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.
> > 
> > the expected value (or values??) from AAA server during 
> network access 
> > learns the used value from network device (DSLAM, etc.) via 
> DHCP. And 
> > BRAS does the comparison to see if they match.
> > 
> > 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!
> 
> 
> "Must re-use existing SP Authentication infrastructure (use 
> Radius Database) ..."
> 
> What we are talking about is carrying the already defined 
> RADIUS attribute (the one used for transporting Option 82 
> payload) from AAA server to the client, as opposed to what's 
> already done now: from AAA client to the server. This does 
> not touch the RADIUS database at all.

Woj> I see that you have not bounced this off any operator running large
scale Radius set-ups today? Sending a circuit-id in an access-accept
requires at least a change to an existing Radius set-up, and in some
cases the server code; servers don't just do this automatically today,
nor is this done (or required) for ppp access. I won't even mention
things like Radius proxies. 

> 
> > > In any case, the local link address option is a non starter for 
> > > IPv4. PANA does not satisfy this requirement.
> > 
> You need to point out a specific problem. Saying that it is 
> not used so it shall never be used does not make any sense.

Woj> The fact that it is not used impacts the operational model, so it
is a valid point.

> Why not? So, you won't allow use of IPv6 link-locals either? 
> If there are real problems how do you expect IPv6 to work at all?

Woj> You're throwing the IPv6 mantra back at me, while I'm telling you
that IPv4 link locals won't work in today's L2 access and aggregation
set-ups, or require extensive changes to the security mechanisms. 

> Again, just a claim without any technical explanation is not 
> useful for this discussion.

Woj> Perhaps you could illuminate us on how you envisage that an
access-node that is configured NOT to pass any IP traffic before seeing
a DHCP assignment will be able to forward local link IP sourced
addresses to the BRAS?

> 
> > > And all of 2, as mentioned earlier, due to the short DHCP 
> leases are 
> > > OS impacting.
> > 
> > set the lease time.
> > Woj> But the client is affected, eg DHCP stack... The assessment 
> > Woj> claims
> > no such impact is there.
> 
> You must have a different definition for "OS impacting." By 
> no definition of "OS impacting" one would think that sending 
> a different lifetime value in a variable field would impact 
> the "operating system", or "protocol stack".

Woj> Your point is in theory reasonable, unfortunately in practice (as
I've been taking pains to point out) sending such a different lifetime
value can prove to require DHCP protocol stack changes, besides a PANA
stack to be added. Some call that OS impacting...

> 
> > > Open source implementation available.". The open source 
> topic is a 
> > > red herring, as it all depends on what conditions are attached to
> > it,
> > 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 
> > Woj> the
> > 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?
> > 
> Please stay away from making such judgments and personal 
> comments on this mailing list.

Woj> Somehow this has not what stopped you from making a judgment about
me and DHCP-auth supporters...

> 
> > 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 
> > 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.
> 
> We are going with the official DSLF requirements. I don't see 
> a requirement like what you are saying. Rather than 
> expressing your own requirements and your own 
> interpretations, please seek DSLF to amend and expand the 
> current requirements. That'd be more productive for all of us.

Woj> We sure will. The whole

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 11 Dec 2007 14:05:12 -0500

On Tue, Dec 11, 2007 at 12:56:29PM +0100, Wojciech Dec (wdec) wrote:
(snip)
> actually claims that no Radius changes are needed!

I agree that some mechanism to carry circuit-id in PANA message would
be needed when DHCP is not used for obtaining a pre-PANA address, in
order to avoid any change to existing RADIUS implementations.  We
(PANA WG) can certainly work on a mechanism to carry a circuite-id in
PANA-Client-Initiation (PCI) message if needed.  That's not a big deal
than adding a mechanism to carry EAP over DHCP in terms of IETF
specification work.

On the other hand, there are also other PANA use cases in which DHCP
is used for obtaining a pre-PANA address.  In such cases, I don't
think any change to existing RADIUS implementations is needed.  So
overall, I think the current assessment is still valid.

(snip)
> whenever mention of DHCP short leases is made (and it is made quite

More information is available on the short lease with Windoes DHCP
server:

http://support.microsoft.com/kb/261964

"After a Dynamic Host Configuration Protocol (DHCP) client lease
expires, it is not immediately scavenged from the database."  This
means Windows DHCP server is slow to update the database (and hence
short lease is not recommended).  On the other hand, I could not
interprete the text to indicate all DHCP servers on any OS have the
same issue and/or Windows DHCP clients do not work with short lease.

(snip)

> it's ok to configure such IP addresses. I'm saying that this is not ok.

I don't really understand why configuraing IPv6 link-local address
before authentication will satisfy DSLF requirements while
configuraing IPv4 address before authentication won't.  Can you please
explain?

Yoshihiro Ohba

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 11 Dec 2007 20:46:14 +0100

> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: 11 December 2007 19:05
> To: Wojciech Dec (wdec)
> Cc: Alper Yegin; [email-masked]; Mark Townsley (townsley); Jari Arkko
> Subject: Re: [Pana] Re: DSLF Requirement analysis
> 
> I agree that some mechanism to carry circuit-id in PANA 
> message would be needed when DHCP is not used for obtaining a 
> pre-PANA address, in order to avoid any change to existing 
> RADIUS implementations.  We (PANA WG) can certainly work on a 
> mechanism to carry a circuite-id in PANA-Client-Initiation 
> (PCI) message if needed.  That's not a big deal than adding a 
> mechanism to carry EAP over DHCP in terms of IETF specification work.
> 
> On the other hand, there are also other PANA use cases in 
> which DHCP is used for obtaining a pre-PANA address.  In such 
> cases, I don't think any change to existing RADIUS 
> implementations is needed.  So overall, I think the current 
> assessment is still valid.

The issue is that an operator will deploy one mode of PANA or the other,
not both. The assement should indicate which one is assumed for the
answers. The other issue, as in my previous mails, is that if this extra
coupling of DHCP-PANA-AAA state is assumed then it complicates BRAS
implementations and more significantly operations.

> 
> (snip)
> > 
> > > Finally, this link actually reveals the truth about the 
> > > unsuitability
> > of
> > 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 
> > Woj> 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)
> 
> "After a Dynamic Host Configuration Protocol (DHCP) client 
> lease expires, it is not immediately scavenged from the 
> database."  This means Windows DHCP server is slow to update 
> the database (and hence short lease is not recommended).  On 
> the other hand, I could not interprete the text to indicate 
> all DHCP servers on any OS have the same issue and/or Windows 
> DHCP clients do not work with short lease.

Woj> Let's say that this is a grey area. My previous feedback from
operators has highlighted that this is an issue. That said unless the
PANA WG can claim with 100% accuracy that it's not an issue, the
assement is not accurate.

> > > 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)
> > 
> > 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.
> I don't really understand why configuraing IPv6 link-local 
> address before authentication will satisfy DSLF requirements 
> while configuraing IPv4 address before authentication won't.  
> Can you please explain?

Woj> I'm specifically not addressing IPv6, because how IPv6 should
actually be deployed in broadband is a grey area for me. I can count on
one hand the # of operators I know who have done so, and amongst these
there are differences.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 11 Dec 2007 16:11:53 -0500

On Tue, Dec 11, 2007 at 08:46:14PM +0100, Wojciech Dec (wdec) wrote:
(snip)
> answers. 

I think at this moment it is hard for PANA WG to determine/suggest
which use case should be used for DSL (more requirements are expected
to recommend one).  But we can certainly include detailed assessment
(like above) if that helps DLSF to understand the assesment better.

> The other issue, as in my previous mails, is that if this extra

As I expressed previously, I don't agree with this issue since there
is no written requirement on BRAS complexity.

> assement is not accurate.

I don't really see an issue unless operators are clear about what
the exact issue on existing DHCP client with short lease.

> one hand the # of operators I know who have done so, and amongst these

Given that IPv6 needs to be considered according to IPAuth-11, I don't
see an issue on assigning an IP address before authentication.  For
the same reason, assigning an IP address before authentication should
not be an issue even for DHCP authentication for IPv6.

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 12 Dec 2007 00:05:51 +0200

> you chose not to comment on 

No I don't. And I had already responded to those issues.

> and that you will be taking action to amend

The point of enumeration was to show there exists solutions to the problem
you claimed. Both 1 and 2b being practical and applicable to all
requirements as explained, I don't see a need to do anything else.

> experienced with building these products have concerns with what this

We certainly followed up on their input on the int-area list and I had
already said that we did that and I had even given this link:
http://www1.ietf.org/mail-archive/web/int-area/current/msg01129.html

> things like Radius proxies.

You seem to be talking about "not even a single line of code change." So
once again, you seem to have more requirements in your mind than what the
requirements read. If you convince DSLF that the requirements shall be
amended in such a way, then you should do that. Once we get such
requirements from DSLF, we make an attempt at responding to them.

> set-ups, or require extensive changes to the security mechanisms.

Telling us? You should be explaining the "why" part..... We cannot be going
with your assessment without seeing the technical explanation. 

> a DHCP assignment will be able to forward local link IP sourced

Once again...... as explained earlier on the int-area list...... this
appears to be reconfiguration of filters to allow PANA in addition to DHCP.

> value can prove to require DHCP protocol stack changes, 

I find it impossible to believe that you need a different DHCP stack because
now your DHCP client is getting a short lease. 

> besides a PANA

As iterated many times on the int-area list, PANA can be added as 3rd party
software. It does not have to impact the OS.

> > > Nowhere

Alper

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 12 Dec 2007 10:16:21 +0100

> Sent: 11 December 2007 22:06
> > First off, am I correct in assuming that you agree with the other 
> > issues you chose not to comment on
> 

You haven't

> > and that you will be taking action to amend the assessment on these 
> > points specifically:
> > 
> > ---snip---
> > 
> > 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.
> > 
> > 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.
> > 
> > Woj> One of the problems in the assessment is that it appears to 
> > Woj> respond
> > 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.
> 
> The point of enumeration was to show there exists solutions 
> to the problem you claimed. Both 1 and 2b being practical and 
> applicable to all requirements as explained, I don't see a 
> need to do anything else.

Practical in your mind, and during the course of this discussion it's
become increasingly evident that there's been very poor guidance in how
DSL operators deploy their networks, and the practical problems in them,
and the mechanisms already in place on the network elements. You've also
chosen to ignore BRAS vendor concerns.

> > > > Woj> There needs to be a dedicated mechanism is the one whereby 
> > > > Woj> some
> > > There is already such code extracting the Option 82 content from 
> > > DHCP message and "shooting off" to AAA with RADIUS, right?
> > 
> We certainly followed up on their input on the int-area list 
> and I had already said that we did that and I had even given 
> this link:

If you're referring to the statement "And yes your observation is
correct, the DHCP auth solution with EAP has
the same issues" you're missing the point, I'm talking about a PANA
solution specifically and the statement is that it will be difficult to
acheive the same scale and performormance. It also affects the widely
deployed access-nodes (have you ever tried configuring a dynamic PANA
filter on an access-node??)

> > > > > 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.
> > > > > Not sure what you mean by "AAA delivers the expected 
> Option-82 
> > > > > to the network"? AAA expects to hear that value from 
> the network 
> > > > Woj> This is indeed very novel. So in fact the first 
> trip to the 
> > > > Woj> 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
> > > "Must re-use existing SP Authentication infrastructure 
> (use Radius 
> > > Database) ..."
> > >
> > > What we are talking about is carrying the already defined RADIUS 
> > > attribute (the one used for transporting Option 82
> > > payload) from AAA server to the client, as opposed to 
> what's already 
> > > done now: from AAA client to the server. This does not touch the 
> > > RADIUS database at all.
> > 
> > Woj> I see that you have not bounced this off any operator running 
> > Woj> large
> You seem to be talking about "not even a single line of code 
> change." So once again, you seem to have more requirements in 
> your mind than what the requirements read. If you convince 
> DSLF that the requirements shall be amended in such a way, 
> then you should do that. Once we get such requirements from 
> DSLF, we make an attempt at responding to them.
> 
> starter for 
> > > You need to point out a specific problem. Saying that it 
> is not used 
> > > so it shall never be used does not make any sense.
> > 
> Telling us? You should be explaining the "why" part..... We 
> cannot be going with your assessment without seeing the 
> technical explanation. 

IPv4 is still around, that's what I'm telling you. That's technical fact
#1. Fact #2, look at SAVI which describes the source guard mechanism
used today - your assement makes no mention of the assumption that such
a mechanism needs to be either revised, or dual addressing pools (and
short leases) be used.

> > > Again, just a claim without any technical explanation is 
> not useful 
> > > for this discussion.
> > 
> > access-node that is configured NOT to pass any IP traffic before 
> > seeing a DHCP assignment will be able to forward local link 
> IP sourced 
> > addresses to the BRAS?
> 
> Once again...... as explained earlier on the int-area 
> list...... this appears to be reconfiguration of filters to 
> allow PANA in addition to DHCP.

And as explained earlier, your assessment makes no mention of this
assumption and which PANA mode it applies to.

> > > You must have a different definition for "OS impacting." By no 
> > > definition of "OS impacting" one would think that sending a 
> > > different lifetime value in a variable field would impact the 
> > > "operating system", or "protocol stack".
> > 
> I find it impossible to believe that you need a different 
> DHCP stack because now your DHCP client is getting a short lease. 

Where is your proof? Practice has shown something different. And again,
your assessment makes absolutely no mention of this assumption.

> As iterated many times on the int-area list, PANA can be 
> added as 3rd party software. It does not have to impact the OS.
> 
> > > > > red herring, as it all depends on what conditions are 
> attached 
> > > > > to
> > > > it,
> > > > problems you are seeing with the client being 
> configured with an 
> > > > IP address before it is authenticated, how does it work with
> > > DHCPv6 given
> > Woj> Somehow this has not what stopped you from making a judgment 
> > Woj> about
> > > > 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
> > > We are going with the official DSLF requirements. I don't see a 
> > > requirement like what you are saying. Rather than expressing your 
> > > own requirements and your own interpretations, please 
> seek DSLF to 
> > > amend and expand the current requirements. That'd be more 
> productive 
> > > for all of us.
> >

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 12 Dec 2007 10:46:19 +0100

> Sent: 11 December 2007 21:12
> To: Wojciech Dec (wdec)
> Cc: Yoshihiro Ohba; Mark Townsley (townsley); Jari Arkko; 
> [email-masked]
> > > I agree that some mechanism to carry circuit-id in PANA message 
> > > would be needed when DHCP is not used for obtaining a pre-PANA 
> > > address, in order to avoid any change to existing RADIUS 
> > > implementations.  We (PANA WG) can certainly work on a 
> mechanism to 
> > > carry a circuite-id in PANA-Client-Initiation
> which DHCP 
> > The issue is that an operator will deploy one mode of PANA or the 
> > other, not both. The assement should indicate which one is 
> assumed for 
> > the answers.
> 
> I think at this moment it is hard for PANA WG to 
> determine/suggest which use case should be used for DSL (more 
> requirements are expected to recommend one).  But we can 
> certainly include detailed assessment (like above) if that 
> helps DLSF to understand the assesment better.

This would be certainly helpful.

> As I expressed previously, I don't agree with this issue 
> since there is no written requirement on BRAS complexity.
> 
The thing is that the PANA usage models require not only more complex
BRAS mechanisms (at least), but also affect the SP's operations. The
assessment carries no mention of this.

> I don't really see an issue unless operators are clear about 
> what the exact issue on existing DHCP client with short lease.
> 

>From a vendor perspective, we tried it and we're not going there again
following customer feedback.

> > > configuraing IPv4 address before authentication won't.
> > > Can you please explain?
> > 
> > actually be deployed in broadband is a grey area for me. I 
> can count 
> > on one hand the # of operators I know who have done so, and amongst 
> > these there are differences.
> 
> Given that IPv6 needs to be considered according to 
> IPAuth-11, I don't see an issue on assigning an IP address 
> before authentication.  For the same reason, assigning an IP 
> address before authentication should not be an issue even for 
> DHCP authentication for IPv6.
> 
This is a bit of a conundrum composed of;
- Widely deployed IPv4 security mechanisms rely on DHCP assignement of
the address before any L2 communication is enabled. This eliminates the
local-link address PANA usage model and forces the pre-PANA address
pools (short leases and all)
- Short leases force the use of dedicated pools, and their management,
besides extra operational and device complexity (to say the least)

None of these facts seem to have been considered in the assessment.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 12 Dec 2007 10:57:15 +0000

> not be an issue even for DHCP authentication for IPv6.
Yoshi, you're right that it is unclear what the operational issues are
with respect to IPv6. This has not been addressed well by the DSL Forum,
internally or externally.

Authentication before IP assignment, route and filter installation for
IPv4 is well-understood in the DSL community, but it seems like it needs
to be better communicated to the IETF.

- Mark

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 12 Dec 2007 14:12:58 +0200

Wojciech,

As majority of the WG is OK with the assessment, we are going with that now.
Significant amount of your disagreements seem to stem from unstated
requirements, as multiple people already stated on the ML. If you are
convinced about those additional requirements, it is best if you get DSLF to
agree including them in the next revision of the requirement set. That'd be
the most productive approach. Until than, we'll go with what is stated in
the official DSLF liaison with respect to the requirements.

Anyway this is just the beginning of information exchange between IETF PANA
WG and DSLF. Further two-way communication between the two is welcome and
even expected.

Alper