Subject: RE: Solutions ...

From: George Tsirtsis <[email-masked]>
Date: Tue, 22 Jan 2002 14:55:19 -0500

James,

I think there are two very different issues here.

1. Authentication transport protocol which can optionally accommodate
session key agreement

2. Secured Neighbor Discovery.

I think (1) is well defined in PANA so far and we have a chance to do
something useful given the mix of people involved in this work. If you are
thinking along the same lines forget the rest of the e-mail.

(2) is a much harder problem that IPv6 WG has avoided for some time now
despite its expertise and I do not see what PANA WG will be able to offer
here, unless all people from IPv6 WG get involved. IMO IPv6 WG should take
up this work or a different WG should be created to look at this
fundamentally hard problem if there is enough real interest.  PANA has a
well defined problem that is IP version independent and should not get
confused by more adventurous tasks.

My 2 (now obsolete) drachmas

George

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Tuesday, January 22, 2002 6:45 PM
To: Erik Nordmark; Patil Basavaraj (NET/Dallas)
Cc: 'Erik Nordmark'; Pekka Nikander; [email-masked]
Subject: Re: Solutions ...

Erik/Raj,

> > But can or should PANA be considered as an enabler for securing the
> > traffic over the last hop? What I mean here is that PANA could
enable
> > exchange of keys (securely) which could be used to setup a Local
> > Security Association (LSA beteween client and AP or AR) and any
> > traffic sent over this LSA would be at least secured over the last
> > hop.
>
> That is a good question.
> I don't think there is an obvious answer.
>
> I think 802.1X with 802.11 will be used to derive per-station keys for
WEP.
> Does that mean that PANA should be required to solve this type of
> problem in the general case as well?
> Does it imply that it is desired to do this in PANA?
>

I think this is a critical problem and it will be a gating issue
about whether public access wireless service providers deploy IPv6
networks
using Neighbor Discovery and/or DHCP, or whether they deploy
using PPP or some other way of rendering the last hop to look
like a point to point link. I personally think this problem
has more urgency than the last hop authentication problem,
since there are already L2 ways of dealing with last hop
authentication, and securing signaling on the last hop
currently has no solution.  The last hop authentication protocol that
PANA is
coming up is also a natural fit for solving this problem
in general.

Currently, I see no working group in IETF where this issue is
being addressed. One choice might be IPNG, but they seem
to have such a broad charter that it might simply get lost.

Therefore, I would support examining this issue in PANA.
There was also some feeling at the IPNG meeting in SLC
that solutions for IPv4 networks should be examined
as well. So the scope of any charter item (should we
choose to add it) needs to be discussed.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 22 Jan 2002 13:49:53 -0800

Hi George,

> confused by more adventurous tasks.

OK fair enough.

However, as was pointed out by a number of people in SLC, 1) is not
a particularly pressing issue since it can and is handled today at L2
by a variety of mechanisms. So PANA is more kind of a futures
sort of thing. How many people are planning on doing PANA
products withing the next 2 years?

Whereas for 2), it is an issue that is pretty urgent if wireless ISPs
(such as DoCoMo) can deploy reliable wireless IPv6 service on 802.11
and want to be able to utilize the full  spectrum of IP multi-access
link support. And, just because 2) is a hard problem,
isn't any reason not to do it.

            jak

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 22 Jan 2002 13:56:54 -0800

> confused by more adventurous tasks.

The problem of securing network access in not limited to
neighbor discovery. It involves securing router discovery, and
neighbor discovery in IPv6, and address resolution in IPv4. The
problem is not even specific to IPv6, same applies to IPv4.

I agree this is a harder problem to solve, and currently
outside the scope of PANA. And I think we should keep
it separate. PANA is not meant to solve all the issues
related to "secure network access." It deals with solving the
must-fix problem of authenticating the clients. Once we
have the PANA, we can see it may provide sufficient hooks
(key distribution, etc.) to help solving this other problem as well.
Once current charter is completed, depending on the solution
at hand and what else is needed we might either not need anything
else, re-charter the WG or create a new WG. i think this is better
than expanding the charter at this point.

my 0.02 cents.

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 22 Jan 2002 17:08:08 -0500

I 100% agree with Alper.

Yoshihiro Ohba

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 23 Jan 2002 14:43:41 +0100 (CET)

> 2. Secured Neighbor Discovery.

To be more specific I'd actually like to separate 2 into
2a. Secured Host-Router interaction in Neighbor Discovery
2b. Secured Host-to-Host interaction in Neighbor Discovery

The issues in authenticating and authorizing a router might be rather
different than AA'ing a host.

  Erik

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 23 Jan 2002 12:43:01 -0800 (PST)

Hello,

I understand that this issue was discussed some time
on this list, but since the subject arose on the
design team, I would like to post some comments here
to hear some feedback.

1)

NAT, proxies, etc are out there we like it or not. 

I believe (but can be convinced otherswise) that not
dealing with this issue might limit the applicability
of PANA. sometimes you can have several PANA clients
behind a NAPT or Proxy, which will make identification
difficult to happen. 

Several groups are working to make SIP, IPsec, etc
work through NAT/NAPT, saying that PANA will not deal
with seems like living in denial, but again, since
this is rough consensus I leave the decision to the
list. 

My position is that we should not say that PANA will
not work in these kind of environments but make the
requirements/protocol flexible enough so it can. Then
somebody can write a draft/ extension to make it work.

2)

A similar issue is that I advocate that the
identification of the device (IP address, MAC address,
etc) that the client is using should be carried in
PANA protocol if needed. My argument is that in the
current Internet we cannot assume that a packet will
arrive untouched on the PAA server so that you can
infer the MAC/IP address from the packet itself. 
There are NAT, NAPT, Proxies, VPNs, all kinds of
tunneling, etc out there.

Since this is rough consensus I'll not bring this
issue again if people say that there are not
NAT/proxies out there and/or we should provide
flexibility in the protocol to deal with them.

regards,

Reinaldo 

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/