Lionel,
The part you simply seem to fail to understand even though many people
in the DSLForum has pointed out repeatedly on the PANA proposal is:
- DSL currently AAA authenticates on the DHCP discover based on the
option 82 data. The EAP proposal is a small step from what deploys
worldwide.
- A new protocol that impacts every network node is not small deal,
this is one of the reasons allot of the DSL vendors are supporting the
EAP over DHCP approach.
As for this huge advantage of PANA in that it does not change the DHCP
State Machine. PANA does require modifications to the DHCP
implementations as your last proposal now DHCP is clearly triggered
and controlled by PANA. That effectively makes DHCP part of the PANA
state machine. So now a massive new protocol and changes to the DHCP
and every node on the broadband network is somehow lighter than a
pause in the DHCP state machine between DHCPDISCOVERY and DHCPOFFER to
run some EAP messages.
- Ric
On 03/08/2008, at 12:23 PM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> wrote:
Hi All,
Actually, in the DHCP-auth proposal, the DHCPEAP exchanges are
triggered by the DHCPDISCOVER/SOLLICIT message and achieved by a
DHCPOFFER/ADVERTISE sent back to the DHCP client in response to the
initial DHCPDISCOVER. Therefore, between the DHCPDISCOVER/SOLLICIT
and the DHCPOFFER/ADVERTISE, any EAPoIP transport protocol will
fulfil the DSL security requirement. And as PANA is already
specified for that, I'm not sure that a new solution is required, at
least in IETF.
As the DHCP server/Relay and the AAA client are colocated within the
BNG/BRAS, the same DHCPDISCOVER/SOLLICIT can trigger in the same way
a PANA/EAP authentication, as soon as the use of unspecified IP
addresses (IPv4) or link-local addresses (IPv6) are allowed for PANA
in the context of DSL network (as it is discussed in the PANA WG).
After the final PANA-Auth-Answer, a DHCPOFFER/ADVERTISE will be sent
to the DHCP client to complete the IP address allocation procedure.
If DHCP-Auth and PANA could be seen as quite similar solutions when
you are considering a basic successful authorization (i.e. impact on
the HGW and the BNG/BRAS, no impact on the DSLAM), I see several
advantages for PANA against DHCP.
The first one is that PANA will not introduce modification to the
DHCP client and the DHCP state machine. The other one is that
authentication related server-initiated procedures (re-
authentication/session termination) can be performed wihtout relying
on DHCP exhanges and impacting therefore the client's DHCP state
machine.
Of course, PANA would be a totally new protocol to support in DSL
networks. But I don't think that the impacts of this introduction
would be more important than the required evolution of the DHCP
protocol to be able to fulfil the same EAP functionalities. And
anyway, the IP session model and the whole EAP authentication
procedure are brand-new functionalities to introduce in the DSL
networks.
BR,
Lionel
-----Message d'origine-----
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Basavaraj Patil
Envoyé : mardi 29 juillet 2008 12:20
À : ext Richard Pruss; Alper Yegin
Cc : [EMAIL PROTECTED]; [email protected]
Objet : Re: [Int-area] [dhcwg] dhcp-auth, part 2
Hi Ric,
On 7/29/08 4:43 AM, "ext Richard Pruss" <[EMAIL PROTECTED]> wrote:
I made pretty much the same observation on Pana for DSL yesterday.
Nope. There is no modification to DHCP at all when PANA is
used. No
new DHCP options, messages, changes to the state machines, etc.
And you propose a whole new protocol that is not supported
on all the
network devices in question.
I hope you are not implying that with DHCP-auth there is no
implication or impact to hosts or network devices in
question. What you are proposing is essentially transforming
DHCP into an entirely new protocol. You are just riding on
the DHCP coattails and expect EAP to get a free ride... But I
don't believe it is that simple.
-Raj
- Ric
Alper
- Ric
Alper
Alper
-----Original Message-----
From: Alper Yegin [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 26, 2008 2:28 AM
To: 'Richard Pruss'
Cc: '[email protected]'; '[EMAIL PROTECTED]'
Subject: RE: [Int-area] dhcp-auth
I don't appreciate your comments. Let's stay on the technical
course.
Let's start just looking at the issues about Figure 3...
- What is the DHCP-wise functionality of the NAS?
Text claims it
is a "DHCP relay" but I see it terminating some of the DHCP
messages and also generating some other messages. This is not
compliant with DHCP.
As we explained to you many times most vendors BRAS's act as a
DHCP proxy and terminate all messages and look like a
server to
the client.
That's not accurate according to Figure 3. I see "some" DHCP
messages terminating on the NAS (e.g., DHCPEAP*) and "others"
going through (e.g.,
DHCPDISCOVER) within the same DHCP flow.
I don't think it is as simple as your two-sentence explanation
anyways. As requested earlier, IETF needs to see a
document where
this DHCP proxy model is defined. I'm aware of one DHCP proxy
model and it is nothing like what your document is suggesting.
Can you please send us a document that describes the DHCP proxy
model?
IETF needs to buy in the DHCP proxy model before any other
proposal built on top of that gets accepted.
- How does the NAS handle EAP retransmissions? It
needs to send
unsolicited DHCP messages to the DHCP client. This is not
compliant with DHCP.
Actually that issue is open and we can discuss what a
compliant
implementation would mean in terms of retransmission timers so
that right thing always happens at the right layer.
OK, please explain.
- I see NAS inserting additional DHCP option (EAP Success) on
DHCPOFFER as it forwards that message from DHCP
server to DHCP
client. This again breaks DHCP.
As we explained to you many times most vendors BRAS's act as a
DHCP proxy and terminate all messages and look like a
server to
the client.
Again, NAS does not really terminate "all" messages (see above).
And this
"box in the middle" inserting DHCP options towards the
DHCP client
breaks DHCP.
Lets take this to the dhcwg list as that is where the review
happens next week.
Really? What happened to the escalation of this
discussion to int-
area and the outcome of the poll from last IETF? I hope
Jari can
clarify this.
Alper
- Ric
Alper
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
dhcwg mailing list
[EMAIL PROTECTED]
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
