Re: [Int-area] [dhcwg] dhcp-auth, part 2

[Richard Pruss <ric at cisco.com>]

On 29/07/2008, at 11:19 AM, Basavaraj Patil wrote:

> Hi Ric,
>
>
> On 7/29/08 4:43 AM, "ext Richard Pruss" <ric at cisco.com> 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.

Actually it is.  We have DHCP implementations integrated to subscriber  
control and RADIUS and we have EAP.
The gap to implementation of this is by design very small.

- Ric

> -Raj
>
> > - Ric
> >
> >
> > > Alper
> > >
> > > > - Ric
> > > >
> > > >
> > > > > Alper
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Alper
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Alper Yegin [mailto:alper.yegin at yegin.org]
> > > > > > Sent: Saturday, July 26, 2008 2:28 AM
> > > > > > To: 'Richard Pruss'
> > > > > > Cc: 'int-area at ietf.org'; 'dhcwg at ietf.org'
> > > > > > 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
> > > > > > > > Int-area at ietf.org
> > > > > > > > https://www.ietf.org/mailman/listinfo/int-area
> >
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg at ietf.org
> > https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
Int-area mailing list
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area