RE: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication

["Alper Yegin" <alper.yegin at yegin.org>]

> > How is setting up a different filter on the devices that already know
> how to
> > setup filters considered a "considerable re-work"? I'd appreciate if you
> can
> > tell us how this is anything more than simply setting up a filter rule.
> >
> The devices currently install these filters based on DHCP snooping.  In
> our proposal current architecture use of the DHCP ack will still trigger
> drive the source address verification on the first network hop, exactly
> as they do today.
> 
> With PANA, these devices which are the whole of the transmission edge
> would all need to get a new PANA snooping enabled code base, with all
> the filtering use cases around that.  


If we run PANA with link-local IP address, then we can still utilize DHCP
snooping as usual. 

> New ideas like authenticated and
> unauthenticated IP addresses and policy for those need to be hooked to
> new filters that operate on IP streams. 

Not sure how difficult that is, but note that you need that even for your
DHCP solution when running DHCPv6 -- the link-local address is already
configured on the CPE before executing DHCP.


> A snooping version of PANA or

What does "a snooping version of PANA" mean?

> some sort of PANA grafting to a policy distribution mechanisms.

Not sure I understand this either. Could you please explain?


> That more new stuff than I care to count can charitably called
> "considerable re-work", more it should be pretty obvious from this is
> not the application for PANA.  


Have you read RFC 4058? 

   DSL networks are a specific example where PANA has the potential for
   addressing some of the deployment scenarios.  Some DSL deployments do
   not use PPP [RFC1661] as the access link-layer (IP is carried over
   ATM and the subscriber device is either statically or DHCP-
   configured).  The operators of these networks are left either using
   an application-layer web-based login (captive portal) scheme for
   subscriber authentication, or providing a best-effort service only as
   they cannot perform subscriber authentication required for the
   differentiated services.  The captive portal scheme is a non-standard
   solution that has various limitations and security flaws.


PPP-less DSL networks have been one of the deployment scenarios we had
identified from the very beginning. So it is not an afterthought.

> This application is deeply entwined with
> layer 2, PANA is clearly aimed at IP authentication and is not a layer 2
> or in the DHCP Auth case layer 2.5 application.
> 
> I wonder why you keep driving this square peg into a round hole.  The
> first entry of the PANA FAQ is that PANA is layer 2 agnostic and you
> seem determined to undo that.
> http://www.toshiba.com/tari/pana/pana-faq.txt

There is no need to confuse things. PANA is not dependent on a specific L2
because it carries EAP above IP. How is that a mismatch with the problem
DSLF is facing? 


Alper




_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg