Subject: [Int-area] EAP and DHCP end-points

From: "Alper Yegin" <[email-masked]>
Date: Wed, 5 Dec 2007 08:59:29 +0200

Today Sam asked a question about the EAP end-points with respect to
dhcp-auth proposal.

The answers we got were either not clear or not accurate.

It is not true that EAP authenticator is always on the DHCP server. In
Figure 5 of their I-D, EAP authenticator and DHCP relay are co-located in
NAS:

        (HGW)                (NAS)                (AAA)           (DHCP)
     DHCP Client           AAA Client        RADIUS Server   DHCP Server
                          AAA Client

    DHCPDISCOVER ------->
    (w/DHCP-auth-proto EAP)

                 <------- DHCPEAP
                          (w/EAP Message)

    DHCPEAP ------->
    (w/EAP Message)

                          RADIUS Access-Request ------->
                          (w/EAP Message)

                                                <-------- RADIUS
                                    Access-Accept (w/EAP Message)
                                   (Access-Reject (w/EAP Message)
                                                 if unsuccessful)

               (DHCP messages continue normally from
               this point forward if successful)
                          DHCPDISCOVER ------------------------------>
                          (w/RADIUS attributes suboption)

                               <----------------------------- DHCPOFFER

                 <------- DHCPOFFER (w/EAP Success Message)
                          (w/yiaddr)

    DHCPREQUEST  ------->

                 <------- DHCPACK

         Figure 5: Message Flow with new message and a DHCP relay

As for EAP peer and DHCP client, we never got a clear acknowledgement that
it may be on a device sitting behind the CPE (HGW) at home, like a PC. It
has to be so because:
- There are clear DSLF requirements for that [e.g., IPAuth-9 Should be
simple to implement on client (PC or CPE)],
- Replacing PPPoE means doing that on the home PCs as well, and
- The I-D clearly states "The DHCP Client resides either on a home network
device or the HGW,..."

Alper

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Richard Pruss <[email-masked]>
Date: Wed, 05 Dec 2007 10:10:17 -0800

The answer you got was accurate but possibly not clear.

The BRAS (NAS on the diagram) is a DHCP server to the client.

We call a device acting like a DHCP server to the HGW and client to the 
central DHCP Server a proxy and so does Juniper.

In retrospect I made the mistake of calling it a relay in the document 
because I was trying to support Richard Johnsons draft
which documents the existence of these implementations and tries to move 
them towards being relays by documenting how to
override the server-id attribute.

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-dhc-server-override-05.txt

- Ric

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 5 Dec 2007 13:53:50 -0500

Section 5.5 of DSL TR-101 says:

R-181 The Broadband Network Gateway MUST be able to function as a DHCP
Relay Agent as described in RFC 951 "BOOTP", RFC 2131 "DHCP" and RFC
3046 "DHCP Relay Agent Information Option" on selected untrusted
interfaces.

R-182 The Broadband Network Gateway MUST be able to function as a DHCP
relay agent on selected trusted interfaces, when an access node acts
as a Layer 2 DHCP relay agent as specified in Appendix B -- Layer 2
DHCP Relay Agent.

Given that BNG is equivalent to NAS and your answer is accurate, how
does your answer satisfy the TR-101 requirements?

Yoshihiro Ohba

---

From: "Peter Arberg" <[email-masked]>
Date: Wed, 5 Dec 2007 11:20:46 -0800

We can start a long theoretical discussion on pros and cons
of relay versus dhcp proxy in the NAS, but that has nothing
to do with TR-101, and it has nothing to do with the draft,
no one said that if the NAS is working as a dhcp proxy it 
is incapable of working as a dhcp relay if setup to do so.

I think it is true for all features functionalities that a 
device will perform what it is configured to do, if you
configure it to do dhcp proxy, then it is because there are
clear advantages for you to do so in a specific setup, if you
configure it to act as a normal dhcp relay then it will do 
so, and you loose the added functionality and benefits of the
dhcp proxy.

The dhcp proxy functionality which is used in many NAS devices
will make the NAS look like a dhcp server to the client and
make it look like a dhcp relay to the actual dhcp server.

I really think we are getting of track with the discussion, it
seem much more about about finding mistakes in statement, 
comments instead of keeping the eye on the ball and discuss
if there are some advantage to include an authentication 
functionality to the dhcp process.

So as stated earlier I think one of the advantages the draft is
providing is to allow authentication before address assignment.

As I understand it with pana we have to have address assignment
before the authentication, and as such if the end-device is 
getting ip-address from dhcp, the end-device will have to get
a ip-address from dhcp, then do authentication, and possible
be rejected or possible have the dhcp process boot-strapped
to pana, so when the authentication is successful the dhcp 
process can request a new public address.

I do not think anyone is argueing that the pana solution is not
workable, what is said is it will require more time and more
resources on the NAS to handle several dhcp address allocations 
per end-device.

Knowing how carriers in broadband networks constantly are trying 
to get as many subscriber authentications in as little time as
possible, I think options that will streamline the authentication
process have to be looked at.

Peter

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: 5. december 2007 10:54
> To: Richard Pruss
> Cc: [email-masked]; 'Sam Hartman'
> Subject: Re: [Int-area] EAP and DHCP end-points
> 
> > >        (HGW)                (NAS)                (AAA)    
>        (DHCP)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Dec 2007 11:41:05 -0800

> The BRAS (NAS on the diagram) is a DHCP server to the client.

So if it's a DHCP server, aren't you going to have to hack it to  
support the new DHCP EAP messages and the supporting queries?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 05 Dec 2007 15:51:47 -0500

>>>>> "Peter" == Peter Arberg <[email-masked]> writes:

    Peter> We can start a long theoretical discussion on pros and cons
    Peter> of relay versus dhcp proxy in the NAS, but that has nothing
    Peter> to do with TR-101, and it has nothing to do with the draft,
    Peter> no one said that if the NAS is working as a dhcp proxy it
    Peter> is incapable of working as a dhcp relay if setup to do so.

Peter, the problem I have is that when we are talking about security
protocols, understanding the endpoints and cryptographically verifying
the endpoints becomes critical.

So, I suspect that we will have to do away with a certain sloppiness
that has been common here.

---

From: Richard Pruss <[email-masked]>
Date: Wed, 05 Dec 2007 13:30:14 -0800

Ted Lemon wrote, around 5/12/07 11:41 AM:
> So if it's a DHCP server, aren't you going to have to hack it to support 
> the new DHCP EAP messages and the supporting queries?
> 
Yep and in terms of the major implimentors in DSL, Cisco, Redback and 
Hauwei and Juniper have spoke up here and said they are supportive of 
implement this function in the BRAS.

Alcatel-Lucent, Nokia-Siemens and Thomoson Telecom (and the service 
providers France Telecom,Telecom Italia and Portugal Telecom) have 
posted a document in the DSLForum that extends the current requirement 
list and shows how the new requirements can be met with DHCP 
Authentication. This certainly indicates they are probably be thinking 
of implementing this function in the BRAS.

- Ric

---

From: "Peter Arberg" <[email-masked]>
Date: Wed, 5 Dec 2007 13:33:40 -0800

Hi Sam,

I understand it is important to know, and agree it could have been
made more clear.

But I expect as long as the end-points are consistent then from
the security point of view it do not matter if it is:

1)   HGW  -------   NAS                  
NAS is the DHCP server
NAS is the authentication end-point

2)   HGW  -------  NAS  (------ DHCP Server)
NAS acting as DHCP Proxy, looks like server to the HGW
NAS is the authentication end-point

2)   HGW  -------(NAS)----- DHCP Server
NAS is acting as DHCP Relay
DHCP Server is the authentication end-point

cheers,
Peter

> From: Sam Hartman [mailto:[email-masked]] 
> Sent: 5. december 2007 12:52
> To: [email-masked]
> Cc: 'Yoshihiro Ohba'; 'Richard Pruss'; [email-masked]

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 6 Dec 2007 00:36:40 +0200

Hi Peter,

> process can request a new public address.

No.

It's true that the client has to configure "a" IP address before running
PANA. That can be a (IPv4 or IPv6) link-local address, or a short-lease DHCP
address. 

	[Btw, DHCP-proponents claimed the client using an IP address prior
to 
	authentication is such a big problem, yet they did not answer how
it'd 
	work with DHCPv6 where the client is already autoconfigured with
IPv6 
	link-local address]

And once the access authentication is successful, now the "session IP
address" can be assigned via DHCP.

> resources on the NAS to handle several dhcp address allocations

We debated that and it is not clear why that should be the case. First of
all, the IP address used with PANA does not have to be assigned by DHCP.

> process have to be looked at.

I don't see a show stopper in PANA towards that goal.

Alper

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Thu, 6 Dec 2007 00:01:07 +0100

> Yep and in terms of the major implimentors in DSL, Cisco, 
> Redback and Hauwei and Juniper have spoke up here and said 
> they are supportive of implement this function in the BRAS.
> 
> Alcatel-Lucent, Nokia-Siemens and Thomoson Telecom (and the 
> service providers France Telecom,Telecom Italia and Portugal 
> Telecom) have posted a document in the DSLForum that extends 
> the current requirement list and shows how the new 
> requirements can be met with DHCP Authentication. This 
> certainly indicates they are probably be thinking of 
> implementing this function in the BRAS.
> 

I think that the aim of this contribution is quite different from your
understanding, at least from France Telecom point of view.
The aim was to list the requirements that a DHCP-based solution should
fulfill, this solution being for now the only working assumption in the
DSL Forum.

In the conclusion, I think there was something like: "This contribution
presents requirements on the usage of the EAP over DHCP authentication
method in the context of IP sessions, should the EAP over DHCP method be
selected"

I'm pretty sure that France Telecom will be able to express their own
conclusion/standpoint. Therefore, please do not speak on behalf France
Telecom the next time. Even if it is just to express your "feelings".

Lionel

---

From: Julien Laganier <[email-masked]>
Date: Thu, 6 Dec 2007 00:42:54 +0100

On Wednesday 05 December 2007, Richard Pruss wrote:
>  This certainly indicates they are probably be thinking

This *certainly* indicates that we *probably* know nothing about what 
they're thinking.

---

From: Julien Laganier <[email-masked]>
Date: Thu, 6 Dec 2007 00:42:54 +0100

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 5 Dec 2007 15:54:05 -0800

During the meeting yesterday, I made reference to a new draft
titled: "DHCP Fragmentation and Reassembly":

http://www.ietf.org/internet-drafts/draft-templin-dhcpmtu-00.txt

The intention is that this would apply to any case in which
the DHCP client and server need to exchange long messages
but IP fragmentation and reassembly might be problematic.

The domain of applicability for this would be for any DHCP
usage and not just the DHCP-AUTH stuff. But, I would also
like to use it as a template for future documents that add
similar support for other UDP applications. Any comments
on it would be welcome.

Thanks - Fred
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Dec 2007 16:05:05 -0800

> implement this function in the BRAS.

Is it harder or easier to add this functionality than to support PANA?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Dec 2007 16:12:42 -0800

> similar support for other UDP applications. Any comments

The fact that you say it this way actually illustrates the main  
problem with it.   There's already a way to do fragmentation of UDP  
packets.   It's done at the IP layer, so there's no need to do it on a  
per-UDP-protocol basis.

A relay agent that doesn't handle a full 1500-byte DHCP packet is  
broken - DHCP has been specified to allow this for a really long time  
now.   My comment in the WG is simply that nobody really ever uses  
this, so we can't be sure that it works on every device.   But it  
should.   So I would much rather get it working than come up with a  
workaround.

E.g. you could come up with a hack to TCP to make it work for routers  
that can't handle packets larger than 576 bytes, despite the fact that  
the physical layers between which they are routing support 1500-byte  
packets.   But you wouldn't do that.  You'd send back the router, and  
demand a refund.

---

From: Joe Touch <[email-masked]>
Date: Wed, 05 Dec 2007 16:50:10 -0800

Ted Lemon wrote:
> The fact that you say it this way actually illustrates the main problem
> with it.   There's already a way to do fragmentation of UDP packets.  
> It's done at the IP layer, so there's no need to do it on a
> per-UDP-protocol basis.
> 
> A relay agent that doesn't handle a full 1500-byte DHCP packet is broken

Agreed. Relay agents for an app that speaks UDP should handle whatever
size packet the app can send. In this case, if DHCP can send 1500-byte
packets, the relay should be able to forward them.

Joe

---

From: "Peter Arberg" <[email-masked]>
Date: Wed, 5 Dec 2007 16:52:57 -0800

I think any NAS vendor will be supportive of implementing the
DSLF choosen authentication methoed for IP Sessions, if
it is DHCP Auth or PANA or something else :)

My guess is the DHCP Auth with CHAP Auth is the easiest to
implement in a NAS, but the security you get is also the
weakest... 

Peter

> From: Ted Lemon [mailto:[email-masked]] 
> Sent: 5. december 2007 16:05
> To: [email-masked]
> Cc: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 5 Dec 2007 16:59:24 -0800

Ted, 

> Sent: Wednesday, December 05, 2007 4:13 PM
> To: Templin, Fred L
> Cc: [email-masked]
> packets.   It's done at the IP layer, so there's no need to 
> do it on a  per-UDP-protocol basis.

IP fragmentation and reassembly doesn't work very well when
there is no IP source address, which is the case the DHCP-AUTH
stuff was looking at. It also doesn't work very well for UDP
applications that sit behind IPv4 NATs and/or firewalls;
especially when those devices fail to pass non-initial IPv4
fragments. There are also wrapping problems with the 16-bit
ip_id, which are documented in RFC4963.

But all that said, I'm not saying go out and change all UDP
applications everywhere - only those for which IP fragmentation
may be problematic.

> should.   So I would much rather get it working than come up with a  

Hmm; several folks told me that relay agents only need to
support 576? In any event, I'm all for paths that support
the larger packet sizes w/o fragmentation - greatly in
favor of it, in fact. But when the path doesn't support the
packet size, and the application can't reduce the size of the
packet, then it has to do what needs to be done to get the
packet through.

> demand a refund.

Nodes are supposed to accept at least as large as the size of
their attached links, so you are indeed describing a case of
broken router. But, when there are links with small MTUs on
the path, TCP has a way of reducing the size of the segments
it sends when it correctly implements RFC1191.

Fred

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Dec 2007 17:12:25 -0800

> it is DHCP Auth or PANA or something else :)

The reason I asked the question is that if it's pretty much all the  
same to the vendors, and it would solve the problem, then it would be  
expedient to go with the PANA solution.   The reason it would be  
expedient is that support for the DHCP option in the Internet Area  
meeting was weak, and I suspect that of all the people who raised  
their hands supporting it (e.g., me), a significant percentage would  
have raised their hands in support of PANA as well.   So you could get  
a strong consensus really easily.

When I asked about this yesterday, Richard said that the reason for  
choosing DHCP over PANA is that fewer elements in the network have to  
change, but my superficial understanding of PANA suggests to me that  
this is not actually the case.   It seems to me that PANA can traverse  
essentially the same path that DHCP relay packets traverse, given that  
you're going to have to make a change on the BRAS anyway.

As I say, I'm not an expert in PANA, so I may have missed something,  
but this is my naive understanding of the situation.   And again, as I  
say, I'm not a strong proponent of PANA - I'm just suggesting that we  
do what is expedient, and will work, rather than fighting a pitched  
battle for an alternative that in the final analysis probably isn't a  
better choice, and fundamentally does pretty much the same thing.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Dec 2007 17:19:56 -0800

On Dec 5, 2007, at 4:59 PM, Templin, Fred L wrote:
> stuff was looking at.

True.

> It also doesn't work very well for UDP
> fragments.

The idea of relaying DHCP through NAT makes my teeth itch.

> support 576?

It depends on what you mean by "need to."   If they are BOOTP relay  
agents that only know about RFC951, then you could indeed make this  
argument.   But at this late date, anything that's in a device that  
does DHCP relay is really a DHCP relay agent, not a BOOTP relay  
agent.   And the DHCP protocol explicitly allows packets larger than  
576 bytes.

Admittedly it does not require them, but in practice any relay agent  
that doesn't support them is breaking DHCP functionality that's  
specified in the protocol.   So while technically you could say that  
it's not noncompliant, since there is a significant piece of the DHCP  
protocol that doesn't work with that device, it's pretty clearly broken.

> But when the path doesn't support the

E.g., get a firmware update for the broken device!   :')

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 5 Dec 2007 17:34:03 -0800

Ted, 

> Sent: Wednesday, December 05, 2007 5:20 PM
> To: [email-masked]

> E.g., get a firmware update for the broken device!   :')

ACK on all of the above, except that there really are
UDP applications that can't reduce the size of the packets
they send and can't rely on IP fragmentation because of
behind-NAT placement. (Well, OK, I know of one such
application but there are probably others...)

Fred

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 5 Dec 2007 21:50:05 -0500

> From: Ted Lemon, December 05, 2007 8:12 PM
> 
> > I think any NAS vendor will be supportive of implementing the DSLF 
> > choosen authentication methoed for IP Sessions, if it is 
> DHCP Auth or 
> > PANA or something else :)
> 
> The reason I asked the question is that if it's pretty much 
> all the same to the vendors, and it would solve the problem, 
> then it would be  
> expedient is that support for the DHCP option in the Internet 
> Area meeting was weak, and I suspect that of all the people 
> who raised their hands supporting it (e.g., me), a 
> significant percentage would  

PANA might be good for some things, but based on my interpretation, it
is very inefficient for the DSLF requirements.  E.g., see:
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg07834.html
These extra messages lead to additional error states which will be a
pain for the uneducated subscriber to debug.  Without DHCP Auth, don't
be surprised to see IEEE 802.1af eventually grow to fill the Broadband
Authentication space. 

Disclaimer: If someone can provide an integrated PANA+DHCP flow which
explicitly matches the DSLF requirements, and which doesn't need all the
extra messages, then I reserve my right to change my opinion!  But sadly
such a flow has yet to appear in our months of discussion on this topic.

Eric
 
> When I asked about this yesterday, Richard said that the 
> reason for choosing DHCP over PANA is that fewer elements in 
> the network have to change, but my superficial understanding 
> of PANA suggests to me that  
> essentially the same path that DHCP relay packets traverse, 
> given that you're going to have to make a change on the BRAS anyway.
> 
> say, I'm not a strong proponent of PANA - I'm just suggesting 
> that we do what is expedient, and will work, rather than 
> fighting a pitched battle for an alternative that in the 
> final analysis probably isn't a better choice, and 
> fundamentally does pretty much the same thing.
> 
> 
> 
>

---

From: Richard Pruss <[email-masked]>
Date: Wed, 05 Dec 2007 19:00:19 -0800

> better choice, and fundamentally does pretty much the same thing.
The DHCP Authentication solution assumes that port marking (in DHCP 
Option 82) and then the layer 2 network is secure by current features in 
the DSLAM that are provisioned by DHCP snooping.  Thus the DHCP 
Authentication, while only being implemented on the Layer 3 edge and the 
CPE, does secure the large layer 2 network in front of the layer 3 
edge.  Basically you cannot send a packet into the layer 2 network until 
the DHCP ack is received (DHCP packets are obviously the only exception 
to this).

Often my frustration in this dialog has been that people do not seem to 
understand how big an issue this layer 2 secured edge is.  A couple of 
points to that:
- Firstly these metro and dsl aggregation networks can be large, 200K 
subscribers sites connected common.
- Services like large content sources are deployed in the layer 2 networks.
- Multiservice and layer 2 content distribution are the main real 
technical drivers to move from PPPoE.

PANA would require something to get identity from the layer 2 switch 
directly connected to the subscriber site and then something else to 
enforce policy in the layer 2 provider edge. This is a very different 
implementation task but also means that the service edge which touches 
millions of homes would need to implement and upgrade to whatever 
spaghetti sauce control plain PANA propose to control the layer 2 
switches at this edge.  These are not big BRAS's with lots of memory and 
CPU, these are small edge devices, built to be as cheap as possible, 
providers are very, very reluctant to replace them with things that 
could run a big control plain.

Personally I think the most likely result of specifying something that 
needs an equipment upgrade to the layer 2 edge for SP's to deploy a 
service without a cost advantage will probably be that we will see 
deployment of proprietary authentication that do not inflict this cost 
and operation hardship on the SP's.

- Ric

---

From: Joe Touch <[email-masked]>
Date: Wed, 05 Dec 2007 19:11:34 -0800

Templin, Fred L wrote:
...
>> On Dec 5, 2007, at 3:54 PM, Templin, Fred L wrote:
...
> there is no IP source address, which is the case the DHCP-AUTH

All IP packets have a source address; there is no reason why any given
address would fail on frag/reassy (including 0's or 1's).

> especially when those devices fail to pass non-initial IPv4

At that point you're seeking to traverse a non-Internet device; all bets
are off, and there's frankly no point in trying to provide DHCP to the
device behind it.

> There are also wrapping problems with the 16-bit

The problem lies in the host or tunnel endpoint that wraps those IDs, in
violation of RFC791. The RFC4963 is incorrect in suggesting that the
error lies anywhere else; thankfully, it's only (mis)informational in
that regard.

If the IP ID wrap is really going to be deprecated, let's do so. If not,
can we please stop calling wrap of the ID anything other than a
violation of a standard?

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 5 Dec 2007 19:31:20 -0800

Joe - just a couple of clarifications, and an attempt to
wrap this thread up:

> From: Joe Touch [mailto:[email-masked]] 
> Sent: Wednesday, December 05, 2007 7:12 PM
> To: Templin, Fred L
> Cc: Ted Lemon; [email-masked]

> address would fail on frag/reassy (including 0's or 1's).

The situation that originally started this discussion was the
case for a DHCP exchange in which large packets must be sent
before the client actually gets an IPv4 address. Then, if
you have multiple such clients all using the same (all-0's)
source address and their fragmented datagrams end up in the
server's reassembly buffer at the same time, you can have
reassembly misassociations.
 
> are off, and there's frankly no point in trying to provide DHCP to the

The NAT comment was not meant to include DHCP; it was meant
to be specific to "other" UDP applications.

> can we please stop calling wrap of the ID anything other than a

I have no comment on this for the moment.

But, to bring some closure to the issue at hand, can we
agree that there is *no* fragmentation issue for the DHCP-AUTH
proposal and no extra mechanism (such as draft-templin) needed?

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Wed, 05 Dec 2007 22:40:32 -0800

Hi, Fred,

> reassembly misassociations.

Understood. The fundamental problem here is sourcing packets with
addresses the host doesn't own. While I appreciate this was an easy way
to solve the problem, it violates 791, which means almost all bets on
the rest of how IP works (or doesn't) are off.

It's also legal for hosts to drop duplicate IP packets, which means that
if you happen to try to send a packet with the same ID as someone else,
it might not get through even if it wasn't fragmented.

IMO, the best solution is to assume collision with backoff, i.e., try to
send a packet with a random ID, and if you get no response, try again. A
small number of tries ought to be reasonably successful, statistically,
even if some individual tries get corrupted.

That would allow you to still use fragmentation, FWIW.

> to be specific to "other" UDP applications.

Well, NATs that don't pass fragmented packets are going to cause
problems with those apps anyway.

> proposal and no extra mechanism (such as draft-templin) needed?

I agree there is no extra mechanism. IMO, it's OK to use large IP
packets and allow IP fragmentation. The solution, IMO, is to have the
app treat the message as "lossy" - perhaps moreso than usual, i.e. - and
retry with other IDs if one fails.

I don't see a need for fragmenting at the app layer to address this issue.

Joe

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 6 Dec 2007 12:42:28 +0200

Eric, Ric,

Answering you at once... as your messages have the same symptom: Repeating
the same problem claims and ignoring the answers already provided..... This
is not the way to take this community to the right technical answers.
 
> http://www1.ietf.org/mail-archive/web/dhcwg/current/msg07834.html

Already answered:
http://www1.ietf.org/mail-archive/web/dhcwg/current/msg07780.html but didn't
hear from you.

> be surprised to see IEEE 802.1af eventually grow to fill the Broadband

Anyone should be less concerned about 1X doing its job than 
DH-Configuration-P growing into DH-Configuration-and-Authentication-P.

> such a flow has yet to appear in our months of discussion on this topic.

As soon as we free some time from fighting off political maneuvers, we'll
get back to that.

> enforce policy in the layer 2 provider edge. 

Until you explain this more, it is hard to respond to it.

> This is a very different

There is none of that going on. If DSLF wants to stick to using Option 82,
it can do so with the DHCP messaging that follows successful PANA
authentication. I had explained this before.

> and operation hardship on the SP's.

I don't see where the equipment upgrade necessity came from. Use of PANA
boiled down to edge allowing PANA passthrough (similar to how it allows
DHCP). We had discussed this as well... All repeat points with no follow ups
on your part are being brought up again....

Alper

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 6 Dec 2007 08:34:12 -0500

Alper,

>From my point of view, it is simple:

Show me a PANA+DHCP call flow that meets DSLF requirements.  If it has
an equivalent number of messages and error states, I will support it.  I
will even help implement it.

Until then, I will believe my analysis earlier in these threads is
accurate.

Eric

> From: Alper Yegin, December 06, 2007 5:42 AM
> 
> Eric, Ric,
> 
> Answering you at once... as your messages have the same 
> symptom: Repeating the same problem claims and ignoring the 
> answers already provided..... This is not the way to take 
> this community to the right technical answers.
>  
> http://www1.ietf.org/mail-archive/web/dhcwg/current/msg07780.h
> tml but didn't hear from you.
> 
> 
> > explicitly matches the DSLF requirements, and which doesn't 
> need all 
> > the extra messages, then I reserve my right to change my 
> opinion!  But 
> > sadly such a flow has yet to appear in our months of 
> discussion on this topic.
> 
> As soon as we free some time from fighting off political 
> maneuvers, we'll get back to that.
> 
> > switches at this edge. These are not big BRAS's with lots of memory 
> > and CPU, these are small edge devices, built to be as cheap as 
> > possible, providers are very, very reluctant to replace them with 
> > things that could run a big control plain.
> 
> There is none of that going on. If DSLF wants to stick to 
> using Option 82, it can do so with the DHCP messaging that 
> follows successful PANA authentication. I had explained this before.
> 
> I don't see where the equipment upgrade necessity came from. 
> Use of PANA boiled down to edge allowing PANA passthrough 
> (similar to how it allows DHCP). We had discussed this as 
> well... All repeat points with no follow ups on your part are 
> being brought up again....
> 
> Alper
>

---

From: "FREDRICX Francois" <[email-masked]>
Date: Thu, 6 Dec 2007 19:10:17 +0100

Dear All,

Just to confirm Lionel's comment. As editor of this contribution I can
say that the intent of the co-authors is to identify some requirements
on the EAPoDHCP method, SHOULD this method be selected as the
appropriate one for our needs. We think this can be interesting
information at this point in time, as this method is currently being
proposed to the ietf and is not cast in stone yet.

It just shows that the co-authors find that this method is worth
investigating, it is NOT a statement by any co-signer that it will
include it into products or will deploy it into its network.
As this contribution still has to be presented to and discussed within
the DSLF (next week) I cannot say more about it right now on this forum,
but our proposal will be to first agree upon such requirements within
the DSLF and then to forward this information to the ietf.
 
Best regards,
Francois Fredricx.

-----Original Message-----
From: MORAND Lionel RD-CORE-ISS
[mailto:[email-masked]] 
Sent: donderdag 6 december 2007 0:01
To: [email-masked]; Ted Lemon
Cc: Sam Hartman; [email-masked]
Subject: RE: [Int-area] EAP and DHCP end-points

> providers France Telecom,Telecom Italia and Portugal
> Telecom) have posted a document in the DSLForum that extends the 
> current requirement list and shows how the new requirements can be met

> with DHCP Authentication. This certainly indicates they are probably 
> be thinking of implementing this function in the BRAS.
> 

Lionel

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 6 Dec 2007 18:00:25 -0500

Eric,

As Alper mentioned, your previous assessment on PANA+DHCP call flow is
for the worst case.

Here is my assessment.  I am showing IPv4-only cases to focus on
"number of messages" discussion, but I can also show IPv6-only and
dual-stack cases if people would like to see how PANA works with IPv6.

Abbreviation
------------

RT: Round-Trip
PRPA: Pre-PANA Address
POPA: Post-PANA Address (=Service IP address)

Assumption
----------

- A 1RT EAP method is used
- Piggybacking EAP is turned off in PANA
- AAA RTs are not shown

Use Cases
---------

Use Case 1: Link Local PRPA (4.5RT)

  PaC-initiated PANA (2.5RT) 
  DHCP for POPA (2RT) 

  Note: Use Case 1 requires multicast PAA discovery mechanism
  which needs to be defined.

Use Case 2: DHCP-provided PRPA, PRPA==POPA (5RT)

  DHCP for PRPA with short lease (2RT) 
  PAA-initiated PANA (2RT)
  DHCP for extending lease (1RT)

Use Case 3: DHCP-provided PRPA, PRPA!=POPA (6RT)

  DHCP for PRPA (2RT) 
  PAA-initiated PANA (2RT) 
  DHCP for POPA (2RT)

Regards,
Yoshihiro Ohba

---

From: "Soininen Jonne (NSN-FI/Espoo)" <[email-masked]>
Date: Sun, 9 Dec 2007 19:22:02 +0200

Hello everybody,

I would have to go with Lionel here. I guess Richard has a bit  
misunderstood the contribution to DSLF.

I would appreciate if you, Richard, would actually ask Nokia Siemens  
Networks before telling to the world what we think. In addition, the  
is the IETF - it doesn't matter what Nokia Siemens Networks or FT or  
Cisco think. We should discuss the technical merits and not company  
positions on these lists.

I hope this helps.

Cheers,

Jonne.