- 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
