Re: [Int-area] [dhcwg] dhcp-auth, part 2
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Int-area] [dhcwg] dhcp-auth, part 2
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.
-Raj
>
> - Ric
>
>
>> Alper
>>
>>>
>>> - Ric
>>>
>>>
>>>> Alper
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Alper
>>>>
>>From int-area-bounces at ietf.org Sat Aug 2 10:12:24 2008
Return-Path: <int-area-bounces at ietf.org>
X-Original-To: int-area-archive at megatron.ietf.org
Delivered-To: ietfarch-int-area-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 328323A69D6;
Sat, 2 Aug 2008 10:12:24 -0700 (PDT)
X-Original-To: int-area at core3.amsl.com
Delivered-To: int-area at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 5601E28C117;
Tue, 29 Jul 2008 03:19:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 8D4Wv+JQf3i3; Tue, 29 Jul 2008 03:19:57 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134])
by core3.amsl.com (Postfix) with ESMTP id 3F6203A69B8;
Tue, 29 Jul 2008 03:19:57 -0700 (PDT)
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id
m6TAJBNR014679; Tue, 29 Jul 2008 05:20:06 -0500
Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by
esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);
Tue, 29 Jul 2008 13:19:50 +0300
Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by
daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);
Tue, 29 Jul 2008 05:19:48 -0500
Received: from 10.241.59.97 ([10.241.59.97]) by daebe101.NOE.Nokia.com
([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ;
Tue, 29 Jul 2008 10:19:47 +0000
User-Agent: Microsoft-Entourage/12.11.0.080522
Date: Tue, 29 Jul 2008 05:19:48 -0500
From: Basavaraj Patil <basavaraj.patil at nokia.com>
To: ext Richard Pruss <ric at cisco.com>, Alper Yegin <alper.yegin at yegin.org>
Message-ID: <C4B458F4.15E2D%basavaraj.patil at nokia.com>
Thread-Topic: [dhcwg] [Int-area] dhcp-auth, part 2
Thread-Index: AcjxZKD8Kl8E7STsvk+16Nxa3QZJ9Q==
In-Reply-To: <B760037E-D09B-4C36-B2FC-13E85D59BFBF at cisco.com>
Mime-version: 1.0
X-OriginalArrivalTime: 29 Jul 2008 10:19:48.0052 (UTC)
FILETIME=[A104A940:01C8F164]
X-Nokia-AV: Clean
X-Mailman-Approved-At: Sat, 02 Aug 2008 10:12:23 -0700
Cc: dhcwg at ietf.org, int-area at ietf.org
Subject: Re: [Int-area] [dhcwg] dhcp-auth, part 2
X-BeenThere: int-area at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>,
<mailto:int-area-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area at ietf.org>
List-Help: <mailto:int-area-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>,
<mailto:int-area-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: int-area-bounces at ietf.org
Errors-To: int-area-bounces at ietf.org
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.
-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
-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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
