<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Or even easier... just have the corner-case VLAN itself, and have<br>
the AUTH webpage reachable inside that VLAN. So no reassociation<br>
required... Just say, "please visit: <a class="moz-txt-link-freetext" href="http://auth.ietf78-meeting.org">http://auth.ietf78-meeting.org</a>"
to authenticate.<br>
...<br>
<br>
John<br>
<br>
On 6/27/2010 9:13 PM, John Kemp wrote:
<blockquote cite="mid:4C282150.3060201@network-services.uoregon.edu"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<br>
If we're talking wi-fi only, then I think one easy way to do it is part
of the <br>
OS on the Cisco AP's. I believe you can assign a VLAN that is
nothing-but-an-IP-redirect.<br>
<br>
So we could just call that the "corner-case-users-AUTH-vlan", they
visit webpage<br>
and type credentials. Then we say: "good auth". We push their MAC
into an ACL list<br>
on the "corner-case" VLAN and tell them, now associate with the
"corner-case" VLAN.<br>
<br>
That's just one idea... :(<br>
<br>
John Kemp (<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:kemp@network-services.uoregon.edu">kemp@network-services.uoregon.edu</a>)<br>
<br>
<br>
On 6/27/2010 9:05 PM, Jim Martin wrote:
<blockquote
cite="mid:657480DE-BDF9-480B-A673-F73514BD169E@daedelus.com"
type="cite">
<pre wrap="">On Jun 27, 2010, at 8:57 PM, Joel Jaeggli wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ok, you're stupid...
</pre>
</blockquote>
<pre wrap=""> Thanks....
</pre>
<blockquote type="cite">
<pre wrap="">Item one is exactly what it does. Think nomadix.
</pre>
</blockquote>
<pre wrap=""> Ok, that's just fine from a user experience perspective.
</pre>
<blockquote type="cite">
<pre wrap="">The mechanism is normally a pc with two interfaces bridged although layer-3 ports are also feasible.
</pre>
</blockquote>
<pre wrap=""> Ah, here's the point where I'm unclear. A few questions:
- Are the data plane and the control plane enmeshed or separate? IE, does the box sit inline with traffic at all times, or does it just handle the access request and then it tweeks ACLs on the AP/Switch/etc?
- If this is inline, how would you envision this going in from a data path standpoint? Are there VLANs that have the APs and the portal on it, but no router, and then a second set of VLANs between the portal and the router? Can this be made redundant between multiple portal boxes? Do they sync state? Any performance worries? Etc...
- If this is a "redirect and push ACLs" kinda thing, what hardware requirements are there? Particular firmware needs? Any concerns about how this might translate to different gear?
- Jim
</pre>
<blockquote type="cite">
<pre wrap="">Joel's iPad
On Jun 27, 2010, at 8:48 PM, Jim Martin <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:jim@daedelus.com"><jim@daedelus.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> Ok, call me stupid, but I still don't get it. When we say "portal" does that mean all traffic goes through it, or is there redirection initially and then the network elements themselves allow full access (via MAC filters or whatnot)?
What I'm hoping for here is a description of the following things:
- What will the user experience be? (Ie, they get blocked on anything but HTTP initially, and get redirected to a portal page, enter credentials and have full access)
- What path will the bits take?
- What pieces will be needed to make this happen?
- Jim
On Jun 27, 2010, at 8:29 PM, Joel Jaeggli wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Not the it helps or anything but John and I will be in the same location at the end of the week it think.
I think modula the 802.1x digression we have consensus around the following things.
Prototype captive portal
A need for two machines
Identy token (email address) and secret key (registration code)
Hopefully the non mandatory nature of the experiment.
Item 3 is what gets socialized with Ray and Russ.
Joel
Joel's iPad
On Jun 27, 2010, at 8:18 PM, Jim Martin <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:jim@daedelus.com"><jim@daedelus.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Gentlepeople,
From some of the comments that have flown around here in the last day or so, I'm concerned that we aren't all in sync on what we're trying to do with the admission control project. Here's an attempt to clarify it from my point of view. If anyone disagrees with this, please speak up!
Goal
------
The IETF Meeting in Beijing this fall will have a network that is designed to connect to the Internet in a completely unfiltered way. Due to this lack of filtering, we've been asked to ensure that only IETF attendees can gain access to that network. At this point, the requested authentication tokens are a simple shared username/password that are distributed to the attendees as they arrive, however we'd like to ensure that per-user authentication is possible should the requirements become more strict.
To this end, we'd like to prototype this admission control system for Maastricht, both to validate the system under load and to provide a "heads up" to the attendees that this will be the way things are in Beijing. This also allows us to disable the admission control if there's a problem, an option not available in Beijing.
Caveats
-----------
- We're late. We need to socialize what we'll be doing to the IETF community via Ray (IETF Administrative Director) and Russ (IETF Chair), so we need to get them information soon.
- We have people with very limited laptops/devices, so we cannot assume they can to 802.1x
- We have some very privacy focused individuals which will undoubtedly be concerned with anything we do. We simply need to avoid stirring up the hornets more than we need to.
- The equipment being used in Maastricht is not guaranteed to be the same equipment being used in Beijing. Keeping things as device agnostic as possible is a good thing.
- Failure /IS/ an option in Maastricht, but would be very bad in Beijing
Timeline
------------
We really need a fleshed out plan ASAP. There an administrative call for the Maastricht IETF early (US) Tuesday morning where we should be able to put details forward.
- Jim
_______________________________________________
ietf78-tech mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:ietf78-tech@daedelus.com">ietf78-tech@daedelus.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.daedelus.com/mailman/listinfo/ietf78-tech">http://www.daedelus.com/mailman/listinfo/ietf78-tech</a>
</pre>
</blockquote>
</blockquote>
<pre wrap=""> </pre>
</blockquote>
</blockquote>
<pre wrap=""> </pre>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
ietf78-tech mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:ietf78-tech@daedelus.com">ietf78-tech@daedelus.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.daedelus.com/mailman/listinfo/ietf78-tech">http://www.daedelus.com/mailman/listinfo/ietf78-tech</a>
</pre>
</blockquote>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
ietf78-tech mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ietf78-tech@daedelus.com">ietf78-tech@daedelus.com</a>
<a class="moz-txt-link-freetext" href="http://www.daedelus.com/mailman/listinfo/ietf78-tech">http://www.daedelus.com/mailman/listinfo/ietf78-tech</a>
</pre>
</blockquote>
<br>
</body>
</html>