Subject: draft-ietf-pana-usage-scenarios-00.txt

From: Jacques Caron <[email-masked]>
Date: Sun, 03 Feb 2002 01:57:17 +0100

Hi,

First of all, I'd like to apologize if any of the comments below have 
already been made or have already been discussed, as I said, I'm pretty new 
to the list...

Also, don't be offended if I'm pretty negative about the whole draft. I see 
a need for something like PANA (actually, EAP over UDP) as an interim 
solution until 802.1x is widely deployed, but none of the other 
explanations below make any sense to me. Maybe I just didn't understand them...

In 1.3:

>      Device
>
>        A user's equipment (namely notebook computers, PDAs, etc.) that
>        requires access to a provider's network.

Might want to use something less generic than "device". I'd use "client", 
personally.

>      Local Network
>
>        The immediate network(s) that is available to the device/user for
>        Connecting. The network that the device is connecting to may be
>        operated by anyone (not necessarily the users home network
>        operator).

You didn't define what a home network is. I guess everybody in the current 
audience knows what you're talking about, but...

In section 2:

>As new type of networks (including wireless LANs)
>    are deployed in hotspot areas the legacy mechanisms may not be
>    appropriate in such scenarios.

Which legacy mechanisms are you referring to? 802.1x? How is it not 
appropriate?

>3.1.  NAS

What's your definition of a NAS? For me, a NAS is a dialup (modem/ISDN) 
server. It *might* be a PPTP/L2TP server, or even an IPsec server, but I 
guess you need to define the context...

>    i) PPP always assumes a link layer disconnect indication.

PPP has (optional?) mechanisms to check that a connection is still alive. 
Otherwise I guess PPPoE, PPTP and L2TP might be problematic...

>       -- This feature is not available in networks such as Wireless LANs
>          and others.

WLANs have a disconnect indication (it's called disassociation). And they 
obviously don't use PPP. What are "others"?

>   So there has to be some mechanism to detect when
>          the client disconnects.  This might mean that there is also a
>          need to re-authenticate client X to appear just after client A
>          left, spoof the MAC and IP addresses of the client A, and
>          basically continue to use client A's authenticated access.

That's certainly true, especially in the case of WLANs, but I don't think 
it's related to PPP.

>    ii) Since PPP works in scenarios where dedicated links exist, it
>        normally assumes a single access router in that link.
>
>       -- However, this is not true in multi-access links, such as WLANs.

Again, WLANs don't use PPP.

>          Multiple ARs are required for efficient control and robustness.

Switched from NASes to ARs?

>          The multi-AR scenario is discussed in section 3.3.
>
>    iii) PPP does address configuration to the client.
>
>       -- Address configuration should be decoupled from AAA
>          functionalities since in many cases devices may use other
>          address configuration mechanisms such as DHCP, stateless
>          address autoconfiguration, etc.

- those features are optional
- PPP's purpose is not to do AAA. AAA is just one of the many features of 
PPP, and having AAA in the initial phase of PPP is very logical
- in many cases, address configuration is actually linked to AAA (assigning 
specific IP addresses to some customers is quite common)
- PPP is indeed used in a point-to-point link context (hence the name), 
where no MAC address is available
- DHCP is used in a multi-access (LAN) context

>3.1.1.  Layer Two Specific Network Access Mechanisms

Why is this under 3.1?

>    WISPs are becoming prevalent and they are also starting Internet
>    access services in public areas such as airports and hotel lobbies.
>    The access control technologies they are currently considering would
>    be (i) web-based access control or (ii) L2 access control such as
>    802.1X.  The web-based access control is performed at a higher layer
>    after obtaining an IP address, whereas the L2 access control is
>    performed before obtaining an IP address.  There are pros and cons as
>    to which layer access control is performed.

Maybe these should be detailed or at least listed?

>   However, a higher layer
>    access control would be suitable for realizing user-agnostic network

"user-agnostic" might be a bit pedantic :-) Try anonymous, free...

>    access services in which a user can access local information such as
>    local-area map and flight information for free of charge, while
>    access to specific external web-sites is subject to charge.

Should be more precise on the "higher layer". The previous discussion leads 
to believe you're talking about web-based interfaces only, while I think 
you're talking about anything above L2.

Note also, that I don't see the problem with using L2 authentication to 
achieve that: one could authorize unknown users to connect anyway, but be 
limited to a restricted set of resources.

>    The web-based access control could provide such a service, but there
>    is no standard protocol or method which could help WISPs to support
>    roaming users.  While web-based access control can support devices
>    with web browsers, there are number of other applications such as
>    FTP, VoIP require a standard client application or protocol at the
>    client. The client will use this protocol to initiate the network
>    access for any non browser based applications.

It is also:
- more "transparent" for the user (no need to type in a login and password 
every time he/she connects)
- more secure (with the use of secure protocols such as SRP, or, to a 
lesser extent, MD5-Challenge). web-based access control is way to easy to 
spoof.

>   In addition to charge
>    a user for external web access, a local WISP can also provide charge-
>    based information delivery services such as music download, VoIP,
>    etc.  These services are provided by the local network and external
>    connectivity is supported by gateways.

What's the relationship with PANA? Any application-level AAA requirements 
should be performed within the application protocol. PANA is for network 
access only, isn't it?

>   It is also envisioned that
>    NAS can be triggered either by the device or PAA, based on provider
>    business model.

NAS? PANA you mean? What's the relationship between what triggers it and 
the business model?

>  PANA could provide a standardized way of
>    L2-independent user-agnostic network access with roaming enabled.

I think the one and only advantage of PANA in this scenario is to provide 
an interim solution to 802.1x until it is widely deployed: 802.1x usually 
requires low-level integration into the firmware, drivers and/or OS, both 
on the client and the AP, while PANA could be a very easy to implement and 
port solution.

>3.1.2.  Multiple Access Routers
>
>    In multi-access environments such as Ethernet and 802.11a/b, it is

802.11a/b -> 802.11 (that's the whole family, which includes a, b, g and 
more to come).
Also, you might want to generalize even more: Ethernet and 802.11 are both 
IEEE 802 protocols, which also include Token Ring and many others :-)

>    possible for multiple ARs to exist on the same subnet. This is a

May want to define what an "AR" (access router) is. I guess that's the 
default router to the Internet, but that's unclear.

>    fundamental difference from PPP in which a single AR is always
>    associated with a PPP tunnel and the association never changes
>    throughout the lifetime of the PPP connection.

I guess in the case of PPP tunnels (PPPoE, PPTP, L2TP), it is not 
impossible at all to imagine HA scenarios with primary/backup endpoints. I 
would even be surprised if that didn't exist. And even in the case of 
dialup, I believe there are some implementations that allow stateful 
failover to a standby NAS.

>    It would be desirable to use multiple ARs in such a way that traffic
>    coming from and going to a specific device always goes through a
>    single AR for ease of access control, but traffic among different
>    devices diverges for the purpose of load balancing and redundancy.

among -> from?
Also, load balancing and redundancy are often mutually exclusive. So I'd 
use "or" rather than "and".

>    Although many NAS-based networks support multiple ARs for inbound
>    traffic, however, for outbound traffic (originated from user devices
>    connected via PPP tunnels to a single NAS) a single AR is always
>    used.

What are NASes doing here again? I thought we had moved to a different 
scenario? And I have to admit I don't even understand the above sentence :-(

>   In an 802.11a/b network, it is possible to support multiple
>    ARs if all first hop routers reside behind the layer-2 access points.
>    On the other hand, if WLAN access points act as first hop access
>    routers then it boils down to the same NAS type of model as described
>    earlier.

If you have dense enough coverage, you should be able to roam (in the 
802.11 sense of the word) to another AP (which would maintain L2 
connectivity), and that one could also be doing VRRP or something 
equivalent to maintain L3 connectivity. And if you don't, well we're not in 
a multi-AR scenario anyway, are we?

>    Thus in order to achieve load balancing and redundancy in a more
>    flexible way we may need a different type of solution and in which

None of the above indicates that.

>    case PANA seems to be appropriate.  Consider the following scenario
>    (see Fig.1 for IPv4 example):
>
>
>    o  Unlike the existing PPP-based NAS model, the device randomly (or
>       by using some other criteria) selects one of the ARs as the
>       default router and always uses the selected AR as the next hop for
>       the outgoing traffic.  The network is also configured in such a
>       way that ICMP Redirect would not occur in the edge subnet to avoid
>       divergence of traffic coming from the user terminal.

Why the reference to the PPP-based NAS model again, since we're in a 
multiple-access network scenario?

>    o  Like the existing PPP-based NAS model, each AR has at least two
>       interfaces, one (Ie) is attached to the edge subnet and the other
>       (Ic) is attached to the core network.  The subnet prefix assigned
>       to Interface Ic covers that is assigned to Interface Ie.

Syntax error :-)

>   When an
>       AR receives an address resolution request (ARP REQUEST or Neighbor
>       Solicitation) from R (who is searching for the device on Interface
>       Ic) the AR that is selected by the device replies to the address
>       resolution request on behalf of the device and thereby guarantees
>       that all incoming traffic going to the device passes through the
>       AR.  This part is the same as the existing PPP-based NAS scenario.

This seems to be proxy-ARP scenario, which is very far from being generalized.

>    For example, assume that devices D1 and D3 perform initial
>    authentication with AR1 and that devices D2 and D4 perform initial
>    authentication with AR2.  If initial authentication is successful,
>    AR1 and AR2 will open firewall and create proxy ARP (or ND) entries
>    for D1/D3 and D2/D4, respectively.  Packets originated from D1 or D3
>    are forwarded to AR1.  Packets originated from D2 or D4 are forwarded
>    to AR2.  On the other hand, in terms of the reverse direction, when
>    core router R receives a packet destined for either D1 or D2, it is

You mean D1 or D3, I guess?

>    delivered to the final destination through AR1 in the following way.
>    If R does not yet have an ARP/Neighbor cache of the destination, it
>    performs address resolution since it thinks that the destination is
>    on-link according to the prefix assignment.  Only AR1 makes a
>    response to the address resolution request with specifying the MAC
>    address of Ic1.

Syntax error.

>   Then, R forwards the packet to AR1 which delivers it
>    to the final destination device.  In the same way, when R receives a
>    packet destined for either D3 or D4, it is delivered to the final
>    destination through AR2.

You mean D2 or D4...

>    In the above case, since both the incoming and outgoing traffic with
>    regard to a specific device are controlled to pass though a single
>    AR,

Syntax error.

>  it would be easier to perform authentication via the same AR.
>    However, this would change if the topology is different or if traffic
>    coming from and going to a specific device diverges among different
>    ARs as a result of ICMP Redirect or the use of "Default Router
>    Preferences and More-Specific Routes" [Draves] in IPv6.

Not sure whether this is a syntax error or if it's just my internal parser, 
but I don't think this is very clear...

>   Detailed
>    architecture tradeoffs will be discussed in framework document.

Stupid question: why not use VRRP, and all is said and done? And anyway, 
what's PANA got to do with any of that?

>3.1.3.1.  Interface Switching
>
>    If multiple interfaces are connectable to the same local network,
>    only one of those interfaces may be activated at a time for the
>    purpose of battery saving,

Why would anyone connect multiple interfaces to the same network? Why do 
you assume the device is battery powered, and that activating an interface 
actually has an influence on battery life? Probably just a wording problem, 
to make those postulates of your scenario rather than affirmations.

>  and perform interface switching when other
>    interface is to be activated, with or without changing IP address.

No comprendo. Why is another interface to be activated?

>  In
>    such an environment, the device may have to perform initial
>    authentication each time interface switching occurs, as well as
>    periodical re-authentication for the activated interface.  This would
>    not be desired if initial authentication or re-authentication
>    involves communication with the AAA infrastructure which would
>    increase AAA signaling traffic in the core network unless the user's
>    credential is stored in the L2 network access point.

Isn't there some work about fast handoffs and context transfer in the 
Seamoby WG?

>    The LSA established by using PANA as a result of successful initial
>    authentication with an interface can be used for local re-
>    authentication which would be performed periodically or at every
>    interface switching event.  See section "Using LSA for details.

You have to think: what's the purpose of periodic reauth? It is there so that:
- the home AAA server, can make sure the client is really still there and 
that the foreign network is not trying to fake accounting
- the foreign network can make sure nobody took the place of the "real" client

Using an LSA will solve problem #2, but not problem #1. Periodic end-to-end 
reauth will solve both. Conclusion: the LSA is useless :-/

>    Note that this kind of optimization by PANA would not be possible if
>    (i) multiple interfaces are connected to different local networks
>    each managed by an independent PAA

Which is a lot more probable.

>and (ii) re-authentication is not
>    required.
>
>
>3.1.3.2.  Multi-homing

Same remarks apply.

>3.1.3.3.  Interface Sharing

I really don't see the point of the whole section?

>3.2.  WLAN

I thought that subject had already been discussed in 3.1.1?

>    WLAN is a one of the many scenarios where PANA could be useful. While
>    802.1X specification is being deployed by WISPs today, it would not
>    meet the future needs such as inter-technology hand-offs,

Why not?

>    differentiation between free and paid access

Already proved otherwise earlier.

>and others.

Be more precise.

>    While interworking with 802.1X needs to be taken into consideration,
>    a solution at the higher layer is clearly another option, especially
>    where only legacy 802.11a/b interface cards and APs are available.

Indeed that's the only reason I see and the reason I'm here ;->

>    An alternative is that L2 authentication could be used to get free
>    local access, and PANA could then later be used to access specific
>    paid services or access to global Internet.

Again, application-level AAA is an altogether different subject. And if 
using volume-based billing, nothing prevents the local operator from 
excluding some traffic (for local/free services) from the billing. For 
duration billing, one could start billing only when non-free services start 
to be used.

>3.3.  GPRS
>
>    In GPRS there are only two methods of authenticating/acquiring an
>    address from networks other than the GPRS access network (corporate
>    or ISP).  In one mode PPP is terminated by the GGSN which then
>    authenticates the user (using the RADIUS client) to the "other"
>    network, being the ISP the user connects to or the "home" corporate
>    network depending on the requested APN.  In the second mode, PPP is
>    terminated in the MT, ONLY the Challenge Response is piggybacked on
>    PDP context requests. The RADIUS client in the GGSN then relays this
>    info to the RADIUS server wherever that maybe (Based on the APN).

Need to define GGSN, MT, APN, PDP... Not everybody is versed into GPRS 
lingo :-( And I think that the whole paragraph needs re-wording, even the 
parts I can understand it took me 3 times to understand :-/

>    As yet another example, there is no  mechanism for exchanging a
>    second level of authentication and addressing information, only the
>    interaction with the cellular systems' authentication and address
>    assignment mechanism is possible (although Mobile IP could be used).
>
>    A protocol that decouples the authentication and addressing from PPP
>    (and Mobile IP) could allow an operator to provide remote
>    authentication and authorization of home network services and address
>    assignment within such a domain using one of the available IP layer
>    tunneling mechanisms to deliver packets.

No comprendo at all. And I even think you're actually contradicting yourself?

>3.4.  Intra-domain, Inter-technology Handoff
>
>    Although the PANA WG will not directly work on solutions relating to
>    mobility of the device.

Syntax error.

>   However, it is noted in the PANA WG charter
>    that the ability to re-authenticate locally with the PAA, can be an
>    important element in allowing efficient handling of mobile devices.
>    This section describe possible situations where an LSA established by
>    using PANA would be useful for mobile nodes.

Don't think a charter can be considered as a reference document or as a 
justification :-)

>Such access dependence requires an access
>    dependent identity for the user.

Syntax error.

>  Hence while connected to a Cellular
>    network, a user is identified by an IMSI, on a WLAN or Bluetooth
>    network a user will have a different identity.

Not necessarily. See EAP SIM and EAP AKA drafts.

>4.1.  Using LSA for Re-authentication
>
>    Once initial authentication is successful, re-authentication would be
>    necessary in the following situations:
>
>    o  When there is a change in attributes of either the device or PAA.
>       For example, re-authentication would be necessary when the
>       device's IP address changes due to e.g., interface switching or
>       handoff.

I would believe this is a new authentication altogether, even though it 
might be linked to the previous one (see Multi-Session-Id in Diameter). 
Re-auth is a "timed", home-server-requested, periodic check.

>    o  If the underlying access network does not have a capability to
>       detect physical disconnection of devices, periodical re-
>       authentication is necessary for (i) preventing connection
>       hijacking from malicious users which would possibly occur when the
>       device is shutdown or the user leaves the local network with the
>       device without performing explicit log-off from the local network
>       or (ii) improve the accuracy of accounting.

For (ii), a simple echo request method is enough (e.g. ping, or any L2 
mechanism such as those that exist in PPP and probably in 802.11), and will 
be a lot less resource-intensive, so you can do it more often, and get a 
way better accuracy.

And you forgot the most important that I mentioned earlier: to allow the 
home server to make sure the foreign network is not trying to cheat on 
accounting.

>    On the other hand, it is desired that periodical re-authentication is
>    performed locally between the device and PAA in order to minimize the
>    signaling traffic.

This won't work for the reason mentioned above.

>4.2.  Using LSA for IKE
>
>    The shared key for the LSA or other shared key derived from the LSA
>    can also be used as an IKE credential with which an IPsec SA between
>    the device and PAA is established via IKE[RFC2409].  This would be
>    useful especially in roaming environment where it is difficult to
>    share the IKE credential a priori between the device and an IPsec
>    entity in the local network.
>
>    The established IPsec SA can be used for protecting PANA message
>    exchange, which would be useful for quick re-authentication and/or
>    secure explicit log-off.

EAP SRP allows for quick re-auth as standard. Explicit logoff is a good 
idea, but I believe in most cases there's already a function for that at L2?

>    It is also possible to utilize the LSA to establish an IPsec tunnel
>    between a device and an IPsec gateway.  The established IPsec tunnel
>    can be used for protecting user data packets in the access network at
>    the IP layer.  This would provide access network security without
>    relying on L2 security mechanisms, which is important considering the
>    recent exposure of WEP vulnerabilities.

It's also about as useful as WEP in a roaming environment: encrypt data up 
to some totally uninteresting place, with a key known to a third party. 
Worthless.

>5.  Conclusion
>
>    The scenarios described above show a clear need for a common edge

Well, not that clear to me ;->

My own conclusion is that I don't see any of your scenarios showing any 
need for anything new, other than a simpler-to-deploy interim alternative 
to 802.1x, and maybe some mechanism to force a new authentication without 
breaking an existing connection on existing L2 protocols (though I'm not 
quite sure this is explicitly forbidden by either PPP or 802.1x, for 
instance), to allow for service rate changes (that would also require EAP 
to transport cost information to be of any use).

Sorry if I sound very negative, maybe I missed a point, but then it means 
it's not clear enough :-)

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 4 Feb 2002 15:59:20 -0500

Hello Jacques,

> explanations below make any sense to me. Maybe I just didn't understand 

Thanks for sending a lot of comments.  Regardless of whether it is a
positive or negative reaction, it would be better than no reaction :)
This kind of severe comments are important to improve the quality of the 
draft.  

Detailed comments are described in line.

Thanks,
Yoshihiro Ohba

> Might want to use something less generic than "device". I'd use "client", 

The requirements draft also uses this term.

> audience knows what you're talking about, but...

I'll remove "(not necessarily the users home network operator)".

> Which legacy mechanisms are you referring to? 802.1x? How is it not 

L2 authentication mechanisms like PPP and 802.1x.  

One example is shows in the same section 

   "For example, while basic connectivity may be user-agnostic,
   enhanced services will be
   available only to authorized users (since charging is involved for
   such services)."

By using L2 authentication, this kind of services are not possible
without using some layer violation technique and I don't think layer
violation is a generic and appropriate solution.

> guess you need to define the context...

I mean a more generic definition such as described in RFC 2881:

   A NAS is sometimes referred to as a Remote Access Server (RAS) as it
   typically allows remote access to a network.  However, a more general
   picture is that of an "Edge Server", where the NAS sits on the edge
   of an IP network of some type, and allows dynamic access to it.

> Otherwise I guess PPPoE, PPTP and L2TP might be problematic...

Yes.  PPP itself has a link layer disconnect detection mechanism by using 
LCP echo request/reply.  So an appropriate text would be like:

  i) IP over PPP always assumes PPP provides a link layer disconnect
  indication viewing PPP as a link layer).

> obviously don't use PPP. What are "others"?

Thanks for pointing this out.  An an appropriate text would be like:

  -- If there is an intermidiate L2 entity such as switch, hub or AP,
  between a device and an AR, this feature is not available if 
  the AR needs to detect disconnection of the device.

> That's certainly true, especially in the case of WLANs, but I don't think 

The intention here is that the assumption for PPP does not always
apply to non-PPP networks.  So it's valid that the above paragraph is
not related to PPP.

> Again, WLANs don't use PPP.

Again, the intention here is that the assumption for PPP does not always
apply to non-PPP networks.  So it's valid the above paragraph is not
related to PPP.

> - those features are optional

When PPP is used for IP, isn't it true that IP address configuration
is done within PPP IPCP?

> PPP, and having AAA in the initial phase of PPP is very logical

Your statement would be logical only in a specific service scenario.
Even in the case of PPP, AAA could be performed after PPP IPCP if PANA
runs over IP over PPP, and this would be useful for providing other
types of services as described in section 3.1.1.

> specific IP addresses to some customers is quite common)

On the other hand, there is also a need for another type of services in
which address configuration is not necessarily linked to AAA.

> >3.1.1.  Layer Two Specific Network Access Mechanisms

Because the contents would apply to generic network access control,
and are not much tied with WLAN and mobility.

> Maybe these should be detailed or at least listed?

OK.  I'll try to do that.

> "user-agnostic" might be a bit pedantic :-) Try anonymous, free...

OK.

> you're talking about anything above L2.

Yes, "higher layer" in this context means any layer that is higher
than L2.

> limited to a restricted set of resources.

Anything is possible if the solution is based on layer violation :)
In addition, if there is no problem with L2 authentication to achive
that, an AP product should have already been available that allows
assigning an IP address before performing 802.1X :)

> lesser extent, MD5-Challenge). web-based access control is way to easy to 

I agree with you on these.

> should be performed within the application protocol. PANA is for network 

I don't think this means application-level AAA.  Instead, it means
that more specific filtering rule can be installed as a result of
PANA.

> NAS? PANA you mean? What's the relationship between what triggers it and 

"NAS" here should be replaced with network access service, I guess.
And the word "service model" would be more appropriate than "business
model".  Thanks.

> on the client and the AP, while PANA could be a very easy to implement and 

Not all networks are possible with 802.1x.  If a reader of this draft
thinks that 802.1X (or PANA) is absolutely better than the other or
that PANA is an interim solution to something, he or she might be
misunderstanding or missing something in the contents of the draft.

After reading my entire comments, if you still think that PANA is
interim solution, please show me exact paragraph(s) that is incorrect
or does not still make sense.

> IEEE 802 protocols, which also include Token Ring and many others :-)

I will change it to "such as IEEE 802 networks". 
Thanks.

> default router to the Internet, but that's unclear.

"the default router" may not be appropriate in multi-AR environment.
It is a first hop router for a device.

> failover to a standby NAS.

But in the case of backup NAS, the device does not view the two NAS'es
as different ones.  

The multi-AR scenario in the draft would cover broader cases in which
the device may or may not view multiple ARs as different ones.

> >   devices diverges for the purpose of load balancing and redundancy.

Yes.

> use "or" rather than "and".

Agreed.

> scenario? And I have to admit I don't even understand the above sentence :-(

NAS is an "Edge Server" as previously mentioned.  
Anyway, the paragraph will be removed in the next version 
reflecting Paal's suggstion for compressing this section.

> a multi-AR scenario anyway, are we?

First, it seems to me that multi-AP and multi-AR are orthogonal
issues.  Second, if my understanding is correct VRRP only takes care
of tranfering routing context.  It would not transfer other context
such as PANA protocol context and/or filtering rules.

> None of the above indicates that.

OK.  The paragraph will be removed in the next version.

> multiple-access network scenario?

Because someone made a comment during the meeting that a similar
scenario is already used in the PPP-based NAS model and hence is not a
new scenario.  So I tried to describe the difference between this
scenario and PPP-based NAS.  Anyway, the paragraph will be removed in
the next version.

> >      to Interface Ic covers that is assigned to Interface Ie.

Thanks for finding this and other syntax errors.
The paragraph will be removed in the next version.

> This seems to be proxy-ARP scenario, which is very far from being 

The paragraph will be removed in the next version.

> You mean D1 or D3, I guess?

Yes, as already suggested by Paal.  The paragraph will be removed in
the next version.

> >   response to the address resolution request with specifying the MAC

Where?  Anyway, the paragraph will be removed in the next version.

> >   packet destined for either D3 or D4, it is delivered to the final

Yes, as already suggested by Paal.  Anyway, the paragraph will be
removed in the next version.

> >   regard to a specific device are controlled to pass though a single

OK.

> but I don't think this is very clear...

Hmm, this indicates the case in which a device will use multiple ARs
in the same subnet as a next hop for different destination addresses.

> what's PANA got to do with any of that?

As I previously mentioned, if my understanding is correct, VRRP only
takes care of tranfering routing state.  It would not transfer other
states such as PANA protocol states and/or filtering rules.
Using VRRP solely does not solve the problem.

> to make those postulates of your scenario rather than affirmations.

Please understand why I used "may".

> No comprendo. Why is another interface to be activated?

Bluetooth is said to be less consume battery.  If there are a device
with Bluetooth and 802.11 interfaces, and if the network also supports
both types of L2 technologies, it would make sense for the device to
change interfaces from 802.11 to Bluetooth.

> Isn't there some work about fast handoffs and context transfer in the 

The scenario does not necessarily use mobility managent protocols 
or context tranfer.

> reauth will solve both. Conclusion: the LSA is useless :-/

You seem to forget that re-authentication interval are different for
#1 and #2.  Interval for #1 could be per-day, per-hour, etc, but #2 is
required to be performed for every less than 5 minites.  If #1 is
required to be peformed very frequently, there would be a scalablity
problem (guess what happens if each of 100000 users of an ISP
performes periodical end-to-end authentication for every 5-minite in
multi-ISP roaming environment).

So I can say that your conclusion is incorrect. :)

However, as you pointed out, end-to-end re-authentication is necessary
for #1 (but less frequently) even if we have local re-authentication.
I will explicitly state about this.  Thanks.

> Which is a lot more probable.

But is it valid for assuming such a "happy network configuration" for
PANA?

> >and (ii) re-authentication is not

Same comments apply.

> I really don't see the point of the whole section?

The point is that PANA works naturally with new types of access
control such as prefix-based access control.

> >   meet the future needs such as inter-technology hand-offs,

How about changing "would not meet" to "would not easily meet"?

> Already proved otherwise earlier.

Same as above.

> Be more precise.

I'll remove "and others".

> duration billing, one could start billing only when non-free services start 

I don't mean application-level AAA here.  And please understand this 
is "an alternative" and does not prevent other scenarios like you mentioned.

According to the charter, a separate draft will be produced from this
WG for PANA and 802.1X or PPP.  You can work for that if you like.

> parts I can understand it took me 3 times to understand :-/

I'll ask Phil for explanation about those words.

> No comprendo at all. And I even think you're actually contradicting 

The point is that in GPRS, PPP authentication is used for device
authentication, and user-level authentication mechanism is necessary
even without using Mobile IP.

> >   Although the PANA WG will not directly work on solutions relating to

OK.

> Don't think a charter can be considered as a reference document or as a 

OK.  I'll remove the reference to the charter.

> >   dependent identity for the user.

Where?

> Not necessarily. See EAP SIM and EAP AKA drafts.

I think Hesham can comment on this.

> Re-auth is a "timed", home-server-requested, periodic check.

Mobile IP does not require a new authentication altogether when a
Moble Node changes its Care-of Address.  Why PANA requires a new
authentication altogether for similar cases?

> be a lot less resource-intensive, so you can do it more often, and get a 

You are right.  I'll remove (ii).

> This won't work for the reason mentioned above.

This will work for the reason mentioned above.  On the other hand, 
I also agree that there is a case in which end-to-end re-authentication 
is necessary (but less frequently than local re-authentication).

> idea, but I believe in most cases there's already a function for that at L2?

I guess that the Lightweight challenge option for EAP SRP is for
end-to-end re-authentication.  That's different from local
re-authentication.  And you admit that not all L2 technologies have
explicit logoff by mentioning "in most cases", so I don't think 
I missed a point for explicit logoff.

> to some totally uninteresting place, with a key known to a third party. 

You seem to be misunderstandnig.  The encryption key for IPsec in this
scenario cannot be known to a third party, since key exchange is
performed by using IKE, and the communication channel for IKE is
secured by using ISAKMP-SA which is established during IKE phase 1
negotiation.

> it's not clear enough :-)

I would wait for your reaction for my comments. :)

Thank you very much for careful reading.

> Jacques.

Yoshihiro Ohba

---

From: James Carlson <[email-masked]>
Date: Mon, 4 Feb 2002 17:45:14 -0500 (EST)

>   indication viewing PPP as a link layer).

I'm not sure that makes sense.  IP over PPP doesn't really assume much
besides PPP supplying link-layer delivery of datagrams for IP.  Where
the physical layer supports disconnect indications, PPP can deal with
this and send the notification to IP.  Where the physical layer does
not, PPP has options to allow detection and can then notify IP.  This
doesn't mean that PPP is *required* to do this.  In some
implementations, it may not.

>   the AR needs to detect disconnection of the device.

Instead of "is not available," I'd write "may not be available."
There are likely to be cases where there's an L2 intermediary that
*does* send disconnect notification.  (Think IP over FR.)

> When PPP is used for IP, isn't it true that IP address configuration

IPCP address negotiation is *optional*.  If the peers refuse to
negotiate addresses, you're basically back to a SLIP-like link: any
necessary addresses have to be configured (or otherwise guessed at;
screen-scraping was once popular, as was BOOTP over SLIP) in order to
make the link work.

You can even refuse IP addressing via IPCP and then proceed to use
DHCP to acquire the necessary addresses.

It's not the way it's *supposed* to be used, but it's certainly
supported by the standards.

> Anything is possible if the solution is based on layer violation :)

Layering violations are often in the eye of the beholder.  :-/

The allow-unknown-users-to-connect-with-minimal-privileges scenario is
one that I think will be compelling.  It allows the provider to (for
example) present the user with web-based form to sign up for
additional levels of access.

The ancient example of a working interface like this was the old
"library" user available at some universities.  This was a special
user name that didn't prompt for a password, but allowed access to
just the local research library.  Thus, remote users could dial in and
get 'guest'-level access without having to register.

> even without using Mobile IP.

I don't think that's GPRS-specific.  PPP authentication just covers
the link itself.  It really has no notion of "users" or "applications"
as such (modulo what others have imputed to it :-/).

> end-to-end re-authentication.

It's for link-layer re-authentication; it covers just as much as is
covered by EAP SRP in the first authentication, but is cheaper in that
it doesn't require a new key exchange.

-- 
James Carlson, Solaris Networking         <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 4 Feb 2002 19:28:52 -0500

> implementations, it may not.

Then how about this?

  i) IP over PPP can expect PPP provides a link layer disconnect
  indication (viewing PPP as a link layer).

> *does* send disconnect notification.  (Think IP over FR.)

OK, thanks.

> supported by the standards.

Then how about this?

 iii) In many cases PPP does address configuration to the client.

> as such (modulo what others have imputed to it :-/).

The identifier for a PPP client can be tied with a person or a device
or whatever it can.  In this sense, it really has no notion of "users"
or "applications".  On the other hand, the section focuses on what the
identifier is tied to.  In the case of typical dial-up PPP, it is tied
with a person.  In the case of GPRS, the identifier is tied with the
device.  That is my understanding.

> it doesn't require a new key exchange.

Very interesting.  EAP is getting less transparent to NAS, isn't it?

Anyway, it seems that there are many ways for re-authenticaion.

Thanks,
Yoshihiro Ohba

---

From: Jacques Caron <[email-masked]>
Date: Tue, 05 Feb 2002 01:30:35 +0100

Hi Yoshihiro,

>The requirements draft also uses this term.

Might be good to change both :-) Device seems just way too generic to me.

Some additional comments, on section 2:

>    Today's technologies mostly rely on access specific mechanisms.

add "to perform authentication".

>However, PPP may not be
>    appropriate for most new type of networks.

I'm not sure this is needed, I think it is known, and the goal of the draft 
is not to say PPP is not appropriate, but that there are scenarios (e.g. 
link layers not using PPP) where authentication is needed and there is no 
mechanism for it, or where PPP is used, but the authentication mechanisms 
built into it are not appropriate.

>   Moreover, node
>    configuration through PPP is not always necessary.

Again, not sure this one is relevant here, and I don't quite believe it's 
true :-)

>   Today's wireless
>    networks, especially cellular networks, also have relied on specific
>    layer 2 identifiers and layer 3 messaging (NOT IP) to accomplish user
>    authentication.

I'm not sure it qualifies for layer 3 messaging, as it's not pure PDU 
transport from the client to somewhere else, but rather L3 messaging from 
the authenticator to the authentication backend, supporting L2 authentication.

>   As new type of networks (including wireless LANs)

typeS

>    appropriate in such scenarios.

add something like "as will be shown in further sections", otherwise it 
just looks like a pulled-out-of-thin-air statement :-)

>   Different kinds of service models are
>    also emerging in today's Internet.  For example, while basic
>    connectivity may be user-agnostic, enhanced services will be

same remark for user-agnostic as I already did somewhere else.

>    such services).

>    The following scenarios are described in the next section:
>          - NAS
>          - WLAN
>          - GPRS
>          - Intra-domain, inter-technology handoff

Given your large definition of a NAS (see below), what is the purpose of 
separating NAS from WLAN, and even GPRS? Either it's all part of the NAS 
"problem", or you need to split that in specific instances of NASes, e.g. 
dialup, VPDN, WLAN, LAN, GPRS, and whatnot. Or PPP, 802, GPRS. Or any other 
classification that makes sense.

Back to our thread...

>    of an IP network of some type, and allows dynamic access to it.

Add a reference ("Basic NAS functionality, as defined in [x],...").

For the rest of the section, I actually still don't understand the point. 
What are you trying to show?
- that PPP cannot be used in all cases?
- that L2 technologies other than PPP might not provide all the 
functionality of PPP?
- or that authentication within PPP is not always appropriate?
- or some specific requirements for PANA that are achieved by PPP and need 
to be "reproduced"?

Also, would the "edge server" be the first L2 device, or the first L3 device?

>   indication viewing PPP as a link layer).

I don't see why you absolutely want to keep this...

>   the AR needs to detect disconnection of the device.

You switched from NAS to AR. What would the NAS be? The "intermediate L2 
entity", or the AR? For me it's the L2 entity, and that thing always knows 
how to detect a disconnection.

>apply to non-PPP networks.  So it's valid that the above paragraph is

I think nearly all L2 access mechanisms have some disconnect indication, 
either directly (link down, explicit logoff...) or indirectly (timeout in 
echo requests), so the assumption is still valid, and again, I don't know 
what you're trying to prove (apparently that other L2 technologies don't 
have all the characteristics of PPP, but I don't see how that is related to 
the goal of the draft)?

>When PPP is used for IP, isn't it true that IP address configuration

Yes, but the NAS does not necessarily provide the configuration. The client 
can be preconfigured with it, for instance, and the NAS will just be 
presented with that information and can only accept/reject it.

>types of services as described in section 3.1.1.

For that goal, I think we would be better off making sure that it is 
possible to perform a brand new authentication in PPP (and other L2 
protocols) even once a session has been started. Actually, I'm not sure 
either PPP or 802.1X specifically prohibit it (have to check the state 
machines to see if it's possible to get back into a state where 
authentication is required without tearing down the whole connection, only 
the ability to transmit datagrams).

>which address configuration is not necessarily linked to AAA.

In most cases it actually isn't (but it all depends on what you mean by 
"linked to").

[...]

>Anything is possible if the solution is based on layer violation :)

Where is there a layer violation?

>assigning an IP address before performing 802.1X :)

The AP would actually try to perform 802.1X auth, but it's just a matter of 
config, more likely on the Radius server:
- if the user is known, allow him/her to connect with full access
- if the user is not known, allow him/her to connect anyway, but with 
restricted access.

IP allocation then happens afterwards. It might be linked in some way to 
the result of the previous auth. Also, the user might be associated to a 
different VLAN depending on the case (for APs that support 802.1Q VLAN 
tagging).

Another point, you seem to suppose that the user will always check the 
"free" things first, and then maybe move to "non-free" things. No reason 
for that.

>that more specific filtering rule can be installed as a result of

You're definitely not talking about network access, but about applications. 
AAA for an application should be within the application, otherwise you get 
awful problems with NAT, proxies and whatnot. See the EAP over HTTP draft 
for a better solution (which still needs quite some work, though).

[...]

>misunderstanding or missing something in the contents of the draft.

Probably.

>or does not still make sense.

I think I'll wait for an updated revision of the draft, waaaay too many 
changes to have a good view :-)

>It is a first hop router for a device.

Hence the need to define it.

>But in the case of backup NAS, the device does not view the two NAS'es

Why should it?

>the device may or may not view multiple ARs as different ones.

I have to admit I have no idea of what PANA brings to the equation here, 
though.

[...]

>issues.

Quite, but then what's the point of the "integrated AP and AR" case above?

>   Second, if my understanding is correct VRRP only takes care

Indeed, not that I know of (but apparently VRRP does a lot more than I 
thought it did), but the whole context/state replication is not specific to 
PANA, and I don't see how/why PANA is linked to it?

[...]

>Please understand why I used "may".

I think the wording is not appropriate (it reads "if X, then Y may Z"). I 
would rather say something like:
"In this scenario, a network provides access using different access 
technologies, and a client has multiple interfaces matching the 
technologies offered. The client only uses one interface at a time, and 
switches from one interface to the other based on variable requirements 
(e.g. power-saving vs. performance)".

>multi-ISP roaming environment).

Honestly, given the granularity of billing intervals, many home servers 
will really do periodic re-auth at quite short intervals (probably 
somewhere between 1 and 10 minutes, certainly not every day!). Indeed this 
implies quite a bit of traffic, hence the need to optimize that (reducing 
the number of roundtrips to the minimum, for instance), but I think it all 
remains anecdotal when compared to the "real" useful traffic.

>But is it valid for assuming such a "happy network configuration" for

I think one of the most frequent cases we'll see will be GPRS/WLAN 
switching, and I think in most cases the two networks won't be controlled 
by the same operator, and if they are, they have such different 
architectures that I doubt it will use the same PAA.

But to make a long story short, your whole "interface switching" scenario 
is nothing else than a fast handover scenario, even though the two "cells" 
are actually in the same location, and are differentiated only by the media 
used. I'm not sure how PANA actually helps in any way?

>control such as prefix-based access control.

I think the goal of the draft is not to show where PANA would work, but 
where PANA is needed because no existing solution already works. And 
honestly, I think existing (L2 based) solutions work out a lot better than 
PANA in the scenarios you describe in this section...

>How about changing "would not meet" to "would not easily meet"?

It doesn't change the question... You shouldn't have unjustified 
statements, so any explanation of why you think it will not/would not/would 
not easily meet the future needs is needed.

[...]

>is "an alternative" and does not prevent other scenarios like you mentioned.

Again, I think the draft should show cases where PANA is needed, not cases 
where PANA might be used, don't you think?

[...]

>even without using Mobile IP.

Well, the whole device vs. user authentication is a very general one, and 
it applies to all authentication technologies that I know of, including 
PANA. But I don't see anything in the text above that says anything about 
that, it really looks more like some kind of VPN discussion, but I don't 
quite know where it's trying to get to and why (and what the relationship 
with PANA might be)?

[...]
> > >   dependent identity for the user.

Mmmm, not actually a syntax error, more of a wording issue.

"Currently these mechanisms are specific to each type of media (e.g. HLR in 
GPRS and 802.1x in 802 media), and require different types of identities of 
the same user" sounds better (not that I believe what I write...).

>I think Hesham can comment on this.

Until he does, simply consider that a given user should be assigned by his 
home network a globally routable NAI that should work on any media, 
provided the local network has direct or indirect roaming agreements with 
the home network.

[...]
>authentication altogether for similar cases?

I'm not familiar with all the details of Mobile IP authentication, but from 
what I remember from Diameter discussions, it is actually a new authentication.

[...]

>I missed a point for explicit logoff.

I say "in most cases" because I don't know all L2 technologies, but careful 
examination would be necessary before making any statements.

[...]

>secured by using ISAKMP-SA which is established during IKE phase 1

The third party in this case is the local network, as opposed to the client 
and the home network (in the case of a corporate network here, otherwise 
VPNs are not very useful, TLS at the application level is).

>I would wait for your reaction for my comments. :)

Hope you like them :-)

I think before you release a new version, you should carefully think about 
what you're trying to state. I believe the goal of this draft is to show 
scenarios where current solutions don't work, either because a specific L2 
(or L2 "emulation" such as VPNs or MobileIP) technology does not have an 
appropriate authentication system, or because the said authentication 
system does not meet all the needs.

So, I believe you should structure your document as:
- what the needs are
- what the current authentication technologies are (EAP for PPP, 802.1x for 
802 media...), and how they meet or don't meet the needs stated above
- cases where there is no authentication technology available (and hence 
where PANA is needed and appropriate)

This will make things much clearer...

Good luck,

Jacques.

---

From: James Carlson <[email-masked]>
Date: Tue, 5 Feb 2002 07:49:47 -0500 (EST)

> the ability to transmit datagrams).

At least for PPP, reauthentication is perfectly legitimate.  For CHAP
and EAP, it's merely a matter of sending a new Challenge or Request
message.  For PAP, it requires another trip through LCP, but the trip
can be shortened by recognizing that all of the final options are
already known and thus no actual 'negotiation' is needed.

There's unfortunately quite a gap between "perfectly legitimate per
the written standards" and "works on the garden variety
implementations."  I would not argue to take this as a reason to say
that PPP reauthentication doesn't work.  Instead, if it's necessary
for some purpose, I'd argue that forcing the deficient manufacturers
to clean up their implementations is the right way to go.

> quite know where it's trying to get to and why (and what the relationship 

Agreed; the problem is much deeper.  I think the notion of somehow
requiring PANA to represent "users" versus "devices" is bankrupt.
"Users" exist in reference to particular applications, not in
reference to IP links.  In other words, for a given IP link, you might
have zero, one, or many human users.  How or why should PANA's
authentication know about the distinction?

> system does not meet all the needs.

Actually, one other possibility exists: the L2 emulation provides the
necessary authentication but causes such distortion of the network
topology or performance that it's a net less.  (Pun not quite
intended.)

For example, PPPoE is one such issue.  It does shoe-horn in the
authentication desired, but it causes multicast to become quite
problematic and has caused endemic MTU-related problems on the
Internet (due in part to rampant and apparently unfixable firewall
misconfiguration).  For this latter problem, even worse kludges have
been devised: see, for example, MSS clamping in rp-pppoe.  Instead of
all this, some mechanism that allowed the node to authenticate and
then use plain old IP (rather than some unnecessary and probably
hazardous encapsulation) would be highly advantageous.  (Perhaps RFC
3118 ... ?)

---

From: James Carlson <[email-masked]>
Date: Tue, 5 Feb 2002 08:22:29 -0500 (EST)

>   indication (viewing PPP as a link layer).

I don't understand "can expect" in the context of typical draft
language.  Perhaps "SHOULD" is what's intended here.

In any event, I think this section needs substantial work.  Points (i)
and (iii) are demonstrably untrue.  Point (ii) seems to state the
obvious -- that the Point to Point Protocol is designed for
point-to-point links rather than for multiaccess links.

>  iii) In many cases PPP does address configuration to the client.

First of all, PPP does not make a distinction between "server" and
"client."  Only the *users* of PPP do that.  Secondly, as I said, IPCP
*can* do address configuration, but is not required to, and thus this
statement doesn't support your later contention that address
configuration needs to be decoupled.  It already can be without
changing any aspect of PPP.  Lastly, and most importantly, I would
dispute the basis of the need for this decoupling.

The fact that PPP has a mechanism for allowing the peers to agree on
IP endpoint addresses to be used on the link says nothing at all about
the behavior of those peers with reference to other protocols.  In
particular, it's perfectly legitimate (and, in fact, common) for a NAS
to make a DHCP request on behalf of a PPP link, and then use the
DHCP-assigned address in the IPCP Configure-Nak sent to the "client"
on the link.  Doing so requires no extensions to any protocols nor any
additional standards documents.  It's also perfectly legitimate for a
"client" to send DHCP requests over an established PPP link in order
to discover network services, request additional addresses, or even
acquire a different address.  The whole point of IPCP address
negotiation is to avoid the accidental misconfigurations that were
once common with SLIP -- not to "force" anyone to use any particular
IP address.  IPCP address negotiation is not a security mechanism.

In any event, I think this part of the thread is probably veering
dangerously off-topic.  PPP ought not be part of the solution space
for multiaccess networks that don't have point-to-point semantics.

> device.  That is my understanding.

I think that's still flawed.  The fact that (at least today) a
"typical dial-up PPP" link involves a PC running some GUI'd flavor of
CP/M doesn't quite change the fact that what's being authenticated is
the link itself, not the purported user(s) of the link.

In fact, on DSL, it's not at all uncommon these days to have that
PPP(oE) link terminating on a NAT box, with several distinct humans
behind the NAT.

In any event, I don't think this distinction is necessary or useful.
Authentication of the link is just that, and it's essentially the same
for PPP, GPRS, 802.1x, and (I'd submit) for PANA.  I don't see why
*network* services should be tied to a *human* user except by some
local (deployment-related) convention.  If you need to authenticate
humans at all, it's in reference to either local privileges or to
applications, not IP addresses and links.

> Very interesting.  EAP is getting less transparent to NAS, isn't it?

I don't think I see the implication that you seem to.  When used with
AAA, SRP-SHA1 is designed to be used in the same way as any other
EAP-based algorithm.  The messages are passed through by the NAS to
the AAA server.  The 'light' part of the Lightweight reauthentication
is that the full key exchange (which requires somewhat expensive
modular arithmetic) is not required by the entities performing the
SRP-SHA1 authentication.

Now, it's certainly true that if the AAA server passes the session key
to the NAS (for use with ECP), then the NAS *could* handle the
Lightweight reauthentication without bothering to pass the messages to
the AAA server.  That's not described by the draft, and is something
I'd view as merely a local optimization.  In other words, if the NAS
*wants* to snoop in on the EAP exchange and optimize it in a way
that's still compatible with the externally visible behavior described
by the documents, then I'd certainly not stand in the way of that.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 5 Feb 2002 16:02:05 -0500

Hello James,

> for multiaccess networks that don't have point-to-point semantics.

I tend to agree with you on the last paragraph.  Maybe it would be
better to remove section 3.1, provided that explicit and clear problem
statement is described in section 2 with including that "PPP ought not
be part of the solution space for multiaccess networks that don't have
point-to-point semantics".

> applications, not IP addresses and links.

I think this section describes GPRS-specific local convention for PPP, 
not generic things for authentication of the link.

> by the documents, then I'd certainly not stand in the way of that.

Now I understand what's the magic in EAP SRP.  I'll add some text
mentioning that some EAP mechanism has a built-in mechanism to support
local re-authentication.

Thanks,
Yoshihiro Ohba

---

From: James Carlson <[email-masked]>
Date: Tue, 5 Feb 2002 17:22:57 -0500 (EST)

> point-to-point semantics".

I think that's getting a lot closer to the answer.  I don't think that
the language I used there is exactly what one wants to see in a
requirements document, but it's at least closer.  I think it should
simply state that the target PANA environment is multiaccess networks
(not point-to-point networks), and thus any solution needs to work
well in such an environment.

> not generic things for authentication of the link.

I think that what I wrote still holds: the PPP authentication in GPRS
authenticates the link itself.  Yes, I realize that the service
providers "think" that the user name provided actually corresponds to
a human.  There is, however, still no reason to suspect that this is
generally the case or that it really has any bearing on PANA.

For a counterexample, suppose we had both "mode 2" (as you describe;
the MT alone) GPRS PPP authentication and PANA authentication.  What
would happen?  Would PANA be used to authenticate the "user?"  Why?
Didn't the authentication of the MT achieve that?  Now suppose "mode
1" is used.  Does the network still demand PANA even though the user
has already been authenticated as part of PPP?  If not, then how is
the difference between the two managed?

I find this notion very hard to understand.  Once you've authenticated
the link by any means (e.g., talking to a human who has the wires in
his hands), what more authentication of the link would you care to do?
It seems that once you've done this, the next logical abstraction
takes place well above the network and datalink layers; it's in IPsec
certificates, ssh passwords, and the like.

Is one of the desires behind PANA the ability to somehow "enforce" the
notion that there's one (and only one) responsible (and live and
immediately available) human behind every IP link?  In my opinion,
that would seem like generally bad idea.  I think that a reasonable
goal for PANA is merely to authenticate the identity of a newly-
attached node on a network.  Users and other such issues should be
problems dealt with by other means.

In other words, I think PANA should fill exactly the hole left between
Mobile IP and PPP: authentication of nodes to attach to regular IP
networks.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 5 Feb 2002 18:49:20 -0500

Hello Jacques, 

> Might be good to change both :-) Device seems just way too generic to me.

What do other people think?

> Some additional comments, on section 2:

Anyway, I'll revise this section to reflect comments from you
and James.

[...]

> classification that makes sense.

NAS part describes generic sceanrios that would apply to all L2
technologies.  Each of other parts describes special scenarios that
are related to a specific L2 technology or characteristics.

OK.

> - or some specific requirements for PANA that are achieved by PPP and need 

Following James' comment, I'll remove this section unless there is
strong objection.

> Also, would the "edge server" be the first L2 device, or the first L3 

I mean it is an L3 device (i.e., PAA) in the local network.

[...]

> different VLAN depending on the case (for APs that support 802.1Q VLAN 

I am aware of that scheme.  It seems to me that this is a layer
violation if the AP would need to either control with which IP subnet 
(or VLAN) the user's device is associated, or look through the
payload of MAC frames carrying user data.  It seems to me that 
using PANA for this case is much simpler than the above scheme.

> "free" things first, and then maybe move to "non-free" things. No reason 

I don't suppose that.

> for a better solution (which still needs quite some work, though).

That part relates to PANA for network access with finer granularity.
We recognize the NAT issue for network access based on PANA.

Application level AAA such as EAP over HTTP is out of the scope, I
believe.

[...]

OK.

> >But in the case of backup NAS, the device does not view the two NAS'es

I didn't say it should.  As I mentioned below PANA should broader cases.

[...]

> Quite, but then what's the point of the "integrated AP and AR" case above?

Since I mentioned "orthogonal", the "integrated AP and AR" case is also 
included and PANA should also cover that case.

> PANA, and I don't see how/why PANA is linked to it?

Even in the VRRP environment, the same consideration as described in
the draft is necessary for PANA if there is a possiblity that traffic
coming from and going to a specific device diverges among different
ARs as a result of ICMP Redirect or the use of "Default Router
Preferences and More-Specific Routes" in IPv6.

OK, thanks.

> remains anecdotal when compared to the "real" useful traffic.

Sorry, I'm not convinced since I don't hear such a need for end-to-end
re-authentication at least in the WECA WISPr committee in which 802.11
multi-ISP roaming is discussed.

> architectures that I doubt it will use the same PAA.

I believe that in the current GPRS/WLAN interworking discussion, 3GPP
operators want to also administrate WLAN AP, considering the fact that
it is actively discussed in 3GPP.

> used. I'm not sure how PANA actually helps in any way?

As I said in a previous mail, the "interface switching" scenario is
not directly related to mobility managenent protocol.  That's why we
separated them.  But I agree that we should make it clear in the
draft.

> PANA in the scenarios you describe in this section...

I don't think there is an existing working solution for this scenario.
So I don't understand your point.

> not easily meet the future needs is needed.

For intertechnology handoff, see section 3.4, for free and paid access, 
please see my comments above.

[...]

OK, thanks.

[...]

> provided the local network has direct or indirect roaming agreements with 

Even the same identifier is used, if re-authentication is performed
end-to-end and/or different re-authentication mechanisms are used for
different L2 technologies, it would increase signaling delay during
heterogenious handoff.  I don't have a good idea for how local
re-authentication is performed among different L2 authentication
mechanisms.  Hesham could comment more.

> what I remember from Diameter discussions, it is actually a new 

Could you give me a reference to that?

[...]

> VPNs are not very useful, TLS at the application level is).

That is a different issue.  The usage of IPsec here is similar to WEP/AES
in 802.11.  If you need addtitional security, then end-to-end like 
security would be needed anyway.

[...]

> This will make things much clearer...

I'll try to reflect your comments in the next version.

> Jacques.

I appreciate your detailed comments.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 5 Feb 2002 19:33:01 -0500

James,

On Tue, Feb 05, 2002 at 05:22:57PM -0500, James Carlson wrote:

[...]

> the difference between the two managed?

I think that the network still demands PANA even though an entity has
already been authenticated as part of PPP if we consider the
intra-domain inter-technology handoff scenario.

And I don't see any reason for prohibiting multiple levels of 
authentication (PPP and PANA) for different purposes.

The same thing could apply to DHCP authentication stuff.  I don't see
any reason for prohibiting multiple types of authentication (DHCP and
PANA) for different purposes.

> Mobile IP and PPP: authentication of nodes to attach to regular IP

I'm not convinced yet for the above reason.

Thanks,
Yoshihiro Ohba

---

From: James Carlson <[email-masked]>
Date: Wed, 6 Feb 2002 17:00:25 -0500 (EST)

> intra-domain inter-technology handoff scenario.

This gets into an area of the draft (section 3.4) that I don't fully
understand.  It's almost certainly the case that when one is switching
link technologies, one will have to acquire new network layer
addresses.  Otherwise, you end up with host routes injected into the
provider's tables to allow nodes to roam between the domains.  If this
is what you really wanted (rather than just plain old IP access), then
why wouldn't you just use Mobile IP (which comes with its own set of
authentication mechanisms and routing-like protocols)?

This looks like a scoping problem with PANA.  Why is PANA solving the
roaming problem?

Why is reauthentication when switching link technologies necessarily a
problem?  Is this known to be too expensive to support without some
sort of special PANA definitions?  Where is the data to support this
contention?

I agree that the technologies for authenticating the links need to
converge somewhat.  Running a subnetwork-dependent mechanism to
transport EAP, and then running standard AAA behind that would seem to
fix everything that is in need of fixing: the user's identity would be
as defined by the AAA service and the mechanism for the backend would
be the same in all cases.  What is the incremental benefit of using
another protocol to authenticate?

Which of these two things should PANA really address?

	1. Ethernet is a link layer with no authentication mechanism.

	2. All link layers should have the same authentication
           mechanism.

I would submit that (1) is a more pressing issue: there's no solution
here.  There are already authentication mechanisms for other link
layers; that's well and good and doesn't need to be resolved.

> authentication (PPP and PANA) for different purposes.

That path doesn't make sense to me.  I don't believe that we should be
inventing new levels of problems to solve *unless* someone has an
identifiable deployment that doesn't work without these new levels.
Instead, I think we should stick with known problems for which there
are no workable solutions.

In other words, I don't follow the derivation of the requirement: what
is the canonical description of "authenticating a user to the network"
versus "authenticating the link?"

> PANA) for different purposes.

Again, the point is stating the fundamental requirements: in order to
have a requirement, there really needs to be a demonstrable *need*.
I'm still having a hard time seeing that need.

There are all sorts of interesting things that one could (and might)
do.  We should not attempt to do all of them: if we build it, they
might not come ...

> I'm not convinced yet for the above reason.

Nor am I convinced.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 6 Feb 2002 18:24:45 -0500

James,

> authentication mechanisms and routing-like protocols)?

Mobile IPv6 does not have AAA extention.  Mobile IPv4 with co-located
Care-of Address mode does not, too.  One could define AAA extention
for them like Mobile IPv4 Foreign Agent Care-of Address mode does,
however, why should we invent the same wheel for each protocol?
Instead, modular approach in which AAA authentication functionality is
realized in a separated protocol (i.e., PANA) is much better.

> This looks like a scoping problem with PANA.  Why is PANA solving the

The charter also mentioned:

  The WG will not directly work on solutions relating to mobility of
  the device.  However, it is noted that the ability to
  re-authenticate locally with the PAA, can be an important element in
  allowing efficient handling of mobile devices.

> sort of special PANA definitions?  Where is the data to support this

I think Hesham's comment already answer the first two questions and I
believe that's enough.

> 	1. Ethernet is a link layer with no authentication mechanism.

Ethernet has 802.1X authentication mechanism at L2.

> 	2. All link layers should have the same authentication

All link layers should have the same authentication mechanism at L3 in
order to realize the scenarios described in the usage scenarios I-D,
regardless of what kind of L2 authentication mechanisms are used.

> versus "authenticating the link?"

As a result of long discussion on "user authentication vs. device
authentication" among the requirements team, we realized that none of
two does not reflect the real aspects.  In the case of PANA,
"authenticating the link" would also be inappropriate considering
multi-access networks.  So it only says "PANA MUST authenticate a PaC
for network access".

> do.  We should not attempt to do all of them: if we build it, they

I strongly believe they will come, and that's why this WG was
created....   

Thanks,
Yoshihiro Ohba

---

From: Jacques Caron <[email-masked]>
Date: Thu, 07 Feb 2002 22:31:03 +0100

Hi Yoshihiro,

>however, why should we invent the same wheel for each protocol?

Not the same wheel. The wheel is EAP, it's been invented, it's fine, let's 
use it. The only thing to do is add a way to encapsulate it within the 
startup phase of the protocol.

>realized in a separated protocol (i.e., PANA) is much better.

Easier, certainly. Better, I'm not convinced. I foresee immense security 
issues. An authentication mechanism within the startup phase of a protocol 
is pretty much OK, since it's part of an exchange involving only two 
devices: the client, and the NAS/AP/switch/whatever. A L3 protocol opens 
the door to numerous attacks from remote devices, so it will be necessary 
to add some safeguards that will require some quite intensive security work.

>regardless of what kind of L2 authentication mechanisms are used.

What scenarios are there that still stand and which are not implementable 
with existing L2 authentication mechanisms?

Jacques.

---

From: Jacques Caron <[email-masked]>
Date: Thu, 07 Feb 2002 22:38:23 +0100

>         1. Ethernet is a link layer with no authentication mechanism.

As Yoshihiro pointed out, Ethernet has an authentication mechanism, which 
is 802.1x. The only issue I see with 802.1x is that it often requires 
low-level integration (firmware, driver, OS, switches, APs...), so it might 
take some time before it becomes widely deployed.

Hence my view that PANA (in my opinion, PANA would just be EAP/UDP) is only 
an interim measure: it's very easy to port to any device (it's 100% 
userland using only very standard TCP/IP), but it might have security 
implications (which would probably require at the minimum some limitation 
of the devices that can talk to each other).

There might be other cases where PANA can serve as an interim measure until 
better mechanisms are deployed (e.g. EAP over HTTP), but there, even more 
than security, transparency to intermediate devices (NAT boxes, proxies...) 
is an issue.

Jacques.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 7 Feb 2002 17:44:00 -0500

Hello Jacques,

> startup phase of the protocol.

You can try to propose it to the Mobile IP WG.

> to add some safeguards that will require some quite intensive security work.

That's why the charter states:

  - Chosen approach for handling the security issues and which
  existing security mechanisms that are chosen for the protocol. (in
  framework draft)

> with existing L2 authentication mechanisms?

I have already answered within this thread.  Please make more specific
questions after carefully analyzing this thread.  

Thanks,
Yoshihiro Ohba

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 08 Feb 2002 10:19:57 +0100

Jacques Caron <[email-masked]> writes:

> As Yoshihiro pointed out, Ethernet has an authentication mechanism,
> which is 802.1x. The only issue I see with 802.1x is that it often
> requires low-level integration (firmware, driver, OS, switches,
> APs...), so it might take some time before it becomes widely deployed.

This brings up something I have been thinking about:

How is PANA intended to interact with link-level-specific
authentication mechanisms, such as IEEE 802.1x?  Will PANA define data
structures used to perform context transfers for inter-technology
handoff?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 12 Feb 2002 21:07:23 -0500

> to clean up their implementations is the right way to go.

Regarding re-authentcation in PPP, there is a statement in RFC1661:

---------------------------------
3.5.  Authentication Phase

[...]

   Only Link Control Protocol, authentication protocol, and link quality
   monitoring packets are allowed during this phase.  All other packets
   received during this phase MUST be silently discarded.

So I don't think PPP re-authentication is possible without temporal
communication disruption.  On the other hand, 802.1X seems to allow an
authorization state to remain during re-authentication without
temporal communication disruption.  Please correct me if I'm wrong.

Yoshihiro Ohba

---

From: James Carlson <[email-masked]>
Date: Wed, 13 Feb 2002 06:28:13 -0500 (EST)

> Regarding re-authentcation in PPP, there is a statement in RFC1661:

Read RFC 1994 for reauthentication in CHAP.  Read RFC 2284 for EAP.

For reauthentication in PAP, it's a simple matter of using the
'restart option' on Open; see page 17 of RFC 1661 and (for PAP itself)
RFC 1334.

The point I was making is that PPP the *protocol* most certainly does
allow reauthentication.  However, some very common implementations do
not -- they respond to LCP renegotiation by dropping the link.

I can also recommend a book ...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 13 Feb 2002 08:20:34 -0500

> I can also recommend a book ...

OK.  I also found in RFC1661 stating that LCP packets are accepted in
NLP phase.  So it is valid that re-authentication is performed without
necessarily going back to Authentication phase (i.e., the
Authentication phase would be visited only during initial
authentication).

Thanks,
Yoshihiro Ohba