From pana-request@research.telcordia.com Wed Apr 2 15:34:02 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08132 for ; Wed, 2 Apr 2003 15:34:02 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h32KW4Ln024792; Wed, 2 Apr 2003 15:32:04 -0500 (EST) Resent-Date: Wed, 2 Apr 2003 15:32:04 -0500 (EST) Old-Return-Path: Date: Wed, 02 Apr 2003 12:31:14 -0800 Subject: Re: [PANA] the case of mutiple authentications during a single PANA authentication phase From: Alper Yegin To: MORAND Lionel FTRD/DAC/ISS , , , CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3132131475_3318116" X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3132131475_3318116 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable How about this text: "Some access networks might require or allow their clients to get authenticated and authorized by the NAP and ISP before the clients gain network access. PANA must be capable of enabling two independent authentication operations (i.e., execution of two separate EAP methods) for the same client. Determining the authorization parameters as a result of tw= o separate authentications is an operational issue and therefore it is outsid= e the scope of PANA." We still need the definitions of NAP and ISP... alper On 3/27/03 11:36 AM, "MORAND Lionel FTRD/DAC/ISS" wrote: > Hi Basavaraj, > =20 > Some weeks ago, we had a discussion on this subject. One of the scenarios > requiring NAP-ISP authentications in the same PANA authentication session > could be a NAP offering specific access configurations and local services= to > subscribed users accessing to value-added IP services provided by an ISP.= In > this case, the PAA may need to wait for the response of the ISP before > determining the right handling of the access request (and the enforcement= of > the access control at the EP). For instance, a negative response from the= ISP > would limit the access network to a default access configuration and basi= c > services. Distinct PAA sessions (one for NAP, another for ISP) would > complicate the network policy (even if this point is outside the scope of > PANA). > =20 > In the PS (section 2), the misunderstanding is maybe due to the fact that= the > end of the paragraph dealing with the NAP-ISP distinction only considers = the > case of link-layer authentication for the NAP (even if the "if" indicates= that > it is only one possibility). > It is right that a link-layer authentication is often used for specific a= ccess > configurations (e.g. in mobile networks). However, for scenarios in which= a > link-layer authentication mechanism is not available, the NAP could use P= ANA > at the network-layer for the same purpose. > =20 > Considering the PANA proposal, it is stated that current solution support= s > multiple EAP authentications in the same PANA authentication phase. It is= why > I use the term MUST (maybe wrongly). I don't know how will be understood = a > SHOULD or a MAY in this case. > =20 > My strong feeling is that, if the NAP-ISP scenario is clearly identified = and > EAP makes it possible, the MUST in the requirement draft wouldn't be a re= al > constraint. > Saying that PANA must support it, even if it is an optional function of t= he > PAA, seems to be coherent with both PS and solution drafts. But I'm open = to > another view. > =20 > Cheers, > =20 > Lionel > =20 > =20 >> -----Message d'origine----- >> De : Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >> Envoy=E9 : jeudi 27 mars 2003 18:24 >> =C0 : MORAND Lionel FTRD/DAC/ISS; alper@docomolabs-usa.com; >> yohba@tari.toshiba.com; rpenno@nortelnetworks.com >> Cc : pana@research.telcordia.com >> Objet : RE: [PANA] the case of mutiple authentications during a single P= ANA >> authentication phase >>=20 >> =20 >> Hi Lionel, >> =20 >> The PaC may be authenticated by the NAP (via PAA) for network access at >> which point in time the >> PAA authorizes the EP to allow network access for the client. >> Now why does the PAA have to wait for the ISP to authorize access as wel= l. I >> believe the two can >> be distinct operations. What the usage scenarios I-D is saying I believe= is >> that with PANA you >> could do multi-level authentications. But I do not believe it implies th= at >> the PAA has to corelate >> authorizations from different authorities (NAP, ISP) for enforcing acces= s >> control at the EP. >> =20 >> I do not believe that the requirement that you state below of "PANA MUST= be >> capable of supporting >> multiple ....." needs to be a MUST. In fact I think MAY is better suited= if >> at all we need something >> like it. For the scenario where multiple levels of authentication is >> required, would it not suffice >> to do these sequentially? >> =20 >> -Basavaraj >>> -----Original Message----- >>> From: ext MORAND Lionel FTRD/DAC/ISS >>> [mailto:lionel.morand@rd.francetelecom.com] >>> Sent: 27 March, 2003 03:49 AM >>> To: alper@docomolabs-usa.com; yohba@tari.toshiba.com; >>> rpenno@nortelnetworks.com >>> Cc: pana@research.telcordia.com >>> Subject: [PANA] the case of mutiple authentications during a single PAN= A >>> authentication phase >>>=20 >>> In the problem statement/usage scenarios draft as well as in the first = PANA >>> proposal, the case of multiple authentications during the same PANA ses= sion >>> is clearly identified, mainly to allow separate authentications at the = NAP >>> and ISP levels. However, this is not taken into account in the current = PANA >>> requirements draft. In order to align the three documents, we should ad= d the >>> case of multiple authentications into the section 4.1.1 "Authentication= of >>> client" of the PANA requirements draft. A simple wording could be: >>> =20 >>> "PANA MUST be capable of supporting multiple independent client's >>> authentications during a single PANA authentication phase." >>> =20 >>> I use the term "MUST" because this requirement is identified within the >>> problem statement draft and already supported by the current PANA propo= sal >>> (even if it is an optional functionality of the PAA). >>> =20 >>> As a consequence of the above requirement, a PAA may therefore need to = wait >>> for the results of two distinct client authentications before it can gr= ant >>> or deny access to network resources. This could be underlined in the fi= rst >>> paragraph of the section 4.1.2 "Authorization, Accounting and Access >>> Control". Here is a proposal: >>> =20 >>> "The binary authorization provided by PANA MAY be the result of multipl= e >>> independent client's authentications. In this case, the policy used for >>> determining the authorization result is outside the scope of PANA." >>> =20 >>> Does it sound acceptable? >>> =20 >>> BR, >>> =20 >>> Lionel. >=20 --B_3132131475_3318116 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [PANA] the case of mutiple authentications during a single PANA = authentication phase

How about this text:

"Some access networks might require or allow their clients to get
authenticated and authorized by the NAP and ISP before the  
clients gain network access. PANA must be capable of enabling two independe= nt
authentication operations (i.e., execution of two separate EAP methods) for=
the same client. Determining the authorization parameters as a result of tw= o
separate authentications is an operational issue and therefore it is outsid= e
the scope of PANA."

We still need the definitions of NAP and ISP...

alper






On 3/27/03 11:36 AM, "MORAND Lionel FTRD/DAC/ISS" <lionel.mora= nd@rd.francetelecom.com> wrote:

Hi Basavaraj,
Some weeks ago, we had a discussion on this subject. One of = the scenarios requiring NAP-ISP authentications in the same PANA authenticat= ion session could be a NAP offering specific access configurations and local= services to subscribed users accessing to value-added IP services provided = by an ISP. In this case, the PAA may need to wait for the response of the IS= P before determining the right handling of the access request (and the enfor= cement of the access control at the EP). For instance, a negative response f= rom the ISP would limit the access network to a default access configuration= and basic services. Distinct PAA sessions (one for NAP, another for ISP) wo= uld complicate the network policy (even if this point is outside the scope o= f PANA).
In the PS (section 2), the misunderstanding is maybe due to = the fact that the end of the paragraph dealing with the NAP-ISP distinction = only considers the case of link-layer authentication for the NAP (even if th= e "if" indicates that it is only one possibility).
It is right that a link-layer authentication is often used for specific acc= ess configurations (e.g. in mobile networks). However, for scenarios in whic= h a link-layer authentication mechanism is not available, the NAP could use = PANA at the network-layer for the same purpose.
Considering the PANA proposal, it is stated that current sol= ution supports multiple EAP authentications in the same PANA authentication = phase. It is why I use the term MUST (maybe wrongly). I don't know how will = be understood a SHOULD or a MAY in this case.
My strong feeling is that, if the NAP-ISP scenario is clearl= y identified and EAP makes it possible, the MUST in the requirement draft wo= uldn't be a real constraint.
Saying that PANA must support it, even if it is an optional function of the= PAA, seems to be coherent with both PS and solution drafts. But I'm open to= another view.
Cheers,
Lionel
 
-----Message d'origin= e-----
De : Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Envoyé : jeudi 27 mars 2003 18:24
À : MORAND Lionel FTRD/DAC/ISS; alper@docomolabs-usa.com; yoh= ba@tari.toshiba.com; rpenno@nortelnetworks.com
Cc : pana@research.telcordia.com
Objet : RE: [PANA] the case of mutiple authentications during a sing= le PANA authentication phase
Hi Lionel,
The PaC may be authenticated by the NAP  (via PAA) for = network access at which point in time the
PAA authorizes the EP to allow network access for the client.
Now why does the PAA have to wait for the ISP to authorize access as well. = I believe the two can
be distinct operations. What the usage scenarios I-D is saying I believe is= that with PANA you
could do multi-level authentications. But I do not believe it implies that = the PAA has to corelate
authorizations from different authorities (NAP, ISP) for enforcing access c= ontrol at the EP.
I do not believe that the requirement that you state below o= f "PANA MUST be capable of supporting
multiple ....." needs to be a MUST. In fact I think MAY is better suit= ed if at all we need something
like it. For the scenario where multiple levels of authentication is requir= ed, would it not suffice
to do these sequentially?
-Basavaraj
-----Original = Message-----
From: ext MORAND Lionel FTRD/DAC/ISS [mailto:lionel.morand@rd.france= telecom.com]
Sent: 27 March, 2003 03:49 AM
To: alper@docomolabs-usa.com; yohba@tari.toshiba.com; rpenno@norteln= etworks.com
Cc: pana@research.telcordia.com
Subject: [PANA] the case of mutiple authentications during a single = PANA authentication phase

In the problem statement/usage scenarios dr= aft as well as in the first PANA proposal, the case of multiple authenticati= ons during the same PANA session is clearly identified, mainly to allow sepa= rate authentications at the NAP and ISP levels. However, this is not taken i= nto account in the current PANA requirements draft. In order to align the th= ree documents, we should add the case of multiple authentications into the s= ection 4.1.1 "Authentication of client" of the PANA requirements d= raft. A simple wording could be:
 
"PANA MUST be capable of supporting multiple independent client's auth= entications during a single PANA authentication phase."
 
I use the term "MUST" because this requirement is identifi= ed within the problem statement draft and already supported by the current P= ANA proposal (even if it is an optional functionality of the PAA).
 
As a consequence of the above requirement, a PAA may therefore need to wait= for the results of two distinct client authentications before it can grant = or deny access to network resources. This could be underlined in the first p= aragraph of the section 4.1.2 "Authorization, Accounting and Access Con= trol". Here is a proposal:
 
"The binary authorization provided by PANA MAY be the result of multip= le independent client's authentications. In this case, the policy used for d= etermining the authorization result is outside the scope of PANA."
 
Does it sound acceptable?
 
BR,
 
Lionel.


 --B_3132131475_3318116-- From pana-request@research.telcordia.com Thu Apr 3 17:38:06 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17576 for ; Thu, 3 Apr 2003 17:38:06 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h33MbNKs004253; Thu, 3 Apr 2003 17:37:23 -0500 (EST) Resent-Date: Thu, 3 Apr 2003 17:37:23 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FA31.85BF49A8" Subject: RE: [PANA] the case of mutiple authentications during a singlePANA authentication phase Date: Thu, 3 Apr 2003 16:36:52 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF440175326E@daebe007.americas.nokia.com> Thread-Topic: [PANA] the case of mutiple authentications during a singlePANA authentication phase Thread-Index: AcL5VsyMooec06/mS3mabyhmFtEMWwA2qPfg From: To: , , , Cc: X-OriginalArrivalTime: 03 Apr 2003 22:36:53.0115 (UTC) FILETIME=[862BBCB0:01C2FA31] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is a multi-part message in MIME format. ------_=_NextPart_001_01C2FA31.85BF49A8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I can live with this as being a requirement for PANA in the requirements = I-D. =20 -Basavaraj How about this text: "Some access networks might require or allow their clients to get authenticated and authorized by the NAP and ISP before the =20 clients gain network access. PANA must be capable of enabling two = independent authentication operations (i.e., execution of two separate EAP methods) = for the same client. Determining the authorization parameters as a result of = two separate authentications is an operational issue and therefore it is = outside the scope of PANA." We still need the definitions of NAP and ISP...=20 alper ------_=_NextPart_001_01C2FA31.85BF49A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [PANA] the case of mutiple authentications during a single = PANA authentication phase
I can=20 live with this as being a requirement for PANA in the requirements=20 I-D.
 
-Basavaraj


How about this text:

"Some access = networks might=20 require or allow their clients to get
authenticated and authorized = by the=20 NAP and ISP before the  
clients gain network access. PANA = must be=20 capable of enabling two independent
authentication operations = (i.e.,=20 execution of two separate EAP methods) for
the same client. = Determining the=20 authorization parameters as a result of two
separate = authentications is an=20 operational issue and therefore it is outside
the scope of = PANA."

We=20 still need the definitions of NAP and ISP...=20

alper

 ------_=_NextPart_001_01C2FA31.85BF49A8-- From pana-request@research.telcordia.com Wed Apr 9 09:40:43 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27494 for ; Wed, 9 Apr 2003 09:40:24 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h39Db2SZ016830; Wed, 9 Apr 2003 09:37:02 -0400 (EDT) Resent-Date: Wed, 9 Apr 2003 09:37:02 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2FE9C.81B04BF8" Subject: Proposal for message formatting (sec. 9). Date: Wed, 9 Apr 2003 16:32:46 +0300 Message-ID: X-MS-Has-Attach: yes Thread-Topic: Proposal for message formatting (sec. 9). Thread-Index: AcL+nIGc0y0ae0ehQBWbUYFA508tkg== From: To: X-OriginalArrivalTime: 09 Apr 2003 13:32:46.0730 (UTC) FILETIME=[81E336A0:01C2FE9C] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is a multi-part message in MIME format. ------_=_NextPart_001_01C2FE9C.81B04BF8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Attached you can find a proposal section (9 Message Formats)=20 for the draft-ietf-pana-pana-00.txt. It contains some changes=20 that affect the whole draft. There are no error messages defined, which I think should be=20 fixed. This is not only a message format issue, but a protocol=20 issue. Changes to the pana draft in general: - Message naming convention changed (*_ack --> *-Answer,=20 * --> *-Request) to better reflect the Diameter style and the nature of the protocol: answers contain data,=20 but for acks it is not so clear. Requests and answers describe better the protocol.=20 - Thus, 2 messages instead of 1: - PANA-Auth-Request & PANA-Auth-Answer. PAA always sends PANA-Auth-Request and requires an answer to it. - PANA-Start-Request & PANA-Start-Answer. PANA-Start messages are different depending on the sender. - PANA-Success-Request/Answer: PANA requires answer to success, because he PANA SA is not otherwise established properly.=20 And for sake of simplicity, the same naming convention=20 should be used. - Flag change: A flag to R flag to better reflect Diameter style. Requests have the R flag set, answers unset. - Name change: Data-Protection --> Protection-Capability.=20 Data-Protection is misleading term. - Name change: Revocation-Status --> Termination-Cause (Diameter). There is already an AVP that suits for this purpose. - PANA-Disconnect-Request now contains Termination-Cause AVP. There are different reasons for the user to disconnect. Comments welcome, - Dan ------_=_NextPart_001_01C2FE9C.81B04BF8 Content-Type: text/plain; name="draft-ietf-pana-pana-00-sec9.txt" Content-Description: draft-ietf-pana-pana-00-sec9.txt Content-Disposition: attachment; filename="draft-ietf-pana-pana-00-sec9.txt" Content-Transfer-Encoding: base64 OSAgTWVzc2FnZSBGb3JtYXQKCiAgIFRoaXMgc2VjdGlvbiBkZWZpbmVzIG1lc3NhZ2UgZm9ybWF0 cyBmb3IgUEFOQSBwcm90b2NvbC4gIFBBTkEgd2FudHMKICAgdG8gcmV1c2UgZXhpc3RpbmcgcHJv dG9jb2xzIGFzIG11Y2ggYXMgcG9zc2libGUuICBEaWFtZXRlciBtZXNzYWdlCiAgIGZvcm1hdCBp cyBjaG9zZW4gYXMgdGhlIGJhc2UgZm9yIFBBTkEgcHJvdG9jb2wgbWVzc2FnZXMsIGJlY2F1c2Ug aXQKICAgdXNlcyBBVlBzIGFuZCBpbiBjYXNlIG9mIERpYW1ldGVyL1JBRElVUyBiYWNrZW5kIHRo ZSBtZXNzYWdlCiAgIHBhcnNpbmcgY2FwYWJpbGl0aWVzIGNhbiBiZSByZXVzZWQgaW4gdGhlIFBB QS4gIEFsc28sIGlmIHRoZSBFQVAKICAgU2VydmVyIGlzIG5vdCBsb2NhdGVkIGluIHRoZSBQQUEs IHRoZSByZXVzZSBvZiBFQVAtUGF5bG9hZCBBVlAKICAgbWFrZXMgZm9yd2FyZGluZyBmb3IgUEFB IHNpbXBsZXIuIFNlc3Npb24tSUQgQVZQIGlzIHVzZWQgYmVjYXVzZSBpdAogICBjYW4gYmUgdGhl IHNhbWUgYXMgaW4gdGhlIEFBQSBiYWNrZW5kIGFuZCB0aHVzIHNpbXBsaWZpZXMgdGhlCiAgIG92 ZXJhbGwgYXJjaGl0ZWN0dXJlLgoKCjkuMSAgUEFOQSBIZWFkZXIKCiAgIEEgc3VtbWFyeSBvZiB0 aGUgUEFOQSBoZWFkZXIgZm9ybWF0IGlzIHNob3duIGJlbG93LiAgVGhlIGZpZWxkcyBhcmUKICAg dHJhbnNtaXR0ZWQgaW4gbmV0d29yayBieXRlIG9yZGVyLgoKICAgICAgIDAgICAgICAgICAgICAg ICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgICAgIDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgIFZlcnNpb24gICAgfCAgICAgICAgICAgICAg ICAgTWVzc2FnZSBMZW5ndGggICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8 ICAgIEZsYWdzICAgICAgfCAgICAgICAgICAgICAgICAgTWVzc2FnZSBUeXBlICAgICAgICAgICAg ICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICAgICAgICAgICAgICAgIEFwcGxpY2F0 aW9uLUlEICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAg ICB8ICAgICAgICAgICAgICAgICBUcmFuc21pdHRlZCBTZXF1ZW5jZSBOdW1iZXIgICAgICAgICAg ICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICAgICAgICAgICAgICBSZWNlaXZl ZCBTZXF1ZW5jZSBOdW1iZXIgICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwog ICAgICB8ICBBVlBzIC4uLgogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLQoKICAgVmVy c2lvbgoKICAgICAgVGhpcyBWZXJzaW9uIGZpZWxkIE1VU1QgYmUgc2V0IHRvIDEgdG8gaW5kaWNh dGUgUEFOQSBWZXJzaW9uIDEuCgogICBNZXNzYWdlIExlbmd0aAoKICAgICAgVGhlIE1lc3NhZ2Ug TGVuZ3RoIGZpZWxkIGlzIHRocmVlIG9jdGV0cyBhbmQgaW5kaWNhdGVzIHRoZQogICAgICBsZW5n dGggb2YgdGhlIFBBTkEgbWVzc2FnZSBpbmNsdWRpbmcgdGhlIGhlYWRlciBmaWVsZHMuCgogICBG bGFncwoKICAgICAgVGhlIEZsYWdzIGZpZWxkIGlzIGVpZ2h0IGJpdHMuICBUaGUgZm9sbG93aW5n IGJpdHMgYXJlIGFzc2lnbmVkOgoKICAgICAgIDAgMSAyIDMgNCA1IDYgNwogICAgICArLSstKy0r LSstKy0rLSstKwogICAgICB8UiByIHIgciBGIHIgciByfAogICAgICArLSstKy0rLSstKy0rLSst KwoKICAgICAgICAgUihlcXVlc3QpICAgCgogICAgICAgICAgICAgICAgICAgICAtIElmIHNldCwg dGhlIG1lc3NhZ2UgaXMgYSByZXF1ZXN0LiBJZiBjbGVhcmVkLAogICAgICAgICAgICAgICAgICAg ICAgIHRoZSBtZXNzYWdlIGlzIGFuIGFuc3dlci4KCiAgICAgICAgIEYoaW5pc2gpICAgIAogICAg ICAgICAgICAgICAgICAgICAtIEYtZmxhZyBpbiB0aGUgUEFOQSBoZWFkZXIgaW5kaWNhdGVzIGlm IHRoaXMgd2FzCiAgICAgICAgICAgICAgICAgICAgICAgdGhlIGZpbmFsIGF1dGhlbnRpY2F0aW9u IGZyb20gc2VuZGVyJ3MKICAgICAgICAgICAgICAgICAgICAgICBwZXJzcGVjdGl2ZS4gIElmIFBB QSBlbmFibGVzIHR3byBzZXBhcmF0ZQogICAgICAgICAgICAgICAgICAgICAgIGF1dGhlbnRpY2F0 aW9uLCBpdCBzaG91bGQgbm90IHNldCBGLWZsYWcgaW4gdGhlCiAgICAgICAgICAgICAgICAgICAg ICAgUEFOQV9zdWNjZXNzIG9yIFBBTkFfZmFpbHVyZSBtZXNzYWdlIGFmdGVyIHRoZQogICAgICAg ICAgICAgICAgICAgICAgIGZpcnN0IEVBUCBtZXRob2QuCgogICAgICAgICByKGVzZXJ2ZWQpICAK CiAgICAgICAgICAgICAgICAgICAgIC0gdGhlc2UgZmxhZyBiaXRzIGFyZSByZXNlcnZlZCBmb3Ig ZnV0dXJlIHVzZSwKICAgICAgICAgICAgICAgICAgICAgICBhbmQgTVVTVCBiZSBzZXQgdG8gemVy bywgYW5kIGlnbm9yZWQgYnkgdGhlCiAgICAgICAgICAgICAgICAgICAgICAgcmVjZWl2ZXIuCgoK ICAgTWVzc2FnZSBUeXBlCgogICAgICBUaGUgTWVzc2FnZSBUeXBlIGZpZWxkIGlzIHRocmVlIG9j dGV0cywgYW5kIGlzIHVzZWQgaW4gb3JkZXIgdG8KICAgICAgY29tbXVuaWNhdGUgdGhlIG1lc3Nh Z2UgdHlwZSB3aXRoIHRoZSBtZXNzYWdlLiAgVGhlIDI0LWJpdAogICAgICBhZGRyZXNzIHNwYWNl IGlzIG1hbmFnZWQgYnkgSUFOQS4KCiAgIEFwcGxpY2F0aW9uLUlECgogICAgICBBcHBsaWNhdGlv bi1JRCBpcyBmb3VyIG9jdGV0cyBhbmQgaXMgdXNlZCB0byBpZGVudGlmeSB0byB3aGljaAogICAg ICBhcHBsaWNhdGlvbiB0aGUgbWVzc2FnZSBpcyBhcHBsaWNhYmxlIGZvci4gIFRoZSBBcHBsaWNh dGlvbi1JRAogICAgICBmb3IgUEFOQSBpcyA8VEJEPi4KCiAgIFRyYW5zbWl0dGVkIFNlcXVlbmNl IE51bWJlcgoKICAgICAgVGhlIFRyYW5zbWl0dGVkIFNlcXVlbmNlIE51bWJlciBmaWVsZCBjb250 YWlucyB0aGUgbW9ub3RvbmljYWxseQogICAgICBpbmNyZWFzaW5nIDMyIGJpdCBzZXF1ZW5jZSBu dW1iZXIgdGhhdCB0aGUgbWVzc2FnZSBzZW5kZXIKICAgICAgaW5jcmVtZW50cyBldmVyeSB0aW1l IGEgbmV3IHBhY2tldCBpcyBzZW50LgoKICAgUmVjZWl2ZWQgU2VxdWVuY2UgTnVtYmVyCgogICAg ICBUaGUgUmVjZWl2ZWQgU2VxdWVuY2UgTnVtYmVyIGZpZWxkIGNvbnRhaW5zIHRoZSAzMiBiaXQK ICAgICAgdHJhbnNtaXR0ZWQgc2VxdWVuY2UgbnVtYmVyIHRoYXQgdGhlIHBlZXIgaGFzIGxhc3Qg cmVjZWl2ZWQuCgogICBBVlBzCgogICAgICBBVlBzIGFyZSBhIG1ldGhvZCBvZiBlbmNhcHN1bGF0 aW5nIGluZm9ybWF0aW9uIHJlbGV2YW50IHRvIHRoZQogICAgICBQQU5BIG1lc3NhZ2UuICBTZWUg c2VjdGlvbiA8VEJEPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBBVlBzLgoKCjkuMiAgQVZQIEhl YWRlcgoKICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAg ICAgICAgICAgICAgICAgIDMKICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgQVZQIENvZGUgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgQVZQIEZsYWdzICAgfCAgICAgICAgICAgICAg ICAgIEFWUCBMZW5ndGggICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgIFZlbmRvci1JZCAob3B0KSAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgIERhdGEgLi4uCiAgICAgICstKy0rLSst Ky0rLSstKy0rCgoKICAgQVZQIENvZGUKCiAgICAgIFRoZSBBVlAgQ29kZSwgY29tYmluZWQgd2l0 aCB0aGUgVmVuZG9yLUlkIGZpZWxkLCBpZGVudGlmaWVzIHRoZQogICAgICBhdHRyaWJ1dGUgdW5p cXVlbHkuIEFWUCBudW1iZXJzIGFyZSBhbGxvY2F0ZWQgYnkgSUFOQS4KCiAgIEFWUCBGbGFncwoK ICAgICAgVGhlIEFWUCBGbGFncyBmaWVsZCBpcyBlaWdodCBiaXRzLiAgVGhlIGZvbGxvd2luZyBi aXRzIGFyZQogICAgICBhc3NpZ25lZDoKCiAgICAgICAwIDEgMiAzIDQgNSA2IDcKICAgICAgKy0r LSstKy0rLSstKy0rLSsKICAgICAgfFYgTSByIHIgciByIHIgcnwKICAgICAgKy0rLSstKy0rLSst Ky0rLSsKCiAgICAgICAgIE0oYW5kYXRvcnkpIAoKICAgICAgICAgICAgICAgICAgICAgLSBUaGUg J00nIEJpdCwga25vd24gYXMgdGhlIE1hbmRhdG9yeSBiaXQsCgkgICAgICAgICAgICAgICBpbmRp Y2F0ZXMgd2hldGhlciBzdXBwb3J0IG9mIHRoZSBBVlAgaXMKCSAgICAgICAgICAgICAgIHJlcXVp cmVkLgoKICAgICAgICAgVihlbmRvcikgICAgCgogICAgICAgICAgICAgICAgICAgICAtIFRoZSAn VicgYml0LCBrbm93biBhcyB0aGUgVmVuZG9yLVNwZWNpZmljIGJpdCwKICAgICAgICAgICAgICAg ICAgICAgICBpbmRpY2F0ZXMgd2hldGhlciB0aGUgb3B0aW9uYWwgVmVuZG9yLUlEIGZpZWxkCiAg ICAgICAgICAgICAgICAgICAgICAgaXMgcHJlc2VudCBpbiB0aGUgQVZQIGhlYWRlci4KCiAgICAg ICAgIHIoZXNlcnZlZCkgIAoKICAgICAgICAgICAgICAgICAgICAgLSB0aGVzZSBmbGFnIGJpdHMg YXJlIHJlc2VydmVkIGZvciBmdXR1cmUgdXNlLAogICAgICAgICAgICAgICAgICAgICAgIGFuZCBN VVNUIGJlIHNldCB0byB6ZXJvLCBhbmQgaWdub3JlZCBieSB0aGUKICAgICAgICAgICAgICAgICAg ICAgICByZWNlaXZlci4KCiAgIEFWUCBMZW5ndGgKCiAgICAgIFRoZSBBVlAgTGVuZ3RoIGZpZWxk IGlzIHRocmVlIG9jdGV0cywgYW5kIGluZGljYXRlcyB0aGUgbnVtYmVyCiAgICAgIG9mIG9jdGV0 cyBpbiB0aGlzIEFWUCBpbmNsdWRpbmcgdGhlIEFWUCBDb2RlLCBBVlAgTGVuZ3RoLCBBVlAKICAg ICAgRmxhZ3MsIGFuZCB0aGUgQVZQIGRhdGEuCgogICBWZW5kb3ItSWQKCiAgICAgIFRoZSBWZW5k b3ItSUQgZmllbGQgaXMgcHJlc2VudCBpZiB0aGUgJ1YnIGJpdCBpcyBzZXQgaW4gdGhlIEFWUAog ICAgICBGbGFncyBmaWVsZC4gVGhlIG9wdGlvbmFsIGZvdXItb2N0ZXQgVmVuZG9yLUlEIGZpZWxk IGNvbnRhaW5zCiAgICAgIHRoZSB1bmlxdWVseSBhc3NpZ25lZCA8VEJEPiBpZCB2YWx1ZSwgZW5j b2RlZCBpbiBuZXR3b3JrIGJ5dGUKICAgICAgb3JkZXIuICBBbnkgdmVuZG9yIHdpc2hpbmcgdG8g aW1wbGVtZW50IGEgdmVuZG9yLXNwZWNpZmljIFBBTkEKICAgICAgQVZQIE1VU1QgdXNlIHRoZWly IG93biBWZW5kb3ItSUQgYWxvbmcgd2l0aCB0aGVpciBwcml2YXRlbHkKICAgICAgbWFuYWdlZCBB VlAgYWRkcmVzcyBzcGFjZSwgZ3VhcmFudGVlaW5nIHRoYXQgdGhleSB3aWxsIG5vdAogICAgICBj b2xsaWRlIHdpdGggYW55IG90aGVyIHZlbmRvcidzIHZlbmRvci1zcGVjaWZpYyBBVlAocyksIG5v ciB3aXRoCiAgICAgIGZ1dHVyZSBJRVRGIGFwcGxpY2F0aW9ucy4KCiAgIERhdGEKCiAgICAgIFRo ZSBEYXRhIGZpZWxkIGlzIHplcm8gb3IgbW9yZSBvY3RldHMgYW5kIGNvbnRhaW5zIGluZm9ybWF0 aW9uCiAgICAgIHNwZWNpZmljIHRvIHRoZSBBdHRyaWJ1dGUuIFRoZSBmb3JtYXQgYW5kIGxlbmd0 aCBvZiB0aGUgRGF0YQogICAgICBmaWVsZCBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBBVlAgQ29kZSBh bmQgQVZQIExlbmd0aCBmaWVsZHMuCgoKOS4zICBQQU5BIE1lc3NhZ2VzCgogICBUaGUgZm9sbG93 aW5nIGZpZ3VyZSBYIGxpc3RzIGFsbCBQQU5BIG1lc3NhZ2VzIGRlZmluZWQgaW4gdGhpcwogICBk cmFmdCB3aXRoIHRoZSBzZW5kZXIgYW5kIHJlY2VpdmVyIGlsbHVzdHJhdGVkLgoKICAgICAgTWVz c2FnZSAgICAgICBEaXJlY3Rpb246IFBhQy0tLVBBQQogICAgICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCiAgICAgIFBBTkEtRGlzY292ZXIgICAgICAgICAgICAtLS0tLS0tLT4g IAoKICAgICAgUEFOQS1TdGFydC1SZXF1ZXN0ICAgICAgIDwtLS0tLS0tLQogICAgICBQQU5BLVN0 YXJ0LUFuc3dlciAgICAgICAgLS0tLS0tLS0+CgogICAgICBQQU5BLUF1dGgtUmVxdWVzdCAgICAg ICAgPC0tLS0tLS0tCiAgICAgIFBBTkEtQXV0aC1BbnN3ZXIgICAgICAgICAtLS0tLS0tLT4KCiAg ICAgIFBBTkEtU3VjY2Vzcy1SZXF1ZXN0ICAgICA8LS0tLS0tLS0KICAgICAgUEFOQS1TdWNjZXNz LUFuc3dlciAgICAgIC0tLS0tLS0tPgoKICAgICAgUEFOQS1SZWF1dGgtUmVxdWVzdCAgICAgIDwt LS0tLS0tPgogICAgICBQQU5BLVJlYXV0aC1BbnN3ZXIgICAgICAgPC0tLS0tLS0+CgogICAgICBQ QU5BLURpc2Nvbm5lY3QtUmVxdWVzdCAgLS0tLS0tLS0+CiAgICAgIFBBTkEtRGlzY29ubmVjdC1B bnN3ZXIgICA8LS0tLS0tLS0KCiAgICAgIFBBTkEtUmV2b2NhdGlvbi1SZXF1ZXN0ICA8LS0tLS0t LS0KICAgICAgUEFOQS1SZXZvY2F0aW9uLUFuc3dlciAgIC0tLS0tLS0tPiAKICAKICAgICAgICAg ICAgRmlndXJlIFguCgoKOS4zLjEgIE1lc3NhZ2Ugc3BlY2lmaWNhdGlvbnMKCiAgIEV2ZXJ5IFBB TkEgTWVzc2FnZSBkZWZpbmVkIE1VU1QgaW5jbHVkZSBhIGNvcnJlc3BvbmRpbmcgQUJORgogICBb UkZDMjIzNF0gc3BlY2lmaWNhdGlvbiBmb3VuZCBpbiB0aGUgW0RJQU1FVEVSXSBzcGVjLiAgUEFO QQogICBNZXNzYWdlcyBoYXZlIGRpZmZlcmVudCBoZWFkZXIgZm9ybWF0IGNvbXBhcmVkIHRvIERp YW1ldGVyLgogICBFeHBsYWluLi4gPFRCRD4uCgogICBFeGFtcGxlX21lc3NhZ2UgOjo9IDwgUEFO QS1IZWFkZXI6IDxNZXNzYWdlIHR5cGU+LCAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbQUNLXSwgW0ZJTl0gPgogICAgICAgICAgICAgICAgICAqIFsgQVZQIF0KCgo5LjMu MiAgUEFOQS1EaXNjb3ZlcgoKICAgUEFOQS1EaXNjb3ZlciBtZXNzYWdlIGlzIHVzZWQgdG8gZGlz Y292ZXIgdGhlIGFkZHJlc3Mgb2YKICAgUEFBKHMpLiBCb3RoIHNlcXVlbmNlIG51bWJlcnMgaW4g dGhpcyBtZXNzYWdlIGFyZSBzZXQgdG8gemVybwogICAoMCkuIElmIEVQIGRldGVjdHMgYSBuZXcg UGFDIGFuZCBzZW5kcyB0aGUgUEFOQS1EaXNjb3ZlciB0byBQQUEsIGl0CiAgIE1VU1QgaW5jbHVk ZSB0aGUgRGV2aWNlLUlEIG9mIHRoZSBQYUMuCgogICAgICBQQU5BLVBBQS1EaXNjb3ZlciA6Oj0g PCBQQU5BLUhlYWRlcjogPFRCRD4gPgogICAgICAgICAgICAgICAgMCoxIDwgRGV2aWNlLUlEID4J CiAgICAgICAgICAgICAgICAgICogWyBBVlAgXQoKCjkuMy4zICBQQU5BLVN0YXJ0LVJlcXVlc3QK CiAgIFBBTkEtU3RhcnQtUmVxdWVzdCBpcyBzZW50IGJ5IFBBQSB0byBQYUMuICBQQUEgc2V0cyB0 aGUKICAgdHJhbnNtaXNzaW9uIHNlcXVlbmNlIG51bWJlciB0byBhbiBpbml0aWFsIHJhbmRvbSB2 YWx1ZS4gIFRoZQogICByZWNlaXZlZCBzZXF1ZW5jZSBudW1iZXIgaXMgc2V0IHRvIHplcm8gKDAp LgoKICAgICAgUEFOQV9zdGFydF9yZXF1ZXN0IDo6PSA8IFBBTkEtSGVhZGVyOiA8VEJEPiA+CiAg ICAgICAgICAgICAgICAgICAgPCBTZXNzaW9uLUlEID4KICAgICAgICAgICAgICAgICAgICA8IENv b2tpZSA+CiAgICAgICAgICAgICAgICAgICogWyBBVlAgXQoKCjkuMy40ICBQQU5BLVN0YXJ0LUFu c3dlcgoKICAgUEFOQS1TdGFydC1BbnN3ZXIgKFBTQSkgaXMgc2VudCBieSBQYUMgdG8gUEFBIGlu IHJlc3BvbnNlIHRvCiAgIFBBTkFfc3RhcnQgbWVzc2FnZS4gIFRoZSBQQU5BX3N0YXJ0IG1lc3Nh Z2UgdHJhbnNtaXNzaW9uIHNlcXVlbmNlCiAgIG51bWJlciBmaWVsZCBpcyBjb3BpZWQgdG8gdGhl IHJlY2VpdmVkIHNlcXVlbmNlIG51bWJlciBmaWVsZC4gIFRoZQogICB0cmFuc21pc3Npb24gc2Vx dWVuY2UgbnVtYmVyIGlzIHNldCB0byBpbml0aWFsIHJhbmRvbSB2YWx1ZS4KCiAgICAgIFBBTkFf c3RhcnRfYW5zd2VyIDo6PSA8IFBBTkEtSGVhZGVyOiA8VEJEPiA+CiAgICAgICAgICAgICAgICAg ICAgPCBTZXNzaW9uLUlEID4KICAgICAgICAgICAgICAgICAgICA8IENvb2tpZSA+CiAgICAgICAg ICAgICAgICAgICogWyBBVlAgXQoKCjkuMy41ICBQQU5BLUF1dGgtUmVxdWVzdAoKICAgUEFOQS1B dXRoLVJlcXVlc3QgaXMgc2VudCBieSBQQUEgdG8gUGFDLgoKICAgICAgUEFOQS1BdXRoLVJlcXVl c3QgOjo9IDwgUEFOQS1IZWFkZXI6IDxUQkQ+ID4KICAgICAgICAgICAgICAgICAgICA8IFNlc3Np b24tSUQgPgogICAgICAgICAgICAgICAgICAgIDwgRUFQLVBheWxvYWQgPgogICAgICAgICAgICAg ICAgICAqIFsgQVZQIF0KICAgICAgICAgICAgICAgIDAqMSA8IE1BQyA+CgoKOS4zLjYgIFBBTkEt QXV0aC1BbnN3ZXIKCiAgIFBBTkEtQXV0aC1BbnN3ZXIgaXMgc2VudCBieSBQYUMgdG8gUEFBIGlu IHJlc3BvbnNlIHRvCiAgIFBBTkEtQXV0aC1SZXF1ZXN0LgoKICAgICAgUEFOQS1BdXRoLUFuc3dl ciA6Oj0gPCBQQU5BLUhlYWRlcjogPFRCRD4gPgogICAgICAgICAgICAgICAgICAgIDwgU2Vzc2lv bi1JRCA+CiAgICAgICAgICAgICAgICAgICAgPCBFQVAtUGF5bG9hZCA+CiAgICAgICAgICAgICAg ICAgICogWyBBVlAgXQogICAgICAgICAgICAgICAgMCoxIDwgTUFDID4KCgo5LjMuNyAgUEFOQS1T dWNjZXNzLVJlcXVlc3QKCiAgIFBBTkEtU3VjY2Vzcy1SZXF1ZXN0IGlzIHNlbnQgYnkgUEFBIHRv IFBhQyB3aGVuIFBBQSByZWNlaXZlcyBFQVAKICAgU3VjY2Vzcy4KCiAgICAgIFBBTkEtU3VjY2Vz cyA6Oj0gPCBQQU5BLUhlYWRlcjogPFRCRD4sIFtGSU5dID4KICAgICAgICAgICAgICAgICAgICA8 IFNlc3Npb24tSUQgPgogICAgICAgICAgICAgICAgICAgIDwgRGV2aWNlLUlEID4KICAgICAgICAg ICAgICAgICAgICA8IEVBUC1QYXlsb2FkID4KICAgICAgICAgICAgICAgICAgICA8IFByb3RlY3Rp b24tQ2FwYWJpbGl0eSA+CiAgICAgICAgICAgICAgICAgICogWyBBVlAgXQogICAgICAgICAgICAg ICAgMCoxIDwgTUFDID4KCgo5LjMuOCAgUEFOQS1TdWNjZXNzLUFuc3dlcgoKICAgUEFOQS1TdWNj ZXNzLUFuc3dlciBpcyBzZW50IGJ5IFBhQyB0byBQQUEgaW4gcmVzcG9uc2UgdG8KICAgUEFOQS1T dWNjZXNzLVJlcXVlc3QuCgogICAgICBQQU5BLVN1Y2Nlc3MtQWNrIDo6PSA8IFBBTkEtSGVhZGVy OiA8VEJEPiwgQUNLLCBbRklOXSA+CiAgICAgICAgICAgICAgICAgICAgPCBTZXNzaW9uLUlEID4K ICAgICAgICAgICAgICAgICAgICA8IERldmljZS1JRCA+CiAgICAgICAgICAgICAgICAgICogWyBB VlAgXQogICAgICAgICAgICAgICAgMCoxIDwgTUFDID4KCgo5LjMuOSAgUEFOQS1SZWF1dGgtUmVx dWVzdAoKICAgUEFOQS1SZWF1dGgtUmVxdWVzdCBjYW4gYmUgc2VuZCBib3RoIGJ5IFBhQyBhbmQg UEFBLgoKICAgICAgUEFOQS1SZWF1dGgtUmVxdWVzdCA6Oj0gPCBQQU5BLUhlYWRlcjogPFRCRD4g PgogICAgICAgICAgICAgICAgICAgIDwgU2Vzc2lvbi1JRCA+CiAgICAgICAgICAgICAgICAwKjEg WyBBZGQtRGV2aWNlLUlEIF0KICAgICAgICAgICAgICAgIDAqMSBbIFJlbW92ZS1EZXZpY2UtSUQg XQogICAgICAgICAgICAgICAgICAqIFsgQVZQIF0KICAgICAgICAgICAgICAgIDAqMSA8IE1BQyA+ CgoKOS4zLjEwICBQQU5BLVJlYXV0aC1BbnN3ZXIKCiAgIFBBTkEtUmVhdXRoLUFuc3dlciBpcyBz ZW50IGluIHJlc3BvbnNlIHRvIFBBTkEtUmVhdXRoLVJlcXVlc3QuCgogICAgICBQQU5BLVJlYXV0 aC1BbnN3ZXIgOjo9IDwgUEFOQS1IZWFkZXI6IDxUQkQ+LCBBQ0sgPgogICAgICAgICAgICAgICAg ICAgIDwgU2Vzc2lvbi1JRCA+CiAgICAgICAgICAgICAgICAgICAgPCBEZXZpY2UtSUQgPgogICAg ICAgICAgICAgICAgICAqIFsgQVZQIF0KICAgICAgICAgICAgICAgIDAqMSA8IE1BQyA+CgoKOS4z LjExICBQQU5BLURpc2Nvbm5lY3QtUmVxdWVzdAoKICAgUEFOQS1EaXNjb25uZWN0LVJlcXVlc3Qg aXMgc2VudCBieSBQYUMgdG8gUEFBLgoKICAgICAgUEFOQS1EaXNjb25uZWN0LVJlcXVlc3QgOjo9 IDwgUEFOQS1IZWFkZXI6IDxUQkQ+ID4KICAgICAgICAgICAgICAgICAgICA8IFNlc3Npb24tSUQg PgogICAgICAgICAgICAgICAgICAgIDwgVGVybWluYXRpb24tQ2F1c2UgPgogICAgICAgICAgICAg ICAgICAqIFsgQVZQIF0KICAgICAgICAgICAgICAgIDAqMSA8IE1BQyA+CgoKOS4zLjEyICBQQU5B LURpc2Nvbm5lY3QtQW5zd2VyCgogICBQQU5BLURpc2Nvbm5lY3QtQW5zd2VyIGlzIHNlbnQgYnkg UEFBIHRvIFBhQyBpbiByZXNwb25zZSB0bwogICBQQU5BLURpc2Nvbm5lY3QtUmVxdWVzdC4KCiAg ICAgIFBBTkEtRGlzY29ubmVjdC1BbnN3ZXIgOjo9IDwgUEFOQS1IZWFkZXI6IDxUQkQ+LCBBQ0sg PgogICAgICAgICAgICAgICAgICAgIDwgU2Vzc2lvbi1JRCA+CiAgICAgICAgICAgICAgICAgICog WyBBVlAgXQogICAgICAgICAgICAgICAgMCoxIDwgTUFDID4KCgo5LjMuMTMgIFBBTkEtUmV2b2Nh dGlvbi1SZXF1ZXN0CgogICBQQU5BLVJldm9jYXRpb24tUmVxdWVzdCBpcyBzZW50IGJ5IFBBQSB0 byBQYUMuCgogICAgICBQQU5BLVJldm9jYXRpb24tUmVxdWVzdCA6Oj0gPCBQQU5BLUhlYWRlcjog PFRCRD4gPgogICAgICAgICAgICAgICAgICAgIDwgU2Vzc2lvbi1JRCA+CgkJICAgIDygVGVybWlu YXRpb24tQ2F1c2UgPgogICAgICAgICAgICAgICAgICAqIFsgQVZQIF0KICAgICAgICAgICAgICAg IDAqMSA8IE1BQyA+CgoKOS4zLjE0ICBQQU5BLVJldm9jYXRpb24tQW5zd2VyCgogICBQQU5BLVJl dm9jYXRpb24tQW5zd2VyIGlzIHNlbnQgZnJvbSBQYUMgdG8gUEFBIGluIHJlc3BvbnNlIHRvCiAg IFBBTkEtUmV2b2NhdGlvbi1SZXF1ZXN0LgogICAgCiAgICAgIFBBTkEtUmV2b2NhdGlvbi1BbnN3 ZXIgOjo9IDwgUEFOQS1IZWFkZXI6IDxUQkQ+LCBBQ0sgPgogICAgICAgICAgICAgICAgICAgIDwg U2Vzc2lvbi1JRCA+CiAgICAgICAgICAgICAgICAgICogWyBBVlAgXQogICAgICAgICAgICAgICAg MCoxIDwgTUFDID4KCgo5LjQgIEFWUHMgaW4gUEFOQQoKICAgU29tZSBvZiB0aGUgdXNlZCBBVlBz IGFyZSBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgYW5kIHNvbWUgb2YgdGhlbQogICBhcmUgZGVm aW5lZCBpbiBvdGhlciBkb2N1bWVudHMgbGlrZSBbRElBTUVURVJdLgoKCjkuNC4xICBDb29raWUt QVZQCgogICBUaGUgQ29va2llIEFWUCAoQ29kZSA8VEJEPikgaXMgb2YgdHlwZSBPY3RldFN0cmlu Zy4KCgo5LjQuMiAgTUFDIEFWUAoKICAgVGhlIE1BQyBBVlAgKENvZGUgPFRCRD4pIGlzIG9mIHR5 cGUgT2N0ZXRTdHJpbmcuCgoKOS40LjMgIERldmljZS1JRCBBVlAgIAoKICAgVGhlIERldmljZS1J RCBBVlAgKENvZGUgPFRCRD4pIGlzIG9mIHR5cGUgR3JvdXBlZC4KCiAgICAgIERldmljZS1JRCA6 Oj0gPCBBVlAgSGVhZGVyOiA8VEJEPiA+CiAgICAgICAgICAgICAgICAgICAgPCBEZXZpY2UtSXlw ZSA+CiAgICAgICAgICAgICAgICAgICAgPCBEZXZpY2UtRGF0YSA+CgoKOS40LjMuMSAgRGV2aWNl LVR5cGUgQVZQCgogICBUaGUgRGV2aWNlLVR5cGUgQVZQIChDb2RlIDxUQkQ+KSBpcyBvZiB0eXBl IFVuc2lnbmVkMzIuIEJlbG93IGlzIGEKICAgbGlzdCBvZiBzcGVjaWZpZWQgRGV2aWNlLVR5cGVz OgoKICAgICAgSVBWNl9BRERSRVNTICAgICAgICAgICAgICAgICAgICAgIDEKICAgICAgSVBWNF9B RERSRVNTICAgICAgICAgICAgICAgICAgICAgIDIKCgo5LjQuMy4yICBEZXZpY2UtRGF0YSBBVlAK CiAgIFRoZSBEZXZpY2UtRGF0YSBBVlAgKENvZGUgPFRCRD4pIGlzIG9mIHR5cGUgT2N0ZXRTdHJp bmcuICBUaGUKICAgbGVuZ3RoIGRlcGVuZHMgb24gdGhlIERldmljZS1UeXBlIEFWUC4gIEJlbG93 IGlzIGEgbGlzdCBvZiBsZW5ndGhzCiAgIGluIG9jdGV0cyBmb3Igc3BlY2lmaWVkIChTZWUgRGV2 aWNlLVR5cGUgQVZQIGRlZmluaXRpb24pCiAgIERldmljZS1UeXBlczoKCiAgICAgIElQVjZfQURE UkVTUyAgICAgICAgICAgICAgICAgICAgICAxNgogICAgICBJUFY0X0FERFJFU1MgICAgICAgICAg ICAgICAgICAgICAgNAoKCjkuNC40ICBQcm90ZWN0aW9uLUNhcGFiaWxpdHkgQVZQCgogICBUaGUg UHJvdGVjdGlvbi1DYXBhYmlsaXR5IEFWUCAoQ29kZSA8VEJEPikgaXMgb2YgdHlwZSBVbnNpZ25l ZDMyLgogICBUaGUgQVZQIGRhdGEgaXMgdXNlZCBhcyBhIGNvbGxlY3Rpb24gb2YgZmxhZ3MgZm9y IGRpZmZlcmVudCBkYXRhCiAgIHByb3RlY3Rpb24gY2FwYWJpbGl0eSBpbmRpY2F0aW9ucy4gIEJl bG93IGlzIGEgbGlzdCBvZiBzcGVjaWZpZWQKICAgZGF0YSBwcm90ZWN0aW9uIGNhcGFiaWxpdGll czoKCiAgICAgIEwyX1BST1RFQ1RJT04gICAgICAgICAgICAgICAgICAgICAxCiAgICAgIElQU0VD X1BST1RFQ1RJT04gICAgICAgICAgICAgICAgICAyCgoKOS40LjUgIEVBUC1QYXlsb2FkIEFWUAoK ICAgVGhlIEVBUC1QYXlsb2FkIEFWUCBpcyBkZWZpbmVkIGluIFtYWFhdLgoKCjkuNC42ICBUZXJt aW5hdGlvbi1DYXVzZSBBVlAKCiAgIFRoZSBUZXJtaW5hdGlvbi1DYXVzZSBBVlAgaXMgZGVmaW5l ZCBpbiBbRElBTUVURVJdLgoKCjkuNC43ICBBZGQtRGV2aWNlLUlECgogICBUaGUgQWRkLURldmlj ZS1JRCBBVlAgKENvZGUgPFRCRD4pIGlzIG9mIHR5cGUgR3JvdXBlZC4KCiAgICAgIEFkZC1EZXZp Y2UtSUQgOjo9IDwgQVZQIEhlYWRlcjogPFRCRD4gPgogICAgICAgICAgICAgICAgIDEqIFsgRGV2 aWNlLUlEIF0KCgo5LjQuOCAgUmVtb3ZlLURldmljZS1JRAoKICAgVGhlIFJlbW92ZS1EZXZpY2Ut SUQgQVZQIChDb2RlIDxUQkQ+KSBpcyBvZiB0eXBlIEdyb3VwZWQuCgogICAgICBSZW1vdmUtRGV2 aWNlLUlEIDo6PSA8IEFWUCBIZWFkZXI6IDxUQkQ+ID4KICAgICAgICAgICAgICAgICAxKiBbIERl dmljZS1JRCBdCgoKOS40LjkgIFNlc3Npb24tSUQKCiAgIFRoZSBTZXNzaW9uLUlEIEFWUCBpcyBk ZWZpbmVkIGluIFtESUFNRVRFUl0uCg== ------_=_NextPart_001_01C2FE9C.81B04BF8-- From pana-request@research.telcordia.com Wed Apr 9 10:37:55 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01027 for ; Wed, 9 Apr 2003 10:37:55 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h39EbRsq021052; Wed, 9 Apr 2003 10:37:27 -0400 (EDT) Resent-Date: Wed, 9 Apr 2003 10:37:27 -0400 (EDT) Old-Return-Path: Date: Wed, 9 Apr 2003 16:36:36 +0200 From: Julien Bournelle To: Dan.Forsberg@nokia.com Cc: pana@research.telcordia.com Subject: Re: Proposal for message formatting (sec. 9). Message-ID: <20030409143636.GL71934@ipv6-5.int-evry.fr> Mail-Followup-To: Dan.Forsberg@nokia.com, pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Julien Bournelle X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi, after a really quick look, I have a comment. Please see below, > > 9.1 PANA Header > > A summary of the PANA header format is shown below. The fields are > transmitted in network byte order. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags | Message Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Application-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Transmitted Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Received Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVPs ... > +-+-+-+-+-+-+-+-+-+-+-+-+- > > Application-ID > > Application-ID is four octets and is used to identify to which > application the message is applicable for. The Application-ID > for PANA is . I know that Diameter has this fields to distinguish between his various applications but PANA doesn't need this field to work. Am I wrong ? Do we add it just for simplify PANA/Diameter cooperation ? -- julien.bournelle@int-evry.fr From pana-request@research.telcordia.com Wed Apr 9 12:00:34 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03952 for ; Wed, 9 Apr 2003 12:00:15 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h39Fx3dj027451; Wed, 9 Apr 2003 11:59:03 -0400 (EDT) Resent-Date: Wed, 9 Apr 2003 11:59:03 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Proposal for message formatting (sec. 9). Date: Wed, 9 Apr 2003 18:54:48 +0300 Message-ID: Thread-Topic: Proposal for message formatting (sec. 9). Thread-Index: AcL+pYBgvQy0WkKxTOu3ZtGwNGpv/wAAIjOwAAE80xAAAAE7MA== From: To: Cc: X-OriginalArrivalTime: 09 Apr 2003 15:54:49.0325 (UTC) FILETIME=[59C001D0:01C2FEB0] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA03952 Julien, You're right! As the introduction says it would be great if we could use Diamter message processing as much as possible. I thought that maybe we should make the App-Id field reserved, but then, the App-Id can actually help the Diameter stack to recognize PANA application and thus if possible to process the Hop-by-Hop and End-to-End Ids differently (tseq and rseq). Of course there is UDP protocol and port number to make a difference, but this helps in the application layer. but I would actually like to go even further.. We could use the Diameter header as it is together with PANA layer retransmissions ALSO for PANA-Auth-Request/Answer packets. Hop-by-Hop and End-to-End Ids provide replay protection and duplicate detection together with in sequence delivery. Currently PANA does it for all other but PANA-Auth-Request/Answer messages, which makes the layer architecture not so sound (This is now a problem anyway if EAP Server doesn't do retransmissions in the backend AAA infrastructure (dependancy)). The reason we didn't take this step during the design team lifetime was that we didn't know if EAP was truly lock-step safe (request/response protocol and only one pending request at a time). In the IETF56 EAP meeting it became clear that EAP is truly lock-step safe, even with EAP notifications, and thus the reasoning in the Appendix A of pana-pana-00 draft doesn't hold anymore. Even the EAP-Success/Failure gets a response in PANA. Additional benefit in this approach is simplicity and a good resistance to blind DoS attacks: peer accepts only new requests that have the Hop-by-Hop Id increased by one. No need for accept windows etc. In case of a retransmission, peer gets the same packet again with exactly the same HbH Id, which means that the other peer didn't get the answer in time (can happen with user input for example) or it was lost (unrealiable link layer). PAA initializes its Hop-by-Hop Id in the beginning. PaC does the same when it first sends a request to PAA (PANA-Reauth-Request). In case of no MAC, PAA may want to know beforehand what Id the Request must contain (defence against DoS attack in PAA). PaC can send its initial Hop-by-Hop Id in a Initial-Hop-By-Hop-Id AVP in the PANA-Success-Answer message, for example. Or optionally in the PAA-Discover message. PAA then knows that the first PANA-Reauth-Request message from PaC must contain this Id. Let me hear your comments. - Dan > -----Original Message----- > From: ext Julien Bournelle [mailto:Julien.Bournelle@int-evry.fr] > Sent: 09 April, 2003 17:37 > To: Forsberg Dan (NRC/Helsinki) > Cc: pana@research.telcordia.com > Subject: Re: Proposal for message formatting (sec. 9). > > > Hi, > > after a really quick look, I have a comment. Please see below, > > > > 9.1 PANA Header > > > > A summary of the PANA header format is shown below. The > fields are > > transmitted in network byte order. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Version | Message Length > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Flags | Message Type > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Application-ID > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Transmitted Sequence Number > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Received Sequence Number > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | AVPs ... > > +-+-+-+-+-+-+-+-+-+-+-+-+- > > > > Application-ID > > > > Application-ID is four octets and is used to identify to which > > application the message is applicable for. The Application-ID > > for PANA is . > > I know that Diameter has this fields to distinguish between > his various > applications but PANA doesn't need this field to work. Am I wrong ? > > Do we add it just for simplify PANA/Diameter cooperation ? > > -- > julien.bournelle@int-evry.fr > > From pana-request@research.telcordia.com Thu Apr 10 05:11:54 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12750 for ; Thu, 10 Apr 2003 05:11:26 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3A99lk4027999; Thu, 10 Apr 2003 05:09:47 -0400 (EDT) Resent-Date: Thu, 10 Apr 2003 05:09:47 -0400 (EDT) Old-Return-Path: Date: Thu, 10 Apr 2003 11:08:50 +0200 From: Julien Bournelle To: Dan.Forsberg@nokia.com Cc: pana@research.telcordia.com Subject: Re: Proposal for message formatting (sec. 9). Message-ID: <20030410090850.GX71934@ipv6-5.int-evry.fr> Mail-Followup-To: Dan.Forsberg@nokia.com, pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Julien Bournelle X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi, thanks for your reply, please see comments below, On Wed, Apr 09, 2003 at 06:54:48PM +0300, Dan.Forsberg@nokia.com wrote: > Julien, > > You're right! As the introduction says it would be great if we could use Diamter message processing as much as possible. I thought that maybe we should make the App-Id field reserved, but then, the App-Id can actually help the Diameter stack to recognize PANA application and thus if possible to process the Hop-by-Hop and End-to-End Ids differently (tseq and rseq). Of course there is UDP protocol and port number to make a difference, but this helps in the application layer. > I agree with you that it is a good idea to re-use Diameter Header for PANA to ease cooperation and that tseq and rseq fields fit well with hoy-by-hop id and end-to-end id. Of course, it remains the App-Id field and we can use it the way you propose but it just seems weird for me to "add" a field in the PANA header "just" for Diameter. Basically, I'm not against it but I wanted to know how others (and you :-) feel about that. > but I would actually like to go even further.. > > We could use the Diameter header as it is together with PANA layer retransmissions ALSO for PANA-Auth-Request/Answer packets. Hop-by-Hop and End-to-End Ids provide replay protection and duplicate detection together with in sequence delivery. Currently PANA does it for all other but PANA-Auth-Request/Answer messages, which makes the layer architecture not so sound (This is now a problem anyway if EAP Server doesn't do retransmissions in the backend AAA infrastructure (dependancy)). > > The reason we didn't take this step during the design team lifetime was that we didn't know if EAP was truly lock-step safe (request/response protocol and only one pending request at a time). In the IETF56 EAP meeting it became clear that EAP is truly lock-step safe, even with EAP notifications, and thus the reasoning in the Appendix A of pana-pana-00 draft doesn't hold anymore. Even the EAP-Success/Failure gets a response in PANA. > > Additional benefit in this approach is simplicity and a good resistance to blind DoS attacks: peer accepts only new requests that have the Hop-by-Hop Id increased by one. No need for accept windows etc. In case of a retransmission, peer gets the same packet again with exactly the same HbH Id, which means that the other peer didn't get the answer in time (can happen with user input for example) or it was lost (unrealiable link layer). > > PAA initializes its Hop-by-Hop Id in the beginning. PaC does the same when it first sends a request to PAA (PANA-Reauth-Request). In case of no MAC, PAA may want to know beforehand what Id the Request must contain (defence against DoS attack in PAA). PaC can send its initial Hop-by-Hop Id in a Initial-Hop-By-Hop-Id AVP in the PANA-Success-Answer message, for example. Or optionally in the PAA-Discover message. PAA then knows that the first PANA-Reauth-Request message from PaC must contain this Id. > > Let me hear your comments. > > - Dan > > > -----Original Message----- > > From: ext Julien Bournelle [mailto:Julien.Bournelle@int-evry.fr] > > Sent: 09 April, 2003 17:37 > > To: Forsberg Dan (NRC/Helsinki) > > Cc: pana@research.telcordia.com > > Subject: Re: Proposal for message formatting (sec. 9). > > > > > > Hi, > > > > after a really quick look, I have a comment. Please see below, > > > > > > 9.1 PANA Header > > > > > > A summary of the PANA header format is shown below. The > > fields are > > > transmitted in network byte order. > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > > 6 7 8 9 0 1 > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Version | Message Length > > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Flags | Message Type > > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Application-ID > > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Transmitted Sequence Number > > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Received Sequence Number > > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | AVPs ... > > > +-+-+-+-+-+-+-+-+-+-+-+-+- > > > > > > Application-ID > > > > > > Application-ID is four octets and is used to identify to which > > > application the message is applicable for. The Application-ID > > > for PANA is . > > > > I know that Diameter has this fields to distinguish between > > his various > > applications but PANA doesn't need this field to work. Am I wrong ? > > > > Do we add it just for simplify PANA/Diameter cooperation ? > > > > -- > > julien.bournelle@int-evry.fr > > > > -- julien.bournelle@int-evry.fr From pana-request@research.telcordia.com Thu Apr 10 14:11:01 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28926 for ; Thu, 10 Apr 2003 14:10:42 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3AI9q87007832; Thu, 10 Apr 2003 14:09:52 -0400 (EDT) Resent-Date: Thu, 10 Apr 2003 14:09:52 -0400 (EDT) Old-Return-Path: Date: Thu, 10 Apr 2003 14:09:41 -0400 To: Dan.Forsberg@nokia.com Cc: Julien.Bournelle@int-evry.fr, pana@research.telcordia.com Subject: Re: Proposal for message formatting (sec. 9). Message-ID: <20030410180941.GB731@catfish> Mail-Followup-To: Dan.Forsberg@nokia.com, Julien.Bournelle@int-evry.fr, pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 126 X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Dan, On Wed, Apr 09, 2003 at 06:54:48PM +0300, Dan.Forsberg@nokia.com wrote: > Julien, > > You're right! As the introduction says it would be great if we could use Diamter message processing as much as possible. I thought that maybe we should make the App-Id field reserved, but then, the App-Id can actually help the Diameter stack to recognize PANA application and thus if possible to process the Hop-by-Hop and End-to-End Ids differently (tseq and rseq). Of course there is UDP protocol and port number to make a difference, but this helps in the application layer. > > but I would actually like to go even further.. > > We could use the Diameter header as it is together with PANA layer retransmissions ALSO for PANA-Auth-Request/Answer packets. Hop-by-Hop and End-to-End Ids provide replay protection and duplicate detection together with in sequence delivery. Currently PANA does it for all other but PANA-Auth-Request/Answer messages, which makes the layer architecture not so sound (This is now a problem anyway if EAP Server doesn't do retransmissions in the backend AAA infrastructure (dependancy)). I guess you mention yet another scheme that uses two identifiers with PANA layer retransmission but is not described in Appendix. If so, I'm not sure what "this step" in the sentence below means. > > The reason we didn't take this step during the design team lifetime was that we didn't know if EAP was truly lock-step safe (request/response protocol and only one pending request at a time). In the IETF56 EAP meeting it became clear that EAP is truly lock-step safe, even with EAP notifications, and thus the reasoning in the Appendix A of pana-pana-00 draft doesn't hold anymore. Even the EAP-Success/Failure gets a response in PANA. EAP is now lock-step for Request/Response exchanges, but the lock-step characteristic does not hold for EAP Success/Failure message, i.e., EAP Success/Failure message may be sent from an EAP authenticator even when the authenticator does not receive the Response to the outstanding Request. The following reasoning for "single sequence number with PANA-layer retransmission" method in the Appendix A.2.2 still holds when the new EAP message is Sucess/Failure: Another problem occurs when a new EAP message overrides the outstanding EAP Request, the PaC cannot assume any more that the sequence number of the next message to be accepted is the last accepted message + 1. So the PaC needs to accept a range of sequence numbers, instead of a single sequence number. These two additional things would increase the complexity of this method. On the other hand, the following reasoning for "single sequence number with PANA-layer retransmission" method does not hold any more, since the EAP-Success/Failure gets a response in PANA. This would require timer-based retransmission not only at PaC side but also at PAA side. I will revise the Appendix in the next version of specification. > > Additional benefit in this approach is simplicity and a good resistance to blind DoS attacks: peer accepts only new requests that have the Hop-by-Hop Id increased by one. No need for accept windows etc. In case of a retransmission, peer gets the same packet again with exactly the same HbH Id, which means that the other peer didn't get the answer in time (can happen with user input for example) or it was lost (unrealiable link layer). > > PAA initializes its Hop-by-Hop Id in the beginning. PaC does the same when it first sends a request to PAA (PANA-Reauth-Request). In case of no MAC, PAA may want to know beforehand what Id the Request must contain (defence against DoS attack in PAA). PaC can send its initial Hop-by-Hop Id in a Initial-Hop-By-Hop-Id AVP in the PANA-Success-Answer message, for example. Or optionally in the PAA-Discover message. PAA then knows that the first PANA-Reauth-Request message from PaC must contain this Id. I think the scheme you mention actually needs to maintain four identifiers: Hop-by-Hop Id and End-to-End Id for PANA requests sent by PAA and Hop-by-Hop Id and End-to-End Id for PANA requests sent by PaC. Is this correct? If this is correct, the scheme seems to be no simpler than the current scheme that maintains two identifiers. Yoshihiro Ohba > > Let me hear your comments. > > - Dan > > > -----Original Message----- > > From: ext Julien Bournelle [mailto:Julien.Bournelle@int-evry.fr] > > Sent: 09 April, 2003 17:37 > > To: Forsberg Dan (NRC/Helsinki) > > Cc: pana@research.telcordia.com > > Subject: Re: Proposal for message formatting (sec. 9). > > > > > > Hi, > > > > after a really quick look, I have a comment. Please see below, > > > > > > 9.1 PANA Header > > > > > > A summary of the PANA header format is shown below. The > > fields are > > > transmitted in network byte order. > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > > 6 7 8 9 0 1 > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Version | Message Length > > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Flags | Message Type > > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Application-ID > > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Transmitted Sequence Number > > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Received Sequence Number > > | > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | AVPs ... > > > +-+-+-+-+-+-+-+-+-+-+-+-+- > > > > > > Application-ID > > > > > > Application-ID is four octets and is used to identify to which > > > application the message is applicable for. The Application-ID > > > for PANA is . > > > > I know that Diameter has this fields to distinguish between > > his various > > applications but PANA doesn't need this field to work. Am I wrong ? > > > > Do we add it just for simplify PANA/Diameter cooperation ? > > > > -- > > julien.bournelle@int-evry.fr > > > > > > From pana-request@research.telcordia.com Fri Apr 11 07:01:37 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06694 for ; Fri, 11 Apr 2003 07:01:19 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3BAwrZT013980; Fri, 11 Apr 2003 06:58:53 -0400 (EDT) Resent-Date: Fri, 11 Apr 2003 06:58:53 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Proposal for message formatting (sec. 9). Date: Fri, 11 Apr 2003 13:58:37 +0300 Message-ID: Thread-Topic: Proposal for message formatting (sec. 9). Thread-Index: AcL/jG6sLL/oeqcGRwy4xK0VpJBQwQAhxQDA From: To: Cc: , X-OriginalArrivalTime: 11 Apr 2003 10:58:38.0223 (UTC) FILETIME=[4E2C89F0:01C30019] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <0RA3pC.A.SaD.s_pl-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Yoshi, Your comments are good. The main question is if it would be benefical enough to use Diameter message formatting. Small comments inline. > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 10 April, 2003 21:10 > To: Forsberg Dan (NRC/Helsinki) > Cc: Julien.Bournelle@int-evry.fr; pana@research.telcordia.com > Subject: Re: Proposal for message formatting (sec. 9). > > > Hi Dan, > > On Wed, Apr 09, 2003 at 06:54:48PM +0300, > Dan.Forsberg@nokia.com wrote: > > Julien, > > > > You're right! As the introduction says it would be great if > we could use Diamter message processing as much as possible. > I thought that maybe we should make the App-Id field > reserved, but then, the App-Id can actually help the Diameter > stack to recognize PANA application and thus if possible to > process the Hop-by-Hop and End-to-End Ids differently (tseq > and rseq). Of course there is UDP protocol and port number to > make a difference, but this helps in the application layer. > > > > but I would actually like to go even further.. > > > > We could use the Diameter header as it is together with > PANA layer retransmissions ALSO for PANA-Auth-Request/Answer > packets. Hop-by-Hop and End-to-End Ids provide replay > protection and duplicate detection together with in sequence > delivery. Currently PANA does it for all other but > PANA-Auth-Request/Answer messages, which makes the layer > architecture not so sound (This is now a problem anyway if > EAP Server doesn't do retransmissions in the backend AAA > infrastructure (dependancy)). > > I guess you mention yet another scheme that uses two identifiers with > PANA layer retransmission but is not described in Appendix. If so, > I'm not sure what "this step" in the sentence below means. Yes two identifiers because two fields in the header, but it's similar to the case with one identifier. > > > > The reason we didn't take this step during the design team > lifetime was that we didn't know if EAP was truly lock-step > safe (request/response protocol and only one pending request > at a time). In the IETF56 EAP meeting it became clear that > EAP is truly lock-step safe, even with EAP notifications, and > thus the reasoning in the Appendix A of pana-pana-00 draft > doesn't hold anymore. Even the EAP-Success/Failure gets a > response in PANA. > > EAP is now lock-step for Request/Response exchanges, but the lock-step > characteristic does not hold for EAP Success/Failure message, i.e., > EAP Success/Failure message may be sent from an EAP authenticator even > when the authenticator does not receive the Response to the > outstanding Request. The following reasoning for "single sequence > number with PANA-layer retransmission" method in the Appendix A.2.2 > still holds when the new EAP message is Sucess/Failure: > > Another problem occurs when a new EAP message overrides the > outstanding EAP Request, the PaC cannot assume any more that the > sequence number of the next message to be accepted is the last > accepted message + 1. So the PaC needs to accept a range of > sequence numbers, instead of a single sequence number. These two > additional things would increase the complexity of this method. > > > On the other hand, the following reasoning for "single sequence number > with PANA-layer retransmission" method does not hold any more, since > the EAP-Success/Failure gets a response in PANA. > > This would require > timer-based retransmission not only at PaC side but also at PAA > side. > > I will revise the Appendix in the next version of specification. > > > > > Additional benefit in this approach is simplicity and a > good resistance to blind DoS attacks: peer accepts only new > requests that have the Hop-by-Hop Id increased by one. No > need for accept windows etc. In case of a retransmission, > peer gets the same packet again with exactly the same HbH Id, > which means that the other peer didn't get the answer in time > (can happen with user input for example) or it was lost > (unrealiable link layer). > > > > PAA initializes its Hop-by-Hop Id in the beginning. PaC > does the same when it first sends a request to PAA > (PANA-Reauth-Request). In case of no MAC, PAA may want to > know beforehand what Id the Request must contain (defence > against DoS attack in PAA). PaC can send its initial > Hop-by-Hop Id in a Initial-Hop-By-Hop-Id AVP in the > PANA-Success-Answer message, for example. Or optionally in > the PAA-Discover message. PAA then knows that the first > PANA-Reauth-Request message from PaC must contain this Id. > > I think the scheme you mention actually needs to maintain four > identifiers: Hop-by-Hop Id and End-to-End Id for PANA requests sent by > PAA and Hop-by-Hop Id and End-to-End Id for PANA requests sent by PaC. > Is this correct? If this is correct, the scheme seems to be no > simpler than the current scheme that maintains two identifiers. > That's right. Because PaC and PAA are both able to do retransmissions (sending requests and waiting answers), both of them need to maintain their own ids. The difference with the dual seq case is acks. > Yoshihiro Ohba > > > > > Let me hear your comments. > > > > - Dan > > > > > -----Original Message----- > > > From: ext Julien Bournelle [mailto:Julien.Bournelle@int-evry.fr] > > > Sent: 09 April, 2003 17:37 > > > To: Forsberg Dan (NRC/Helsinki) > > > Cc: pana@research.telcordia.com > > > Subject: Re: Proposal for message formatting (sec. 9). > > > > > > > > > Hi, > > > > > > after a really quick look, I have a comment. Please see below, > > > > > > > > 9.1 PANA Header > > > > > > > > A summary of the PANA header format is shown below. The > > > fields are > > > > transmitted in network byte order. > > > > > > > > 0 1 2 > 3 > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > > > 6 7 8 9 0 1 > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Version | Message Length > > > | > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Flags | Message Type > > > | > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Application-ID > > > | > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Transmitted Sequence Number > > > | > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Received Sequence Number > > > | > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | AVPs ... > > > > +-+-+-+-+-+-+-+-+-+-+-+-+- > > > > > > > > Application-ID > > > > > > > > Application-ID is four octets and is used to > identify to which > > > > application the message is applicable for. The > Application-ID > > > > for PANA is . > > > > > > I know that Diameter has this fields to distinguish between > > > his various > > > applications but PANA doesn't need this field to work. Am > I wrong ? > > > > > > Do we add it just for simplify PANA/Diameter cooperation ? > > > > > > -- > > > julien.bournelle@int-evry.fr > > > > > > > > > > > From pana-request@research.telcordia.com Mon Apr 14 07:52:30 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01414 for ; Mon, 14 Apr 2003 07:52:30 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3EBmwqx003738; Mon, 14 Apr 2003 07:48:58 -0400 (EDT) Resent-Date: Mon, 14 Apr 2003 07:48:58 -0400 (EDT) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: Subject: open issues Date: Mon, 14 Apr 2003 13:47:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi all, i have placed some open issues on the following web page: http://www.tschofenig.com/pana/issues_list.html please take a look at it and send comments to the list. i will move the open issues into dan's issue list format once he has finished it. ciao hannes From pana-request@research.telcordia.com Mon Apr 14 09:07:10 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04052 for ; Mon, 14 Apr 2003 09:07:09 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3ED7Kor008230; Mon, 14 Apr 2003 09:07:20 -0400 (EDT) Resent-Date: Mon, 14 Apr 2003 09:07:20 -0400 (EDT) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: Subject: question: pana messaging Date: Mon, 14 Apr 2003 14:52:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi all, the pana draft describes some messages. these messages have a certain semantic and are in most cases directional e.g. PANA-Start-Request <-------- PANA-Start-Answer --------> PANA-Auth-Request <-------- PANA-Auth-Answer --------> why isn't it possible to use these messages in both directions? it would be good to have a generic message which can be executed from both entities (pac and paa) especially with respect to extensibility. furthermore, if the pac is preconfigured with the address of the paa then there is no need for a discovery message. hence the PANA-Start-Request (or better the PANA-Auth-Request) could go from the pac to the paa. currently the cookie stuff mandates a certain direction (thank you dan for pointing to this issue). here are my questions: a) should we add a message to carry AVPs in both directions? c) should we optimize signaling if the pac is already configured with the ip address of the paa? please read the pana draft and verify that the signaling message handling works in all your scenarios. ciao hannes From pana-request@research.telcordia.com Mon Apr 14 15:05:41 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17164 for ; Mon, 14 Apr 2003 15:05:41 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3EJ0bYr003736; Mon, 14 Apr 2003 15:00:37 -0400 (EDT) Resent-Date: Mon, 14 Apr 2003 15:00:37 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: question: pana messaging Date: Mon, 14 Apr 2003 13:56:29 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44017532E6@daebe007.americas.nokia.com> Thread-Topic: question: pana messaging Thread-Index: AcMChuaVfZiUFqUXSk6c7OArVp8mnwAMKKtA From: To: , X-OriginalArrivalTime: 14 Apr 2003 18:56:30.0370 (UTC) FILETIME=[8F583820:01C302B7] X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Resent-Message-ID: <3ejDl.A.P6.UVwm-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA17164 >hi all, > >the pana draft describes some messages. these messages have a certain >semantic and are in most cases directional e.g. > > PANA-Start-Request <-------- > PANA-Start-Answer --------> > > PANA-Auth-Request <-------- > PANA-Auth-Answer --------> > >why isn't it possible to use these messages in both directions? At least the messages you mention above can be used in either direction. >it would be >good to have a generic message which can be executed from both entities (pac >and paa) especially with respect to extensibility. > >furthermore, if the pac is preconfigured with the address of the paa then >there is no need for a discovery message. True. >hence the PANA-Start-Request (or >better the PANA-Auth-Request) could go from the pac to the paa. currently >the cookie stuff mandates a certain direction (thank you dan for pointing to >this issue). > >here are my questions: >a) should we add a message to carry AVPs in both directions? What kind of AVPs did you have in mind? Also I am still unclear of the added benefit of having a generic message that is direction independent. I think the current message set is already sufficient. if you think there is some functionality mandated by requirements that cannot be met via these messages, only then we should think of adding a new message. Otherwise it is better to keep the message set limited. >c) should we optimize signaling if the pac is already configured with the ip >address of the paa? Absolutely. > >please read the pana draft and verify that the signaling message handling >works in all your scenarios. > >ciao >hannes -bp From pana-request@research.telcordia.com Mon Apr 14 16:33:40 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20769 for ; Mon, 14 Apr 2003 16:33:33 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3EKXWWk010790; Mon, 14 Apr 2003 16:33:32 -0400 (EDT) Resent-Date: Mon, 14 Apr 2003 16:33:32 -0400 (EDT) Old-Return-Path: Date: Mon, 14 Apr 2003 17:33:05 -0400 To: Dan.Forsberg@nokia.com Cc: yohba@tari.toshiba.com, Julien.Bournelle@int-evry.fr, pana@research.telcordia.com Subject: Re: Proposal for message formatting (sec. 9). Message-ID: <20030414213252.GB16951@catfish> Mail-Followup-To: Dan.Forsberg@nokia.com, yohba@tari.toshiba.com, Julien.Bournelle@int-evry.fr, pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 19 Resent-Message-ID: <5HB3c.A.doC.bsxm-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Dan, On Fri, Apr 11, 2003 at 01:58:37PM +0300, Dan.Forsberg@nokia.com wrote: > Hi Yoshi, > > Your comments are good. The main question is if it would be benefical enough to use Diameter message formatting. Small comments inline. I basically agree on using Diameter formats for PANA. However, I think we need to resolve assignment policies for AVP Code, Command Code and Command Flags and AVP flags. For example, is the AVP Code space shared between Diameter and PANA, or unique to each protocol, or partially shared between the two? In other words, if PANA defines a new AVP that is specific to PANA with AVP Code = X, then does it mean Diameter cannot assign X for a new AVP for Diameter? The same issue exists for Command Code, Command Flags and AVP flags. Yoshihiro Ohba From pana-request@research.telcordia.com Mon Apr 14 16:53:50 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21483 for ; Mon, 14 Apr 2003 16:53:49 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3EKrx1N012816; Mon, 14 Apr 2003 16:53:59 -0400 (EDT) Resent-Date: Mon, 14 Apr 2003 16:53:59 -0400 (EDT) Old-Return-Path: Date: Mon, 14 Apr 2003 13:53:52 -0700 Subject: Re: Proposal for message formatting (sec. 9). From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Dan, Thank you for putting together the Message Format section. Here are some comments on the current design: - I see the message formats includes some protocol features we have not fully discussed yet. For example: session-id, add-device-id, remove-device-id. I recommend we separately discuss them first, and than incorporate into the message formats if necessary. - I understand the desire to re-use DIAMETER code, but let's not overdo it. From "PANA design perspective", I don't see why we should have "Application ID" field in the header. - Device ID can also include various link-layer address types. Let's reflect that onto the design (currently only IP addresses are included). - How about alignment requirements? I'd say we should require 8-octet alignment for AVPs. Alper > Hi, > > Attached you can find a proposal section (9 Message Formats) > for the draft-ietf-pana-pana-00.txt. It contains some changes > that affect the whole draft. > > There are no error messages defined, which I think should be > fixed. This is not only a message format issue, but a protocol > issue. > > Changes to the pana draft in general: > > - Message naming convention changed (*_ack --> *-Answer, > * --> *-Request) to better reflect the Diameter style > and the nature of the protocol: answers contain data, > but for acks it is not so clear. Requests and answers > describe better the protocol. > > - Thus, 2 messages instead of 1: > - PANA-Auth-Request & PANA-Auth-Answer. > PAA always sends PANA-Auth-Request and requires an > answer to it. > - PANA-Start-Request & PANA-Start-Answer. > PANA-Start messages are different depending on the sender. > - PANA-Success-Request/Answer: PANA requires answer to success, > because he PANA SA is not otherwise established properly. > And for sake of simplicity, the same naming convention > should be used. > > - Flag change: A flag to R flag to better reflect Diameter style. > Requests have the R flag set, answers unset. > > - Name change: Data-Protection --> Protection-Capability. > Data-Protection is misleading term. > > - Name change: Revocation-Status --> Termination-Cause (Diameter). > There is already an AVP that suits for this purpose. > > - PANA-Disconnect-Request now contains Termination-Cause AVP. > There are different reasons for the user to disconnect. > > > > Comments welcome, > - Dan > From pana-request@research.telcordia.com Mon Apr 14 18:43:16 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25849 for ; Mon, 14 Apr 2003 18:43:16 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3EMgQsA021830; Mon, 14 Apr 2003 18:42:26 -0400 (EDT) Resent-Date: Mon, 14 Apr 2003 18:42:26 -0400 (EDT) Old-Return-Path: Date: Mon, 14 Apr 2003 19:41:47 -0400 To: Hannes Tschofenig Cc: pana@research.telcordia.com Subject: Re: question: pana messaging Message-ID: <20030414234147.GB18357@catfish> Mail-Followup-To: Hannes Tschofenig , pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 76 Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Hannes, On Mon, Apr 14, 2003 at 02:52:37PM +0200, Hannes Tschofenig wrote: > hi all, > > the pana draft describes some messages. these messages have a certain > semantic and are in most cases directional e.g. > > PANA-Start-Request <-------- > PANA-Start-Answer --------> > > PANA-Auth-Request <-------- > PANA-Auth-Answer --------> > > why isn't it possible to use these messages in both directions? it would be > good to have a generic message which can be executed from both entities (pac > and paa) especially with respect to extensibility. > > furthermore, if the pac is preconfigured with the address of the paa then > there is no need for a discovery message. hence the PANA-Start-Request (or > better the PANA-Auth-Request) could go from the pac to the paa. currently > the cookie stuff mandates a certain direction (thank you dan for pointing to > this issue). Even if the PaC is preconfigured with the address of the paa, cookie-based 3-way handshake is needed to avoid resource consumption attacks during the handshake phase. Currently this is done by discovery/start(-req)/start(-ans) message and I don't think we can omit these exchanges when the PAA does not have any state for the PaC before the handshake. On the other hand, we can omit some of the messages at the time of EAP-based re-authentication in whiich the PAA already has a state for the PaC. It looks like: PaC PAA Message(tseq,rseq)[AVPs] ----------------------------------------------------- // Discovery and initial handshake phase -----> PANA_discover(0,0) // Authentication phase <----- PANA_auth(p,q)[EAP, MAC] // or PANA-Auth-Request -----> PANA_auth(q+1,p)[EAP, MAC] // or PANA-Auth-Answer . . where the sequence numbers continue from the previous message exchange instead of being started from fresh ones. If EAP-based re-authentication is initiated from PAA, the first discover message is not needed. We can add this optimized behavior to section 4.4. > > here are my questions: > a) should we add a message to carry AVPs in both directions? So far I don't see a requirement for this. > c) should we optimize signaling if the pac is already configured with the ip > address of the paa? I would say that we should optimize signaling when the PAA has already a state for the PaC regardless of whether the PaC is already configured with the IP address of the PAA. > > please read the pana draft and verify that the signaling message handling > works in all your scenarios. > > ciao > hannes > > Yoshihiro Ohba From pana-request@research.telcordia.com Tue Apr 15 02:49:19 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17015 for ; Tue, 15 Apr 2003 02:48:55 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3F6kiAs017049; Tue, 15 Apr 2003 02:46:44 -0400 (EDT) Resent-Date: Tue, 15 Apr 2003 02:46:44 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: question: pana messaging Date: Tue, 15 Apr 2003 09:42:50 +0300 Message-ID: Thread-Topic: question: pana messaging Thread-Index: AcMC10jNqNGF6iVOTS6F7iMz728rTQAQLxvA From: To: , Cc: X-OriginalArrivalTime: 15 Apr 2003 06:42:51.0190 (UTC) FILETIME=[3C482560:01C3031A] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi, The generic message that can be sent to both directions is PANA-Reauth-Request(/Answer). PANA-Start-Request/Answer message pairs are unidirectional because of the cookie stuff. Currently, PAA initiates authentication with PANA-Auth-Request, thus the direction. It's easier to create the state machines, when message sequences are clear and simple. Current PANA draft states that PaC unicasts discovery message to PAA, even it knows the address of the PAA. More comments inline. > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 15 April, 2003 02:42 > To: Hannes Tschofenig > Cc: pana@research.telcordia.com > Subject: Re: question: pana messaging > > > Hi Hannes, > > On Mon, Apr 14, 2003 at 02:52:37PM +0200, Hannes Tschofenig wrote: > > hi all, > > > > the pana draft describes some messages. these messages have > a certain > > semantic and are in most cases directional e.g. > > > > PANA-Start-Request <-------- > > PANA-Start-Answer --------> > > > > PANA-Auth-Request <-------- > > PANA-Auth-Answer --------> > > > > why isn't it possible to use these messages in both > directions? it would be > > good to have a generic message which can be executed from > both entities (pac > > and paa) especially with respect to extensibility. > > > > furthermore, if the pac is preconfigured with the address > of the paa then > > there is no need for a discovery message. hence the > PANA-Start-Request (or > > better the PANA-Auth-Request) could go from the pac to the > paa. currently > > the cookie stuff mandates a certain direction (thank you > dan for pointing to > > this issue). > > Even if the PaC is preconfigured with the address of the paa, > cookie-based 3-way handshake is needed to avoid resource consumption > attacks during the handshake phase. Currently this is done by > discovery/start(-req)/start(-ans) message and I don't think > we can omit > these exchanges when the PAA does not have any state for the > PaC before > the handshake. > > On the other hand, we can omit some of the messages at the time of > EAP-based re-authentication in whiich the PAA already has a state for > the PaC. It looks like: > > PaC PAA Message(tseq,rseq)[AVPs] > ----------------------------------------------------- > // Discovery and initial handshake phase > -----> PANA_discover(0,0) > > // Authentication phase > <----- PANA_auth(p,q)[EAP, MAC] // or PANA-Auth-Request > -----> PANA_auth(q+1,p)[EAP, MAC] // or PANA-Auth-Answer > . > . > > where the sequence numbers continue from the previous message exchange > instead of being started from fresh ones. If EAP-based > re-authentication is initiated from PAA, the first discover message is > not needed. > > We can add this optimized behavior to section 4.4. For me this is session resumption and adds a new feature to the PANA protocol. This may be useful in some cases. In this case the SA is still alive between PaC and PAA, but the reauthentication messages are not sent anymore? Thus, the EP may be blocking traffic from PaC.. session resumption is a fast way to enable network access again, without full handshake and AAA backend involvement? Security aspects? This is similar to TLS. > > > > here are my questions: > > a) should we add a message to carry AVPs in both directions? > > So far I don't see a requirement for this. PANA-Reauth-Request. > > c) should we optimize signaling if the pac is already > configured with the ip > > address of the paa? > Cookie stuff doesn't make life easy with this. > I would say that we should optimize signaling when the PAA > has already a > state for the PaC regardless of whether the PaC is already configured > with the IP address of the PAA. > > > > > please read the pana draft and verify that the signaling > message handling > > works in all your scenarios. > > > > ciao > > hannes > > > > > > Yoshihiro Ohba > > From pana-request@research.telcordia.com Tue Apr 15 03:42:08 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18361 for ; Tue, 15 Apr 2003 03:42:08 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3F7fQw4019853; Tue, 15 Apr 2003 03:41:26 -0400 (EDT) Resent-Date: Tue, 15 Apr 2003 03:41:26 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Proposal for message formatting (sec. 9). Date: Tue, 15 Apr 2003 10:37:29 +0300 Message-ID: Thread-Topic: Proposal for message formatting (sec. 9). Thread-Index: AcMCx+diAe+vnSNuReKfpVwXgaKdqAAUlsXQ From: To: , X-OriginalArrivalTime: 15 Apr 2003 07:37:31.0019 (UTC) FILETIME=[DF3655B0:01C30321] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA18361 Alper, Thank you for your comments. > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 14 April, 2003 23:54 > To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > Subject: Re: Proposal for message formatting (sec. 9). > > > > Hi Dan, > > Thank you for putting together the Message Format section. > > Here are some comments on the current design: > > - I see the message formats includes some protocol features > we have not > fully discussed yet. For example: session-id, add-device-id, > remove-device-id. I recommend we separately discuss them > first, and than > incorporate into the message formats if necessary. Sure. > - I understand the desire to re-use DIAMETER code, but let's > not overdo it. > From "PANA design perspective", I don't see why we should > have "Application > ID" field in the header. To make the header structure similar to Diameter. If we break it, then it doesn't matter what kind of format we use, because implementations must be different then. We have a prototype that uses Diameter message formatting (testing SeNAA) on top of UDP. This is a very nice feature, because the Diameter stack callbacks can be used with PANA messages too. The interaction with the AAA backend becomes very smooth. This means of course that Diameter and PANA id values don't overlap. With Diameter PANA could have Application-Id 4 and the new AVPs could be registered from the Diameter number space (or then we could use Vendor-Id for PANA). I talked with John Loughney (one of the authors of Diameter base spec) about this and he didn't see any problems with this approach. PANA could support different applications in the future too. A preshared SA between PaC and PAA and extensible message types sounds compelling. And if the protocol works smoothly with AAA backends (one doesn't have to specify different AVPs with Diameter and PANA) the scenario looks interesting. > - Device ID can also include various link-layer address > types. Let's reflect > that onto the design (currently only IP addresses are included). Sure. > - How about alignment requirements? I'd say we should require 8-octet > alignment for AVPs. If that doesn't break the Diameter compatibility. > > Alper > > > Hi, > > > > Attached you can find a proposal section (9 Message Formats) > > for the draft-ietf-pana-pana-00.txt. It contains some changes > > that affect the whole draft. > > > > There are no error messages defined, which I think should be > > fixed. This is not only a message format issue, but a protocol > > issue. > > > > Changes to the pana draft in general: > > > > - Message naming convention changed (*_ack --> *-Answer, > > * --> *-Request) to better reflect the Diameter style > > and the nature of the protocol: answers contain data, > > but for acks it is not so clear. Requests and answers > > describe better the protocol. > > > > - Thus, 2 messages instead of 1: > > - PANA-Auth-Request & PANA-Auth-Answer. > > PAA always sends PANA-Auth-Request and requires an > > answer to it. > > - PANA-Start-Request & PANA-Start-Answer. > > PANA-Start messages are different depending on the sender. > > - PANA-Success-Request/Answer: PANA requires answer to success, > > because he PANA SA is not otherwise established properly. > > And for sake of simplicity, the same naming convention > > should be used. > > > > - Flag change: A flag to R flag to better reflect Diameter style. > > Requests have the R flag set, answers unset. > > > > - Name change: Data-Protection --> Protection-Capability. > > Data-Protection is misleading term. > > > > - Name change: Revocation-Status --> Termination-Cause (Diameter). > > There is already an AVP that suits for this purpose. > > > > - PANA-Disconnect-Request now contains Termination-Cause AVP. > > There are different reasons for the user to disconnect. > > > > > > > > Comments welcome, > > - Dan > > > > From pana-request@research.telcordia.com Tue Apr 15 20:16:09 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17489 for ; Tue, 15 Apr 2003 20:16:01 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3G0Ew3A002634; Tue, 15 Apr 2003 20:14:58 -0400 (EDT) Resent-Date: Tue, 15 Apr 2003 20:14:58 -0400 (EDT) Old-Return-Path: Date: Tue, 15 Apr 2003 17:14:54 -0700 Subject: Re: Proposal for message formatting (sec. 9). From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Dan, It seems like you are treating Diameter compatibility as if it is a requirement. It might be a desirable feature at best. Sure it helps with some code reuse or implimentation shortcuts, but these are not necessary for the protocol design, and should not cause undesirable side effects. PANA is not really meant to be an appendix to Diameter. Diameter is one of the possible backend AAA protocols only. For example, addition of the "application id" field is not justifiable for PANA imo. I didn't quite understand the future application support. For future extensions a reserved field might be more than sufficient. Actually AVPs might be good enough too. 64-bit alignment is a nice feature too. I'm not sure which one is better though: Diameter harmonization or this. Alper > Alper, > > Thank you for your comments. > >> -----Original Message----- >> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] >> Sent: 14 April, 2003 23:54 >> To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com >> Subject: Re: Proposal for message formatting (sec. 9). >> >> >> >> Hi Dan, >> >> Thank you for putting together the Message Format section. >> >> Here are some comments on the current design: >> >> - I see the message formats includes some protocol features >> we have not >> fully discussed yet. For example: session-id, add-device-id, >> remove-device-id. I recommend we separately discuss them >> first, and than >> incorporate into the message formats if necessary. > > Sure. > >> - I understand the desire to re-use DIAMETER code, but let's >> not overdo it. >> From "PANA design perspective", I don't see why we should >> have "Application >> ID" field in the header. > > To make the header structure similar to Diameter. If we break it, then it > doesn't matter what kind of format we use, because implementations must be > different then. > > We have a prototype that uses Diameter message formatting (testing SeNAA) on > top of UDP. This is a very nice feature, because the Diameter stack callbacks > can be used with PANA messages too. The interaction with the AAA backend > becomes very smooth. This means of course that Diameter and PANA id values > don't overlap. > > With Diameter PANA could have Application-Id 4 and the new AVPs could be > registered from the Diameter number space (or then we could use Vendor-Id for > PANA). I talked with John Loughney (one of the authors of Diameter base spec) > about this and he didn't see any problems with this approach. > > PANA could support different applications in the future too. A preshared SA > between PaC and PAA and extensible message types sounds compelling. And if the > protocol works smoothly with AAA backends (one doesn't have to specify > different AVPs with Diameter and PANA) the scenario looks interesting. > >> - Device ID can also include various link-layer address >> types. Let's reflect >> that onto the design (currently only IP addresses are included). > > Sure. > >> - How about alignment requirements? I'd say we should require 8-octet >> alignment for AVPs. > > If that doesn't break the Diameter compatibility. > >> >> Alper >> >>> Hi, >>> >>> Attached you can find a proposal section (9 Message Formats) >>> for the draft-ietf-pana-pana-00.txt. It contains some changes >>> that affect the whole draft. >>> >>> There are no error messages defined, which I think should be >>> fixed. This is not only a message format issue, but a protocol >>> issue. >>> >>> Changes to the pana draft in general: >>> >>> - Message naming convention changed (*_ack --> *-Answer, >>> * --> *-Request) to better reflect the Diameter style >>> and the nature of the protocol: answers contain data, >>> but for acks it is not so clear. Requests and answers >>> describe better the protocol. >>> >>> - Thus, 2 messages instead of 1: >>> - PANA-Auth-Request & PANA-Auth-Answer. >>> PAA always sends PANA-Auth-Request and requires an >>> answer to it. >>> - PANA-Start-Request & PANA-Start-Answer. >>> PANA-Start messages are different depending on the sender. >>> - PANA-Success-Request/Answer: PANA requires answer to success, >>> because he PANA SA is not otherwise established properly. >>> And for sake of simplicity, the same naming convention >>> should be used. >>> >>> - Flag change: A flag to R flag to better reflect Diameter style. >>> Requests have the R flag set, answers unset. >>> >>> - Name change: Data-Protection --> Protection-Capability. >>> Data-Protection is misleading term. >>> >>> - Name change: Revocation-Status --> Termination-Cause (Diameter). >>> There is already an AVP that suits for this purpose. >>> >>> - PANA-Disconnect-Request now contains Termination-Cause AVP. >>> There are different reasons for the user to disconnect. >>> >>> >>> >>> Comments welcome, >>> - Dan >>> >> >> > > From pana-request@research.telcordia.com Wed Apr 16 06:40:49 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24615 for ; Wed, 16 Apr 2003 06:40:30 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3GAd64J009154; Wed, 16 Apr 2003 06:39:06 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 06:39:06 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Proposal for message formatting (sec. 9). Date: Wed, 16 Apr 2003 13:35:06 +0300 Message-ID: Thread-Topic: Proposal for message formatting (sec. 9). Thread-Index: AcMDrSX7GjkSOkT/QYm5Qs9egrcUNAAUK4mQ From: To: , X-OriginalArrivalTime: 16 Apr 2003 10:35:06.0664 (UTC) FILETIME=[D8E27A80:01C30403] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA24615 Alper, Diameter compatibility is not a requirement, but a possibility :). I don't see it causing udesirable side effects. App-Id is not causing problems, but making the header a bit bigger. It can help PANA to become more popular/useful and to cope with possible future extensions/capabilities (list of app-ids supported). Do you see any drawbacks in this, or issues why we should not be compatible with Diameter? We should ask other's opinions too. - Dan > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 16 April, 2003 03:15 > To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > Subject: Re: Proposal for message formatting (sec. 9). > > > Hi Dan, > > It seems like you are treating Diameter compatibility as if it is a > requirement. It might be a desirable feature at best. Sure it > helps with > some code reuse or implimentation shortcuts, but these are > not necessary > for the protocol design, and should not cause undesirable > side effects. > PANA is not really meant to be an appendix to Diameter. > Diameter is one of > the possible backend AAA protocols only. > > For example, addition of the "application id" field is not > justifiable for > PANA imo. I didn't quite understand the future application > support. For > future extensions a reserved field might be more than > sufficient. Actually > AVPs might be good enough too. > > 64-bit alignment is a nice feature too. I'm not sure which > one is better > though: Diameter harmonization or this. > > Alper > > > > Alper, > > > > Thank you for your comments. > > > >> -----Original Message----- > >> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > >> Sent: 14 April, 2003 23:54 > >> To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > >> Subject: Re: Proposal for message formatting (sec. 9). > >> > >> > >> > >> Hi Dan, > >> > >> Thank you for putting together the Message Format section. > >> > >> Here are some comments on the current design: > >> > >> - I see the message formats includes some protocol features > >> we have not > >> fully discussed yet. For example: session-id, add-device-id, > >> remove-device-id. I recommend we separately discuss them > >> first, and than > >> incorporate into the message formats if necessary. > > > > Sure. > > > >> - I understand the desire to re-use DIAMETER code, but let's > >> not overdo it. > >> From "PANA design perspective", I don't see why we should > >> have "Application > >> ID" field in the header. > > > > To make the header structure similar to Diameter. If we > break it, then it > > doesn't matter what kind of format we use, because > implementations must be > > different then. > > > > We have a prototype that uses Diameter message formatting > (testing SeNAA) on > > top of UDP. This is a very nice feature, because the > Diameter stack callbacks > > can be used with PANA messages too. The interaction with > the AAA backend > > becomes very smooth. This means of course that Diameter and > PANA id values > > don't overlap. > > > > With Diameter PANA could have Application-Id 4 and the new > AVPs could be > > registered from the Diameter number space (or then we could > use Vendor-Id for > > PANA). I talked with John Loughney (one of the authors of > Diameter base spec) > > about this and he didn't see any problems with this approach. > > > > PANA could support different applications in the future > too. A preshared SA > > between PaC and PAA and extensible message types sounds > compelling. And if the > > protocol works smoothly with AAA backends (one doesn't have > to specify > > different AVPs with Diameter and PANA) the scenario looks > interesting. > > > >> - Device ID can also include various link-layer address > >> types. Let's reflect > >> that onto the design (currently only IP addresses are included). > > > > Sure. > > > >> - How about alignment requirements? I'd say we should > require 8-octet > >> alignment for AVPs. > > > > If that doesn't break the Diameter compatibility. > > > >> > >> Alper > >> > >>> Hi, > >>> > >>> Attached you can find a proposal section (9 Message Formats) > >>> for the draft-ietf-pana-pana-00.txt. It contains some changes > >>> that affect the whole draft. > >>> > >>> There are no error messages defined, which I think should be > >>> fixed. This is not only a message format issue, but a protocol > >>> issue. > >>> > >>> Changes to the pana draft in general: > >>> > >>> - Message naming convention changed (*_ack --> *-Answer, > >>> * --> *-Request) to better reflect the Diameter style > >>> and the nature of the protocol: answers contain data, > >>> but for acks it is not so clear. Requests and answers > >>> describe better the protocol. > >>> > >>> - Thus, 2 messages instead of 1: > >>> - PANA-Auth-Request & PANA-Auth-Answer. > >>> PAA always sends PANA-Auth-Request and requires an > >>> answer to it. > >>> - PANA-Start-Request & PANA-Start-Answer. > >>> PANA-Start messages are different depending on the sender. > >>> - PANA-Success-Request/Answer: PANA requires answer to success, > >>> because he PANA SA is not otherwise established properly. > >>> And for sake of simplicity, the same naming convention > >>> should be used. > >>> > >>> - Flag change: A flag to R flag to better reflect Diameter style. > >>> Requests have the R flag set, answers unset. > >>> > >>> - Name change: Data-Protection --> Protection-Capability. > >>> Data-Protection is misleading term. > >>> > >>> - Name change: Revocation-Status --> Termination-Cause (Diameter). > >>> There is already an AVP that suits for this purpose. > >>> > >>> - PANA-Disconnect-Request now contains Termination-Cause AVP. > >>> There are different reasons for the user to disconnect. > >>> > >>> > >>> > >>> Comments welcome, > >>> - Dan > >>> > >> > >> > > > > > > From pana-request@research.telcordia.com Wed Apr 16 09:31:28 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00585 for ; Wed, 16 Apr 2003 09:31:27 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3GDUJ9L018994; Wed, 16 Apr 2003 09:30:19 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 09:30:19 -0400 (EDT) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: "Yoshihiro Ohba" Cc: Subject: RE: question: pana messaging Date: Wed, 16 Apr 2003 15:14:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <20030414234147.GB18357@catfish> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi yoshi, please see my comments inline: > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Dienstag, 15. April 2003 01:42 > To: Hannes Tschofenig > Cc: pana@research.telcordia.com > Subject: Re: question: pana messaging > > > Hi Hannes, > > On Mon, Apr 14, 2003 at 02:52:37PM +0200, Hannes Tschofenig wrote: > > hi all, > > > > the pana draft describes some messages. these messages have a certain > > semantic and are in most cases directional e.g. > > > > PANA-Start-Request <-------- > > PANA-Start-Answer --------> > > > > PANA-Auth-Request <-------- > > PANA-Auth-Answer --------> > > > > why isn't it possible to use these messages in both directions? > it would be > > good to have a generic message which can be executed from both > entities (pac > > and paa) especially with respect to extensibility. > > > > furthermore, if the pac is preconfigured with the address of > the paa then > > there is no need for a discovery message. hence the > PANA-Start-Request (or > > better the PANA-Auth-Request) could go from the pac to the paa. > currently > > the cookie stuff mandates a certain direction (thank you dan > for pointing to > > this issue). > > Even if the PaC is preconfigured with the address of the paa, > cookie-based 3-way handshake is needed to avoid resource consumption > attacks during the handshake phase. Currently this is done by > discovery/start(-req)/start(-ans) message and I don't think we can omit > these exchanges when the PAA does not have any state for the PaC before > the handshake. you are right with the 3-way handshake. you also know that i am not fully satisfied with the dos protection as it is. this is, however, a different issue which needs to be added to the open issues list. > > On the other hand, we can omit some of the messages at the time of > EAP-based re-authentication in whiich the PAA already has a state for > the PaC. It looks like: > > PaC PAA Message(tseq,rseq)[AVPs] > ----------------------------------------------------- > // Discovery and initial handshake phase > -----> PANA_discover(0,0) > > // Authentication phase > <----- PANA_auth(p,q)[EAP, MAC] // or PANA-Auth-Request > -----> PANA_auth(q+1,p)[EAP, MAC] // or PANA-Auth-Answer > . > . > > where the sequence numbers continue from the previous message exchange > instead of being started from fresh ones. If EAP-based > re-authentication is initiated from PAA, the first discover message is > not needed. i certainly agree with you. > > We can add this optimized behavior to section 4.4. i would vote for it. > > > > > here are my questions: > > a) should we add a message to carry AVPs in both directions? > > So far I don't see a requirement for this. dan mentioned the Reauth-Request(/Answer) message. that would be fine for me. there are, however, other messages which could possible carry AVPs from both entities such as the Data-Protection AVP. in figure 4 of the current draft it says: <----- PANA_success(x+3,y+2) // F-flag set [EAP{Success}, Device-Id, Data-Protection, MAC] -----> PANA_success_ack(y+3,x+3) [Device-Id, MAC] // F-flag set however, the Data-Protection might also be negotiated e.g. not every pac supports ipsec. hence if the paa forces the pac to use ipsec then no network access would be possible. if the paa (and the pac) additionally support link layer security then they could use link layer sec. instead. furtermore the paa might not be able to trigger ipsec after the finished eap authentication. for example: the pac starts without an ip address configured. hence after successful eap auth. the pac obtains an ip address e.g. using stateful address autoconfig. (dhcp). subsequently ipsec can be enabled. thereby the client might send a Data-Protection AVP saying that he is ready to enable ipsec. this is also an example why it should be possible to update device-id info at the paa. the pac cannot provide his ip address. later it is, however, possible. > > > c) should we optimize signaling if the pac is already > configured with the ip > > address of the paa? > > I would say that we should optimize signaling when the PAA has already a > state for the PaC regardless of whether the PaC is already configured > with the IP address of the PAA. ok. > > > > > please read the pana draft and verify that the signaling > message handling > > works in all your scenarios. > > > > ciao > > hannes > > ciao hannes > > > > Yoshihiro Ohba > From pana-request@research.telcordia.COM Wed Apr 16 10:40:32 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03986 for ; Wed, 16 Apr 2003 10:40:32 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3GDnlGY021091; Wed, 16 Apr 2003 09:49:47 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 09:49:47 -0400 (EDT) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: Subject: eap method sequencing Date: Wed, 16 Apr 2003 15:47:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Resent-Message-ID: Resent-From: pana@research.telcordia.COM X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.COM Content-Transfer-Encoding: 7bit hi all, i would like to point the group to an interesting discussion about sequencing in the eap wg. pana provides eap method sequencing. we do we need to limit to two? (seems to be a fairly low number!) " PAA enables two separate authentication, it should not set F-flag in the PANA_success or PANA_failure message after the first EAP method. " does someone has an option regarding sequencing and scenarios in this group? ciao hannes ----- Original Message ----- From: "John Vollbrecht" To: ; Sent: Wednesday, April 16, 2003 3:22 AM Subject: Re: [eap] Re: Issue 104: Sequence prohibition > > I believe the discussion was that sequences would not be allowed except > within a protected method. I think the requirement here is that > "protected" variable be set that then allows sequences. > > We should add this to the state machine. > > John > > --On Tuesday, April 15, 2003 9:50 PM +0300 Pasi.Eronen@nokia.com wrote: > > > > > Hi, > > > > Was this the consensus at IETF 56? The minutes aren't > > completely clear on this topic: issue 87 really refers > > only to starting another method before the first one is > > completed. Was the decision that not only type change > > during one method is forbidden, but all sequences > > (of methods >=4) are forbidden? > > > > (I'm not an fan of sequences myself, but we've been > > working on the state machine diagrams with John, Nick > > and Yoshihiro, and the current versions are in rather > > good shape, and do support sequences. We can change > > them to forbid sequences if the consensus is > > that they must not be allowed.) > > > > Best regards, > > Pasi > > > > > -----Original Message----- > > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > > Sent: Monday, April 14, 2003 8:46 PM > > > To: eap@frascone.com > > > Subject: [eap] Issue 104: Sequence prohibition > > > > > > > > > Submitter name: Bernard Aboba > > > Submitter email address: aboba@internaut.com > > > Date first submitted: April 14th, 2003 > > > Reference: > > > Document: EAP-01 > > > Comment type: T > > > Priority: S > > > Section: 2.1 > > > Rationale/Explanation of issue: > > > > > > At IETF 56, it was proposed that sequences of EAP methods MUST NOT > be > > > supported (with an exception for tunneled EAP methods). The > > > following text > > > changes support that proposal. > > > > > > Change Section 2.1 from: > > > > > > " 2.1 Support for sequences > > > > > > An EAP conversation MAY utilize a sequence of methods. A common > > > example of this is an Identity request followed by a single EAP > > > authentication method such as an MD5-Challenge. However, within or > > > associated with each EAP server, it is not anticipated that a > > > particular named peer will utilize multiple authentication methods > > > (Type 4 or greater), either by supporting a choice of methods or by > > > using multiple methods in sequence. This would make the peer > > > vulnerable to attacks that negotiate the least secure method from > > > among a set (negotiation attacks, described in Section 7.8) or > > > man-in-the-middle attacks (described in Section 7.4). Instead, for > > > each named peer there SHOULD be an indication of exactly one method > > > used to authenticate that peer name. If a peer needs to make use of > > > different authentication methods under different circumstances, then > > > distinct identities SHOULD be employed, each of which identifies > > > exactly one authentication method. If additional authentication > > > methods are required beyond the initial one, the authenticator MAY > > > send a Request packet for a subsequent authentication method, or it > > > MAY send another Identity request. If the peer does not support > > > additional methods, it SHOULD respond with a Nak, indicating no > > > acceptable alternative, as described in Section 5.3. However, peer > > > implementations MAY not respond at all, in which case a timeout will > > > result and authentication will fail. Since the authenticator > > > presumably requires successful completion of the sequence in order > to > > > grant access, authentication failure is the correct result. > > > Therefore, it is not necessary for the authenticator to determine > > > that the peer supports sequences prior to sending a Request for a > > > subsequent authentication method. > > > > > > The above prescription also applies in the situation where an > > > authenticator sends a message of a different Type prior to > completion > > > of the final round of a given method. If the peer wishes to continue > > > authenticating with the method in progress, it SHOULD send a Nak in > > > response to such a Request, indicating the Type in progress as the > > > alternative. Otherwise it MAY send a Response with the same Type as > > > the Request. Since an EAP packet with a different Type may be sent > > > by an attacker, an authenticator receiving a Nak including a > > > preference for the Type in progress SHOULD log the event, but > > > otherwise not take any action. > > > > > > Once a peer has sent a Response of the same Type as a Request, some > > > existing peer implementations might expect the method to run to > > > completion. As a result, these implementations silently discard EAP > > > Requests of a Type different from the method in progress, despite > the > > > requirement for a Response in Section 4.1. For this reason, EAP > > > authenticators that must interoperate with these peers are > > > discouraged from switching methods before the final round of a given > > > method has completed." > > > > > > To: > > > > > > "2.1 Support for sequences > > > > > > An EAP conversation MAY utilize a sequence of methods. A common > > > example of this is an Identity request followed by a single EAP > > > authentication method such as an MD5-Challenge. However a peer > > > MUST utilize only one authentication method (Type 4 or greater) > > > within an EAP conversation. > > > > > > Once a peer has sent a Response of the same Type as the initial > > > Request, an authenticator MUST NOT send a Request of a different > Type > > > prior to completion of the final round of a given method, and > > > MUST NOT send a Request for an additional methods of any Type > > > after completion of the initial authentication method. > > > > > > Supporting multiple authentication > > > methods within an EAP conversation would add complexity > > > to the EAP protocol, would enable man-in-the-middle attacks > > > (see Section 7.4), and would result in interoperablity problems, > > > since existing EAP implementations typically do not support > > > sequences. > > > > > > If an additional authentication method is requested by the > > > authenticator, or if the authenticator sends a Request of > > > a different Type prior to completion of the final round of > > > a given method, the peer SHOULD silently discard the > > > Request. As an alternative, the peer MAY > > > respond with a Nak, indicating no acceptable alternative, > > > as described in Section 5.3. Since spoofed EAP > > > Request packets may be sent by an attacker, an > > > an authenticator receiving an unexpected Nak SHOULD log the > > > event. > > > > > > The case where a single EAP authentication method is > > > utilized, but other methods are run inside it, does not > > > qualify as a sequence of EAP methods as defined here. Such > > > "tunneled" methods appear to the EAP state machine as a single > > > method. Backward compatibility can be provided, since a peer > > > not supporting a "tunneled" method can reply to the initial > > > EAP-Request with a Nak. To avoid adding man-in-the-middle > > > vulnerabilities, "tunneled" methods MUST support protection > > > against these attacks. > > > > > > Within or associated with each EAP server, it is not anticipated > > > that a particular named pper will support a choice of methods. > > > This would make the peer vulnerable to attacks that negotiate the > > > least secure method from among a set (negotiation attacks, > > > described in Section 7.8). Instead, for > > > each named peer there SHOULD be an indication of exactly one method > > > used to authenticate that peer name. If a peer needs to make use of > > > different authentication methods under different circumstances, then > > > distinct identities SHOULD be employed, each of which identifies > > > exactly one authentication method. " > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From pana-request@research.telcordia.COM Wed Apr 16 10:48:54 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04321 for ; Wed, 16 Apr 2003 10:48:53 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3GDLge0018210; Wed, 16 Apr 2003 09:21:42 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 09:21:42 -0400 (EDT) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: , Cc: Subject: RE: question: pana messaging Date: Wed, 16 Apr 2003 15:19:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Resent-Message-ID: <3FoOYC.A.PcE.kjVn-@thumper> Resent-From: pana@research.telcordia.COM X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.COM Content-Transfer-Encoding: 7bit hi dan, thanks for your comments. using the PANA-Reauth-Request(/Answer) for AVPs which could be exchanged in both directions seems to be fine for me. eap-based re-authentication. we once mentioned that there are two possible ways to provide re-authentication. a) MAC-AVP. this is fine and works well for refresh messages to keep state alive. b) EAP-based reauth. as yoshi said it might be good to have a possibility to trigger a reauthentication exchange without requiring the discovery/cookie stuff todo again. ciao hannes > -----Original Message----- > From: Dan.Forsberg@nokia.com [mailto:Dan.Forsberg@nokia.com] > Sent: Dienstag, 15. April 2003 08:43 > To: yohba@tari.toshiba.com; hannes@tschofenig.com > Cc: pana@research.telcordia.com > Subject: RE: question: pana messaging > > > Hi, > > The generic message that can be sent to both directions is > PANA-Reauth-Request(/Answer). PANA-Start-Request/Answer message > pairs are unidirectional because of the cookie stuff. Currently, > PAA initiates authentication with PANA-Auth-Request, thus the > direction. It's easier to create the state machines, when message > sequences are clear and simple. Current PANA draft states that > PaC unicasts discovery message to PAA, even it knows the address > of the PAA. > > More comments inline. > > > -----Original Message----- > > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: 15 April, 2003 02:42 > > To: Hannes Tschofenig > > Cc: pana@research.telcordia.com > > Subject: Re: question: pana messaging > > > > > > Hi Hannes, > > > > On Mon, Apr 14, 2003 at 02:52:37PM +0200, Hannes Tschofenig wrote: > > > hi all, > > > > > > the pana draft describes some messages. these messages have > > a certain > > > semantic and are in most cases directional e.g. > > > > > > PANA-Start-Request <-------- > > > PANA-Start-Answer --------> > > > > > > PANA-Auth-Request <-------- > > > PANA-Auth-Answer --------> > > > > > > why isn't it possible to use these messages in both > > directions? it would be > > > good to have a generic message which can be executed from > > both entities (pac > > > and paa) especially with respect to extensibility. > > > > > > furthermore, if the pac is preconfigured with the address > > of the paa then > > > there is no need for a discovery message. hence the > > PANA-Start-Request (or > > > better the PANA-Auth-Request) could go from the pac to the > > paa. currently > > > the cookie stuff mandates a certain direction (thank you > > dan for pointing to > > > this issue). > > > > Even if the PaC is preconfigured with the address of the paa, > > cookie-based 3-way handshake is needed to avoid resource consumption > > attacks during the handshake phase. Currently this is done by > > discovery/start(-req)/start(-ans) message and I don't think > > we can omit > > these exchanges when the PAA does not have any state for the > > PaC before > > the handshake. > > > > On the other hand, we can omit some of the messages at the time of > > EAP-based re-authentication in whiich the PAA already has a state for > > the PaC. It looks like: > > > > PaC PAA Message(tseq,rseq)[AVPs] > > ----------------------------------------------------- > > // Discovery and initial handshake phase > > -----> PANA_discover(0,0) > > > > // Authentication phase > > <----- PANA_auth(p,q)[EAP, MAC] // or PANA-Auth-Request > > -----> PANA_auth(q+1,p)[EAP, MAC] // or PANA-Auth-Answer > > . > > . > > > > where the sequence numbers continue from the previous message exchange > > instead of being started from fresh ones. If EAP-based > > re-authentication is initiated from PAA, the first discover message is > > not needed. > > > > We can add this optimized behavior to section 4.4. > > For me this is session resumption and adds a new feature to the > PANA protocol. This may be useful in some cases. In this case the > SA is still alive between PaC and PAA, but the reauthentication > messages are not sent anymore? Thus, the EP may be blocking > traffic from PaC.. session resumption is a fast way to enable > network access again, without full handshake and AAA backend > involvement? Security aspects? This is similar to TLS. > > > > > > > > here are my questions: > > > a) should we add a message to carry AVPs in both directions? > > > > So far I don't see a requirement for this. > > PANA-Reauth-Request. > > > > c) should we optimize signaling if the pac is already > > configured with the ip > > > address of the paa? > > > > Cookie stuff doesn't make life easy with this. > > > I would say that we should optimize signaling when the PAA > > has already a > > state for the PaC regardless of whether the PaC is already configured > > with the IP address of the PAA. > > > > > > > > please read the pana draft and verify that the signaling > > message handling > > > works in all your scenarios. > > > > > > ciao > > > hannes > > > > > > > > > > Yoshihiro Ohba > > > > > From pana-request@research.telcordia.COM Wed Apr 16 10:48:36 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04315 for ; Wed, 16 Apr 2003 10:48:35 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3GDN5LU018376; Wed, 16 Apr 2003 09:23:05 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 09:23:05 -0400 (EDT) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: , Subject: RE: question: pana messaging Date: Wed, 16 Apr 2003 15:20:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <697DAA22C5004B4596E033803A7CEF44017532E6@daebe007.americas.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Resent-Message-ID: Resent-From: pana@research.telcordia.COM X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.COM Content-Transfer-Encoding: 7bit hi, please see my comments inline: > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Montag, 14. April 2003 20:56 > To: hannes@tschofenig.com; pana@research.telcordia.com > Subject: RE: question: pana messaging > > > > >hi all, > > > >the pana draft describes some messages. these messages have a certain > >semantic and are in most cases directional e.g. > > > > PANA-Start-Request <-------- > > PANA-Start-Answer --------> > > > > PANA-Auth-Request <-------- > > PANA-Auth-Answer --------> > > > >why isn't it possible to use these messages in both directions? > > At least the messages you mention above can be used in either > direction. > > >it would be > >good to have a generic message which can be executed from both > entities (pac > >and paa) especially with respect to extensibility. > > > >furthermore, if the pac is preconfigured with the address of the paa then > >there is no need for a discovery message. > > True. > > >hence the PANA-Start-Request (or > >better the PANA-Auth-Request) could go from the pac to the paa. currently > >the cookie stuff mandates a certain direction (thank you dan for > pointing to > >this issue). > > > >here are my questions: > >a) should we add a message to carry AVPs in both directions? > > What kind of AVPs did you have in mind? capability negotiation for example. Also I am still unclear of the > added benefit of having a generic message that is direction > independent. I think the current message set is already sufficient. if > you think there is some functionality mandated by requirements that > cannot be met via these messages, only then we should think of adding > a new message. Otherwise it is better to keep the message set limited. > > >c) should we optimize signaling if the pac is already configured > with the ip > >address of the paa? > > Absolutely. > > > > >please read the pana draft and verify that the signaling message handling > >works in all your scenarios. > > > >ciao > >hannes > ciao hannes > -bp > From pana-request@research.telcordia.com Wed Apr 16 14:43:28 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11485 for ; Wed, 16 Apr 2003 14:43:14 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3GIe7vU012291; Wed, 16 Apr 2003 14:40:07 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 14:40:07 -0400 (EDT) Old-Return-Path: Date: Wed, 16 Apr 2003 15:39:27 -0400 To: Hannes Tschofenig Cc: Yoshihiro Ohba , pana@research.telcordia.com Subject: Re: question: pana messaging Message-ID: <20030416193926.GA991@catfish> Mail-Followup-To: Hannes Tschofenig , Yoshihiro Ohba , pana@research.telcordia.com References: <20030414234147.GB18357@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 73 Resent-Message-ID: <3ibnzC.A.4_C.FOan-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Hannes, On Wed, Apr 16, 2003 at 03:14:58PM +0200, Hannes Tschofenig wrote: > > (snip) > > > > > > > > here are my questions: > > > a) should we add a message to carry AVPs in both directions? > > > > So far I don't see a requirement for this. > > dan mentioned the Reauth-Request(/Answer) message. that would be fine for > me. OK. > > there are, however, other messages which could possible carry AVPs from both > entities such as the Data-Protection AVP. > > in figure 4 of the current draft it says: > > > <----- PANA_success(x+3,y+2) // F-flag set > [EAP{Success}, Device-Id, Data-Protection, MAC] > -----> PANA_success_ack(y+3,x+3) > [Device-Id, MAC] // F-flag set > > however, the Data-Protection might also be negotiated e.g. not every pac > supports ipsec. hence if the paa forces the pac to use ipsec then no network > access would be possible. if the paa (and the pac) additionally support link > layer security then they could use link layer sec. instead. If the access network supports IPsec but does not force PaCs to always use it, then the Data-Protection AVP can contain a new flag to indicate whether per-packet protection is required or not. However, this still does not mean that negotiation is needed for PANA and I don't think Data-Protection AVP is needed for PANA_success_ack to support the scenario you mentioned. > > furtermore the paa might not be able to trigger ipsec after the finished eap > authentication. for example: the pac starts without an ip address > configured. hence after successful eap auth. the pac obtains an ip address > e.g. using stateful address autoconfig. (dhcp). subsequently ipsec can be > enabled. thereby the client might send a Data-Protection AVP saying that he > is ready to enable ipsec. When the PAA registers an IP address of the PaC as the device identifier, it can mean that the PaC is ready to enable IPsec with using that IP address. Then the PAA can inform EP of the IP address and the IKE credential of the PaC so that EP can perform IKE with the PaC. I think what we actually need to support this scenario is the abitility to use both IP address and MAC address as the device identifier at one time, instead of using either IP address or MAC address at one time. However, this still does not mean that negotiation is needed for PANA. > > this is also an example why it should be possible to update device-id info > at the paa. the pac cannot provide his ip address. later it is, however, > possible. I agree that it should be possible to update device-id information for the reason I mentioned above. Thanks, Yoshihiro Ohba From pana-request@research.telcordia.com Wed Apr 16 16:11:10 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15224 for ; Wed, 16 Apr 2003 16:11:09 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3GKBDwr019755; Wed, 16 Apr 2003 16:11:13 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 16:11:13 -0400 (EDT) Old-Return-Path: Date: Wed, 16 Apr 2003 17:10:30 -0400 To: Dan.Forsberg@nokia.com Cc: alper@docomolabs-usa.com, pana@research.telcordia.com Subject: Re: Proposal for message formatting (sec. 9). Message-ID: <20030416211030.GA1255@catfish> Mail-Followup-To: Dan.Forsberg@nokia.com, alper@docomolabs-usa.com, pana@research.telcordia.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 123 Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Dan, Please see my comments below. On Tue, Apr 15, 2003 at 10:37:29AM +0300, Dan.Forsberg@nokia.com wrote: > Alper, > > Thank you for your comments. > > > -----Original Message----- > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > Sent: 14 April, 2003 23:54 > > To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > > Subject: Re: Proposal for message formatting (sec. 9). > > > > > > > > Hi Dan, > > > > Thank you for putting together the Message Format section. > > > > Here are some comments on the current design: > > > > - I see the message formats includes some protocol features > > we have not > > fully discussed yet. For example: session-id, add-device-id, > > remove-device-id. I recommend we separately discuss them > > first, and than > > incorporate into the message formats if necessary. > > Sure. > > > - I understand the desire to re-use DIAMETER code, but let's > > not overdo it. > > From "PANA design perspective", I don't see why we should > > have "Application > > ID" field in the header. > > To make the header structure similar to Diameter. If we break it, then it doesn't matter what kind of format we use, because implementations must be different then. > > We have a prototype that uses Diameter message formatting (testing SeNAA) on top of UDP. This is a very nice feature, because the Diameter stack callbacks can be used with PANA messages too. The interaction with the AAA backend becomes very smooth. This means of course that Diameter and PANA id values don't overlap. > > With Diameter PANA could have Application-Id 4 and the new AVPs could be registered from the Diameter number space (or then we could use Vendor-Id for PANA). I talked with John Loughney (one of the authors of Diameter base spec) about this and he didn't see any problems with this approach. What about header flags? If one bit is assigned for F-bit in PANA, cannot Diameter use that bit for a new flag? Since the flags field is only 8-bit, the field will be consumed up quickly if bit allocation for the field is shared between Diameter and PANA. > > PANA could support different applications in the future too. A preshared SA between PaC and PAA and extensible message types sounds compelling. And if the protocol works smoothly with AAA backends (one doesn't have to specify different AVPs with Diameter and PANA) the scenario looks interesting. > > > - Device ID can also include various link-layer address > > types. Let's reflect > > that onto the design (currently only IP addresses are included). > > Sure. > > > - How about alignment requirements? I'd say we should require 8-octet > > alignment for AVPs. > > If that doesn't break the Diameter compatibility. I think 8-octet alignment breaks the Diameter compatibility, since Diameter does 32-bit (4-octet) alignment. Yoshihiro Ohba > > > > > Alper > > > > > Hi, > > > > > > Attached you can find a proposal section (9 Message Formats) > > > for the draft-ietf-pana-pana-00.txt. It contains some changes > > > that affect the whole draft. > > > > > > There are no error messages defined, which I think should be > > > fixed. This is not only a message format issue, but a protocol > > > issue. > > > > > > Changes to the pana draft in general: > > > > > > - Message naming convention changed (*_ack --> *-Answer, > > > * --> *-Request) to better reflect the Diameter style > > > and the nature of the protocol: answers contain data, > > > but for acks it is not so clear. Requests and answers > > > describe better the protocol. > > > > > > - Thus, 2 messages instead of 1: > > > - PANA-Auth-Request & PANA-Auth-Answer. > > > PAA always sends PANA-Auth-Request and requires an > > > answer to it. > > > - PANA-Start-Request & PANA-Start-Answer. > > > PANA-Start messages are different depending on the sender. > > > - PANA-Success-Request/Answer: PANA requires answer to success, > > > because he PANA SA is not otherwise established properly. > > > And for sake of simplicity, the same naming convention > > > should be used. > > > > > > - Flag change: A flag to R flag to better reflect Diameter style. > > > Requests have the R flag set, answers unset. > > > > > > - Name change: Data-Protection --> Protection-Capability. > > > Data-Protection is misleading term. > > > > > > - Name change: Revocation-Status --> Termination-Cause (Diameter). > > > There is already an AVP that suits for this purpose. > > > > > > - PANA-Disconnect-Request now contains Termination-Cause AVP. > > > There are different reasons for the user to disconnect. > > > > > > > > > > > > Comments welcome, > > > - Dan > > > > > > > > > From pana-request@research.telcordia.com Wed Apr 16 19:36:47 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21380 for ; Wed, 16 Apr 2003 19:36:27 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3GNZdV8003120; Wed, 16 Apr 2003 19:35:39 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 19:35:39 -0400 (EDT) Old-Return-Path: Date: Wed, 16 Apr 2003 16:35:57 -0700 Subject: Re: question: pana messaging From: Alper Yegin To: Yoshihiro Ohba , Hannes Tschofenig CC: Message-ID: In-Reply-To: <20030416193926.GA991@catfish> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: <5jNpuB.A.nw.Kjen-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >> however, the Data-Protection might also be negotiated e.g. not every pac >> supports ipsec. hence if the paa forces the pac to use ipsec then no network >> access would be possible. if the paa (and the pac) additionally support link >> layer security then they could use link layer sec. instead. The simplistic assumption is this: If the link is not multiaccess, we don't need to worry about L2 or L3 ciphering. Otherwise, if the network has L2 ciphering capability, it requires all of its clients to use it. If not, it requires all of its clients to use IPsec. These are not negotiable at all. If we want to extend this, we need to understand: Under what conditions such negotiation will be useful? For example, allowing some clients to use L2 ciphering whereas others to use only IPsec, does this make sense? Does it make sense to "allow" some clients to use both L2 ciphering and IPsec after PANA? > > If the access network supports IPsec but does not force PaCs to always > use it, then the Data-Protection AVP can contain a new flag to > indicate whether per-packet protection is required or not. However, > this still does not mean that negotiation is needed for PANA and I > don't think Data-Protection AVP is needed for PANA_success_ack to > support the scenario you mentioned. > >> >> furtermore the paa might not be able to trigger ipsec after the finished eap >> authentication. for example: the pac starts without an ip address >> configured. hence after successful eap auth. the pac obtains an ip address >> e.g. using stateful address autoconfig. (dhcp). subsequently ipsec can be >> enabled. thereby the client might send a Data-Protection AVP saying that he >> is ready to enable ipsec. > > When the PAA registers an IP address of the PaC as the device > identifier, it can mean that the PaC is ready to enable IPsec with > using that IP address. Then the PAA can inform EP of the IP address > and the IKE credential of the PaC so that EP can perform IKE with the > PaC. I think what we actually need to support this scenario is the > abitility to use both IP address and MAC address as the device > identifier at one time, instead of using either IP address or MAC > address at one time. However, this still does not mean that > negotiation is needed for PANA. I agree that this does not mean negotitation is needed. Still PAA can indicate IPsec is a must. Only in that case it might mean that PaC can do DHCP before turning IPsec on. > >> >> this is also an example why it should be possible to update device-id info >> at the paa. the pac cannot provide his ip address. later it is, however, >> possible. > > I agree that it should be possible to update device-id information > for the reason I mentioned above. It'd be good if someone can start a new thread to discuss "session id". Please list the usage scenarios of the session id concept (aforementioned one, fast re-auth, etc.). Note that currently pana-00 is using device ID as the handle. Alper > > > Thanks, > Yoshihiro Ohba > > From pana-request@research.telcordia.com Wed Apr 16 19:42:59 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21513 for ; Wed, 16 Apr 2003 19:42:53 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3GNh8p5003561; Wed, 16 Apr 2003 19:43:08 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 19:43:08 -0400 (EDT) Old-Return-Path: Date: Wed, 16 Apr 2003 16:43:20 -0700 Subject: Re: Proposal for message formatting (sec. 9). From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: <1k6ijB.A.e3.Lqen-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Dan, Not having that Diameter-specific field in the PANA header does not mean that PANA will be incompatible with Diameter. I'm afraid the level of compatibility you are aiming is "source code compatibility". I'm not concerned about the header size, but I'm concerned about incorporating headers into PANA that currently does not mean anything to PANA. Is there an explanation of what "application ID" means to PANA? Do we have this field in other applications of Diameter, such as in the Mobile IPv4 header, or PPP or 802.1x headers? Alper > Alper, > > Diameter compatibility is not a requirement, but a possibility :). I don't see > it causing udesirable side effects. App-Id is not causing problems, but making > the header a bit bigger. It can help PANA to become more popular/useful and to > cope with possible future extensions/capabilities (list of app-ids supported). > Do you see any drawbacks in this, or issues why we should not be compatible > with Diameter? > > We should ask other's opinions too. > > - Dan > >> -----Original Message----- >> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] >> Sent: 16 April, 2003 03:15 >> To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com >> Subject: Re: Proposal for message formatting (sec. 9). >> >> >> Hi Dan, >> >> It seems like you are treating Diameter compatibility as if it is a >> requirement. It might be a desirable feature at best. Sure it >> helps with >> some code reuse or implimentation shortcuts, but these are >> not necessary >> for the protocol design, and should not cause undesirable >> side effects. >> PANA is not really meant to be an appendix to Diameter. >> Diameter is one of >> the possible backend AAA protocols only. >> >> For example, addition of the "application id" field is not >> justifiable for >> PANA imo. I didn't quite understand the future application >> support. For >> future extensions a reserved field might be more than >> sufficient. Actually >> AVPs might be good enough too. >> >> 64-bit alignment is a nice feature too. I'm not sure which >> one is better >> though: Diameter harmonization or this. >> >> Alper >> >> >>> Alper, >>> >>> Thank you for your comments. >>> >>>> -----Original Message----- >>>> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] >>>> Sent: 14 April, 2003 23:54 >>>> To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com >>>> Subject: Re: Proposal for message formatting (sec. 9). >>>> >>>> >>>> >>>> Hi Dan, >>>> >>>> Thank you for putting together the Message Format section. >>>> >>>> Here are some comments on the current design: >>>> >>>> - I see the message formats includes some protocol features >>>> we have not >>>> fully discussed yet. For example: session-id, add-device-id, >>>> remove-device-id. I recommend we separately discuss them >>>> first, and than >>>> incorporate into the message formats if necessary. >>> >>> Sure. >>> >>>> - I understand the desire to re-use DIAMETER code, but let's >>>> not overdo it. >>>> From "PANA design perspective", I don't see why we should >>>> have "Application >>>> ID" field in the header. >>> >>> To make the header structure similar to Diameter. If we >> break it, then it >>> doesn't matter what kind of format we use, because >> implementations must be >>> different then. >>> >>> We have a prototype that uses Diameter message formatting >> (testing SeNAA) on >>> top of UDP. This is a very nice feature, because the >> Diameter stack callbacks >>> can be used with PANA messages too. The interaction with >> the AAA backend >>> becomes very smooth. This means of course that Diameter and >> PANA id values >>> don't overlap. >>> >>> With Diameter PANA could have Application-Id 4 and the new >> AVPs could be >>> registered from the Diameter number space (or then we could >> use Vendor-Id for >>> PANA). I talked with John Loughney (one of the authors of >> Diameter base spec) >>> about this and he didn't see any problems with this approach. >>> >>> PANA could support different applications in the future >> too. A preshared SA >>> between PaC and PAA and extensible message types sounds >> compelling. And if the >>> protocol works smoothly with AAA backends (one doesn't have >> to specify >>> different AVPs with Diameter and PANA) the scenario looks >> interesting. >>> >>>> - Device ID can also include various link-layer address >>>> types. Let's reflect >>>> that onto the design (currently only IP addresses are included). >>> >>> Sure. >>> >>>> - How about alignment requirements? I'd say we should >> require 8-octet >>>> alignment for AVPs. >>> >>> If that doesn't break the Diameter compatibility. >>> >>>> >>>> Alper >>>> >>>>> Hi, >>>>> >>>>> Attached you can find a proposal section (9 Message Formats) >>>>> for the draft-ietf-pana-pana-00.txt. It contains some changes >>>>> that affect the whole draft. >>>>> >>>>> There are no error messages defined, which I think should be >>>>> fixed. This is not only a message format issue, but a protocol >>>>> issue. >>>>> >>>>> Changes to the pana draft in general: >>>>> >>>>> - Message naming convention changed (*_ack --> *-Answer, >>>>> * --> *-Request) to better reflect the Diameter style >>>>> and the nature of the protocol: answers contain data, >>>>> but for acks it is not so clear. Requests and answers >>>>> describe better the protocol. >>>>> >>>>> - Thus, 2 messages instead of 1: >>>>> - PANA-Auth-Request & PANA-Auth-Answer. >>>>> PAA always sends PANA-Auth-Request and requires an >>>>> answer to it. >>>>> - PANA-Start-Request & PANA-Start-Answer. >>>>> PANA-Start messages are different depending on the sender. >>>>> - PANA-Success-Request/Answer: PANA requires answer to success, >>>>> because he PANA SA is not otherwise established properly. >>>>> And for sake of simplicity, the same naming convention >>>>> should be used. >>>>> >>>>> - Flag change: A flag to R flag to better reflect Diameter style. >>>>> Requests have the R flag set, answers unset. >>>>> >>>>> - Name change: Data-Protection --> Protection-Capability. >>>>> Data-Protection is misleading term. >>>>> >>>>> - Name change: Revocation-Status --> Termination-Cause (Diameter). >>>>> There is already an AVP that suits for this purpose. >>>>> >>>>> - PANA-Disconnect-Request now contains Termination-Cause AVP. >>>>> There are different reasons for the user to disconnect. >>>>> >>>>> >>>>> >>>>> Comments welcome, >>>>> - Dan >>>>> >>>> >>>> >>> >>> >> >> > > > From pana-request@research.telcordia.com Wed Apr 16 20:58:54 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22818 for ; Wed, 16 Apr 2003 20:58:53 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3H0wYq1007534; Wed, 16 Apr 2003 20:58:34 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 20:58:34 -0400 (EDT) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: question: pana messaging Date: Wed, 16 Apr 2003 17:58:04 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C1326@TNEXVS02.tahoenetworks.com> Thread-Topic: question: pana messaging Thread-Index: AcMEdPSqD1Pz+GqOQniDnlT4mxto8wABw6Pw From: "Mohan Parthasarathy" To: "Alper Yegin" , "Yoshihiro Ohba" , "Hannes Tschofenig" Cc: X-OriginalArrivalTime: 17 Apr 2003 00:58:04.0779 (UTC) FILETIME=[670BD3B0:01C3047C] Resent-Message-ID: <4IXDlC.A.k1B.5wfn-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA22818 > > >> however, the Data-Protection might also be negotiated e.g. > not every pac > >> supports ipsec. hence if the paa forces the pac to use > ipsec then no network > >> access would be possible. if the paa (and the pac) > additionally support link > >> layer security then they could use link layer sec. instead. > > The simplistic assumption is this: If the link is not > multiaccess, we don't > need to worry about L2 or L3 ciphering. Otherwise, if the > network has L2 > ciphering capability, it requires all of its clients to use > it. If not, it > requires all of its clients to use IPsec. These are not > negotiable at all. > Yes. > If we want to extend this, we need to understand: Under what > conditions such > negotiation will be useful? For example, allowing some > clients to use L2 > ciphering whereas others to use only IPsec, does this make > sense? Does it It is still not negotiation here. The network enforces this on the clients. > make sense to "allow" some clients to use both L2 ciphering > and IPsec after > PANA? > I see it more as what the network wants to enforce on the client. I don't see anything negotiable in this unless someone tells what is being negotiated here. > > > > > If the access network supports IPsec but does not force > PaCs to always > > use it, then the Data-Protection AVP can contain a new flag to > > indicate whether per-packet protection is required or not. However, > > this still does not mean that negotiation is needed for PANA and I > > don't think Data-Protection AVP is needed for PANA_success_ack to > > support the scenario you mentioned. > > > >> > >> furtermore the paa might not be able to trigger ipsec > after the finished eap > >> authentication. for example: the pac starts without an ip address > >> configured. hence after successful eap auth. the pac > obtains an ip address > >> e.g. using stateful address autoconfig. (dhcp). > subsequently ipsec can be > >> enabled. thereby the client might send a Data-Protection > AVP saying that he > >> is ready to enable ipsec. > > > > When the PAA registers an IP address of the PaC as the device > > identifier, it can mean that the PaC is ready to enable IPsec with > > using that IP address. Then the PAA can inform EP of the IP address > > and the IKE credential of the PaC so that EP can perform > IKE with the > > PaC. I think what we actually need to support this scenario is the > > abitility to use both IP address and MAC address as the device > > identifier at one time, instead of using either IP address or MAC > > address at one time. However, this still does not mean that > > negotiation is needed for PANA. > > I agree that this does not mean negotitation is needed. Still PAA can > indicate IPsec is a must. Only in that case it might mean > that PaC can do > DHCP before turning IPsec on. > > > > > >> > >> this is also an example why it should be possible to > update device-id info > >> at the paa. the pac cannot provide his ip address. later > it is, however, > >> possible. > > > > I agree that it should be possible to update device-id information > > for the reason I mentioned above. > > It'd be good if someone can start a new thread to discuss > "session id". > Please list the usage scenarios of the session id concept > (aforementioned > one, fast re-auth, etc.). Note that currently pana-00 is > using device ID as > the handle. > > > Alper > mohan > > > > > > Thanks, > > Yoshihiro Ohba > > > > > > From pana-request@research.telcordia.com Wed Apr 16 21:31:17 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23387 for ; Wed, 16 Apr 2003 21:31:17 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3H1UpHv009219; Wed, 16 Apr 2003 21:30:51 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 21:30:51 -0400 (EDT) Old-Return-Path: Date: Wed, 16 Apr 2003 18:30:58 -0700 Subject: Re: question: pana messaging From: Alper Yegin To: Mohan Parthasarathy , Yoshihiro Ohba , Hannes Tschofenig CC: Message-ID: In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E016C1326@TNEXVS02.tahoenetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >> If we want to extend this, we need to understand: Under what >> conditions such >> negotiation will be useful? For example, allowing some >> clients to use L2 >> ciphering whereas others to use only IPsec, does this make >> sense? Does it > > It is still not negotiation here. The network enforces this > on the clients. > >> make sense to "allow" some clients to use both L2 ciphering >> and IPsec after >> PANA? >> > I see it more as what the network wants to enforce on the client. > I don't see anything negotiable in this unless someone tells > what is being negotiated here. OK, let me expand on this a bit more... I don't know if the following scenario is realistic and needed: "The access network can do both L2 ciphering and L3 ciphering. PaC is being told that the access network can do any one of these, and optionally both at the same time. PaC must choose at least one, but it can choose both at the same time". So, in that case, PaC will have to indicate its choice: L2, L3, or both. This is what I mean by "negotiation". But first thing we should do is to analize this scenario, or see if there are other scenarios that requires PaC to have a say in this. Alper From pana-request@research.telcordia.com Wed Apr 16 21:46:50 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23716 for ; Wed, 16 Apr 2003 21:46:46 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3H1kXTt010016; Wed, 16 Apr 2003 21:46:33 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 21:46:33 -0400 (EDT) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: question: pana messaging Date: Wed, 16 Apr 2003 18:45:42 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A426@TNEXVS02.tahoenetworks.com> Thread-Topic: question: pana messaging Thread-Index: AcMEgPuibS/bu6A1S/a3u7Ji86r1bAAAN7vQ From: "Mohan Parthasarathy" To: "Alper Yegin" , "Yoshihiro Ohba" , "Hannes Tschofenig" Cc: X-OriginalArrivalTime: 17 Apr 2003 01:45:42.0820 (UTC) FILETIME=[0E924640:01C30483] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA23716 > > >> If we want to extend this, we need to understand: Under what > >> conditions such negotiation will be useful? For example, allowing > >> some clients to use L2 > >> ciphering whereas others to use only IPsec, does this make > >> sense? Does it > > > > It is still not negotiation here. The network enforces this on the > > clients. > > > >> make sense to "allow" some clients to use both L2 > ciphering and IPsec > >> after PANA? > >> > > I see it more as what the network wants to enforce on the client. I > > don't see anything negotiable in this unless someone tells what is > > being negotiated here. > > OK, let me expand on this a bit more... > > I don't know if the following scenario is realistic and needed: > > "The access network can do both L2 ciphering and L3 > ciphering. PaC is being told that the access network can do > any one of these, and optionally both at the same time. PaC > must choose at least one, but it can choose both at the same time". > > So, in that case, PaC will have to indicate its choice: L2, > L3, or both. > The way I see it is, "you need to choose option A or option B or ...". PaC can choose option A ,but rather than indicating it, starts the negotiation relevant to A i.e if the network supports L2 and L3, the client starts L3 negotiation which means it wants to do L3. Perhaps indicating this separately makes PAA/EP more prepared on what to expect next i.e L2 and L3 may require different details to be communicated to EP. This means client chooses, PAA does the setup, acks and then PaC begins the real negotiation. Is this a strong enough reason ? > This is what I mean by "negotiation". But first thing we > should do is to analize this scenario, or see if there are > other scenarios that requires PaC to have a say in this. > Agreed. > Alper > mohan From pana-request@research.telcordia.com Wed Apr 16 22:07:58 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24028 for ; Wed, 16 Apr 2003 22:07:57 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3H2868D011455; Wed, 16 Apr 2003 22:08:06 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 22:08:06 -0400 (EDT) Old-Return-Path: Date: Wed, 16 Apr 2003 19:08:10 -0700 Subject: Re: question: pana messaging From: Alper Yegin To: Mohan Parthasarathy , Yoshihiro Ohba , Hannes Tschofenig CC: Message-ID: In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A426@TNEXVS02.tahoenetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: <4SV-QB.A.2yC.Fygn-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > The way I see it is, "you need to choose option A or option B or ...". > PaC can choose option A ,but rather than indicating it, starts the > negotiation relevant to A i.e if the network supports L2 and L3, > the client starts L3 negotiation which means it wants to do L3. > Perhaps indicating this separately makes PAA/EP more prepared > on what to expect next i.e L2 and L3 may require different details > to be communicated to EP. Yes. For example if the PaC does not explicitly indicate its intentions, this might open up a security hole. Access point allows the PaC's traffic thinking PaC is using L3 ciphers. Access router allows the PaC's traffic thinking it is using L2 ciphers. And maybe the Pac is using neither! [OK, maybe the access point can be a bit smart and look for an IPsec header and access router's IP address as the destination of incoming packets, but...] If we were to enable such a scenario, I'd prefer PaC explicitly indicating its intentions. > This means client chooses, PAA does the > setup, acks and then PaC begins the real negotiation. Is this > a strong enough reason ? Alper From pana-request@research.telcordia.com Wed Apr 16 23:20:17 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25161 for ; Wed, 16 Apr 2003 23:20:17 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3H3IYIF014967; Wed, 16 Apr 2003 23:18:34 -0400 (EDT) Resent-Date: Wed, 16 Apr 2003 23:18:34 -0400 (EDT) Old-Return-Path: Date: Thu, 17 Apr 2003 00:17:54 -0400 To: Alper Yegin Cc: Mohan Parthasarathy , Yoshihiro Ohba , Hannes Tschofenig , pana@research.telcordia.com Subject: Re: question: pana messaging Message-ID: <20030417041754.GA2784@catfish> Mail-Followup-To: Alper Yegin , Mohan Parthasarathy , Yoshihiro Ohba , Hannes Tschofenig , pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A426@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 40 Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Wed, Apr 16, 2003 at 07:08:10PM -0700, Alper Yegin wrote: > > The way I see it is, "you need to choose option A or option B or ...". > > PaC can choose option A ,but rather than indicating it, starts the > > negotiation relevant to A i.e if the network supports L2 and L3, > > the client starts L3 negotiation which means it wants to do L3. > > > Perhaps indicating this separately makes PAA/EP more prepared > > on what to expect next i.e L2 and L3 may require different details > > to be communicated to EP. > > Yes. > > For example if the PaC does not explicitly indicate its intentions, this > might open up a security hole. Access point allows the PaC's traffic > thinking PaC is using L3 ciphers. Access router allows the PaC's traffic > thinking it is using L2 ciphers. And maybe the Pac is using neither! [OK, > maybe the access point can be a bit smart and look for an IPsec header and > access router's IP address as the destination of incoming packets, but...] I think there is some scenario in which the network supports L2 or L3 (or both) ciphers, but authenticated PaC is using neither, but EP still allows forwarding unprotected packets for the PaC. In some sense, per-packet protection may be needed only by PaCs that want to protect its traffic from others. If such a scenario makes sense, it might be useful if Data-Protection AVP contains a flag that indicates whether the network forces per-packet protection to all PaCs or not. Yoshihiro Ohba > > If we were to enable such a scenario, I'd prefer PaC explicitly indicating > its intentions. > > > This means client chooses, PAA does the > > setup, acks and then PaC begins the real negotiation. Is this > > a strong enough reason ? > > Alper > > From pana-request@research.telcordia.com Thu Apr 17 00:29:30 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26866 for ; Thu, 17 Apr 2003 00:29:22 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3H4SZbA018367; Thu, 17 Apr 2003 00:28:36 -0400 (EDT) Resent-Date: Thu, 17 Apr 2003 00:28:36 -0400 (EDT) Old-Return-Path: Date: Thu, 17 Apr 2003 01:28:09 -0400 To: pana@research.telcordia.com Subject: session-id Message-ID: <20030417052808.GC2784@catfish> Mail-Followup-To: pana@research.telcordia.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 54 Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Per Alper's suggestion, I try to open up a new thread for session-id. In pana-00 draft, a PANA session is identified by using device identifier, which is either an IP address or a MAC address. I have the following scenario which might be difficult to support in the current draft: A PaC starts PANA with using unspecified IP address. After the PaC is succesfully authenticated, it configures an IP address via DHCP. Before the PaC obtains an IP address, the MAC address is used as the device identifier. Suppose that the network forces all PaCs to use L3 ciphers, the PaC needs to perform IKE in order to establish an IPsec tunnel between the PaC and EP after the PaC obtains an IP address. The IKE credential is to be derived from EAP Master Key established between the PaC and PAA as a result of successful PANA authentication (I presume an Informational RFC describes a mechanism for the credential derivation). In order for IKE to succeed, the EP needs to know the IKE credential and IP address of the PaC. This means that IP address should also be a device identifier even when the MAC address is initially used as the device identifier. Note that the MAC address may still be used as a device identifier even after the PaC configures an IP address, in order to secure future DHCP re-configuration. The IP address can be a link-local address, however, if additional packet filtering is applied at EP to inner IP headers based on the PaC's global IP address, then such a global IP address would need to be registered to the EP as a device identifier. This scenario might affect PANA design as follows: - Both MAC address and IP address might need to be used as device identifier at one time. - Multiple IP addresses might need to be used as device identifier at one time. These observation might boil down to the following functionalities for PANA: - Ability to update device identifier, perhaps based on add/delete operation. - Ability to identify a PANA session based on a session identifier, which is more stable identifier than device identifier. Comments? Yoshihiro Ohba From pana-request@research.telcordia.com Thu Apr 17 17:54:07 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09793 for ; Thu, 17 Apr 2003 17:54:07 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3HLrEe8029254; Thu, 17 Apr 2003 17:53:14 -0400 (EDT) Resent-Date: Thu, 17 Apr 2003 17:53:14 -0400 (EDT) Old-Return-Path: Date: Thu, 17 Apr 2003 14:53:31 -0700 Subject: WG Last Call: draft-ietf-pana-threats-eval-03.txt From: Alper Yegin To: Message-ID: In-Reply-To: <697DAA22C5004B4596E033803A7CEF4401752FE8@daebe007.americas.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hello, This is a WG last call for: PANA Threat Analysis and Security Requirements I-D : draft-ietf-pana-threats-eval-03.txt Status sought : Informational Please send in your comments by May 1st, 2003 to the WG discussion list. -Chairs From pana-request@research.telcordia.com Thu Apr 17 19:01:05 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13517 for ; Thu, 17 Apr 2003 19:01:01 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3HN0upw004008; Thu, 17 Apr 2003 19:00:56 -0400 (EDT) Resent-Date: Thu, 17 Apr 2003 19:00:56 -0400 (EDT) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: session-id Date: Thu, 17 Apr 2003 15:59:59 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A42D@TNEXVS02.tahoenetworks.com> Thread-Topic: session-id Thread-Index: AcMEngSeDgfqOakHR3+cZNu2Gl+hYAAeCKKA From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: X-OriginalArrivalTime: 17 Apr 2003 22:59:59.0666 (UTC) FILETIME=[12672120:01C30535] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA13517 Yoshihiro, > Per Alper's suggestion, I try to open up a new thread for session-id. > > In pana-00 draft, a PANA session is identified by using > device identifier, which is either an IP address or a MAC > address. I have the following scenario which might be > difficult to support in the current draft: > > A PaC starts PANA with using unspecified IP address. After the PaC > is succesfully authenticated, it configures an IP address via DHCP. > Before the PaC obtains an IP address, the MAC address is used as > the device identifier. Suppose that the network forces all PaCs to > use L3 ciphers, the PaC needs to perform IKE in order to establish > an IPsec tunnel between the PaC and EP after the PaC obtains an IP > address. > > The IKE credential is to be derived from EAP Master Key established > between the PaC and PAA as a result of successful PANA > authentication (I presume an Informational RFC describes a > mechanism for the credential derivation). > > In order for IKE to succeed, the EP needs to know the IKE > credential and IP address of the PaC. This means that IP address > should also be a device identifier even when the MAC > address is initially used as the device identifier. Note that the > MAC address may still be used as a device identifier even after the > PaC configures an IP address, in order to secure future DHCP > re-configuration. I have a basic question here. Who decides what device identifier the client uses ? Assume the client wants to use the MAC address as the device identifier, and the network wants to use Ipsec for preventing service theft, does PAA fail the device identifier exchange ? > > The IP address can be a link-local address, however, if additional > packet filtering is applied at EP to inner IP headers based on the > PaC's global IP address, then such a global IP address would need > to be registered to the EP as a device identifier. > > This scenario might affect PANA design as follows: > > - Both MAC address and IP address might need to be used as device > identifier at one time. > > - Multiple IP addresses might need to be used as device identifier at > one time. > > These observation might boil down to the following functionalities for > PANA: > > - Ability to update device identifier, perhaps based on add/delete > operation. > > - Ability to identify a PANA session based on a session identifier, > which is more stable identifier than device identifier. > I think it would make sense to separate these two identifiers. Device identifier is used for access control and it should just be that. As there could be multiple of them in use at the same time, it might make sense to use a separate identifier for session. -mohan > > Comments? > > Yoshihiro Ohba > > From pana-request@research.telcordia.com Thu Apr 17 19:40:16 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14313 for ; Thu, 17 Apr 2003 19:40:16 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3HNe3ni006135; Thu, 17 Apr 2003 19:40:03 -0400 (EDT) Resent-Date: Thu, 17 Apr 2003 19:40:03 -0400 (EDT) Old-Return-Path: Date: Thu, 17 Apr 2003 20:39:29 -0400 To: Mohan Parthasarathy Cc: Yoshihiro Ohba , pana@research.telcordia.com Subject: Re: session-id Message-ID: <20030418003929.GA15267@catfish> Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A42D@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A42D@TNEXVS02.tahoenetworks.com> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 100 Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Mohan, On Thu, Apr 17, 2003 at 03:59:59PM -0700, Mohan Parthasarathy wrote: > Yoshihiro, > > > Per Alper's suggestion, I try to open up a new thread for session-id. > > > > In pana-00 draft, a PANA session is identified by using > > device identifier, which is either an IP address or a MAC > > address. I have the following scenario which might be > > difficult to support in the current draft: > > > > A PaC starts PANA with using unspecified IP address. After the PaC > > is succesfully authenticated, it configures an IP address via DHCP. > > Before the PaC obtains an IP address, the MAC address is used as > > the device identifier. Suppose that the network forces all PaCs to > > use L3 ciphers, the PaC needs to perform IKE in order to establish > > an IPsec tunnel between the PaC and EP after the PaC obtains an IP > > address. > > > > The IKE credential is to be derived from EAP Master Key established > > between the PaC and PAA as a result of successful PANA > > authentication (I presume an Informational RFC describes a > > mechanism for the credential derivation). > > > > In order for IKE to succeed, the EP needs to know the IKE > > credential and IP address of the PaC. This means that IP address > > should also be a device identifier even when the MAC > > address is initially used as the device identifier. Note that the > > MAC address may still be used as a device identifier even after the > > PaC configures an IP address, in order to secure future DHCP > > re-configuration. > I have a basic question here. Who decides what device identifier the > client > uses ? Assume the client wants to use the MAC address as the device > identifier, > and the network wants to use Ipsec for preventing service theft, does > PAA fail > the device identifier exchange ? I think PAA should always specify what types of device identifier it can support. In the current draft it is done by including Device-Id AVP of a specific type that is required by the network in PANA_success message sent by the PAA. I think we can naturally extend this by just allowing one or more Device-Id AVP(s) carried in PANA_success. For example, if PAA supports both MAC address and IP address as device identifier, it can send a PANA_success message containing two Device-Id AVPs in PANA_success, indicating that the PaC needs to send the same set of Device-Id AVPs in PANA_success_ack. If the PaC does not have an IP address yet, then it can include two Device-Id AVPs, one containing its MAC address and the other containing an unspecified (i.e., all-0's) IP address. As soon as the PaC obtains an IP address, the PaC should inform the updated IP address via PANA_reauth message exchange. I'm not sure which entity should initiate PANA_reauth message exchange in this case, PaC or PAA? > > > > > The IP address can be a link-local address, however, if additional > > packet filtering is applied at EP to inner IP headers based on the > > PaC's global IP address, then such a global IP address would need > > to be registered to the EP as a device identifier. > > > > This scenario might affect PANA design as follows: > > > > - Both MAC address and IP address might need to be used as device > > identifier at one time. > > > > - Multiple IP addresses might need to be used as device identifier at > > one time. > > > > These observation might boil down to the following functionalities for > > PANA: > > > > - Ability to update device identifier, perhaps based on add/delete > > operation. > > > > - Ability to identify a PANA session based on a session identifier, > > which is more stable identifier than device identifier. > > > I think it would make sense to separate these two identifiers. Device > identifier is used for access control and it should just be that. As > there could be multiple of them in use at the same time, it might make > sense to use a separate identifier for session. Are there any other scenarios where session-id is useful? Yoshihiro Ohba > > -mohan > > > > > Comments? > > > > Yoshihiro Ohba > > > > > From pana-request@research.telcordia.com Fri Apr 18 09:18:19 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12667 for ; Fri, 18 Apr 2003 09:18:14 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3IDEC1d021005; Fri, 18 Apr 2003 09:14:12 -0400 (EDT) Resent-Date: Fri, 18 Apr 2003 09:14:12 -0400 (EDT) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: "Alper Yegin" , "Yoshihiro Ohba" Cc: Subject: RE: question: pana messaging Date: Fri, 18 Apr 2003 15:12:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi alper, please see my comments inline: > -----Original Message----- > From: Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: Donnerstag, 17. April 2003 01:36 > To: Yoshihiro Ohba; Hannes Tschofenig > Cc: pana@research.telcordia.com > Subject: Re: question: pana messaging > > > >> however, the Data-Protection might also be negotiated e.g. not > every pac > >> supports ipsec. hence if the paa forces the pac to use ipsec > then no network > >> access would be possible. if the paa (and the pac) > additionally support link > >> layer security then they could use link layer sec. instead. > > The simplistic assumption is this: If the link is not > multiaccess, we don't > need to worry about L2 or L3 ciphering. Otherwise, if the network has L2 > ciphering capability, it requires all of its clients to use it. If not, it > requires all of its clients to use IPsec. These are not negotiable at all. i wouldn't mandate issues which are subject to network administrators. there are reasons why you would like to use ipsec although you have link layer protection. which security is most appropriate depends on the given scenario, on the architecture and on the policy issue of the administrator running the network. in some multiaccess cases it might be reasonable to only use packet filters (particularly if accounting is only time-based and network based on data volume). > > If we want to extend this, we need to understand: Under what > conditions such > negotiation will be useful? For example, allowing some clients to use L2 > ciphering whereas others to use only IPsec, does this make sense? why not? some clients might not support ipsec at all. some others have a "poor" implementation which does not support nesting ipsec (vpn access in addition to the network access). Does it > make sense to "allow" some clients to use both L2 ciphering and > IPsec after > PANA? link layer and network layer security protection terminate a different locations (usually). depending on which messages you would like to protect there might be a reason todo both. furthermore you might have the requirement for heterogenous network access with mobility where you switch between different link layer technologies. each link layer provides different security properties. one way to tackle this problem is to establish security at a high layer (network layer). > > > > > > If the access network supports IPsec but does not force PaCs to always > > use it, then the Data-Protection AVP can contain a new flag to > > indicate whether per-packet protection is required or not. However, > > this still does not mean that negotiation is needed for PANA and I > > don't think Data-Protection AVP is needed for PANA_success_ack to > > support the scenario you mentioned. > > > >> > >> furtermore the paa might not be able to trigger ipsec after > the finished eap > >> authentication. for example: the pac starts without an ip address > >> configured. hence after successful eap auth. the pac obtains > an ip address > >> e.g. using stateful address autoconfig. (dhcp). subsequently > ipsec can be > >> enabled. thereby the client might send a Data-Protection AVP > saying that he > >> is ready to enable ipsec. > > > > When the PAA registers an IP address of the PaC as the device > > identifier, it can mean that the PaC is ready to enable IPsec with > > using that IP address. Then the PAA can inform EP of the IP address > > and the IKE credential of the PaC so that EP can perform IKE with the > > PaC. I think what we actually need to support this scenario is the > > abitility to use both IP address and MAC address as the device > > identifier at one time, instead of using either IP address or MAC > > address at one time. However, this still does not mean that > > negotiation is needed for PANA. > > I agree that this does not mean negotitation is needed. Still PAA can > indicate IPsec is a must. Only in that case it might mean that PaC can do > DHCP before turning IPsec on. i have to state that the term negotiation might not be the best. i think that there must be a way to indicate which mechanisms a paa supports. > > > > > >> > >> this is also an example why it should be possible to update > device-id info > >> at the paa. the pac cannot provide his ip address. later it > is, however, > >> possible. > > > > I agree that it should be possible to update device-id information > > for the reason I mentioned above. > > It'd be good if someone can start a new thread to discuss "session id". > Please list the usage scenarios of the session id concept (aforementioned > one, fast re-auth, etc.). Note that currently pana-00 is using > device ID as > the handle. > ciao hannes > > Alper > > > > > > > Thanks, > > Yoshihiro Ohba > > > > > From pana-request@research.telcordia.com Fri Apr 18 09:27:42 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13025 for ; Fri, 18 Apr 2003 09:27:32 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3IDRDfC021769; Fri, 18 Apr 2003 09:27:13 -0400 (EDT) Resent-Date: Fri, 18 Apr 2003 09:27:13 -0400 (EDT) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: "Yoshihiro Ohba" , Subject: RE: session-id Date: Fri, 18 Apr 2003 15:12:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20030417052808.GC2784@catfish> x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi yoshi, the session id-stuff is addressed with Issue 6: Session Identifier or SPIs. i fully agree with you with respect to the dhcp based scenario. i also agree to your conclusions and i fully support - the introduction of an identifier which is different to the mac/ip address - the ability to update the mac/ip address furthermore i think that it is good to separate the different identifiers and to avoid overloading. (as a general design principle) it is helpful to point to installed state information based on a fixed length identifier instead of using something with variable length (different link layer addresses, ipv4/ipv6 addresses). the uniqueness of such an identifier, however, requires some care: a) is it sufficient to have (let's say) a 128-bit number which is randomly created? b) should we apply a concept similar to the spi (ike, ikev2) which provides uniqueness between the two entities. however, in case of mobility spi collisions still can occur. ciao hannes > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Donnerstag, 17. April 2003 07:28 > To: pana@research.telcordia.com > Subject: session-id > > > Per Alper's suggestion, I try to open up a new thread for session-id. > > In pana-00 draft, a PANA session is identified by using device > identifier, which is either an IP address or a MAC address. I have > the following scenario which might be difficult to support in the > current draft: > > A PaC starts PANA with using unspecified IP address. After the PaC > is succesfully authenticated, it configures an IP address via DHCP. > Before the PaC obtains an IP address, the MAC address is used as > the device identifier. Suppose that the network forces all PaCs to > use L3 ciphers, the PaC needs to perform IKE in order to establish > an IPsec tunnel between the PaC and EP after the PaC obtains an IP > address. > > The IKE credential is to be derived from EAP Master Key established > between the PaC and PAA as a result of successful PANA > authentication (I presume an Informational RFC describes a > mechanism for the credential derivation). > > In order for IKE to succeed, the EP needs to know the IKE > credential and IP address of the PaC. This means that IP address > should also be a device identifier even when the MAC > address is initially used as the device identifier. Note that the > MAC address may still be used as a device identifier even after the > PaC configures an IP address, in order to secure future DHCP > re-configuration. > > The IP address can be a link-local address, however, if additional > packet filtering is applied at EP to inner IP headers based on the > PaC's global IP address, then such a global IP address would need > to be registered to the EP as a device identifier. > > This scenario might affect PANA design as follows: > > - Both MAC address and IP address might need to be used as device > identifier at one time. > > - Multiple IP addresses might need to be used as device identifier at > one time. > > These observation might boil down to the following functionalities for > PANA: > > - Ability to update device identifier, perhaps based on add/delete > operation. > > - Ability to identify a PANA session based on a session identifier, > which is more stable identifier than device identifier. > > > Comments? > > Yoshihiro Ohba > From pana-request@research.telcordia.com Fri Apr 18 09:28:01 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13044 for ; Fri, 18 Apr 2003 09:28:00 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3IDRhvd021838; Fri, 18 Apr 2003 09:27:43 -0400 (EDT) Resent-Date: Fri, 18 Apr 2003 09:27:43 -0400 (EDT) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: "Mohan Parthasarathy" , "Alper Yegin" , "Yoshihiro Ohba" Cc: Subject: RE: question: pana messaging Date: Fri, 18 Apr 2003 15:12:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A426@TNEXVS02.tahoenetworks.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi mohan, please see my comment inline: > -----Original Message----- > From: Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > Sent: Donnerstag, 17. April 2003 03:46 > To: Alper Yegin; Yoshihiro Ohba; Hannes Tschofenig > Cc: pana@research.telcordia.com > Subject: RE: question: pana messaging > > > > > > > > >> If we want to extend this, we need to understand: Under what > > >> conditions such negotiation will be useful? For example, allowing > > >> some clients to use L2 > > >> ciphering whereas others to use only IPsec, does this make > > >> sense? Does it > > > > > > It is still not negotiation here. The network enforces this on the > > > clients. > > > > > >> make sense to "allow" some clients to use both L2 > > ciphering and IPsec > > >> after PANA? > > >> > > > I see it more as what the network wants to enforce on the client. I > > > don't see anything negotiable in this unless someone tells what is > > > being negotiated here. > > > > OK, let me expand on this a bit more... > > > > I don't know if the following scenario is realistic and needed: > > > > "The access network can do both L2 ciphering and L3 > > ciphering. PaC is being told that the access network can do > > any one of these, and optionally both at the same time. PaC > > must choose at least one, but it can choose both at the same time". > > > > So, in that case, PaC will have to indicate its choice: L2, > > L3, or both. > > > The way I see it is, "you need to choose option A or option B or ...". > PaC can choose option A ,but rather than indicating it, starts the > negotiation relevant to A i.e if the network supports L2 and L3, > the client starts L3 negotiation which means it wants to do L3. > Perhaps indicating this separately makes PAA/EP more prepared > on what to expect next i.e L2 and L3 may require different details > to be communicated to EP. This means client chooses, PAA does the > setup, acks and then PaC begins the real negotiation. Is this > a strong enough reason ? the pac cannot simply start (let's say) ike since the paa must know that a particular client wants to start this procedure. it needs to send him the ip address of the ep (if not co-located with the paa) where the ipsec tunnel should terminate. it furthermore needs to send the keys and other parameters there in order for the ep to be ready to respond to it. in case of link layer protection the situation would be worse. imagine what happens if the client suddenly starts to transmit only encrypted packets. the ep is, however, not prepared to decrypt them since it has not received the necessary parameters yet. as a result the communication to the network is broken. the same happens if the network (by some magic) assumes that the client would use link layer security. unfortunately the client hasn't enabled -> all packets get dropped (no further communication might be possible - also with the paa). this is bad. > > > This is what I mean by "negotiation". But first thing we > > should do is to analize this scenario, or see if there are > > other scenarios that requires PaC to have a say in this. > > > Agreed. > ciao hannes > > Alper > > > mohan > From pana-request@research.telcordia.com Fri Apr 18 09:28:21 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13068 for ; Fri, 18 Apr 2003 09:28:20 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3IDRg8O021828; Fri, 18 Apr 2003 09:27:42 -0400 (EDT) Resent-Date: Fri, 18 Apr 2003 09:27:42 -0400 (EDT) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: "Mohan Parthasarathy" , "Alper Yegin" , "Yoshihiro Ohba" Cc: Subject: RE: question: pana messaging Date: Fri, 18 Apr 2003 15:12:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E016C1326@TNEXVS02.tahoenetworks.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi mohan, please see my comment inline: > > > > > >> however, the Data-Protection might also be negotiated e.g. > > not every pac > > >> supports ipsec. hence if the paa forces the pac to use > > ipsec then no network > > >> access would be possible. if the paa (and the pac) > > additionally support link > > >> layer security then they could use link layer sec. instead. > > > > The simplistic assumption is this: If the link is not > > multiaccess, we don't > > need to worry about L2 or L3 ciphering. Otherwise, if the > > network has L2 > > ciphering capability, it requires all of its clients to use > > it. If not, it > > requires all of its clients to use IPsec. These are not > > negotiable at all. > > > Yes. > > > If we want to extend this, we need to understand: Under what > > conditions such > > negotiation will be useful? For example, allowing some > > clients to use L2 > > ciphering whereas others to use only IPsec, does this make > > sense? Does it > > It is still not negotiation here. The network enforces this > on the clients. what is the incentive for the network to enforce strong protection? the client does not want an adversary to inject traffic or to eavesdrop the transmitted datat traffic. the network does not care. the same is true for the negotiation of the refresh interval. for the benefit of the network access provider there shouldn't be a refresh interval at all. the client, however, wants to stop accounting if it lost connectivity. hence the network suggest something (which is probably aligned to the accounting interval) and the client has to indicate something. hence you cannot mandate a certain refresh interval here as well. (as derek mentioned there is a tradeoff) i see these as the same mechanisms why not to make them more general for future extensions to the pana protocol. > > > make sense to "allow" some clients to use both L2 ciphering > > and IPsec after > > PANA? > > > I see it more as what the network wants to enforce on the client. > I don't see anything negotiable in this unless someone tells > what is being negotiated here. the negotiable part here is: network supports something (possible more than one mechanism): a) network and link layer protection b) client says that he would like to enable something if there is always only one choice then there is clearly no negotiation. this does not seem to be the case here. maybe it is better to see this procedure as an indication of what is supported rather than a negotiation. > > > > > > > > > If the access network supports IPsec but does not force > > PaCs to always > > > use it, then the Data-Protection AVP can contain a new flag to > > > indicate whether per-packet protection is required or not. However, > > > this still does not mean that negotiation is needed for PANA and I > > > don't think Data-Protection AVP is needed for PANA_success_ack to > > > support the scenario you mentioned. > > > > > >> > > >> furtermore the paa might not be able to trigger ipsec > > after the finished eap > > >> authentication. for example: the pac starts without an ip address > > >> configured. hence after successful eap auth. the pac > > obtains an ip address > > >> e.g. using stateful address autoconfig. (dhcp). > > subsequently ipsec can be > > >> enabled. thereby the client might send a Data-Protection > > AVP saying that he > > >> is ready to enable ipsec. > > > > > > When the PAA registers an IP address of the PaC as the device > > > identifier, it can mean that the PaC is ready to enable IPsec with > > > using that IP address. Then the PAA can inform EP of the IP address > > > and the IKE credential of the PaC so that EP can perform > > IKE with the > > > PaC. I think what we actually need to support this scenario is the > > > abitility to use both IP address and MAC address as the device > > > identifier at one time, instead of using either IP address or MAC > > > address at one time. However, this still does not mean that > > > negotiation is needed for PANA. > > > > I agree that this does not mean negotitation is needed. Still PAA can > > indicate IPsec is a must. Only in that case it might mean > > that PaC can do > > DHCP before turning IPsec on. > > > > > > > > > >> > > >> this is also an example why it should be possible to > > update device-id info > > >> at the paa. the pac cannot provide his ip address. later > > it is, however, > > >> possible. > > > > > > I agree that it should be possible to update device-id information > > > for the reason I mentioned above. > > > > It'd be good if someone can start a new thread to discuss > > "session id". > > Please list the usage scenarios of the session id concept > > (aforementioned > > one, fast re-auth, etc.). Note that currently pana-00 is > > using device ID as > > the handle. > > > > > > Alper > > > mohan ciao hannes > > > > > > > > > > Thanks, > > > Yoshihiro Ohba > > > > > > > > > > > From pana-request@research.telcordia.com Fri Apr 18 09:28:35 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13082 for ; Fri, 18 Apr 2003 09:28:29 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3IDRqsd021846; Fri, 18 Apr 2003 09:27:52 -0400 (EDT) Resent-Date: Fri, 18 Apr 2003 09:27:52 -0400 (EDT) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: "Yoshihiro Ohba" Cc: Subject: RE: question: pana messaging Date: Fri, 18 Apr 2003 15:12:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20030416193926.GA991@catfish> x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi yoshi, ~snip~ > > If the access network supports IPsec but does not force PaCs to always > use it, then the Data-Protection AVP can contain a new flag to > indicate whether per-packet protection is required or not. i don't know whether has to be a flag or an object. however, it think that something similar should be there. However, > this still does not mean that negotiation is needed for PANA and I > don't think Data-Protection AVP is needed for PANA_success_ack to > support the scenario you mentioned. maybe negotiation is the wrong term. the paa indicates what it supports and the client chooses something. this information needs to be somewhere. if we think about extensibility then a flag might not be the best choice - instead it would be better to support something which is more extensible. > > > > > furtermore the paa might not be able to trigger ipsec after the > finished eap > > authentication. for example: the pac starts without an ip address > > configured. hence after successful eap auth. the pac obtains an > ip address > > e.g. using stateful address autoconfig. (dhcp). subsequently > ipsec can be > > enabled. thereby the client might send a Data-Protection AVP > saying that he > > is ready to enable ipsec. > > When the PAA registers an IP address of the PaC as the device > identifier, it can mean that the PaC is ready to enable IPsec with > using that IP address. Then the PAA can inform EP of the IP address > and the IKE credential of the PaC so that EP can perform IKE with the > PaC. I think what we actually need to support this scenario is the > abitility to use both IP address and MAC address as the device > identifier at one time, instead of using either IP address or MAC > address at one time. i agree with you that we need the abitility to use both IP address and MAC address as the device identifier at one time. this is not a negotiation - clearly. i consider it a negotiation if the paa supports a number of things (even some stuff we have not yet thought about). and then the client wants to use something. you could call it notification. > However, this still does not mean that > negotiation is needed for PANA. > what is wrong with the ability to specify what the paa supports? furthermore there should be a way for the pac to trigger something. think about the dhcp based scenario again. the paa might establish packet filters after the successful authentication with the help of the mac address. then the client decides that it would be good to enable ipsec (after obtaining an ip address from the dhcp). then you need a message which says: pac paa i want to use ipsec (here is my ip address) ----------------> ok, here is the ip address of the end point (e.g. ep) <---------------- > > > > this is also an example why it should be possible to update > device-id info > > at the paa. the pac cannot provide his ip address. later it is, however, > > possible. > > I agree that it should be possible to update device-id information > for the reason I mentioned above. ok. ciao hannes > > > Thanks, > Yoshihiro Ohba > From pana-request@research.telcordia.com Fri Apr 18 13:52:29 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20750 for ; Fri, 18 Apr 2003 13:52:29 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3IHpXOZ010522; Fri, 18 Apr 2003 13:51:33 -0400 (EDT) Resent-Date: Fri, 18 Apr 2003 13:51:33 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Issues Tracker for PANA WG drafts Date: Fri, 18 Apr 2003 12:51:01 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4402058D8B@daebe007.americas.nokia.com> Thread-Topic: Issues Tracker for PANA WG drafts Thread-Index: AcMFyI9NAAH57ZQdQHu4/ty9jzOGqQ== From: To: X-OriginalArrivalTime: 18 Apr 2003 17:51:01.0974 (UTC) FILETIME=[137D8F60:01C305D3] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA20750 Hello, In order to better track issues w.r.t the PANA WG drafts we have decided to use an issue tracking solution. Thanks to Dan Forsberg for maintaining the issues web site. The URL for this is: http://danforsberg.info:8080/pana-issues/ In the future if you would like to raise an issue with any of the PANA WG drafts in progress, please mention if it is a new issue or it is something that is already recognized and is being tracked. -Basavaraj From pana-request@research.telcordia.com Fri Apr 18 13:54:53 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20820 for ; Fri, 18 Apr 2003 13:54:52 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3IHt2kt010793; Fri, 18 Apr 2003 13:55:02 -0400 (EDT) Resent-Date: Fri, 18 Apr 2003 13:55:02 -0400 (EDT) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: question: pana messaging Date: Fri, 18 Apr 2003 10:54:39 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A42E@TNEXVS02.tahoenetworks.com> Thread-Topic: question: pana messaging Thread-Index: AcMFrF42TGuVBcEtQMOCWjV+O/7HtAAJpzkQ From: "Mohan Parthasarathy" To: , "Alper Yegin" , "Yoshihiro Ohba" Cc: X-OriginalArrivalTime: 18 Apr 2003 17:54:39.0447 (UTC) FILETIME=[951D4E70:01C305D3] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA20820 > hi mohan, > > please see my comment inline: > > > > > > > > >> however, the Data-Protection might also be negotiated e.g. > > > not every pac > > > >> supports ipsec. hence if the paa forces the pac to use > > > ipsec then no network > > > >> access would be possible. if the paa (and the pac) > > > additionally support link > > > >> layer security then they could use link layer sec. instead. > > > > > > The simplistic assumption is this: If the link is not > multiaccess, > > > we don't need to worry about L2 or L3 ciphering. Otherwise, if the > > > network has L2 > > > ciphering capability, it requires all of its clients to use > > > it. If not, it > > > requires all of its clients to use IPsec. These are not > > > negotiable at all. > > > > > Yes. > > > > > If we want to extend this, we need to understand: Under what > > > conditions such negotiation will be useful? For example, allowing > > > some clients to use L2 > > > ciphering whereas others to use only IPsec, does this make > > > sense? Does it > > > > It is still not negotiation here. The network enforces this on the > > clients. > > what is the incentive for the network to enforce strong > protection? the client does not want an adversary to inject > traffic or to eavesdrop the transmitted datat traffic. the > network does not care. > The network operator wants to make sure that no one is stealing anyone else service and thus getting service for free in the network. > the same is true for the negotiation of the refresh interval. > for the benefit of the network access provider there > shouldn't be a refresh interval at all. the client, however, > wants to stop accounting if it lost connectivity. hence the > network suggest something (which is probably aligned to the > accounting interval) and the client has to indicate something. > > hence you cannot mandate a certain refresh interval here as > well. (as derek mentioned there is a tradeoff) > > i see these as the same mechanisms why not to make them more > general for future extensions to the pana protocol. > > > > > > > make sense to "allow" some clients to use both L2 ciphering and > > > IPsec after PANA? > > > > > I see it more as what the network wants to enforce on the client. I > > don't see anything negotiable in this unless someone tells what is > > being negotiated here. > > the negotiable part here is: > > network supports something (possible more than one mechanism): > > a) network and link layer protection > > b) client says that he would like to enable something > > if there is always only one choice then there is clearly no > negotiation. this does not seem to be the case here. > > maybe it is better to see this procedure as an indication of > what is supported rather than a negotiation. > I think in the later mails, we agreed to this. -mohan > > > > > > > > > > > > > > If the access network supports IPsec but does not force > > > PaCs to always > > > > use it, then the Data-Protection AVP can contain a new flag to > > > > indicate whether per-packet protection is required or not. > > > > However, this still does not mean that negotiation is > needed for > > > > PANA and I don't think Data-Protection AVP is needed for > > > > PANA_success_ack to support the scenario you mentioned. > > > > > > > >> > > > >> furtermore the paa might not be able to trigger ipsec > > > after the finished eap > > > >> authentication. for example: the pac starts without an > ip address > > > >> configured. hence after successful eap auth. the pac > > > obtains an ip address > > > >> e.g. using stateful address autoconfig. (dhcp). > > > subsequently ipsec can be > > > >> enabled. thereby the client might send a Data-Protection > > > AVP saying that he > > > >> is ready to enable ipsec. > > > > > > > > When the PAA registers an IP address of the PaC as the device > > > > identifier, it can mean that the PaC is ready to enable > IPsec with > > > > using that IP address. Then the PAA can inform EP of the IP > > > > address and the IKE credential of the PaC so that EP can perform > > > IKE with the > > > > PaC. I think what we actually need to support this scenario is > > > > the abitility to use both IP address and MAC address as > the device > > > > identifier at one time, instead of using either IP > address or MAC > > > > address at one time. However, this still does not mean that > > > > negotiation is needed for PANA. > > > > > > I agree that this does not mean negotitation is needed. Still PAA > > > can indicate IPsec is a must. Only in that case it might > mean that > > > PaC can do DHCP before turning IPsec on. > > > > > > > > > > > > > >> > > > >> this is also an example why it should be possible to > > > update device-id info > > > >> at the paa. the pac cannot provide his ip address. later > > > it is, however, > > > >> possible. > > > > > > > > I agree that it should be possible to update device-id > information > > > > for the reason I mentioned above. > > > > > > It'd be good if someone can start a new thread to discuss > "session > > > id". Please list the usage scenarios of the session id concept > > > (aforementioned > > > one, fast re-auth, etc.). Note that currently pana-00 is > > > using device ID as > > > the handle. > > > > > > > > > Alper > > > > > mohan > > ciao > hannes > > > > > > > > > > > > > > > Thanks, > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Fri Apr 18 14:45:20 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22090 for ; Fri, 18 Apr 2003 14:45:10 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3II5fNb011975; Fri, 18 Apr 2003 14:05:41 -0400 (EDT) Resent-Date: Fri, 18 Apr 2003 14:05:41 -0400 (EDT) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: session-id Date: Fri, 18 Apr 2003 11:04:19 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A42F@TNEXVS02.tahoenetworks.com> Thread-Topic: session-id Thread-Index: AcMFOrsSZu3pEM5GQ5i5G3QPxrEB1wAmXL+g From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: X-OriginalArrivalTime: 18 Apr 2003 18:04:20.0259 (UTC) FILETIME=[EF4E2F30:01C305D4] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA22090 Yoshihiro, > > > > > > These observation might boil down to the following > functionalities > > > for > > > PANA: > > > > > > - Ability to update device identifier, perhaps based on > add/delete > > > operation. > > > > > > - Ability to identify a PANA session based on a session > identifier, > > > which is more stable identifier than device identifier. > > > > > I think it would make sense to separate these two > identifiers. Device > > identifier is used for access control and it should just be > that. As > > there could be multiple of them in use at the same time, it > might make > > sense to use a separate identifier for session. > > Are there any other scenarios where session-id is useful? > I am not sure I understand the question. I thought the session id is used for identifying the session related stuff of a given PaC. But this leads to the problem of unique session ids. It might be easy if the PAA allocates a session ID (like SPI allocated by the receiver) to make it unique across all the PaCs. -mohan > Yoshihiro Ohba > > > > > -mohan > > > > > > > > Comments? > > > > > > Yoshihiro Ohba > > > > > > > > > From pana-request@research.telcordia.com Fri Apr 18 19:57:11 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01388 for ; Fri, 18 Apr 2003 19:57:06 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3INsvd7004836; Fri, 18 Apr 2003 19:54:57 -0400 (EDT) Resent-Date: Fri, 18 Apr 2003 19:54:57 -0400 (EDT) Old-Return-Path: Date: Fri, 18 Apr 2003 16:55:18 -0700 Subject: Re: session-id From: Alper Yegin To: Yoshihiro Ohba , Message-ID: In-Reply-To: <20030417052808.GC2784@catfish> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: <16q9C.A.bLB.QBJo-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > Per Alper's suggestion, I try to open up a new thread for session-id. Thank you Yoshi. > > In pana-00 draft, a PANA session is identified by using device > identifier, which is either an IP address or a MAC address. I have > the following scenario which might be difficult to support in the > current draft: > > A PaC starts PANA with using unspecified IP address. After the PaC > is succesfully authenticated, it configures an IP address via DHCP. > Before the PaC obtains an IP address, the MAC address is used as > the device identifier. Suppose that the network forces all PaCs to > use L3 ciphers, the PaC needs to perform IKE in order to establish > an IPsec tunnel between the PaC and EP after the PaC obtains an IP > address. I presume the assumption is that dhcp is secured. Otherwise, the client could be given an IP address prior to PANA and there wouldn't be such a problem. The only reason DHCP comes after PANA is that DHCP is secured using PANA SA, is that right? If this network is using IPsec for access control, then the other assumption seems like this: Clients are allowed to perform DHCP in addition to PANA before they are authorized to access the network. > The IKE credential is to be derived from EAP Master Key established > between the PaC and PAA as a result of successful PANA > authentication (I presume an Informational RFC describes a > mechanism for the credential derivation). > > In order for IKE to succeed, the EP needs to know the IKE > credential and IP address of the PaC. This means that IP address > should also be a device identifier even when the MAC > address is initially used as the device identifier. Note that the > MAC address may still be used as a device identifier even after the > PaC configures an IP address, in order to secure future DHCP > re-configuration. If IPsec is used for access control, MAC address has no significance for PANA or access control. If L2 ciphers are used, IP addresses have no significance... > > The IP address can be a link-local address, however, if additional > packet filtering is applied at EP to inner IP headers based on the > PaC's global IP address, then such a global IP address would need > to be registered to the EP as a device identifier. If we are using an IPsec tunnel between PaC and EP, the inner addresses have no significance for access control. So, I don't think we need to care about them. > > This scenario might affect PANA design as follows: > > - Both MAC address and IP address might need to be used as device > identifier at one time. Sure the PAA and PaC can be aware of both. But depending on the access control mechanism, only one is significant. > > - Multiple IP addresses might need to be used as device identifier at > one time. I think one is enough. > > These observation might boil down to the following functionalities for > PANA: > > - Ability to update device identifier, perhaps based on add/delete > operation. > > - Ability to identify a PANA session based on a session identifier, > which is more stable identifier than device identifier. > > > Comments? Alper From pana-request@research.telcordia.com Fri Apr 18 19:58:00 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01449 for ; Fri, 18 Apr 2003 19:57:59 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3INuudo004960; Fri, 18 Apr 2003 19:56:56 -0400 (EDT) Resent-Date: Fri, 18 Apr 2003 19:56:56 -0400 (EDT) Old-Return-Path: Date: Fri, 18 Apr 2003 16:57:10 -0700 Subject: Re: session-id From: Alper Yegin To: Mohan Parthasarathy , Yoshihiro Ohba CC: Message-ID: In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A42F@TNEXVS02.tahoenetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > I am not sure I understand the question. I thought the session id > is used for identifying the session related stuff of a given PaC. > But this leads to the problem of unique session ids. It might > be easy if the PAA allocates a session ID (like SPI allocated by > the receiver) to make it unique across all the PaCs. This makes sense. It might even make sense to have an NAI-like session id, e.g., 2343245345@PAA1.foo.com, if we care about global identification for any reason. Alper From pana-request@research.telcordia.com Fri Apr 18 21:33:29 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03652 for ; Fri, 18 Apr 2003 21:33:25 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3J1WErm009672; Fri, 18 Apr 2003 21:32:14 -0400 (EDT) Resent-Date: Fri, 18 Apr 2003 21:32:14 -0400 (EDT) Old-Return-Path: Date: Fri, 18 Apr 2003 18:31:04 -0400 To: Alper Yegin Cc: Yoshihiro Ohba , pana@research.telcordia.com Subject: Re: session-id Message-ID: <20030418223104.GA3680@catfish> Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , pana@research.telcordia.com References: <20030417052808.GC2784@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 105 Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Fri, Apr 18, 2003 at 04:55:18PM -0700, Alper Yegin wrote: > > Per Alper's suggestion, I try to open up a new thread for session-id. > > Thank you Yoshi. > > > > > In pana-00 draft, a PANA session is identified by using device > > identifier, which is either an IP address or a MAC address. I have > > the following scenario which might be difficult to support in the > > current draft: > > > > A PaC starts PANA with using unspecified IP address. After the PaC > > is succesfully authenticated, it configures an IP address via DHCP. > > Before the PaC obtains an IP address, the MAC address is used as > > the device identifier. Suppose that the network forces all PaCs to > > use L3 ciphers, the PaC needs to perform IKE in order to establish > > an IPsec tunnel between the PaC and EP after the PaC obtains an IP > > address. > > I presume the assumption is that dhcp is secured. Otherwise, the client > could be given an IP address prior to PANA and there wouldn't be such a > problem. The only reason DHCP comes after PANA is that DHCP is secured using > PANA SA, is that right? I think so. > > If this network is using IPsec for access control, then the other assumption > seems like this: Clients are allowed to perform DHCP in addition to PANA > before they are authorized to access the network. Yes, that would be the other assumption. > > > The IKE credential is to be derived from EAP Master Key established > > between the PaC and PAA as a result of successful PANA > > authentication (I presume an Informational RFC describes a > > mechanism for the credential derivation). > > > > In order for IKE to succeed, the EP needs to know the IKE > > credential and IP address of the PaC. This means that IP address > > should also be a device identifier even when the MAC > > address is initially used as the device identifier. Note that the > > MAC address may still be used as a device identifier even after the > > PaC configures an IP address, in order to secure future DHCP > > re-configuration. > > If IPsec is used for access control, MAC address has no significance for > PANA or access control. If L2 ciphers are used, IP addresses have no > significance... L2 ciphers protect MAC address spoofing but do not protect IP address spoofing. I think this is addressed in section 6.4 of draft-ietf-pana-threats-eval-03.txt. > > > > > The IP address can be a link-local address, however, if additional > > packet filtering is applied at EP to inner IP headers based on the > > PaC's global IP address, then such a global IP address would need > > to be registered to the EP as a device identifier. > > If we are using an IPsec tunnel between PaC and EP, the inner addresses have > no significance for access control. So, I don't think we need to care about > them. I think the relationship between outer IP address and inner IP address is similar to the one between MAC address and IP address. Protecting only outer IP address does not protect inner IP address spoofing. I'm not sure whether this is the area of PANA or SEND. > > > > > This scenario might affect PANA design as follows: > > > > - Both MAC address and IP address might need to be used as device > > identifier at one time. > > Sure the PAA and PaC can be aware of both. But depending on the access > control mechanism, only one is significant. > > > > > - Multiple IP addresses might need to be used as device identifier at > > one time. > > I think one is enough. > > > > > These observation might boil down to the following functionalities for > > PANA: > > > > - Ability to update device identifier, perhaps based on add/delete > > operation. > > > > - Ability to identify a PANA session based on a session identifier, > > which is more stable identifier than device identifier. > > > > > > Comments? > > Alper > Yoshihiro Ohba From pana-request@research.telcordia.com Sun Apr 20 11:19:42 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07737 for ; Sun, 20 Apr 2003 11:19:42 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3KFGMS3023453; Sun, 20 Apr 2003 11:16:22 -0400 (EDT) Resent-Date: Sun, 20 Apr 2003 11:16:22 -0400 (EDT) Old-Return-Path: Message-ID: <20030420151449.25764.qmail@web40013.mail.yahoo.com> Date: Sun, 20 Apr 2003 08:14:49 -0700 (PDT) From: Reinaldo Penno Subject: Re: Issues Tracker for PANA WG drafts To: Basavaraj.Patil@nokia.com, pana@research.telcordia.com In-Reply-To: <697DAA22C5004B4596E033803A7CEF4402058D8B@daebe007.americas.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com My comments on some of these issues... Device-Identifier: The Device Identifier originally could be anything, not necessarily a IP address(es) or link layer. It could be a group-name, user-name, NAI, etc, etc What was the reason for change? IN the beggining it was only link layer or IP addresses. Then we discussed this ad nauseum and concluded that it could be anything, so it seems we are changing it again. Capability negotiation: Capabilty negotiation is a powerful tool. Today I guess thre are two approaches. The offer/answer model (used by SIP/SDP), BGP and some others. You might cvall it capability advertisement, since if the peer does not agree, everything starts over. The other is the PPP/LCP approach, where you have configure-ack, nak, rej, etc. The second one is more flexible but my take more RTTs. The first one needs that the initiator puts all acceptable capabilities and its respective values on the message. regards, Reinaldo --- Basavaraj.Patil@nokia.com wrote: > > Hello, > > In order to better track issues w.r.t the PANA WG > drafts > we have decided to use an issue tracking solution. > Thanks > to Dan Forsberg for maintaining the issues web site. > > The URL for this is: > > http://danforsberg.info:8080/pana-issues/ > > In the future if you would like to raise an issue > with any > of the PANA WG drafts in progress, please mention if > it is a > new issue or it is something that is already > recognized and is > being tracked. > > -Basavaraj > __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com From pana-request@research.telcordia.com Sun Apr 20 16:26:46 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14644 for ; Sun, 20 Apr 2003 16:26:46 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3KKOaUk006430; Sun, 20 Apr 2003 16:24:36 -0400 (EDT) Resent-Date: Sun, 20 Apr 2003 16:24:36 -0400 (EDT) Old-Return-Path: Reply-To: From: "Hannes Tschofenig" To: "Reinaldo Penno" , , Subject: RE: Issues Tracker for PANA WG drafts Date: Sun, 20 Apr 2003 22:23:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030420151449.25764.qmail@web40013.mail.yahoo.com> Resent-Message-ID: <_umAnB.A.UkB.DIwo-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi reinaldo, please see my comment inline: > -----Original Message----- > From: Reinaldo Penno [mailto:rapenno@yahoo.com] > Sent: Sonntag, 20. April 2003 17:15 > To: Basavaraj.Patil@nokia.com; pana@research.telcordia.com > Subject: Re: Issues Tracker for PANA WG drafts > > > My comments on some of these issues... > > Device-Identifier: > > The Device Identifier originally could be anything, > not necessarily a IP address(es) or link layer. It > could be a group-name, user-name, NAI, etc, etc the device identitifier is directly used as an input for a packet filter "tool". a nai, username, groupname etc. are concepts which are unknown to these tools in a pana environment. the username, however, appears in other places (eap) since it is required for a) routing b) authorization/authentication > > What was the reason for change? IN the beggining it > was only link layer or IP addresses. Then we discussed > this ad nauseum and concluded that it could be > anything, so it seems we are changing it again. > > Capability negotiation: > > Capabilty negotiation is a powerful tool. Today I > guess thre are two approaches. The offer/answer model > (used by SIP/SDP), BGP and some others. You might > cvall it capability advertisement, since if the peer > does not agree, everything starts over. > > The other is the PPP/LCP approach, where you have > configure-ack, nak, rej, etc. > > The second one is more flexible but my take more RTTs. > The first one needs that the initiator puts all > acceptable capabilities and its respective values on > the message. which model would you suggest for pana? in particular it would be good to have the functionality: A) Pac <-- Paa: i support x,y and z Pac --> Paa: i would like to use y B) Pac --> Paa: enable x Pac <-- Paa: status (ok, failed) C) Pac <-- Paa: you must use y Pac --> Paa: status (ok, failed) D) Pac --> Paa: what do you support? Pac <-- Paa: i support x,y and z thanks for addressing open issues. ciao hannes > > regards, > > Reinaldo > > > --- Basavaraj.Patil@nokia.com wrote: > > > > Hello, > > > > In order to better track issues w.r.t the PANA WG > > drafts > > we have decided to use an issue tracking solution. > > Thanks > > to Dan Forsberg for maintaining the issues web site. > > > > The URL for this is: > > > > http://danforsberg.info:8080/pana-issues/ > > > > In the future if you would like to raise an issue > > with any > > of the PANA WG drafts in progress, please mention if > > it is a > > new issue or it is something that is already > > recognized and is > > being tracked. > > > > -Basavaraj > > > > > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo > http://search.yahoo.com > From pana-request@research.telcordia.com Mon Apr 21 13:47:41 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23944 for ; Mon, 21 Apr 2003 13:47:40 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3LHjBud014789; Mon, 21 Apr 2003 13:45:11 -0400 (EDT) Resent-Date: Mon, 21 Apr 2003 13:45:11 -0400 (EDT) Old-Return-Path: Message-ID: <20030421174340.33700.qmail@web40010.mail.yahoo.com> Date: Mon, 21 Apr 2003 10:43:40 -0700 (PDT) From: Reinaldo Penno Subject: RE: Issues Tracker for PANA WG drafts To: hannes@tschofenig.com, Basavaraj.Patil@nokia.com, pana@research.telcordia.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hello Hannes, comments inline... --- Hannes Tschofenig wrote: > hi reinaldo, > > please see my comment inline: > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rapenno@yahoo.com] > > Sent: Sonntag, 20. April 2003 17:15 > > To: Basavaraj.Patil@nokia.com; > pana@research.telcordia.com > > Subject: Re: Issues Tracker for PANA WG drafts > > > > > > My comments on some of these issues... > > > > Device-Identifier: > > > > The Device Identifier originally could be > anything, > > not necessarily a IP address(es) or link layer. It > > could be a group-name, user-name, NAI, etc, etc > > the device identitifier is directly used as an input > for a packet filter > "tool". > a nai, username, groupname etc. are concepts which > are unknown to these > tools in a pana environment. well, then I guess the problem is the restriction of the device identifier use. Early in the game device identifier was flexible because people could use data in there to cater to their needs (accounting, filtering, etc, etc). The early proposal was to be able to put anything in there, I'm (still) not convinced why this is an issue. If I put something that is not acceptable by the PAA (or backend AAA), I get an error...Or maybe I could put my IP/MAC address AND something else. Why I cannot stack information so that is more flexible? If, for example, I put that my IP address is a.b.c.d and I'm located at first floor. > > the username, however, appears in other places (eap) > since it is required > for > a) routing > b) authorization/authentication > see above. The information in the device identifier can be used in different ways by different people. If you tell me that being flexible in this case is bad because it would mean big changes in the protocol..well, then that's a different story. But I haven't seen that. > > > > What was the reason for change? IN the beggining > it > > was only link layer or IP addresses. Then we > discussed > > this ad nauseum and concluded that it could be > > anything, so it seems we are changing it again. > > > > Capability negotiation: > > > > Capabilty negotiation is a powerful tool. Today I > > guess thre are two approaches. The offer/answer > model > > (used by SIP/SDP), BGP and some others. You might > > cvall it capability advertisement, since if the > peer > > does not agree, everything starts over. > > > > The other is the PPP/LCP approach, where you have > > configure-ack, nak, rej, etc. > > > > The second one is more flexible but my take more > RTTs. > > The first one needs that the initiator puts all > > acceptable capabilities and its respective values > on > > the message. > > which model would you suggest for pana? well, it depends, if D) happens followed by B), do you want them to be part of the same negotiation, or each one individually self contained transactions? For example, in PPP/LCP all the configure messages, are part of one big negotiation (which means that the state machine is more elaborate), i.e, the negotiation process is a protocol on its own (LCP). I guess the PPP experts on the list can elaborate lenghtly on the pros/cons of this model. SDP has very limited negotiation capabilities. Only two messages and . In order to convey that a capability is not acceptable, the value returned by the peer is often "zero" <0>. There is no different message for that. All the intelligence to figure out if the options are acceptable, to try again, etc relies on the application layer. In this case SIP. > in particular it would be good to have the > functionality: > > A) > > Pac <-- Paa: i support x,y and z > Pac --> Paa: i would like to use y > > B) > Pac --> Paa: enable x > Pac <-- Paa: status (ok, failed) > > C) > Pac <-- Paa: you must use y > Pac --> Paa: status (ok, failed) > > D) > Pac --> Paa: what do you support? > Pac <-- Paa: i support x,y and z > > thanks for addressing open issues. > > ciao > hannes > > > > > > regards, > > > > Reinaldo > > > > > > --- Basavaraj.Patil@nokia.com wrote: > > > > > > Hello, > > > > > > In order to better track issues w.r.t the PANA > WG > > > drafts > > > we have decided to use an issue tracking > solution. > > > Thanks > > > to Dan Forsberg for maintaining the issues web > site. > > > > > > The URL for this is: > > > > > > http://danforsberg.info:8080/pana-issues/ > > > > > > In the future if you would like to raise an > issue > > > with any > > > of the PANA WG drafts in progress, please > mention if > > > it is a > > > new issue or it is something that is already > > > recognized and is > > > being tracked. > > > > > > -Basavaraj > > > > > > > > > __________________________________________________ > > Do you Yahoo!? > > The New Yahoo! Search - Faster. Easier. Bingo > > http://search.yahoo.com > > > __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com From pana-request@research.telcordia.com Mon Apr 21 14:11:09 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24683 for ; Mon, 21 Apr 2003 14:11:09 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3LI9lY2016551; Mon, 21 Apr 2003 14:09:47 -0400 (EDT) Resent-Date: Mon, 21 Apr 2003 14:09:47 -0400 (EDT) Old-Return-Path: Date: Mon, 21 Apr 2003 11:09:57 -0700 Subject: Re: Issues Tracker for PANA WG drafts From: Alper Yegin To: Reinaldo Penno , , Message-ID: In-Reply-To: <20030420151449.25764.qmail@web40013.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Reinaldo, > My comments on some of these issues... > > Device-Identifier: > > The Device Identifier originally could be anything, > not necessarily a IP address(es) or link layer. It > could be a group-name, user-name, NAI, etc, etc > > What was the reason for change? IN the beggining it > was only link layer or IP addresses. Then we discussed > this ad nauseum and concluded that it could be > anything, so it seems we are changing it again. I couldn't track where this recommendation come from, but I cannot see how the DI can be user-name, group-name, NAI, etc. DI is used for access control, and none of these identifiers are carried in the data packets. Only link-layer addresses and IP addresses. Alper From pana-request@research.telcordia.com Mon Apr 21 14:33:18 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25544 for ; Mon, 21 Apr 2003 14:33:18 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3LIW5eL018318; Mon, 21 Apr 2003 14:32:05 -0400 (EDT) Resent-Date: Mon, 21 Apr 2003 14:32:05 -0400 (EDT) Old-Return-Path: Message-ID: <20030421183021.49396.qmail@web40012.mail.yahoo.com> Date: Mon, 21 Apr 2003 11:30:21 -0700 (PDT) From: Reinaldo Penno Subject: Re: Issues Tracker for PANA WG drafts To: Alper Yegin , Basavaraj.Patil@nokia.com, pana@research.telcordia.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com well, I commented on that in my email to Hannes. Information on the DI my not be used directly in the access rule, but can influence which/how to construct the rule. If, for example, I know that the IP address is a.b.c.d AND the user-name is Alper AND he is accessing from his house than the filter rules are going to be X, Y, Z..., otherwise M, N, O. I really do not want to drag this much further. I just want to make the point that it can be very useful/powerful and the changes in the protocol seem to be minimum. But if folks feel otherwise, that's okay. cheers, Reinaldo --- Alper Yegin wrote: > Hi Reinaldo, > > > My comments on some of these issues... > > > > Device-Identifier: > > > > The Device Identifier originally could be > anything, > > not necessarily a IP address(es) or link layer. It > > could be a group-name, user-name, NAI, etc, etc > > > > What was the reason for change? IN the beggining > it > > was only link layer or IP addresses. Then we > discussed > > this ad nauseum and concluded that it could be > > anything, so it seems we are changing it again. > > > I couldn't track where this recommendation come > from, but I cannot see how > the DI can be user-name, group-name, NAI, etc. DI is > used for access > control, and none of these identifiers are carried > in the data packets. Only > link-layer addresses and IP addresses. > > Alper > __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com From pana-request@research.telcordia.com Mon Apr 21 14:53:10 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26068 for ; Mon, 21 Apr 2003 14:53:10 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3LIq4bj019842; Mon, 21 Apr 2003 14:52:04 -0400 (EDT) Resent-Date: Mon, 21 Apr 2003 14:52:04 -0400 (EDT) Old-Return-Path: Date: Mon, 21 Apr 2003 11:52:07 -0700 Subject: Re: Issues Tracker for PANA WG drafts From: Alper Yegin To: Reinaldo Penno , , Message-ID: In-Reply-To: <20030421183021.49396.qmail@web40012.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Reinaldo, > well, > > I commented on that in my email to Hannes. Information > on the DI my not be used directly in the access rule, > but can influence which/how to construct the rule. > > If, for example, I know that the IP address is a.b.c.d > AND the user-name is Alper AND he is accessing from > his house than the filter rules are going to be X, Y, > Z..., otherwise M, N, O. Sure, that makes sense. But you don't need to carry all these in DI. User-name can be carried inside the client id used during the authentication. The location information can be inferred from the location of the PAA. > > I really do not want to drag this much further. I just > want to make the point that it can be very > useful/powerful and the changes in the protocol seem > to be minimum. But if folks feel otherwise, that's > okay. > > cheers, > > Reinaldo Alper > > > > --- Alper Yegin wrote: >> Hi Reinaldo, >> >>> My comments on some of these issues... >>> >>> Device-Identifier: >>> >>> The Device Identifier originally could be >> anything, >>> not necessarily a IP address(es) or link layer. It >>> could be a group-name, user-name, NAI, etc, etc >>> >>> What was the reason for change? IN the beggining >> it >>> was only link layer or IP addresses. Then we >> discussed >>> this ad nauseum and concluded that it could be >>> anything, so it seems we are changing it again. >> >> >> I couldn't track where this recommendation come >> from, but I cannot see how >> the DI can be user-name, group-name, NAI, etc. DI is >> used for access >> control, and none of these identifiers are carried >> in the data packets. Only >> link-layer addresses and IP addresses. >> >> Alper >> > > > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo > http://search.yahoo.com > From pana-request@research.telcordia.COM Mon Apr 21 14:56:42 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26154 for ; Mon, 21 Apr 2003 14:56:42 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3LILpwX017315; Mon, 21 Apr 2003 14:21:51 -0400 (EDT) Resent-Date: Mon, 21 Apr 2003 14:21:51 -0400 (EDT) Old-Return-Path: Date: Mon, 21 Apr 2003 11:21:58 -0700 Subject: Re: session-id From: Alper Yegin To: Yoshihiro Ohba CC: Message-ID: In-Reply-To: <20030418223104.GA3680@catfish> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: Resent-From: pana@research.telcordia.COM X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.COM Content-Transfer-Encoding: 7bit >> If IPsec is used for access control, MAC address has no significance for >> PANA or access control. If L2 ciphers are used, IP addresses have no >> significance... > > L2 ciphers protect MAC address spoofing but do not protect IP address > spoofing. I think this is addressed in section 6.4 of > draft-ietf-pana-threats-eval-03.txt. > >> >>> >>> The IP address can be a link-local address, however, if additional >>> packet filtering is applied at EP to inner IP headers based on the >>> PaC's global IP address, then such a global IP address would need >>> to be registered to the EP as a device identifier. >> >> If we are using an IPsec tunnel between PaC and EP, the inner addresses have >> no significance for access control. So, I don't think we need to care about >> them. > > I think the relationship between outer IP address and inner IP address > is similar to the one between MAC address and IP address. Protecting > only outer IP address does not protect inner IP address spoofing. I'm > not sure whether this is the area of PANA or SEND. IMO, this would be for SEND to handle. This is on the IP address ownership side of the problem, not the access control. Alper From pana-request@research.telcordia.com Mon Apr 21 15:05:04 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26855 for ; Mon, 21 Apr 2003 15:05:03 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3LJ49o0020899; Mon, 21 Apr 2003 15:04:09 -0400 (EDT) Resent-Date: Mon, 21 Apr 2003 15:04:09 -0400 (EDT) Old-Return-Path: Message-ID: <20030421190350.11129.qmail@web40003.mail.yahoo.com> Date: Mon, 21 Apr 2003 12:03:50 -0700 (PDT) From: Reinaldo Penno Subject: Re: Issues Tracker for PANA WG drafts To: Alper Yegin , Basavaraj.Patil@nokia.com, pana@research.telcordia.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <9AIsrC.A.aGF.oCEp-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com --- Alper Yegin wrote: > Reinaldo, > > > well, > > > > I commented on that in my email to Hannes. > Information > > on the DI my not be used directly in the access > rule, > > but can influence which/how to construct the rule. > > > > If, for example, I know that the IP address is > a.b.c.d > > AND the user-name is Alper AND he is accessing > from > > his house than the filter rules are going to be X, > Y, > > Z..., otherwise M, N, O. > > Sure, that makes sense. But you don't need to carry > all these in DI. > User-name can be carried inside the client id used > during the > authentication. The location information can be > inferred from the location > of the PAA. Come on Alper, you know very well that you cannot infer the user location from the location of the PAA. You can have a huge layer 2 metro/wireless/whatever network between PAC and PAA. Not to mention that you can PAAs distribued across your layer 2 infrastructure, etc, etc, Anyway, these where only 2 examples, you can have thousands of other parameters. As I said it boils down to the fact if we think it is useful/powerful or not. I still think it provides for flexibility, will certainly have uses in the field and the changes in the protocol are manageable. regards, Reinaldo > > > > > I really do not want to drag this much further. I > just > > want to make the point that it can be very > > useful/powerful and the changes in the protocol > seem > > to be minimum. But if folks feel otherwise, that's > > okay. > > > > cheers, > > > > Reinaldo > > Alper > > > > > > > > > --- Alper Yegin wrote: > >> Hi Reinaldo, > >> > >>> My comments on some of these issues... > >>> > >>> Device-Identifier: > >>> > >>> The Device Identifier originally could be > >> anything, > >>> not necessarily a IP address(es) or link layer. > It > >>> could be a group-name, user-name, NAI, etc, etc > >>> > >>> What was the reason for change? IN the beggining > >> it > >>> was only link layer or IP addresses. Then we > >> discussed > >>> this ad nauseum and concluded that it could be > >>> anything, so it seems we are changing it again. > >> > >> > >> I couldn't track where this recommendation come > >> from, but I cannot see how > >> the DI can be user-name, group-name, NAI, etc. DI > is > >> used for access > >> control, and none of these identifiers are > carried > >> in the data packets. Only > >> link-layer addresses and IP addresses. > >> > >> Alper > >> > > > > > > __________________________________________________ > > Do you Yahoo!? > > The New Yahoo! Search - Faster. Easier. Bingo > > http://search.yahoo.com > > > __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com From pana-request@research.telcordia.com Mon Apr 21 16:19:53 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00645 for ; Mon, 21 Apr 2003 16:19:49 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3LKHg6B027183; Mon, 21 Apr 2003 16:17:42 -0400 (EDT) Resent-Date: Mon, 21 Apr 2003 16:17:42 -0400 (EDT) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Issues Tracker for PANA WG drafts Date: Mon, 21 Apr 2003 13:17:22 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A431@TNEXVS02.tahoenetworks.com> Thread-Topic: Issues Tracker for PANA WG drafts Thread-Index: AcMIN+uwlImpJct0SB2lYBsJXyAbFQACkEhg From: "Mohan Parthasarathy" To: "Reinaldo Penno" , "Alper Yegin" , , X-OriginalArrivalTime: 21 Apr 2003 20:17:22.0442 (UTC) FILETIME=[044BE6A0:01C30843] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA00645 Reinaldo, > > I commented on that in my email to Hannes. Information > on the DI my not be used directly in the access rule, > but can influence which/how to construct the rule. > > If, for example, I know that the IP address is a.b.c.d > AND the user-name is Alper AND he is accessing from > his house than the filter rules are going to be X, Y, > Z..., otherwise M, N, O. > I am not sure I understand this example. Could you describe the real life scenario where this will be used ? thanks -mohan > I really do not want to drag this much further. I just > want to make the point that it can be very > useful/powerful and the changes in the protocol seem > to be minimum. But if folks feel otherwise, that's > okay. > > cheers, > > Reinaldo > > > > --- Alper Yegin wrote: > > Hi Reinaldo, > > > > > My comments on some of these issues... > > > > > > Device-Identifier: > > > > > > The Device Identifier originally could be > > anything, > > > not necessarily a IP address(es) or link layer. It > > > could be a group-name, user-name, NAI, etc, etc > > > > > > What was the reason for change? IN the beggining > > it > > > was only link layer or IP addresses. Then we > > discussed > > > this ad nauseum and concluded that it could be > > > anything, so it seems we are changing it again. > > > > > > I couldn't track where this recommendation come > > from, but I cannot see how > > the DI can be user-name, group-name, NAI, etc. DI is > > used for access > > control, and none of these identifiers are carried > > in the data packets. Only > > link-layer addresses and IP addresses. > > > > Alper > > > > > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com > > From pana-request@research.telcordia.com Mon Apr 21 17:31:01 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03512 for ; Mon, 21 Apr 2003 17:31:01 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3LLR1Kx002540; Mon, 21 Apr 2003 17:27:01 -0400 (EDT) Resent-Date: Mon, 21 Apr 2003 17:27:01 -0400 (EDT) Old-Return-Path: Date: Mon, 21 Apr 2003 14:27:13 -0700 Subject: Re: Issues Tracker for PANA WG drafts From: Alper Yegin To: Reinaldo Penno , , Message-ID: In-Reply-To: <20030421190350.11129.qmail@web40003.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >>> well, >>> >>> I commented on that in my email to Hannes. >> Information >>> on the DI my not be used directly in the access >> rule, >>> but can influence which/how to construct the rule. >>> >>> If, for example, I know that the IP address is >> a.b.c.d >>> AND the user-name is Alper AND he is accessing >> from >>> his house than the filter rules are going to be X, >> Y, >>> Z..., otherwise M, N, O. >> >> Sure, that makes sense. But you don't need to carry >> all these in DI. >> User-name can be carried inside the client id used >> during the >> authentication. The location information can be >> inferred from the location >> of the PAA. > > Come on Alper, you know very well that you cannot > infer the user location from the location of the PAA. > You can have a huge layer 2 metro/wireless/whatever > network between PAC and PAA. Not to mention that you > can PAAs distribued across your layer 2 > infrastructure, etc, etc, You are right. PAA location by itself does not always give the kind of information you are looking for. PAA might know where a circuit is coming from, and provide this auxiliary information to the backend. I'd preemptively agree that this might not be assumed for all cases :) I think in general what you are aiming is providing some auxiliary data that can affect the "authorization". I think DI is used for one purpose, that is access control, and we should not overload it here. As for providing the additional data for authorization, one possibility is to use EAP TLVs: draft-grayson-eap-authorisation-01.txt Alper > > Anyway, these where only 2 examples, you can have > thousands of other parameters. As I said it boils down > to the fact if we think it is useful/powerful or not. > I still think it provides for flexibility, will > certainly have uses in the field and the changes in > the protocol are manageable. > > regards, > > Reinaldo > > > > >> >>> >>> I really do not want to drag this much further. I >> just >>> want to make the point that it can be very >>> useful/powerful and the changes in the protocol >> seem >>> to be minimum. But if folks feel otherwise, that's >>> okay. >>> >>> cheers, >>> >>> Reinaldo >> >> Alper >> >>> >>> >>> >>> --- Alper Yegin wrote: >>>> Hi Reinaldo, >>>> >>>>> My comments on some of these issues... >>>>> >>>>> Device-Identifier: >>>>> >>>>> The Device Identifier originally could be >>>> anything, >>>>> not necessarily a IP address(es) or link layer. >> It >>>>> could be a group-name, user-name, NAI, etc, etc >>>>> >>>>> What was the reason for change? IN the beggining >>>> it >>>>> was only link layer or IP addresses. Then we >>>> discussed >>>>> this ad nauseum and concluded that it could be >>>>> anything, so it seems we are changing it again. >>>> >>>> >>>> I couldn't track where this recommendation come >>>> from, but I cannot see how >>>> the DI can be user-name, group-name, NAI, etc. DI >> is >>>> used for access >>>> control, and none of these identifiers are >> carried >>>> in the data packets. Only >>>> link-layer addresses and IP addresses. >>>> >>>> Alper >>>> >>> >>> >>> __________________________________________________ >>> Do you Yahoo!? >>> The New Yahoo! Search - Faster. Easier. Bingo >>> http://search.yahoo.com >>> >> > > > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo > http://search.yahoo.com > > From pana-request@research.telcordia.com Mon Apr 21 20:45:51 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10529 for ; Mon, 21 Apr 2003 20:45:50 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3M0htVi015427; Mon, 21 Apr 2003 20:43:55 -0400 (EDT) Resent-Date: Mon, 21 Apr 2003 20:43:55 -0400 (EDT) Old-Return-Path: Date: Mon, 21 Apr 2003 17:43:38 -0700 To: Alper Yegin Cc: Yoshihiro Ohba , pana@research.telcordia.com Subject: Re: session-id Message-ID: <20030422004338.GA1968@steelhead> Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , pana@research.telcordia.COM References: <20030418223104.GA3680@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 42 Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Given that varidation of the inner IP address of an IPsec tunnel in the access network is a task of SEND, do you think session-id is still not necessary for PANA for the remaining part of the scenario (i.e., performing PANA with unspecified IP adress, then DHCP and finally IKE)? Yoshihiro Ohba On Mon, Apr 21, 2003 at 11:21:58AM -0700, Alper Yegin wrote: > >> If IPsec is used for access control, MAC address has no significance for > >> PANA or access control. If L2 ciphers are used, IP addresses have no > >> significance... > > > > L2 ciphers protect MAC address spoofing but do not protect IP address > > spoofing. I think this is addressed in section 6.4 of > > draft-ietf-pana-threats-eval-03.txt. > > > >> > >>> > >>> The IP address can be a link-local address, however, if additional > >>> packet filtering is applied at EP to inner IP headers based on the > >>> PaC's global IP address, then such a global IP address would need > >>> to be registered to the EP as a device identifier. > >> > >> If we are using an IPsec tunnel between PaC and EP, the inner addresses have > >> no significance for access control. So, I don't think we need to care about > >> them. > > > > I think the relationship between outer IP address and inner IP address > > is similar to the one between MAC address and IP address. Protecting > > only outer IP address does not protect inner IP address spoofing. I'm > > not sure whether this is the area of PANA or SEND. > > IMO, this would be for SEND to handle. This is on the IP address ownership > side of the problem, not the access control. > > > Alper > > From pana-request@research.telcordia.com Tue Apr 22 04:48:36 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00476 for ; Tue, 22 Apr 2003 04:48:35 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3M8lKvV009205; Tue, 22 Apr 2003 04:47:20 -0400 (EDT) Resent-Date: Tue, 22 Apr 2003 04:47:20 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: session-id Date: Tue, 22 Apr 2003 11:46:59 +0300 Message-ID: Thread-Topic: session-id Thread-Index: AcMGE47QP5Ketj83QamCaFGu8KkxhwCl9P6w From: To: , Cc: X-OriginalArrivalTime: 22 Apr 2003 08:47:00.0450 (UTC) FILETIME=[BD474420:01C308AB] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 19 April, 2003 01:31 > To: Alper Yegin > Cc: Yoshihiro Ohba; pana@research.telcordia.com > Subject: Re: session-id > > > On Fri, Apr 18, 2003 at 04:55:18PM -0700, Alper Yegin wrote: > > > Per Alper's suggestion, I try to open up a new thread for > session-id. > > > > Thank you Yoshi. > > > > > > > > In pana-00 draft, a PANA session is identified by using device > > > identifier, which is either an IP address or a MAC > address. I have > > > the following scenario which might be difficult to support in the > > > current draft: > > > > > > A PaC starts PANA with using unspecified IP address. > After the PaC > > > is succesfully authenticated, it configures an IP > address via DHCP. > > > Before the PaC obtains an IP address, the MAC address is used as > > > the device identifier. Suppose that the network forces > all PaCs to > > > use L3 ciphers, the PaC needs to perform IKE in order to > establish > > > an IPsec tunnel between the PaC and EP after the PaC > obtains an IP > > > address. > > > > I presume the assumption is that dhcp is secured. > Otherwise, the client > > could be given an IP address prior to PANA and there > wouldn't be such a > > problem. The only reason DHCP comes after PANA is that DHCP > is secured using > > PANA SA, is that right? > > I think so. > > > > > If this network is using IPsec for access control, then the > other assumption > > seems like this: Clients are allowed to perform DHCP in > addition to PANA > > before they are authorized to access the network. > > Yes, that would be the other assumption. Just one small clarification for this scenario: PANA is used for authorization and if it is succesfull, then DHCP is the next step. So, clients are not allowed to perform DHCP if PANA fails. - Dan From pana-request@research.telcordia.com Tue Apr 22 04:49:25 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00506 for ; Tue, 22 Apr 2003 04:49:25 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3M8lB7d009183; Tue, 22 Apr 2003 04:47:11 -0400 (EDT) Resent-Date: Tue, 22 Apr 2003 04:47:11 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: session-id Date: Tue, 22 Apr 2003 11:43:01 +0300 Message-ID: Thread-Topic: session-id Thread-Index: AcMGBkDOufgwBsxXTtGj6IwJ760i7ACoznkg From: To: , , Cc: X-OriginalArrivalTime: 22 Apr 2003 08:43:01.0909 (UTC) FILETIME=[2F18CC50:01C308AB] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA00506 There is a ready made solution for this problem, the Diameter Session-Id AVP. It's eternally unique and created by the AAA client (PAA). With this approach the sessions in PANA are subset with the sessions in the AAA (Diameter) backend. See below the description of this AVP from draft-ietf-aaa-diameter-17.txt. 8.8 Session-Id AVP The Session-Id AVP (AVP Code 263) is of type UTF8String and is used to identify a specific session (see section 8). All messages pertaining to a specific session MUST include only one Session-Id AVP and the same value MUST be used throughout the life of a session. When present, the Session-Id SHOULD appear immediately following the Diameter Header (see section 3). The Session-Id MUST be globally and eternally unique, as it is meant to uniquely identify a user session without reference to any other information, and may be needed to correlate historical authentication information with accounting information. The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below. The Session-Id MUST begin with the sender's identity encoded in the DiameterIdentity type (see section 4.4). The remainder of the Session-Id is delimted by a ";" character, and MAY be any sequence that the client can guarantee to be eternally unique; however, the following format is recommended, (square brackets [] indicate an optional element): ;;[;] and are decimal representations of the high and low 32 bits of a monotonically increasing 64-bit value. The 64-bit value is rendered in two part to simplify formatting by 32-bit processors. At startup, the high 32 bits of the 64-bit value MAY be initialized to the time, and the low 32 bits MAY be initialized to zero. This will for practical purposes eliminate the possibility of overlapping Session-Ids after a reboot, assuming the reboot process takes longer than a second. Alternatively, an implementation MAY keep track of the increasing value in non-volatile memory. is implementation specific but may include a modem's device Id, a layer 2 address, timestamp, etc. Example, in which there is no optional value: accesspoint7.acme.com;1876543210;523 Example, in which there is an optional value: accesspoint7.acme.com;1876543210;523;mobile@200.1.1.88 The Session-Id is created by the Diameter application initiating the session, which in most cases is done by the client. Note that a Session-Id MAY be used for both the authorization and accounting commands of a given application. > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 19 April, 2003 02:57 > To: Mohan Parthasarathy; Yoshihiro Ohba > Cc: pana@research.telcordia.com > Subject: Re: session-id > > > > I am not sure I understand the question. I thought the session id > > is used for identifying the session related stuff of a given PaC. > > But this leads to the problem of unique session ids. It might > > be easy if the PAA allocates a session ID (like SPI allocated by > > the receiver) to make it unique across all the PaCs. > > This makes sense. It might even make sense to have an > NAI-like session id, > e.g., 2343245345@PAA1.foo.com, if we care about global > identification for > any reason. > > Alper > > From pana-request@research.telcordia.com Tue Apr 22 04:57:06 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00597 for ; Tue, 22 Apr 2003 04:57:06 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3M8vA3u009597; Tue, 22 Apr 2003 04:57:10 -0400 (EDT) Resent-Date: Tue, 22 Apr 2003 04:57:10 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: session-id Date: Tue, 22 Apr 2003 11:53:06 +0300 Message-ID: Thread-Topic: session-id Thread-Index: AcMFrpMSo1ZfB5hFTsK4r60YZTPePAC/VgXA From: To: , , X-OriginalArrivalTime: 22 Apr 2003 08:53:06.0884 (UTC) FILETIME=[97B0A840:01C308AC] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ext Hannes Tschofenig [mailto:hannes@tschofenig.com] > Sent: 18 April, 2003 16:12 > To: Yoshihiro Ohba; pana@research.telcordia.com > Subject: RE: session-id > > > hi yoshi, > > the session id-stuff is addressed with Issue 6: Session > Identifier or SPIs. > > i fully agree with you with respect to the dhcp based > scenario. i also agree > to your conclusions and i fully support > - the introduction of an identifier which is different to the > mac/ip address > - the ability to update the mac/ip address I fully agree. > furthermore i think that it is good to separate the different > identifiers > and to avoid overloading. (as a general design principle) That's right. > it is helpful to point to installed state information based on a fixed > length identifier instead of using something with variable > length (different > link layer addresses, ipv4/ipv6 addresses). > > the uniqueness of such an identifier, however, requires some care: > > a) is it sufficient to have (let's say) a 128-bit number > which is randomly > created? > > b) should we apply a concept similar to the spi (ike, ikev2) > which provides > uniqueness between the two entities. however, in case of mobility spi > collisions still can occur. Session ID scope is quite hard to manage when there are multiple PAAs involved, reboots etc. See my email on Diameter Session-Id. It's not fixed length, but is a ready concept. Also, interaction between PANA and Diameter is likely to occur. - Dan > ciao > hannes > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Donnerstag, 17. April 2003 07:28 > > To: pana@research.telcordia.com > > Subject: session-id > > > > > > Per Alper's suggestion, I try to open up a new thread for > session-id. > > > > In pana-00 draft, a PANA session is identified by using device > > identifier, which is either an IP address or a MAC address. I have > > the following scenario which might be difficult to support in the > > current draft: > > > > A PaC starts PANA with using unspecified IP address. > After the PaC > > is succesfully authenticated, it configures an IP > address via DHCP. > > Before the PaC obtains an IP address, the MAC address is used as > > the device identifier. Suppose that the network forces > all PaCs to > > use L3 ciphers, the PaC needs to perform IKE in order to > establish > > an IPsec tunnel between the PaC and EP after the PaC > obtains an IP > > address. > > > > The IKE credential is to be derived from EAP Master Key > established > > between the PaC and PAA as a result of successful PANA > > authentication (I presume an Informational RFC describes a > > mechanism for the credential derivation). > > > > In order for IKE to succeed, the EP needs to know the IKE > > credential and IP address of the PaC. This means that IP address > > should also be a device identifier even when the MAC > > address is initially used as the device identifier. > Note that the > > MAC address may still be used as a device identifier > even after the > > PaC configures an IP address, in order to secure future DHCP > > re-configuration. > > > > The IP address can be a link-local address, however, if > additional > > packet filtering is applied at EP to inner IP headers > based on the > > PaC's global IP address, then such a global IP address would need > > to be registered to the EP as a device identifier. > > > > This scenario might affect PANA design as follows: > > > > - Both MAC address and IP address might need to be used as device > > identifier at one time. > > > > - Multiple IP addresses might need to be used as device > identifier at > > one time. > > > > These observation might boil down to the following > functionalities for > > PANA: > > > > - Ability to update device identifier, perhaps based on add/delete > > operation. > > > > - Ability to identify a PANA session based on a session identifier, > > which is more stable identifier than device identifier. > > > > > > Comments? > > > > Yoshihiro Ohba > > > > From pana-request@research.telcordia.com Tue Apr 22 10:39:08 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12065 for ; Tue, 22 Apr 2003 10:39:08 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3MEbZvB009289; Tue, 22 Apr 2003 10:37:35 -0400 (EDT) Resent-Date: Tue, 22 Apr 2003 10:37:35 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: eap method sequencing Date: Tue, 22 Apr 2003 17:36:42 +0300 Message-ID: Thread-Topic: eap method sequencing Thread-Index: AcMEIRptbRxGN4kWQQe76RawTLtBQQEtR5RQ From: To: , X-OriginalArrivalTime: 22 Apr 2003 14:36:42.0777 (UTC) FILETIME=[97B84890:01C308DC] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA12065 Hi, I think this could be a policy issue (a configurable parameter) in the network side. You could create an issue about this, though. - Dan > -----Original Message----- > From: ext Hannes Tschofenig [mailto:hannes@tschofenig.com] > Sent: 16 April, 2003 16:47 > To: pana@research.telcordia.com > Subject: eap method sequencing > > > hi all, > > i would like to point the group to an interesting discussion about > sequencing in the eap wg. > > pana provides eap method sequencing. > > we do we need to limit to two? (seems to be a fairly low number!) > > " PAA enables two separate authentication, it should > not set F-flag in the PANA_success or PANA_failure message > after the > first EAP method. " > > does someone has an option regarding sequencing and scenarios > in this group? > > ciao > hannes > > > ----- Original Message ----- > From: "John Vollbrecht" > To: ; > Sent: Wednesday, April 16, 2003 3:22 AM > Subject: Re: [eap] Re: Issue 104: Sequence prohibition > > > > > > I believe the discussion was that sequences would not be > allowed except > > within a protected method. I think the requirement here is that > > "protected" variable be set that then allows sequences. > > > > We should add this to the state machine. > > > > John > > > > --On Tuesday, April 15, 2003 9:50 PM +0300 > Pasi.Eronen@nokia.com wrote: > > > > > > > > Hi, > > > > > > Was this the consensus at IETF 56? The minutes aren't > > > completely clear on this topic: issue 87 really refers > > > only to starting another method before the first one is > > > completed. Was the decision that not only type change > > > during one method is forbidden, but all sequences > > > (of methods >=4) are forbidden? > > > > > > (I'm not an fan of sequences myself, but we've been > > > working on the state machine diagrams with John, Nick > > > and Yoshihiro, and the current versions are in rather > > > good shape, and do support sequences. We can change > > > them to forbid sequences if the consensus is > > > that they must not be allowed.) > > > > > > Best regards, > > > Pasi > > > > > > > -----Original Message----- > > > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > > > Sent: Monday, April 14, 2003 8:46 PM > > > > To: eap@frascone.com > > > > Subject: [eap] Issue 104: Sequence prohibition > > > > > > > > > > > > Submitter name: Bernard Aboba > > > > Submitter email address: aboba@internaut.com > > > > Date first submitted: April 14th, 2003 > > > > Reference: > > > > Document: EAP-01 > > > > Comment type: T > > > > Priority: S > > > > Section: 2.1 > > > > Rationale/Explanation of issue: > > > > > > > > At IETF 56, it was proposed that sequences of EAP > methods MUST NOT > > be > > > > supported (with an exception for tunneled EAP methods). The > > > > following text > > > > changes support that proposal. > > > > > > > > Change Section 2.1 from: > > > > > > > > " 2.1 Support for sequences > > > > > > > > An EAP conversation MAY utilize a sequence of methods. A common > > > > example of this is an Identity request followed by a single EAP > > > > authentication method such as an MD5-Challenge. > However, within or > > > > associated with each EAP server, it is not anticipated that a > > > > particular named peer will utilize multiple > authentication methods > > > > (Type 4 or greater), either by supporting a choice of > methods or by > > > > using multiple methods in sequence. This would make the peer > > > > vulnerable to attacks that negotiate the least secure > method from > > > > among a set (negotiation attacks, described in Section 7.8) or > > > > man-in-the-middle attacks (described in Section 7.4). > Instead, for > > > > each named peer there SHOULD be an indication of > exactly one method > > > > used to authenticate that peer name. If a peer needs to > make use of > > > > different authentication methods under different > circumstances, then > > > > distinct identities SHOULD be employed, each of which identifies > > > > exactly one authentication method. If additional authentication > > > > methods are required beyond the initial one, the > authenticator MAY > > > > send a Request packet for a subsequent authentication > method, or it > > > > MAY send another Identity request. If the peer does not support > > > > additional methods, it SHOULD respond with a Nak, indicating no > > > > acceptable alternative, as described in Section 5.3. > However, peer > > > > implementations MAY not respond at all, in which case a > timeout will > > > > result and authentication will fail. Since the authenticator > > > > presumably requires successful completion of the > sequence in order > > to > > > > grant access, authentication failure is the correct result. > > > > Therefore, it is not necessary for the authenticator to > determine > > > > that the peer supports sequences prior to sending a > Request for a > > > > subsequent authentication method. > > > > > > > > The above prescription also applies in the situation where an > > > > authenticator sends a message of a different Type prior to > > completion > > > > of the final round of a given method. If the peer > wishes to continue > > > > authenticating with the method in progress, it SHOULD > send a Nak in > > > > response to such a Request, indicating the Type in > progress as the > > > > alternative. Otherwise it MAY send a Response with the > same Type as > > > > the Request. Since an EAP packet with a different Type > may be sent > > > > by an attacker, an authenticator receiving a Nak including a > > > > preference for the Type in progress SHOULD log the event, but > > > > otherwise not take any action. > > > > > > > > Once a peer has sent a Response of the same Type as a > Request, some > > > > existing peer implementations might expect the method to run to > > > > completion. As a result, these implementations silently > discard EAP > > > > Requests of a Type different from the method in > progress, despite > > the > > > > requirement for a Response in Section 4.1. For this reason, EAP > > > > authenticators that must interoperate with these peers are > > > > discouraged from switching methods before the final > round of a given > > > > method has completed." > > > > > > > > To: > > > > > > > > "2.1 Support for sequences > > > > > > > > An EAP conversation MAY utilize a sequence of methods. A common > > > > example of this is an Identity request followed by a single EAP > > > > authentication method such as an MD5-Challenge. However a peer > > > > MUST utilize only one authentication method (Type 4 or greater) > > > > within an EAP conversation. > > > > > > > > Once a peer has sent a Response of the same Type as the initial > > > > Request, an authenticator MUST NOT send a Request of a different > > Type > > > > prior to completion of the final round of a given method, and > > > > MUST NOT send a Request for an additional methods of any Type > > > > after completion of the initial authentication method. > > > > > > > > Supporting multiple authentication > > > > methods within an EAP conversation would add complexity > > > > to the EAP protocol, would enable man-in-the-middle attacks > > > > (see Section 7.4), and would result in interoperablity problems, > > > > since existing EAP implementations typically do not support > > > > sequences. > > > > > > > > If an additional authentication method is requested by the > > > > authenticator, or if the authenticator sends a Request of > > > > a different Type prior to completion of the final round of > > > > a given method, the peer SHOULD silently discard the > > > > Request. As an alternative, the peer MAY > > > > respond with a Nak, indicating no acceptable alternative, > > > > as described in Section 5.3. Since spoofed EAP > > > > Request packets may be sent by an attacker, an > > > > an authenticator receiving an unexpected Nak SHOULD log the > > > > event. > > > > > > > > The case where a single EAP authentication method is > > > > utilized, but other methods are run inside it, does not > > > > qualify as a sequence of EAP methods as defined here. Such > > > > "tunneled" methods appear to the EAP state machine as a single > > > > method. Backward compatibility can be provided, since a peer > > > > not supporting a "tunneled" method can reply to the initial > > > > EAP-Request with a Nak. To avoid adding man-in-the-middle > > > > vulnerabilities, "tunneled" methods MUST support protection > > > > against these attacks. > > > > > > > > Within or associated with each EAP server, it is not anticipated > > > > that a particular named pper will support a choice of methods. > > > > This would make the peer vulnerable to attacks that > negotiate the > > > > least secure method from among a set (negotiation attacks, > > > > described in Section 7.8). Instead, for > > > > each named peer there SHOULD be an indication of > exactly one method > > > > used to authenticate that peer name. If a peer needs to > make use of > > > > different authentication methods under different > circumstances, then > > > > distinct identities SHOULD be employed, each of which identifies > > > > exactly one authentication method. " > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/eap > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > > From pana-request@research.telcordia.com Tue Apr 22 10:56:21 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12606 for ; Tue, 22 Apr 2003 10:56:20 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3MEuffo011040; Tue, 22 Apr 2003 10:56:41 -0400 (EDT) Resent-Date: Tue, 22 Apr 2003 10:56:41 -0400 (EDT) Old-Return-Path: Message-ID: <3EA5581A.9050502@alcatel.fr> Date: Tue, 22 Apr 2003 16:56:26 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: pana@research.telcordia.com Subject: "new" issue / Event Notification References: <697DAA22C5004B4596E033803A7CEF4402058D8B@daebe007.americas.nokia.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/22/2003 16:56:25, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/22/2003 16:56:27, Serialize complete at 04/22/2003 16:56:27 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi all, the following is about the discovery phase in the pana draft: PaC may also choose to start sending packets before getting authenticated. In that case, the network should detect this and send an unsolicited PANA_start message to PaC. EP is the node that can detect such activity. If EP and PAA are co-located, then an internal mechanism (e.g. API) between the EP module and the PAA module on the same host can prompt PAA to start PANA. In case they are separate, there needs to [be] an explicit message to prompt PAA. 1/ on the one hand, the current version of the pana protocol quickly states [discovery section] that, in case of 'traffic-driven' authentication, the EP must send a PANA_start message to the PAA: Upon detecting the need to authenticate a client, EP can send a PAC_discovery message to the PAA on behalf of the PaC. This message carries a device identifier of the PaC in a Device-Id AVP. 2/ on the other hand, the requirements draft [EP-PAA protocol section] states that the PAA-EP protocol should support event-notification also: Depending on the PANA protocol design, support for either of the push model (i.e., EP initiating the PAA-EP protocol exchange per PaC) or the pull model (i.e., PAA initiating the PAA-EP protocol exchange per PaC), or both might be required. --> the working group should fix this (not listed on the web site) issue also (the PANA protocol OR the PAA-EP protocol supports the EP-triggering) my personal feeling on this is that the PANA protocol should be restricted to PaC-PAA communication and the PAA-EP protocol (whichever you finaly choose) should take it as a requirement. thanks, yacine From pana-request@research.telcordia.com Tue Apr 22 11:09:05 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13053 for ; Tue, 22 Apr 2003 11:09:00 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3MF9Fao012210; Tue, 22 Apr 2003 11:09:15 -0400 (EDT) Resent-Date: Tue, 22 Apr 2003 11:09:15 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: "new" issue / Event Notification Date: Tue, 22 Apr 2003 18:09:03 +0300 Message-ID: Thread-Topic: "new" issue / Event Notification Thread-Index: AcMI33NQR4nRdm8pSqWmNto0yiNN7QAAW2Qw From: To: , X-OriginalArrivalTime: 22 Apr 2003 15:09:03.0972 (UTC) FILETIME=[1CC32240:01C308E1] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA13053 I've created a new issue (Issue11) about this. In general I think that text replacement should be provided. But, let's see what chairs think about this issue system.. - Dan > -----Original Message----- > From: ext Yacine.El_Mghazli@alcatel.fr > [mailto:Yacine.El_Mghazli@alcatel.fr] > Sent: 22 April, 2003 17:56 > To: pana@research.telcordia.com > Subject: "new" issue / Event Notification > > > hi all, > > the following is about the discovery phase in the pana draft: > > PaC may also choose to start sending packets before getting > authenticated. In that case, the network should detect this and > send an unsolicited PANA_start message to PaC. EP is the > node that > can detect such activity. If EP and PAA are co-located, then an > internal mechanism (e.g. API) between the EP module and the PAA > module on the same host can prompt PAA to start PANA. In > case they > are separate, there needs to [be] an explicit message to prompt > PAA. > > > 1/ on the one hand, the current version of the pana protocol quickly > states [discovery section] that, in case of 'traffic-driven' > authentication, the EP must send a PANA_start message to the PAA: > > Upon detecting the need to authenticate a client, EP can send a > PAC_discovery message to the PAA on behalf of the PaC. This > message carries a device identifier of the PaC in a Device-Id AVP. > > 2/ on the other hand, the requirements draft [EP-PAA protocol > section] > states that the PAA-EP protocol should support > event-notification also: > > Depending on the PANA protocol design, support for either > of the push > model (i.e., EP initiating the PAA-EP protocol exchange > per PaC) or > the pull model (i.e., PAA initiating the PAA-EP protocol > exchange per > PaC), or both might be required. > > > --> the working group should fix this (not listed on the web > site) issue > also (the PANA protocol OR the PAA-EP protocol supports the > EP-triggering) > > my personal feeling on this is that the PANA protocol should be > restricted to PaC-PAA communication and the PAA-EP protocol > (whichever > you finaly choose) should take it as a requirement. > > thanks, > yacine > > > From pana-request@research.telcordia.com Tue Apr 22 11:13:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13308 for ; Tue, 22 Apr 2003 11:13:51 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3MFE9Rk012702; Tue, 22 Apr 2003 11:14:09 -0400 (EDT) Resent-Date: Tue, 22 Apr 2003 11:14:09 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: session-id Date: Tue, 22 Apr 2003 18:10:12 +0300 Message-ID: Thread-Topic: session-id Thread-Index: AcMIunwrvEzsx3qrQBak6CNGhPyGfwAJqlkA From: To: , , , Cc: X-OriginalArrivalTime: 22 Apr 2003 15:10:12.0788 (UTC) FILETIME=[45C79F40:01C308E1] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA13308 I've added a text proposal to the issue tracker: Replace: "Session Identifier: The device identifier is also used as the session identifier. This is used for indicating a disconnect or session revocation or for charging purposes." With: "Session Identifier: Session-Id AVP [DIAMETER] is used as the session identifier. This is used for indicating a disconnect or session revocation or for charging purposes." - Dan > -----Original Message----- > From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@siemens.com] > Sent: 22 April, 2003 13:31 > To: Forsberg Dan (NRC/Helsinki); alper@docomolabs-usa.com; > mohanp@tahoenetworks.com; yohba@tari.toshiba.com > Cc: pana@research.telcordia.com > Subject: RE: session-id > > > hi dan, > > thanks for pointing to the diameter session id. sounds good. > > ciao > > hannes > > > > > -----Original Message----- > > > From: Dan.Forsberg@nokia.com [mailto:Dan.Forsberg@nokia.com] > > > Sent: Dienstag, 22. April 2003 10:43 > > > To: alper@docomolabs-usa.com; mohanp@tahoenetworks.com; > > > yohba@tari.toshiba.com > > > Cc: pana@research.telcordia.com > > > Subject: RE: session-id > > > > > > > > > There is a ready made solution for this problem, the Diameter > > > Session-Id AVP. It's eternally unique and created by the AAA > > > client (PAA). With this approach the sessions in PANA are subset > > > with the sessions in the AAA (Diameter) backend. > > > > > > See below the description of this AVP from > draft-ietf-aaa-diameter-17.txt. > > > > > > > > > 8.8 Session-Id AVP > > > > > > The Session-Id AVP (AVP Code 263) is of type UTF8String and is used > > > to identify a specific session (see section 8). All messages > > > pertaining to a specific session MUST include only one > Session-Id AVP > > > and the same value MUST be used throughout the life of a session. > > > When present, the Session-Id SHOULD appear immediately following the > > > Diameter Header (see section 3). > > > > > > The Session-Id MUST be globally and eternally unique, as it is meant > > > to uniquely identify a user session without reference to any other > > > information, and may be needed to correlate historical > authentication > > > information with accounting information. The Session-Id includes a > > > mandatory portion and an implementation-defined portion; a > > > recommended format for the implementation-defined portion > is outlined > > > below. > > > > > > The Session-Id MUST begin with the sender's identity encoded in the > > > DiameterIdentity type (see section 4.4). The remainder of the > > > Session-Id is delimted by a ";" character, and MAY be any sequence > > > that the client can guarantee to be eternally unique; however, the > > > following format is recommended, (square brackets [] indicate an > > > optional element): > > > ;;[;] > > > > > > and are decimal representations of the > > > high and low 32 bits of a monotonically increasing 64-bit value. The > > > 64-bit value is rendered in two part to simplify formatting > by 32-bit > > > processors. At startup, the high 32 bits of the 64-bit value MAY be > > > initialized to the time, and the low 32 bits MAY be initialized to > > > zero. This will for practical purposes eliminate the possibility of > > > overlapping Session-Ids after a reboot, assuming the reboot process > > > takes longer than a second. Alternatively, an > implementation MAY keep > > > track of the increasing value in non-volatile memory. > > > > > > is implementation specific but may include > a modem's > > > device Id, a layer 2 address, timestamp, etc. > > > > > > Example, in which there is no optional value: > > > accesspoint7.acme.com;1876543210;523 > > > > > > Example, in which there is an optional value: > > > accesspoint7.acme.com;1876543210;523;mobile@200.1.1.88 > > > > > > The Session-Id is created by the Diameter application initiating the > > > session, which in most cases is done by the client. Note that a > > > Session-Id MAY be used for both the authorization and accounting > > > commands of a given application. > > > > > > > > > > > > > -----Original Message----- > > > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > > > Sent: 19 April, 2003 02:57 > > > > To: Mohan Parthasarathy; Yoshihiro Ohba > > > > Cc: pana@research.telcordia.com > > > > Subject: Re: session-id > > > > > > > > > > > > > I am not sure I understand the question. I thought the > session id > > > > > is used for identifying the session related stuff of a > given PaC. > > > > > But this leads to the problem of unique session ids. It might > > > > > be easy if the PAA allocates a session ID (like SPI allocated by > > > > > the receiver) to make it unique across all the PaCs. > > > > > > > > This makes sense. It might even make sense to have an > > > > NAI-like session id, > > > > e.g., 2343245345@PAA1.foo.com, if we care about global > > > > identification for > > > > any reason. > > > > > > > > Alper > > > > > > > > > > > > > > From pana-request@research.telcordia.com Tue Apr 22 15:04:59 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21097 for ; Tue, 22 Apr 2003 15:04:59 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3MJ4ltT001283; Tue, 22 Apr 2003 15:04:47 -0400 (EDT) Resent-Date: Tue, 22 Apr 2003 15:04:47 -0400 (EDT) Old-Return-Path: Date: Tue, 22 Apr 2003 12:04:32 -0700 Subject: Re: "new" issue / Event Notification From: Alper Yegin To: , Message-ID: In-Reply-To: <3EA5581A.9050502@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hello Yacine, I couldn't see an inconsistency here. The requirements draft says the PAA-EP protocol should support either push model, or pull model, or both depending on the PANA protocol design. And the current PANA protocol design lets EP notify the PAA about unauthenticated PaCs. Hence the only requirement on the PAA-EP protocol is the support for the "pull model" (as defined below). Does this make sense? Alper > hi all, > > the following is about the discovery phase in the pana draft: > > PaC may also choose to start sending packets before getting > authenticated. In that case, the network should detect this and > send an unsolicited PANA_start message to PaC. EP is the node that > can detect such activity. If EP and PAA are co-located, then an > internal mechanism (e.g. API) between the EP module and the PAA > module on the same host can prompt PAA to start PANA. In case they > are separate, there needs to [be] an explicit message to prompt > PAA. > > > 1/ on the one hand, the current version of the pana protocol quickly > states [discovery section] that, in case of 'traffic-driven' > authentication, the EP must send a PANA_start message to the PAA: > > Upon detecting the need to authenticate a client, EP can send a > PAC_discovery message to the PAA on behalf of the PaC. This > message carries a device identifier of the PaC in a Device-Id AVP. > > 2/ on the other hand, the requirements draft [EP-PAA protocol section] > states that the PAA-EP protocol should support event-notification also: > > Depending on the PANA protocol design, support for either of the push > model (i.e., EP initiating the PAA-EP protocol exchange per PaC) or > the pull model (i.e., PAA initiating the PAA-EP protocol exchange per > PaC), or both might be required. > > > --> the working group should fix this (not listed on the web site) issue > also (the PANA protocol OR the PAA-EP protocol supports the EP-triggering) > > my personal feeling on this is that the PANA protocol should be > restricted to PaC-PAA communication and the PAA-EP protocol (whichever > you finaly choose) should take it as a requirement. > > thanks, > yacine > > > From pana-request@research.telcordia.com Tue Apr 22 15:18:43 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22453 for ; Tue, 22 Apr 2003 15:18:39 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3MIm0S8029983; Tue, 22 Apr 2003 14:48:00 -0400 (EDT) Resent-Date: Tue, 22 Apr 2003 14:48:00 -0400 (EDT) Old-Return-Path: Date: Tue, 22 Apr 2003 11:47:46 -0700 Subject: Re: session-id From: Alper Yegin To: Yoshihiro Ohba CC: Message-ID: In-Reply-To: <20030422004338.GA1968@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > > Given that varidation of the inner IP address of an IPsec tunnel in > the access network is a task of SEND, do you think session-id is still > not necessary for PANA for the remaining part of the scenario (i.e., > performing PANA with unspecified IP adress, then DHCP and finally > IKE)? I'm inclined to think session id concept would be useful, but let's see what else we want to use session ids for, and how it will impact the protocol design. Alper > > Yoshihiro Ohba > > > On Mon, Apr 21, 2003 at 11:21:58AM -0700, Alper Yegin wrote: >>>> If IPsec is used for access control, MAC address has no significance for >>>> PANA or access control. If L2 ciphers are used, IP addresses have no >>>> significance... >>> >>> L2 ciphers protect MAC address spoofing but do not protect IP address >>> spoofing. I think this is addressed in section 6.4 of >>> draft-ietf-pana-threats-eval-03.txt. >>> >>>> >>>>> >>>>> The IP address can be a link-local address, however, if additional >>>>> packet filtering is applied at EP to inner IP headers based on the >>>>> PaC's global IP address, then such a global IP address would need >>>>> to be registered to the EP as a device identifier. >>>> >>>> If we are using an IPsec tunnel between PaC and EP, the inner addresses >>>> have >>>> no significance for access control. So, I don't think we need to care about >>>> them. >>> >>> I think the relationship between outer IP address and inner IP address >>> is similar to the one between MAC address and IP address. Protecting >>> only outer IP address does not protect inner IP address spoofing. I'm >>> not sure whether this is the area of PANA or SEND. >> >> IMO, this would be for SEND to handle. This is on the IP address ownership >> side of the problem, not the access control. >> >> >> Alper >> >> > From pana-request@research.telcordia.com Wed Apr 23 05:50:29 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09245 for ; Wed, 23 Apr 2003 05:50:29 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3N9n7nE027992; Wed, 23 Apr 2003 05:49:07 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 05:49:07 -0400 (EDT) Old-Return-Path: Message-ID: <3EA66178.1030504@alcatel.fr> Date: Wed, 23 Apr 2003 11:48:40 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Alper Yegin CC: pana@research.telcordia.com Subject: Re: "new" issue / Event Notification References: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/23/2003 11:48:40, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/23/2003 11:48:45, Serialize complete at 04/23/2003 11:48:45 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Alper, Alper Yegin wrote: > Hello Yacine, > > I couldn't see an inconsistency here. > > The requirements draft says the PAA-EP protocol should support either push > model, or pull model, or both depending on the PANA protocol design. > And the current PANA protocol design lets EP notify the PAA about > unauthenticated PaCs. Hence the only requirement on the PAA-EP protocol is > the support for the "pull model" (as defined below). > > Does this make sense? yes, this is the current view. did the PANA WG reached a consensus on this subject ? I'm curious about the technical motivations of the design team for such a choice in the PANA protocol design. > Alper thank you, yacine NB: terminology question for the req-draft authors: the PUSH model is defined as follows: - "EP initiating the PAA-EP protocol exchange per PaC" and the PULL model corresponds to: - "PAA initiating the PAA-EP protocol exchange per PaC" is that really what you meant ? isn't it the contrary ? usually, the 'PULL model' better corresponds to bottom-up (EP->PAA) initiated communication. > > > > >>hi all, >> >>the following is about the discovery phase in the pana draft: >> >> PaC may also choose to start sending packets before getting >> authenticated. In that case, the network should detect this and >> send an unsolicited PANA_start message to PaC. EP is the node that >> can detect such activity. If EP and PAA are co-located, then an >> internal mechanism (e.g. API) between the EP module and the PAA >> module on the same host can prompt PAA to start PANA. In case they >> are separate, there needs to [be] an explicit message to prompt >> PAA. >> >> >>1/ on the one hand, the current version of the pana protocol quickly >>states [discovery section] that, in case of 'traffic-driven' >>authentication, the EP must send a PANA_start message to the PAA: >> >> Upon detecting the need to authenticate a client, EP can send a >> PAC_discovery message to the PAA on behalf of the PaC. This >> message carries a device identifier of the PaC in a Device-Id AVP. >> >>2/ on the other hand, the requirements draft [EP-PAA protocol section] >>states that the PAA-EP protocol should support event-notification also: >> >> Depending on the PANA protocol design, support for either of the push >> model (i.e., EP initiating the PAA-EP protocol exchange per PaC) or >> the pull model (i.e., PAA initiating the PAA-EP protocol exchange per >> PaC), or both might be required. >> >> >>--> the working group should fix this (not listed on the web site) issue >>also (the PANA protocol OR the PAA-EP protocol supports the EP-triggering) >> >>my personal feeling on this is that the PANA protocol should be >>restricted to PaC-PAA communication and the PAA-EP protocol (whichever >>you finaly choose) should take it as a requirement. >> >>thanks, >>yacine >> >> >> >> > > From pana-request@research.telcordia.com Wed Apr 23 06:56:31 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11083 for ; Wed, 23 Apr 2003 06:56:31 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3NAtRpv004307; Wed, 23 Apr 2003 06:55:27 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 06:55:27 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Proposal for message formatting (sec. 9). Date: Wed, 23 Apr 2003 13:51:31 +0300 Message-ID: Thread-Topic: Proposal for message formatting (sec. 9). Thread-Index: AcMEcejDE7ebc1iwRUed5JF5yR08OgFEWuYA From: To: , X-OriginalArrivalTime: 23 Apr 2003 10:51:32.0474 (UTC) FILETIME=[4D5D65A0:01C30986] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA11083 Alper, "application ID" could refer to a separate document that uses PANA as its transport. PANA provides authentication for network access by carrying EAP, which itself can be seen as an application. Other applications could be related to DHCP and SEND, or even IKE? For example the Diameter draft specifies five different app ids, that are advertised through capability exchange messages (CER/CEA): Diameter Common Messages 0 NASREQ 1 [NASREQ] Mobile-IP 2 [DIAMMIP] Diameter Base Accounting 3 Relay 0xffffffff Issue1 "Capability Negotiation" could benefit from application ids too. - Dan > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 17 April, 2003 02:43 > To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > Subject: Re: Proposal for message formatting (sec. 9). > > > > Dan, > > Not having that Diameter-specific field in the PANA header > does not mean > that PANA will be incompatible with Diameter. I'm afraid the level of > compatibility you are aiming is "source code compatibility". > > I'm not concerned about the header size, but I'm concerned about > incorporating headers into PANA that currently does not mean > anything to > PANA. Is there an explanation of what "application ID" means to PANA? > Do we have this field in other applications of Diameter, such > as in the > Mobile IPv4 header, or PPP or 802.1x headers? > > Alper > > > > > > Alper, > > > > Diameter compatibility is not a requirement, but a > possibility :). I don't see > > it causing udesirable side effects. App-Id is not causing > problems, but making > > the header a bit bigger. It can help PANA to become more > popular/useful and to > > cope with possible future extensions/capabilities (list of > app-ids supported). > > Do you see any drawbacks in this, or issues why we should > not be compatible > > with Diameter? > > > > We should ask other's opinions too. > > > > - Dan > > > >> -----Original Message----- > >> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > >> Sent: 16 April, 2003 03:15 > >> To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > >> Subject: Re: Proposal for message formatting (sec. 9). > >> > >> > >> Hi Dan, > >> > >> It seems like you are treating Diameter compatibility as if it is a > >> requirement. It might be a desirable feature at best. Sure it > >> helps with > >> some code reuse or implimentation shortcuts, but these are > >> not necessary > >> for the protocol design, and should not cause undesirable > >> side effects. > >> PANA is not really meant to be an appendix to Diameter. > >> Diameter is one of > >> the possible backend AAA protocols only. > >> > >> For example, addition of the "application id" field is not > >> justifiable for > >> PANA imo. I didn't quite understand the future application > >> support. For > >> future extensions a reserved field might be more than > >> sufficient. Actually > >> AVPs might be good enough too. > >> > >> 64-bit alignment is a nice feature too. I'm not sure which > >> one is better > >> though: Diameter harmonization or this. > >> > >> Alper > >> > >> > >>> Alper, > >>> > >>> Thank you for your comments. > >>> > >>>> -----Original Message----- > >>>> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > >>>> Sent: 14 April, 2003 23:54 > >>>> To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > >>>> Subject: Re: Proposal for message formatting (sec. 9). > >>>> > >>>> > >>>> > >>>> Hi Dan, > >>>> > >>>> Thank you for putting together the Message Format section. > >>>> > >>>> Here are some comments on the current design: > >>>> > >>>> - I see the message formats includes some protocol features > >>>> we have not > >>>> fully discussed yet. For example: session-id, add-device-id, > >>>> remove-device-id. I recommend we separately discuss them > >>>> first, and than > >>>> incorporate into the message formats if necessary. > >>> > >>> Sure. > >>> > >>>> - I understand the desire to re-use DIAMETER code, but let's > >>>> not overdo it. > >>>> From "PANA design perspective", I don't see why we should > >>>> have "Application > >>>> ID" field in the header. > >>> > >>> To make the header structure similar to Diameter. If we > >> break it, then it > >>> doesn't matter what kind of format we use, because > >> implementations must be > >>> different then. > >>> > >>> We have a prototype that uses Diameter message formatting > >> (testing SeNAA) on > >>> top of UDP. This is a very nice feature, because the > >> Diameter stack callbacks > >>> can be used with PANA messages too. The interaction with > >> the AAA backend > >>> becomes very smooth. This means of course that Diameter and > >> PANA id values > >>> don't overlap. > >>> > >>> With Diameter PANA could have Application-Id 4 and the new > >> AVPs could be > >>> registered from the Diameter number space (or then we could > >> use Vendor-Id for > >>> PANA). I talked with John Loughney (one of the authors of > >> Diameter base spec) > >>> about this and he didn't see any problems with this approach. > >>> > >>> PANA could support different applications in the future > >> too. A preshared SA > >>> between PaC and PAA and extensible message types sounds > >> compelling. And if the > >>> protocol works smoothly with AAA backends (one doesn't have > >> to specify > >>> different AVPs with Diameter and PANA) the scenario looks > >> interesting. > >>> > >>>> - Device ID can also include various link-layer address > >>>> types. Let's reflect > >>>> that onto the design (currently only IP addresses are included). > >>> > >>> Sure. > >>> > >>>> - How about alignment requirements? I'd say we should > >> require 8-octet > >>>> alignment for AVPs. > >>> > >>> If that doesn't break the Diameter compatibility. > >>> > >>>> > >>>> Alper > >>>> > >>>>> Hi, > >>>>> > >>>>> Attached you can find a proposal section (9 Message Formats) > >>>>> for the draft-ietf-pana-pana-00.txt. It contains some changes > >>>>> that affect the whole draft. > >>>>> > >>>>> There are no error messages defined, which I think should be > >>>>> fixed. This is not only a message format issue, but a protocol > >>>>> issue. > >>>>> > >>>>> Changes to the pana draft in general: > >>>>> > >>>>> - Message naming convention changed (*_ack --> *-Answer, > >>>>> * --> *-Request) to better reflect the Diameter style > >>>>> and the nature of the protocol: answers contain data, > >>>>> but for acks it is not so clear. Requests and answers > >>>>> describe better the protocol. > >>>>> > >>>>> - Thus, 2 messages instead of 1: > >>>>> - PANA-Auth-Request & PANA-Auth-Answer. > >>>>> PAA always sends PANA-Auth-Request and requires an > >>>>> answer to it. > >>>>> - PANA-Start-Request & PANA-Start-Answer. > >>>>> PANA-Start messages are different depending on the sender. > >>>>> - PANA-Success-Request/Answer: PANA requires answer to success, > >>>>> because he PANA SA is not otherwise established properly. > >>>>> And for sake of simplicity, the same naming convention > >>>>> should be used. > >>>>> > >>>>> - Flag change: A flag to R flag to better reflect > Diameter style. > >>>>> Requests have the R flag set, answers unset. > >>>>> > >>>>> - Name change: Data-Protection --> Protection-Capability. > >>>>> Data-Protection is misleading term. > >>>>> > >>>>> - Name change: Revocation-Status --> Termination-Cause > (Diameter). > >>>>> There is already an AVP that suits for this purpose. > >>>>> > >>>>> - PANA-Disconnect-Request now contains Termination-Cause AVP. > >>>>> There are different reasons for the user to disconnect. > >>>>> > >>>>> > >>>>> > >>>>> Comments welcome, > >>>>> - Dan > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > > > From pana-request@research.telcordia.com Wed Apr 23 08:21:13 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15317 for ; Wed, 23 Apr 2003 08:21:13 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3NCJOCh008729; Wed, 23 Apr 2003 08:19:24 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 08:19:24 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: "new" issue / Event Notification Date: Wed, 23 Apr 2003 07:14:40 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4401753372@daebe007.americas.nokia.com> Thread-Topic: "new" issue / Event Notification Thread-Index: AcMI33NQR4nRdm8pSqWmNto0yiNN7QAAW2QwACw3V5A= From: To: , , X-OriginalArrivalTime: 23 Apr 2003 12:14:41.0508 (UTC) FILETIME=[EB0F9240:01C30991] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA15317 It helps if replacement text is suggested as well. However it is still useful to have the issue listed and discussed by WG members before arriving at any consensus on the text/conclusion. -Basavaraj > > I've created a new issue (Issue11) about this. In general I > think that text replacement should be provided. But, let's > see what chairs think about this issue system.. > - Dan > > > > > > > hi all, > > > > the following is about the discovery phase in the pana draft: > > > > PaC may also choose to start sending packets before getting > > authenticated. In that case, the network should detect this and > > send an unsolicited PANA_start message to PaC. EP is the > > node that > > can detect such activity. If EP and PAA are co-located, then an > > internal mechanism (e.g. API) between the EP module and the PAA > > module on the same host can prompt PAA to start PANA. In > > case they > > are separate, there needs to [be] an explicit message to prompt > > PAA. > > > > > > 1/ on the one hand, the current version of the pana > protocol quickly > > states [discovery section] that, in case of 'traffic-driven' > > authentication, the EP must send a PANA_start message to the PAA: > > > > Upon detecting the need to authenticate a client, EP can send a > > PAC_discovery message to the PAA on behalf of the PaC. This > > message carries a device identifier of the PaC in a > Device-Id AVP. > > > > 2/ on the other hand, the requirements draft [EP-PAA protocol > > section] > > states that the PAA-EP protocol should support > > event-notification also: > > > > Depending on the PANA protocol design, support for either > > of the push > > model (i.e., EP initiating the PAA-EP protocol exchange > > per PaC) or > > the pull model (i.e., PAA initiating the PAA-EP protocol > > exchange per > > PaC), or both might be required. > > > > > > --> the working group should fix this (not listed on the web > > site) issue > > also (the PANA protocol OR the PAA-EP protocol supports the > > EP-triggering) > > > > my personal feeling on this is that the PANA protocol should be > > restricted to PaC-PAA communication and the PAA-EP protocol > > (whichever > > you finaly choose) should take it as a requirement. > > > > thanks, > > yacine > > > > > > > > From pana-request@research.telcordia.com Wed Apr 23 08:51:22 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16420 for ; Wed, 23 Apr 2003 08:51:22 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3NCpZ0U010855; Wed, 23 Apr 2003 08:51:35 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 08:51:35 -0400 (EDT) Old-Return-Path: Message-ID: <3EA68C08.30007@alcatel.fr> Date: Wed, 23 Apr 2003 14:50:16 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Cc: Dan.Forsberg@nokia.com, pana@research.telcordia.com Subject: Re: "new" issue / Event Notification References: <697DAA22C5004B4596E033803A7CEF4401753372@daebe007.americas.nokia.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/23/2003 14:50:16, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/23/2003 14:50:18, Serialize complete at 04/23/2003 14:50:18 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by amavisd-new Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi Basavaraj, Basavaraj.Patil@nokia.com wrote: > It helps if replacement text is suggested as well. Bellow is the current text in the current version of the pana protocol draft: Upon detecting the need to authenticate a client, EP can send a PAC_discovery message to the PAA on behalf of the PaC. This message carries a device identifier of the PaC in a Device-Id AVP. If there is a consensus for using PAA-EP protocol here, one can replace the lattest paragraph in the pana draft by a similar one stating that the PAA-EP protocol will deal with this explicit message: "Upon detecting the need to authenticate a client, EP can prompt the PAA using the PAA-EP protocol. This message should carry a device identifier of the PaC." Moreover, the PAA-EP protocol requirements in the requirements draft should state clearly that the PAA-EP protocol must support 'event-notification' (it's the case of most of the candidates, namely SNMP, COPS, etc.). > However it is > still useful to have the issue listed and discussed by WG members > before arriving at any consensus on the text/conclusion. > > -Basavaraj > thanks, yacine > >>I've created a new issue (Issue11) about this. In general I >>think that text replacement should be provided. But, let's >>see what chairs think about this issue system.. >>- Dan >> >> >>> >>>hi all, >>> >>>the following is about the discovery phase in the pana draft: >>> >>> PaC may also choose to start sending packets before getting >>> authenticated. In that case, the network should detect this and >>> send an unsolicited PANA_start message to PaC. EP is the >>>node that >>> can detect such activity. If EP and PAA are co-located, then an >>> internal mechanism (e.g. API) between the EP module and the PAA >>> module on the same host can prompt PAA to start PANA. In >>>case they >>> are separate, there needs to [be] an explicit message to prompt >>> PAA. >>> >>> >>>1/ on the one hand, the current version of the pana >>> >>protocol quickly >> >>>states [discovery section] that, in case of 'traffic-driven' >>>authentication, the EP must send a PANA_start message to the PAA: >>> >>> Upon detecting the need to authenticate a client, EP can send a >>> PAC_discovery message to the PAA on behalf of the PaC. This >>> message carries a device identifier of the PaC in a >>> >>Device-Id AVP. >> >>>2/ on the other hand, the requirements draft [EP-PAA protocol >>>section] >>>states that the PAA-EP protocol should support >>>event-notification also: >>> >>> Depending on the PANA protocol design, support for either >>>of the push >>> model (i.e., EP initiating the PAA-EP protocol exchange >>>per PaC) or >>> the pull model (i.e., PAA initiating the PAA-EP protocol >>>exchange per >>> PaC), or both might be required. >>> >>> >>>--> the working group should fix this (not listed on the web >>>site) issue >>>also (the PANA protocol OR the PAA-EP protocol supports the >>>EP-triggering) >>> >>>my personal feeling on this is that the PANA protocol should be >>>restricted to PaC-PAA communication and the PAA-EP protocol >>>(whichever >>>you finaly choose) should take it as a requirement. >>> >>>thanks, >>>yacine >>> >>> >>> >>> >> > > From pana-request@research.telcordia.com Wed Apr 23 14:03:32 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28319 for ; Wed, 23 Apr 2003 14:03:32 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3NI2gSC004866; Wed, 23 Apr 2003 14:02:42 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 14:02:42 -0400 (EDT) Old-Return-Path: Date: Wed, 23 Apr 2003 20:02:10 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Issues Tracker for PANA WG drafts To: Reinaldo Penno Cc: Alper Yegin , Basavaraj.Patil@nokia.com, pana@research.telcordia.com In-Reply-To: "Your message with ID" <20030421190350.11129.qmail@web40003.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com > Anyway, these where only 2 examples, you can have > thousands of other parameters. As I said it boils down > to the fact if we think it is useful/powerful or not. > I still think it provides for flexibility, will > certainly have uses in the field and the changes in > the protocol are manageable. Reinaldo, While I'm not up to spead on the details of this discussion it seems like you are applying a different criteria than I had in mind. Useful, powerful, flexible is not good guiding principles to come up with a protocol which fits the intended purpose - they look a lot more likely to result in kitchen sink protocols to me. Criteria like "necessary" in to solve what the WG has set out to solve (while also thinking carefully which things need to be well-specified in order to allow limited future extensibility) is a lot likely to result in a succesful WG and a succesful protocol. Erik From pana-request@research.telcordia.com Wed Apr 23 14:08:12 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28479 for ; Wed, 23 Apr 2003 14:08:11 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3NI8W4b005385; Wed, 23 Apr 2003 14:08:32 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 14:08:32 -0400 (EDT) Old-Return-Path: Date: Wed, 23 Apr 2003 11:08:43 -0700 Subject: Re: "new" issue / Event Notification From: Alper Yegin To: CC: Message-ID: In-Reply-To: <3EA66178.1030504@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >> I couldn't see an inconsistency here. >> >> The requirements draft says the PAA-EP protocol should support either push >> model, or pull model, or both depending on the PANA protocol design. >> And the current PANA protocol design lets EP notify the PAA about >> unauthenticated PaCs. Hence the only requirement on the PAA-EP protocol is >> the support for the "pull model" (as defined below). >> >> Does this make sense? > > > yes, this is the current view. did the PANA WG reached a consensus on > this subject ? I'm curious about the technical motivations of the design > team for such a choice in the PANA protocol design. Just like any other part of the draft, this is also subject to the WG discussions. There was no discussion on this after the publication of the version 00, so it is hard to say whether the WG has reached a consensus or not. I can only speak for myself, as I don't remember detailed discussion on this matter during its design. We could expect the PAA-EP protocol to provide this notification, but I don't see why not do it in PANA, and have less requirements on the PAA-EP protocol. > NB: terminology question for the req-draft authors: > > the PUSH model is defined as follows: > - "EP initiating the PAA-EP protocol exchange per PaC" > and the PULL model corresponds to: > - "PAA initiating the PAA-EP protocol exchange per PaC" > > > is that really what you meant ? isn't it the contrary ? > > usually, the 'PULL model' better corresponds to bottom-up (EP->PAA) > initiated communication. Yes, I caught that too, and this is fixed in the latest version: http://www.ietf.org/internet-drafts/draft-ietf-pana-requirements-05.txt Alper > > > > >> >> >> >> >>> hi all, >>> >>> the following is about the discovery phase in the pana draft: >>> >>> PaC may also choose to start sending packets before getting >>> authenticated. In that case, the network should detect this and >>> send an unsolicited PANA_start message to PaC. EP is the node that >>> can detect such activity. If EP and PAA are co-located, then an >>> internal mechanism (e.g. API) between the EP module and the PAA >>> module on the same host can prompt PAA to start PANA. In case they >>> are separate, there needs to [be] an explicit message to prompt >>> PAA. >>> >>> >>> 1/ on the one hand, the current version of the pana protocol quickly >>> states [discovery section] that, in case of 'traffic-driven' >>> authentication, the EP must send a PANA_start message to the PAA: >>> >>> Upon detecting the need to authenticate a client, EP can send a >>> PAC_discovery message to the PAA on behalf of the PaC. This >>> message carries a device identifier of the PaC in a Device-Id AVP. >>> >>> 2/ on the other hand, the requirements draft [EP-PAA protocol section] >>> states that the PAA-EP protocol should support event-notification also: >>> >>> Depending on the PANA protocol design, support for either of the push >>> model (i.e., EP initiating the PAA-EP protocol exchange per PaC) or >>> the pull model (i.e., PAA initiating the PAA-EP protocol exchange per >>> PaC), or both might be required. >>> >>> >>> --> the working group should fix this (not listed on the web site) issue >>> also (the PANA protocol OR the PAA-EP protocol supports the EP-triggering) >>> >>> my personal feeling on this is that the PANA protocol should be >>> restricted to PaC-PAA communication and the PAA-EP protocol (whichever >>> you finaly choose) should take it as a requirement. >>> >>> thanks, >>> yacine >>> >>> >>> >>> >> >> > > > From pana-request@research.telcordia.com Wed Apr 23 14:15:49 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28746 for ; Wed, 23 Apr 2003 14:15:49 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3NIG3HK005916; Wed, 23 Apr 2003 14:16:03 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 14:16:03 -0400 (EDT) Old-Return-Path: Date: Wed, 23 Apr 2003 11:16:18 -0700 Subject: Re: Proposal for message formatting (sec. 9). From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: <0d3F6B.A.TcB.ihtp-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Dan, Without discussing those specific scenarios you outlined below, I cannot see if we really need this field. Rather than saying we might need something like this for A, B, and C, lets do it other way around: Analize A, B, and C and see what exactly we need to do in the PANA protocol design. It might turn out that a flag, or a new AVP is sufficient. Or, we really need that field. Alper > Alper, > > "application ID" could refer to a separate document that uses PANA as its > transport. PANA provides authentication for network access by carrying EAP, > which itself can be seen as an application. Other applications could be > related to DHCP and SEND, or even IKE? > > For example the Diameter draft specifies five different app ids, that are > advertised through capability exchange messages (CER/CEA): > > Diameter Common Messages 0 > NASREQ 1 [NASREQ] > Mobile-IP 2 [DIAMMIP] > Diameter Base Accounting 3 > Relay 0xffffffff > > Issue1 "Capability Negotiation" could benefit from application ids too. > > - Dan > >> -----Original Message----- >> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] >> Sent: 17 April, 2003 02:43 >> To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com >> Subject: Re: Proposal for message formatting (sec. 9). >> >> >> >> Dan, >> >> Not having that Diameter-specific field in the PANA header >> does not mean >> that PANA will be incompatible with Diameter. I'm afraid the level of >> compatibility you are aiming is "source code compatibility". >> >> I'm not concerned about the header size, but I'm concerned about >> incorporating headers into PANA that currently does not mean >> anything to >> PANA. Is there an explanation of what "application ID" means to PANA? >> Do we have this field in other applications of Diameter, such >> as in the >> Mobile IPv4 header, or PPP or 802.1x headers? >> >> Alper >> >> >> >> >>> Alper, >>> >>> Diameter compatibility is not a requirement, but a >> possibility :). I don't see >>> it causing udesirable side effects. App-Id is not causing >> problems, but making >>> the header a bit bigger. It can help PANA to become more >> popular/useful and to >>> cope with possible future extensions/capabilities (list of >> app-ids supported). >>> Do you see any drawbacks in this, or issues why we should >> not be compatible >>> with Diameter? >>> >>> We should ask other's opinions too. >>> >>> - Dan >>> >>>> -----Original Message----- >>>> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] >>>> Sent: 16 April, 2003 03:15 >>>> To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com >>>> Subject: Re: Proposal for message formatting (sec. 9). >>>> >>>> >>>> Hi Dan, >>>> >>>> It seems like you are treating Diameter compatibility as if it is a >>>> requirement. It might be a desirable feature at best. Sure it >>>> helps with >>>> some code reuse or implimentation shortcuts, but these are >>>> not necessary >>>> for the protocol design, and should not cause undesirable >>>> side effects. >>>> PANA is not really meant to be an appendix to Diameter. >>>> Diameter is one of >>>> the possible backend AAA protocols only. >>>> >>>> For example, addition of the "application id" field is not >>>> justifiable for >>>> PANA imo. I didn't quite understand the future application >>>> support. For >>>> future extensions a reserved field might be more than >>>> sufficient. Actually >>>> AVPs might be good enough too. >>>> >>>> 64-bit alignment is a nice feature too. I'm not sure which >>>> one is better >>>> though: Diameter harmonization or this. >>>> >>>> Alper >>>> >>>> >>>>> Alper, >>>>> >>>>> Thank you for your comments. >>>>> >>>>>> -----Original Message----- >>>>>> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] >>>>>> Sent: 14 April, 2003 23:54 >>>>>> To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com >>>>>> Subject: Re: Proposal for message formatting (sec. 9). >>>>>> >>>>>> >>>>>> >>>>>> Hi Dan, >>>>>> >>>>>> Thank you for putting together the Message Format section. >>>>>> >>>>>> Here are some comments on the current design: >>>>>> >>>>>> - I see the message formats includes some protocol features >>>>>> we have not >>>>>> fully discussed yet. For example: session-id, add-device-id, >>>>>> remove-device-id. I recommend we separately discuss them >>>>>> first, and than >>>>>> incorporate into the message formats if necessary. >>>>> >>>>> Sure. >>>>> >>>>>> - I understand the desire to re-use DIAMETER code, but let's >>>>>> not overdo it. >>>>>> From "PANA design perspective", I don't see why we should >>>>>> have "Application >>>>>> ID" field in the header. >>>>> >>>>> To make the header structure similar to Diameter. If we >>>> break it, then it >>>>> doesn't matter what kind of format we use, because >>>> implementations must be >>>>> different then. >>>>> >>>>> We have a prototype that uses Diameter message formatting >>>> (testing SeNAA) on >>>>> top of UDP. This is a very nice feature, because the >>>> Diameter stack callbacks >>>>> can be used with PANA messages too. The interaction with >>>> the AAA backend >>>>> becomes very smooth. This means of course that Diameter and >>>> PANA id values >>>>> don't overlap. >>>>> >>>>> With Diameter PANA could have Application-Id 4 and the new >>>> AVPs could be >>>>> registered from the Diameter number space (or then we could >>>> use Vendor-Id for >>>>> PANA). I talked with John Loughney (one of the authors of >>>> Diameter base spec) >>>>> about this and he didn't see any problems with this approach. >>>>> >>>>> PANA could support different applications in the future >>>> too. A preshared SA >>>>> between PaC and PAA and extensible message types sounds >>>> compelling. And if the >>>>> protocol works smoothly with AAA backends (one doesn't have >>>> to specify >>>>> different AVPs with Diameter and PANA) the scenario looks >>>> interesting. >>>>> >>>>>> - Device ID can also include various link-layer address >>>>>> types. Let's reflect >>>>>> that onto the design (currently only IP addresses are included). >>>>> >>>>> Sure. >>>>> >>>>>> - How about alignment requirements? I'd say we should >>>> require 8-octet >>>>>> alignment for AVPs. >>>>> >>>>> If that doesn't break the Diameter compatibility. >>>>> >>>>>> >>>>>> Alper >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Attached you can find a proposal section (9 Message Formats) >>>>>>> for the draft-ietf-pana-pana-00.txt. It contains some changes >>>>>>> that affect the whole draft. >>>>>>> >>>>>>> There are no error messages defined, which I think should be >>>>>>> fixed. This is not only a message format issue, but a protocol >>>>>>> issue. >>>>>>> >>>>>>> Changes to the pana draft in general: >>>>>>> >>>>>>> - Message naming convention changed (*_ack --> *-Answer, >>>>>>> * --> *-Request) to better reflect the Diameter style >>>>>>> and the nature of the protocol: answers contain data, >>>>>>> but for acks it is not so clear. Requests and answers >>>>>>> describe better the protocol. >>>>>>> >>>>>>> - Thus, 2 messages instead of 1: >>>>>>> - PANA-Auth-Request & PANA-Auth-Answer. >>>>>>> PAA always sends PANA-Auth-Request and requires an >>>>>>> answer to it. >>>>>>> - PANA-Start-Request & PANA-Start-Answer. >>>>>>> PANA-Start messages are different depending on the sender. >>>>>>> - PANA-Success-Request/Answer: PANA requires answer to success, >>>>>>> because he PANA SA is not otherwise established properly. >>>>>>> And for sake of simplicity, the same naming convention >>>>>>> should be used. >>>>>>> >>>>>>> - Flag change: A flag to R flag to better reflect >> Diameter style. >>>>>>> Requests have the R flag set, answers unset. >>>>>>> >>>>>>> - Name change: Data-Protection --> Protection-Capability. >>>>>>> Data-Protection is misleading term. >>>>>>> >>>>>>> - Name change: Revocation-Status --> Termination-Cause >> (Diameter). >>>>>>> There is already an AVP that suits for this purpose. >>>>>>> >>>>>>> - PANA-Disconnect-Request now contains Termination-Cause AVP. >>>>>>> There are different reasons for the user to disconnect. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Comments welcome, >>>>>>> - Dan >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > > From pana-request@research.telcordia.com Wed Apr 23 14:45:03 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00090 for ; Wed, 23 Apr 2003 14:45:02 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3NIjIaA008773; Wed, 23 Apr 2003 14:45:18 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 14:45:18 -0400 (EDT) Old-Return-Path: Date: Wed, 23 Apr 2003 11:45:29 -0700 Subject: IETF 56 notes and slides From: Alper Yegin To: pana Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Folks, IETF 56 presentation slides and meeting notes can be found at: http://www.toshiba.com/tari/pana/ietf56-pana.html Alper From pana-request@research.telcordia.com Wed Apr 23 15:12:07 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01982 for ; Wed, 23 Apr 2003 15:11:59 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3NJC3UP010767; Wed, 23 Apr 2003 15:12:03 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 15:12:03 -0400 (EDT) Old-Return-Path: Date: Wed, 23 Apr 2003 12:12:17 -0700 Subject: Choice of ciphering (was Re: question: pana messaging) From: Alper Yegin To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit The current pana protocol design is quite rigid with respect to enabling data protection after pana: The network mandates use of either L2 or L3 ciphering, or none. But never both. Client has to accept the choice of the network. That's it. Now we are thinking if we can flex this a bit, that's fine. I think what we are looking at is the ability to provide some optional ciphering, or multi-layer protection. Such as: - The network can indicate which ciphering it mandates, and which it can optionally provide. For example, at the end of a successful PANA, PAA can indicate whether L2 ciphering is optionally provided or mandated, and similarly for L3 ciphering. PaC has to use the mandatory one(s), and it can indicate its optional choices. Here are the combinations... Network provides: a- neither L2 nor L3 ciphering. b- no L2, but optional L3 ciphering. c- no L2, but mandatory L3 ciphering. d- optional L2 ciphering, no L3 ciphering. e- optional L2 ciphering and optional L3 ciphering. f- optional L2 ciphering and mandatory L3 ciphering. g- mandatory L2 ciphering, no L3 ciphering. h- mandatory L2 ciphering and optional L3 ciphering. i- mandatory L2 ciphering and mandatory L3 ciphering. Does it make sense to have these scenarios? When PAA indicates one of the above configurations, PaC will have to agree with the mandatory ones, not request the unsupported ones, and decide on the optional ones. So that, at the end of the PANA, the network knows which ones need to be enabled. Of course the order of execution matters. Could this be what we are talking about here? Alper From pana-request@research.telcordia.com Wed Apr 23 18:07:05 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10339 for ; Wed, 23 Apr 2003 18:07:04 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3NM6R0G025815; Wed, 23 Apr 2003 18:06:27 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 18:06:27 -0400 (EDT) Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Choice of ciphering (was Re: question: pana messaging) Date: Wed, 23 Apr 2003 15:05:53 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A439@TNEXVS02.tahoenetworks.com> Thread-Topic: Choice of ciphering (was Re: question: pana messaging) Thread-Index: AcMJ0rkKA7h1fP6uTy2NKxhCRgChawAER/dA From: "Mohan Parthasarathy" To: "Alper Yegin" , X-OriginalArrivalTime: 23 Apr 2003 22:05:54.0191 (UTC) FILETIME=[826D71F0:01C309E4] Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA10339 Alper, > > The current pana protocol design is quite rigid with respect > to enabling > data protection after pana: The network mandates use of > either L2 or L3 > ciphering, or none. But never both. Client has to accept the > choice of the > network. That's it. > > Now we are thinking if we can flex this a bit, that's fine. > > I think what we are looking at is the ability to provide some optional > ciphering, or multi-layer protection. Such as: > > - The network can indicate which ciphering it mandates, and > which it can > optionally provide. > > For example, at the end of a successful PANA, PAA can indicate whether > L2 ciphering is optionally provided or mandated, and similarly for L3 > ciphering. PaC has to use the mandatory one(s), and it can > indicate its > optional choices. > > Here are the combinations... Network provides: > a- neither L2 nor L3 ciphering. > b- no L2, but optional L3 ciphering. > c- no L2, but mandatory L3 ciphering. > d- optional L2 ciphering, no L3 ciphering. > e- optional L2 ciphering and optional L3 ciphering. > f- optional L2 ciphering and mandatory L3 ciphering. > g- mandatory L2 ciphering, no L3 ciphering. > h- mandatory L2 ciphering and optional L3 ciphering. > i- mandatory L2 ciphering and mandatory L3 ciphering. > > Does it make sense to have these scenarios? I think we should try to keep it simple. Why would someone want both L2 and L3 ciphering ? Is it because L2 is weak ? Then, why don't you just use L3 ciphering alone. How does the PAA decide which one of the above to use ? It is very complex. All you need is whether the network can support L2 and/or L3 and client chooses one of them. Why isn't this sufficient ? > > When PAA indicates one of the above configurations, PaC will > have to agree > with the mandatory ones, not request the unsupported ones, > and decide on the > optional ones. So that, at the end of the PANA, the network > knows which ones > need to be enabled. Of course the order of execution matters. > > Could this be what we are talking about here? > > Alper > -mohan > From pana-request@research.telcordia.com Wed Apr 23 19:05:46 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13586 for ; Wed, 23 Apr 2003 19:05:46 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3NN5rT9029668; Wed, 23 Apr 2003 19:05:53 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 19:05:53 -0400 (EDT) Old-Return-Path: Date: Tue, 22 Apr 2003 23:21:03 -0700 To: Mohan Parthasarathy Cc: Alper Yegin , pana@research.telcordia.com Subject: Re: Choice of ciphering (was Re: question: pana messaging) Message-ID: <20030423062103.GC1105@steelhead> Mail-Followup-To: Mohan Parthasarathy , Alper Yegin , pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A439@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A439@TNEXVS02.tahoenetworks.com> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 81 Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Mohan, Please see my comment below. On Wed, Apr 23, 2003 at 03:05:53PM -0700, Mohan Parthasarathy wrote: > > Alper, > > > > > The current pana protocol design is quite rigid with respect > > to enabling > > data protection after pana: The network mandates use of > > either L2 or L3 > > ciphering, or none. But never both. Client has to accept the > > choice of the > > network. That's it. > > > > Now we are thinking if we can flex this a bit, that's fine. > > > > I think what we are looking at is the ability to provide some optional > > ciphering, or multi-layer protection. Such as: > > > > - The network can indicate which ciphering it mandates, and > > which it can > > optionally provide. > > > > For example, at the end of a successful PANA, PAA can indicate whether > > L2 ciphering is optionally provided or mandated, and similarly for L3 > > ciphering. PaC has to use the mandatory one(s), and it can > > indicate its > > optional choices. > > > > Here are the combinations... Network provides: > > a- neither L2 nor L3 ciphering. > > b- no L2, but optional L3 ciphering. > > c- no L2, but mandatory L3 ciphering. > > d- optional L2 ciphering, no L3 ciphering. > > e- optional L2 ciphering and optional L3 ciphering. > > f- optional L2 ciphering and mandatory L3 ciphering. > > g- mandatory L2 ciphering, no L3 ciphering. > > h- mandatory L2 ciphering and optional L3 ciphering. > > i- mandatory L2 ciphering and mandatory L3 ciphering. > > > > Does it make sense to have these scenarios? > > I think we should try to keep it simple. Why would someone want both > L2 and L3 ciphering ? Is it because L2 is weak ? Then, why don't you > just use L3 ciphering alone. How does the PAA decide which one of the > above to use ? It is very complex. All you need is whether the network can > support L2 and/or L3 and client chooses one of them. Why isn't this sufficient ? L3 ciphering does not protect MAC address spoofing, so a DoS attack such as ARP spoofing is still possible in the case of IPv4. On the other hand, L2 ciphering does not protect IP address spoofing. So I think using both L2 and L3 ciphering (at least per-packet integrity check) at the same time makes sense for the network where a higher-level of security is required. But I agree that doing per-packet encryption at both layers might not make sense and thus either L2 encryption or L3 encryption might be enough. Yoshihiro Ohba > > > > When PAA indicates one of the above configurations, PaC will > > have to agree > > with the mandatory ones, not request the unsupported ones, > > and decide on the > > optional ones. So that, at the end of the PANA, the network > > knows which ones > > need to be enabled. Of course the order of execution matters. > > > > Could this be what we are talking about here? > > > > Alper > > > -mohan > > > > > From pana-request@research.telcordia.com Wed Apr 23 19:23:08 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13951 for ; Wed, 23 Apr 2003 19:23:07 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3NNNW1i001104; Wed, 23 Apr 2003 19:23:32 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 19:23:32 -0400 (EDT) Old-Return-Path: Date: Tue, 22 Apr 2003 23:38:45 -0700 To: Yacine.El_Mghazli@alcatel.fr Cc: Basavaraj.Patil@nokia.com, Dan.Forsberg@nokia.com, pana@research.telcordia.com Subject: Re: "new" issue / Event Notification Message-ID: <20030423063844.GD1105@steelhead> Mail-Followup-To: Yacine.El_Mghazli@alcatel.fr, Basavaraj.Patil@nokia.com, Dan.Forsberg@nokia.com, pana@research.telcordia.com References: <697DAA22C5004B4596E033803A7CEF4401753372@daebe007.americas.nokia.com> <3EA68C08.30007@alcatel.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <3EA68C08.30007@alcatel.fr> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 130 Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Yacine, On Wed, Apr 23, 2003 at 02:50:16PM +0200, Yacine.El_Mghazli@alcatel.fr wrote: > hi Basavaraj, > > Basavaraj.Patil@nokia.com wrote: > > >It helps if replacement text is suggested as well. > > > Bellow is the current text in the current version of the pana protocol > draft: > > Upon detecting the need to authenticate a client, EP can send a > PAC_discovery message to the PAA on behalf of the PaC. This > message carries a device identifier of the PaC in a Device-Id AVP. > > If there is a consensus for using PAA-EP protocol here, one can replace > the lattest paragraph in the pana draft by a similar one stating that > the PAA-EP protocol will deal with this explicit message: > > "Upon detecting the need to authenticate a client, EP can prompt the PAA > using the PAA-EP protocol. This message should carry a device identifier > of the PaC." I tend to agree on the proposed text, which makes the PAA-EP protocol more independent of the PaC-PAA protocol. I admit that the current design requires EPs to manufacture a specific PANA message PDU (i.e., PAA_discovery) in its payload while it does not speak PANA. Specifying the required functionality instead of specifying both functionality and message format might be sufficient for the EP-PAA protocol to satisfy the PANA requirement. Of course the actual design of the EP-PAA protocol may choose to carry PANA_discovery message based on their design criteria. Yoshihiro Ohba > > Moreover, the PAA-EP protocol requirements in the requirements draft > should state clearly that the PAA-EP protocol must support > 'event-notification' (it's the case of most of the candidates, namely > SNMP, COPS, etc.). > > >However it is > >still useful to have the issue listed and discussed by WG members > >before arriving at any consensus on the text/conclusion. > > > > >-Basavaraj > > > > > thanks, > yacine > > > > > >>I've created a new issue (Issue11) about this. In general I > >>think that text replacement should be provided. But, let's > >>see what chairs think about this issue system.. > >>- Dan > >> > >> > >>> > >>>hi all, > >>> > >>>the following is about the discovery phase in the pana draft: > >>> > >>> PaC may also choose to start sending packets before getting > >>> authenticated. In that case, the network should detect this and > >>> send an unsolicited PANA_start message to PaC. EP is the > >>>node that > >>> can detect such activity. If EP and PAA are co-located, then an > >>> internal mechanism (e.g. API) between the EP module and the PAA > >>> module on the same host can prompt PAA to start PANA. In > >>>case they > >>> are separate, there needs to [be] an explicit message to prompt > >>> PAA. > >>> > >>> > >>>1/ on the one hand, the current version of the pana > >>> > >>protocol quickly > >> > >>>states [discovery section] that, in case of 'traffic-driven' > >>>authentication, the EP must send a PANA_start message to the PAA: > >>> > >>> Upon detecting the need to authenticate a client, EP can send a > >>> PAC_discovery message to the PAA on behalf of the PaC. This > >>> message carries a device identifier of the PaC in a > >>> > >>Device-Id AVP. > >> > >>>2/ on the other hand, the requirements draft [EP-PAA protocol > >>>section] > >>>states that the PAA-EP protocol should support > >>>event-notification also: > >>> > >>> Depending on the PANA protocol design, support for either > >>>of the push > >>> model (i.e., EP initiating the PAA-EP protocol exchange > >>>per PaC) or > >>> the pull model (i.e., PAA initiating the PAA-EP protocol > >>>exchange per > >>> PaC), or both might be required. > >>> > >>> > >>>--> the working group should fix this (not listed on the web > >>>site) issue > >>>also (the PANA protocol OR the PAA-EP protocol supports the > >>>EP-triggering) > >>> > >>>my personal feeling on this is that the PANA protocol should be > >>>restricted to PaC-PAA communication and the PAA-EP protocol > >>>(whichever > >>>you finaly choose) should take it as a requirement. > >>> > >>>thanks, > >>>yacine > >>> > >>> > >>> > >>> > >> > > > > > > > From pana-request@research.telcordia.com Wed Apr 23 21:22:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17104 for ; Wed, 23 Apr 2003 21:22:51 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.8/8.12.1) id h3O1LZa8008864; Wed, 23 Apr 2003 21:21:35 -0400 (EDT) Resent-Date: Wed, 23 Apr 2003 21:21:35 -0400 (EDT) Old-Return-Path: Date: Wed, 23 Apr 2003 18:21:58 -0700 Subject: Please review From: Alper Yegin To: Message-ID: In-Reply-To: <200304231054.GAA10991@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Folks, Please see the version 05 of the requirements draft. We are planning to take this to working group last call soon. But please don't wait till than, and provide your comments as soon as possible. Based on the comments we'll update the draft one more time so that we'll have a smooth WG LC. Providing text in addition to pointing out issues is *highly* encouraged. Thanks. - Chairs > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Protocol for carrying Authentication for > Network Access Working Group of the IETF. > > Title : Protocol for Carrying Authentication for Network > Access (PANA)Requirements and Terminology > Author(s) : A. Yegin, Y. Ohba, R. Penno et al. > Filename : draft-ietf-pana-requirements-05.txt > Pages : 16 > Date : 2003-4-22 > > It is expected that future IP devices will have a variety of access > technologies to gain network connectivity. Currently there are > access-specific mechanisms for providing client information to the > network for authentication and authorization purposes. In addition > to being limited to specific access media (e.g., 802.1x for IEEE 802 > links), some of these protocols are limited to specific network > topologies (e.g., PPP for point-to-point links). The goal of the > PANA is to provide a layer two agnostic and IPv4/IPv6 compatible > client-server protocol that allows a host to be authenticated for > network access. The protocol will run between a client's device > and an agent device in the network where the agent might be a client > of the AAA infrastructure. This document defines the common > terminology and identifies the requirements for PANA. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pana-requirements-05.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-pana-requirements-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pana-requirements-05.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From pana-request@research.telcordia.com Fri Apr 25 13:23:51 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15746 for ; Fri, 25 Apr 2003 13:23:50 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h3PHMwnf005141; Fri, 25 Apr 2003 13:22:58 -0400 (EDT) Resent-Date: Fri, 25 Apr 2003 13:22:58 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Choice of ciphering (was Re: question: pana messaging) Date: Fri, 25 Apr 2003 10:22:37 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C136A@TNEXVS02.tahoenetworks.com> Thread-Topic: Choice of ciphering (was Re: question: pana messaging) Thread-Index: AcMJ7PWh4bZQRU/SRNi2u68QS76hCwBYgLjA From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Alper Yegin" , X-OriginalArrivalTime: 25 Apr 2003 17:22:38.0376 (UTC) FILETIME=[44F56280:01C30B4F] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA15746 > > Please see my comment below. > > On Wed, Apr 23, 2003 at 03:05:53PM -0700, Mohan Parthasarathy wrote: > > > > Alper, > > > > > > > > The current pana protocol design is quite rigid with respect > > > to enabling > > > data protection after pana: The network mandates use of > > > either L2 or L3 > > > ciphering, or none. But never both. Client has to accept the > > > choice of the > > > network. That's it. > > > > > > Now we are thinking if we can flex this a bit, that's fine. > > > > > > I think what we are looking at is the ability to provide some > > > optional ciphering, or multi-layer protection. Such as: > > > > > > - The network can indicate which ciphering it mandates, and > > > which it can > > > optionally provide. > > > > > > For example, at the end of a successful PANA, PAA can indicate > > > whether L2 ciphering is optionally provided or mandated, and > > > similarly for L3 ciphering. PaC has to use the mandatory > one(s), and > > > it can indicate its optional choices. > > > > > > Here are the combinations... Network provides: > > > a- neither L2 nor L3 ciphering. > > > b- no L2, but optional L3 ciphering. > > > c- no L2, but mandatory L3 ciphering. > > > d- optional L2 ciphering, no L3 ciphering. > > > e- optional L2 ciphering and optional L3 ciphering. > > > f- optional L2 ciphering and mandatory L3 ciphering. > > > g- mandatory L2 ciphering, no L3 ciphering. > > > h- mandatory L2 ciphering and optional L3 ciphering. > > > i- mandatory L2 ciphering and mandatory L3 ciphering. > > > > > > Does it make sense to have these scenarios? > > > > I think we should try to keep it simple. Why would someone > want both > > L2 and L3 ciphering ? Is it because L2 is weak ? Then, why > don't you > > just use L3 ciphering alone. How does the PAA decide which > one of the > > above to use ? It is very complex. All you need is whether > the network > > can support L2 and/or L3 and client chooses one of them. Why isn't > > this sufficient ? > > L3 ciphering does not protect MAC address spoofing, so a DoS > attack such as ARP spoofing is still possible in the case of > IPv4. On the other hand, L2 ciphering does not protect IP > address spoofing. So I think using both L2 and L3 ciphering > (at least per-packet integrity L2 ciphering does not prevent ARP spoofing either. ARP looks at the inner payload and not the ethernet headers. You need something like SEND for ARP. Anyway, it is not in the scope of this WG I guess. > check) at the same time makes sense for the network where a > higher-level of security is required. But I agree that doing > per-packet encryption at both layers might not make sense and > thus either L2 encryption or L3 encryption might be enough. > The overhead also may be high when the client is using Ipsec for his VPN access and it has to do two layers within the access network. I have not yet enabled WEP on my Ipsec VPN access to see how bad it is. > Yoshihiro Ohba > > > > > > > > When PAA indicates one of the above configurations, PaC will > > > have to agree > > > with the mandatory ones, not request the unsupported ones, > > > and decide on the > > > optional ones. So that, at the end of the PANA, the network > > > knows which ones > > > need to be enabled. Of course the order of execution matters. > > > > > > Could this be what we are talking about here? > > > > > > Alper > > > > > -mohan > > > > > > > > > > From pana-request@research.telcordia.com Fri Apr 25 15:25:42 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19656 for ; Fri, 25 Apr 2003 15:25:38 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h3PJOdHV012718; Fri, 25 Apr 2003 15:24:39 -0400 (EDT) Resent-Date: Fri, 25 Apr 2003 15:24:39 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 24 Apr 2003 09:13:22 -0700 To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@research.telcordia.com Subject: Re: Choice of ciphering (was Re: question: pana messaging) Message-ID: <20030424161214.GC711@steelhead> Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E016C136A@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E016C136A@TNEXVS02.tahoenetworks.com> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 55 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Fri, Apr 25, 2003 at 10:22:37AM -0700, Mohan Parthasarathy wrote: > > L3 ciphering does not protect MAC address spoofing, so a DoS > > attack such as ARP spoofing is still possible in the case of > > IPv4. On the other hand, L2 ciphering does not protect IP > > address spoofing. So I think using both L2 and L3 ciphering > > (at least per-packet integrity > > L2 ciphering does not prevent ARP spoofing either. ARP looks > at the inner payload and not the ethernet headers. You need > something like SEND for ARP. Anyway, it is not in the scope of > this WG I guess. This is true. Additional filtering that validates ARP payload might be needed at EP (e.g., access point) for attacks from authenticated clients that use L2 ciphering. To do this, PAA would need to inform EP of both MAC address and IP address and I think providing such a hook to EP is in the scope of PANA (though filtering itself is out of the scope of PANA). However, even (L2 ciphering + filtering ARP at EP) does not prevent spoofed ARP packets directly (i.e., without passing through EPs) sent from authenticated and L2-ciphered attackers. This is basically due to the lack of cryptographic integrity protection in ARP but still better than null L2 ciphering in that unauthenticated attackers cannot launch ARP attacks. > > > check) at the same time makes sense for the network where a > > higher-level of security is required. But I agree that doing > > per-packet encryption at both layers might not make sense and > > thus either L2 encryption or L3 encryption might be enough. > > > The overhead also may be high when the client is using Ipsec for > his VPN access and it has to do two layers within the access network. > I have not yet enabled WEP on my Ipsec VPN access to see how bad > it is. It is possible to avoid double encryption with L3 ciphering in the access network and VPN, if a client that uses IPsec-based VPN can negotiate a separate IPsec SA with the EP on using NULL encryption algorithm for a particular destination IP address (i.e., VPN gateway's address in this case) in addition to an IPsec SA with the EP for protecting other traffic. Traffic selector negotiation in IKEv2 can be used for specifying which traffic belongs to which SA. It might be difficult to avoid double encryption with L2 ciphering and VPN, unless L2 ciphering provides integrity protection without encription or L2 ciphering is turned off with accepting some attacks below L3. Disabling VPN encryption is another possibility but no good since VPN traffic can be eavesdropped on the path between EP and VPN gateway. Yoshihiro Ohba From pana-request@research.telcordia.com Fri Apr 25 17:58:17 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24575 for ; Fri, 25 Apr 2003 17:58:02 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h3PLujMh021303; Fri, 25 Apr 2003 17:56:45 -0400 (EDT) Resent-Date: Fri, 25 Apr 2003 17:56:45 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Fri, 25 Apr 2003 14:57:15 -0700 Subject: Re: Choice of ciphering (was Re: question: pana messaging) From: Alper Yegin To: Mohan Parthasarathy , Message-ID: In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A439@TNEXVS02.tahoenetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >> Here are the combinations... Network provides: >> a- neither L2 nor L3 ciphering. >> b- no L2, but optional L3 ciphering. >> c- no L2, but mandatory L3 ciphering. >> d- optional L2 ciphering, no L3 ciphering. >> e- optional L2 ciphering and optional L3 ciphering. >> f- optional L2 ciphering and mandatory L3 ciphering. >> g- mandatory L2 ciphering, no L3 ciphering. >> h- mandatory L2 ciphering and optional L3 ciphering. >> i- mandatory L2 ciphering and mandatory L3 ciphering. >> >> Does it make sense to have these scenarios? > > I think we should try to keep it simple. Why would someone want both > L2 and L3 ciphering ? Is it because L2 is weak ? Then, why don't you > just use L3 ciphering alone. These are fair questions, which I don't have good answers. I'm just the messenger :) > How does the PAA decide which one of the > above to use? PAA's configuration indicates which one of these is applicable. Note: This config is per PAA, not per PaC. > It is very complex. I'm not sure if it is really that complex. At the end of PANA, both the PaC and PAA knows which ciphering needs to be turned on. Basically PAA indicated which one(s) are mandatory, and PaC additionally chose optional one(s). If L2 ciphers is included in this final list, it needs to be turned on. This is just like what would have happened if only L2 ciphers were used. If L3 ciphers is included, it'll be turned on next. This is independent of whether L2 ciphering is on or off. Am I missing something? > All you need is whether the network can > support L2 and/or L3 and client chooses one of them. Why isn't this sufficient > ? I think you meant to say "L2 or L3 but not both", right? Doing both L2 and L3 is what you are questioning earlier. Some clients doing L2 while some other doing L3 is complex. Alper >> >> When PAA indicates one of the above configurations, PaC will >> have to agree >> with the mandatory ones, not request the unsupported ones, >> and decide on the >> optional ones. So that, at the end of the PANA, the network >> knows which ones >> need to be enabled. Of course the order of execution matters. >> >> Could this be what we are talking about here? >> >> Alper >> > -mohan > >> > > > From pana-request@research.telcordia.com Fri Apr 25 19:12:13 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26689 for ; Fri, 25 Apr 2003 19:12:13 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h3PNCUVl023602; Fri, 25 Apr 2003 19:12:30 -0400 (EDT) Resent-Date: Fri, 25 Apr 2003 19:12:30 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Choice of ciphering (was Re: question: pana messaging) Date: Fri, 25 Apr 2003 16:11:50 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A43D@TNEXVS02.tahoenetworks.com> Thread-Topic: Choice of ciphering (was Re: question: pana messaging) Thread-Index: AcMLdZEPLaJqeVrHTHW4Kvvo5NPTbAACRHmg From: "Mohan Parthasarathy" To: "Alper Yegin" , X-OriginalArrivalTime: 25 Apr 2003 23:11:51.0077 (UTC) FILETIME=[0DBDD550:01C30B80] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <79H8WC.A.pwF.eDcq-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA26689 Alper, > > > >> Here are the combinations... Network provides: > >> a- neither L2 nor L3 ciphering. > >> b- no L2, but optional L3 ciphering. > >> c- no L2, but mandatory L3 ciphering. > >> d- optional L2 ciphering, no L3 ciphering. > >> e- optional L2 ciphering and optional L3 ciphering. > >> f- optional L2 ciphering and mandatory L3 ciphering. > >> g- mandatory L2 ciphering, no L3 ciphering. > >> h- mandatory L2 ciphering and optional L3 ciphering. > >> i- mandatory L2 ciphering and mandatory L3 ciphering. > >> > >> Does it make sense to have these scenarios? > > > > I think we should try to keep it simple. Why would someone > want both > > L2 and L3 ciphering ? Is it because L2 is weak ? Then, why > don't you > > just use L3 ciphering alone. > > These are fair questions, which I don't have good answers. > I'm just the messenger :) > > > How does the PAA decide which one of the > > above to use? > > PAA's configuration indicates which one of these is > applicable. Note: This config is per PAA, not per PaC. Ok. > > > It is very complex. > > I'm not sure if it is really that complex. At the end of > PANA, both the PaC and PAA knows which ciphering needs to be > turned on. Basically PAA indicated which one(s) are > mandatory, and PaC additionally chose optional one(s). If L2 > ciphers is included in this final list, it needs to be turned > on. This is just like what would have happened if only L2 > ciphers were used. If L3 ciphers is included, it'll be turned > on next. This is independent of whether L2 ciphering is on or > off. Am I missing something? > I think the optional part is ncreasing the number of combinations. For example, what is the use of "no L2, L3 optional". Why does the network want to keep something optional ? If you are concerned about service theft, enforce L2 or L3. > > > All you need is whether the network can > > support L2 and/or L3 and client chooses one of them. Why isn't this > > sufficient ? > > I think you meant to say "L2 or L3 but not both", right? > Doing both L2 and L3 is what you are questioning earlier. > Some clients doing L2 while some other doing L3 is complex. > Thinking more about it, perhaps there is not much use in preventing both. So, the network says 1) L2 AND L3 2) L2 or L3 3) L2 4) L3 Isn't this sufficient ? -mohan > Alper > > > >> > >> When PAA indicates one of the above configurations, PaC > will have to > >> agree with the mandatory ones, not request the unsupported ones, > >> and decide on the > >> optional ones. So that, at the end of the PANA, the network > >> knows which ones > >> need to be enabled. Of course the order of execution matters. > >> > >> Could this be what we are talking about here? > >> > >> Alper > >> > > -mohan > > > >> > > > > > > > > From pana-request@research.telcordia.com Fri Apr 25 19:57:20 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27902 for ; Fri, 25 Apr 2003 19:57:19 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h3PNvJXV024642; Fri, 25 Apr 2003 19:57:19 -0400 (EDT) Resent-Date: Fri, 25 Apr 2003 19:57:19 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Fri, 25 Apr 2003 16:57:26 -0700 Subject: Re: Choice of ciphering (was Re: question: pana messaging) From: Alper Yegin To: Mohan Parthasarathy , Message-ID: In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A43D@TNEXVS02.tahoenetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Mohan, >>> It is very complex. >> >> I'm not sure if it is really that complex. At the end of >> PANA, both the PaC and PAA knows which ciphering needs to be >> turned on. Basically PAA indicated which one(s) are >> mandatory, and PaC additionally chose optional one(s). If L2 >> ciphers is included in this final list, it needs to be turned >> on. This is just like what would have happened if only L2 >> ciphers were used. If L3 ciphers is included, it'll be turned >> on next. This is independent of whether L2 ciphering is on or >> off. Am I missing something? >> > I think the optional part is ncreasing the number > of combinations. For example, what is the use of "no L2, L3 optional". > Why does the network want to keep something optional ? > If you > are concerned about service theft, enforce L2 or L3. This question is more about the motivation of this flexibility, which I'll defer to someone else to respond...(because I said earlier that I didn't have a good answer) > >> >>> All you need is whether the network can >>> support L2 and/or L3 and client chooses one of them. Why isn't this >>> sufficient ? >> >> I think you meant to say "L2 or L3 but not both", right? >> Doing both L2 and L3 is what you are questioning earlier. >> Some clients doing L2 while some other doing L3 is complex. >> > Thinking more about it, perhaps there is not much use in > preventing both. So, the network says > > 1) L2 AND L3 > 2) L2 or L3 > 3) L2 > 4) L3 Let me rewrite it a bit: 1) L2 and L3 2) L2 3) L3 4) None This would be the network mandating what ciphering to use. Alternatively, the network could blend this with the optional ones (hence 9 possible combinations I listed earlier), but at the end the PaC would pick one and it'd boil down to executing one of these 4 combinations. So I don't see where the complexity is. Is it with some clients are using L2 ciphering while some others using L2+L3 ciphering (because L3 is optional)? I removed your original "2) L2 or L3" because I believe that one is really complex. If L2 ciphering is necessary and available in an access network, then it must be mandatory. I don't think an optional L3 ciphering can fully replace that. Also, if we allow some clients do L2 ciphering only, some others L3 ciphering only, I suspect all L2 and L3 enforcement points should be aware of each other, and aware of every client's choice. Otherwise, there might be some security holes. Alper > > Isn't this sufficient ? > > -mohan > >> Alper >> >> >>>> >>>> When PAA indicates one of the above configurations, PaC >> will have to >>>> agree with the mandatory ones, not request the unsupported ones, >>>> and decide on the >>>> optional ones. So that, at the end of the PANA, the network >>>> knows which ones >>>> need to be enabled. Of course the order of execution matters. >>>> >>>> Could this be what we are talking about here? >>>> >>>> Alper >>>> >>> -mohan >>> >>>> >>> >>> >>> >> >> > > From pana-request@research.telcordia.com Fri Apr 25 20:59:14 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28472 for ; Fri, 25 Apr 2003 20:59:04 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h3Q0wGRa026294; Fri, 25 Apr 2003 20:58:16 -0400 (EDT) Resent-Date: Fri, 25 Apr 2003 20:58:16 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 24 Apr 2003 14:47:05 -0700 To: Alper Yegin Cc: Mohan Parthasarathy , pana@research.telcordia.com Subject: Re: Choice of ciphering (was Re: question: pana messaging) Message-ID: <20030424214705.GG711@steelhead> Mail-Followup-To: Alper Yegin , Mohan Parthasarathy , pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A43D@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5I6of5zJg18YgZEa" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 171 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com --5I6of5zJg18YgZEa Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline On Fri, Apr 25, 2003 at 04:57:26PM -0700, Alper Yegin wrote: > Mohan, > > >>> It is very complex. > >> > >> I'm not sure if it is really that complex. At the end of > >> PANA, both the PaC and PAA knows which ciphering needs to be > >> turned on. Basically PAA indicated which one(s) are > >> mandatory, and PaC additionally chose optional one(s). If L2 > >> ciphers is included in this final list, it needs to be turned > >> on. This is just like what would have happened if only L2 > >> ciphers were used. If L3 ciphers is included, it'll be turned > >> on next. This is independent of whether L2 ciphering is on or > >> off. Am I missing something? > >> > > I think the optional part is ncreasing the number > > of combinations. For example, what is the use of "no L2, L3 optional". > > Why does the network want to keep something optional ? > > If you > > are concerned about service theft, enforce L2 or L3. My answer is in the attached email which I sent last week. But please see my further comments below. > > This question is more about the motivation of this flexibility, which I'll > defer to someone else to respond...(because I said earlier that I didn't > have a good answer) > > > > >> > >>> All you need is whether the network can > >>> support L2 and/or L3 and client chooses one of them. Why isn't this > >>> sufficient ? > >> > >> I think you meant to say "L2 or L3 but not both", right? > >> Doing both L2 and L3 is what you are questioning earlier. > >> Some clients doing L2 while some other doing L3 is complex. > >> > > Thinking more about it, perhaps there is not much use in > > preventing both. So, the network says > > > > 1) L2 AND L3 > > 2) L2 or L3 > > 3) L2 > > 4) L3 > > Let me rewrite it a bit: > > 1) L2 and L3 > 2) L2 > 3) L3 > 4) None > > This would be the network mandating what ciphering to use. Alternatively, > the network could blend this with the optional ones (hence 9 possible > combinations I listed earlier), but at the end the PaC would pick one and > it'd boil down to executing one of these 4 combinations. So I don't see > where the complexity is. Is it with some clients are using L2 ciphering > while some others using L2+L3 ciphering (because L3 is optional)? > > I removed your original "2) L2 or L3" because I believe that one is really > complex. If L2 ciphering is necessary and available in an access network, > then it must be mandatory. I don't think an optional L3 ciphering can fully > replace that. Also, if we allow some clients do L2 ciphering only, some > others L3 ciphering only, I suspect all L2 and L3 enforcement points should > be aware of each other, and aware of every client's choice. Otherwise, there > might be some security holes. If every (L2 or L3) EP that provides an optional ciphering performs an appropriate access control to filter out packets from unauthorized devices, I don't think EPs need to be aware of each other. But I don't have a good answer for what the "appropriate access control" is, so I tend to agree on the Alper's 4 patterns above for now. Yoshihiro Ohba --5I6of5zJg18YgZEa Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id XAA22648 for ; Wed, 16 Apr 2003 23:23:23 -0400 (EDT) Received: from smtp.tari.toshiba.com ([208.192.119.194]) by thumper.research.telcordia.com (8.12.8/8.12.1) with ESMTP id h3H3MMoG015199 for ; Wed, 16 Apr 2003 23:22:24 -0400 (EDT) Received: from tai.toshiba.com by smtp.tari.toshiba.com (8.9.1/3.7W-020529) with ESMTP id XAA29662 for ; Wed, 16 Apr 2003 23:21:23 -0400 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by tai.toshiba.com (8.8.8+Sun/8.8.8) with ESMTP id XAA20418 for ; Wed, 16 Apr 2003 23:11:55 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.8/8.12.1) with ESMTP id h3H3IMoG014937; Wed, 16 Apr 2003 23:18:23 -0400 (EDT) Received: from localhost (tari.research.telcordia.com [207.3.232.66]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id XAA22642; Wed, 16 Apr 2003 23:18:35 -0400 (EDT) Date: Thu, 17 Apr 2003 00:17:54 -0400 To: Alper Yegin Cc: Mohan Parthasarathy , Yoshihiro Ohba , Hannes Tschofenig , pana@research.telcordia.com Subject: Re: question: pana messaging Message-ID: <20030417041754.GA2784@catfish> Mail-Followup-To: Alper Yegin , Mohan Parthasarathy , Yoshihiro Ohba , Hannes Tschofenig , pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A426@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Content-Type: text/plain; charset=iso-2022-jp X-UIDL: 28a04f9a2e4e0d55a0467b8878f56dd3 On Wed, Apr 16, 2003 at 07:08:10PM -0700, Alper Yegin wrote: > > The way I see it is, "you need to choose option A or option B or ...". > > PaC can choose option A ,but rather than indicating it, starts the > > negotiation relevant to A i.e if the network supports L2 and L3, > > the client starts L3 negotiation which means it wants to do L3. > > > Perhaps indicating this separately makes PAA/EP more prepared > > on what to expect next i.e L2 and L3 may require different details > > to be communicated to EP. > > Yes. > > For example if the PaC does not explicitly indicate its intentions, this > might open up a security hole. Access point allows the PaC's traffic > thinking PaC is using L3 ciphers. Access router allows the PaC's traffic > thinking it is using L2 ciphers. And maybe the Pac is using neither! [OK, > maybe the access point can be a bit smart and look for an IPsec header and > access router's IP address as the destination of incoming packets, but...] I think there is some scenario in which the network supports L2 or L3 (or both) ciphers, but authenticated PaC is using neither, but EP still allows forwarding unprotected packets for the PaC. In some sense, per-packet protection may be needed only by PaCs that want to protect its traffic from others. If such a scenario makes sense, it might be useful if Data-Protection AVP contains a flag that indicates whether the network forces per-packet protection to all PaCs or not. Yoshihiro Ohba > > If we were to enable such a scenario, I'd prefer PaC explicitly indicating > its intentions. > > > This means client chooses, PAA does the > > setup, acks and then PaC begins the real negotiation. Is this > > a strong enough reason ? > > Alper > > --5I6of5zJg18YgZEa-- From pana-request@research.telcordia.com Mon Apr 28 07:32:35 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27242 for ; Mon, 28 Apr 2003 07:32:34 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h3SBVbxN001446; Mon, 28 Apr 2003 07:31:37 -0400 (EDT) Resent-Date: Mon, 28 Apr 2003 07:31:37 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Any benefits for using Diameter message format in UNI interface? Date: Mon, 28 Apr 2003 14:31:25 +0300 Message-ID: Thread-Topic: Any benefits for using Diameter message format in UNI interface? Thread-Index: AcMNebPywXANH+N+Ta607yq/YBS9lg== From: To: Cc: X-OriginalArrivalTime: 28 Apr 2003 11:31:26.0322 (UTC) FILETIME=[B4465D20:01C30D79] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA27242 Hi, We are discussing in PANA WG about the possibility to use Diameter message formatting between PaC and PAA (PAA is generally seen as the AAA Client for the backend AAA). PANA's request/response (see IKEv2 exchanges) style transport together with Diameter message formatting would open up possibilities to extend Diameter apps to work with mobile clients too. Anyway, PANA deals with authentication and authorization which makes Diameter kind of suitable choice for message formatting. PANA could specify new command codes (PANA messages) and AVPs when needed. Do you see any drawbacks with this approach? IANA considerations are of course needed. One possibility could be to preserve a new Application Id for PANA. For PANA it doesn't give any benefit, except the compatibility. Another choice would just mark the App-Id field reserved in PANA spec. Third possibility is to use the App-Id field in PANA scope and separate it from the Diameter App-Ids. Currently Application-Id field is seen as an extra field for the PANA header. If we remove that, compatibility with Diameter is lost, though. PANA also uses two sequence numbers in place of Hop-by-Hop Id and End-to-End Ids which makes PANA a bit different too. -- Another question/proposal. Would there be interest to have an extended support for Diameter over UDP (between mobile client and network), if PANA doesn't go into this direction. Message transport would be request/response style exchanges like in IKEv2 and message formatting Diameter. Sequence numbering similar to IKEv2, which also suits well with Diameter Hop-by-Hop and End-to-End Ids. The result would be to provide transport for Diameter Applications over UDP (connectionless). This would enable roaming clients to be part of apps, because of the sessionless kind of nature of the UDP (no IP binding needed nor handshakes like in TCP or SCTP). IKEv2 could be used to bootstrap an SA between client and the network (optionally one way or mutual authentication too) and to protect the integrity. Together with possible session resumption capabilities and confidentiality protection this framework becomes quite an interesting platform for apps. Let me hear your comments. Tnx, - Dan From pana-request@research.telcordia.com Mon Apr 28 12:27:44 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06190 for ; Mon, 28 Apr 2003 12:27:44 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h3SGQX6Y004782; Mon, 28 Apr 2003 12:26:33 -0400 (EDT) Resent-Date: Mon, 28 Apr 2003 12:26:33 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: mailing list problem ? Date: Mon, 28 Apr 2003 09:25:53 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C137A@TNEXVS02.tahoenetworks.com> Thread-Topic: mailing list problem ? Thread-Index: AcMNotZyG8LGhFmtSiSygauIUtz0Xw== From: "Mohan Parthasarathy" To: X-OriginalArrivalTime: 28 Apr 2003 16:25:53.0433 (UTC) FILETIME=[D6B19090:01C30DA2] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA06190 Hello, I am unable to see my own postings on the mailing list. It looks like others could see it. I am not sure whether this is a problem on my side. Could somebody check this ? thanks mohan From pana-request@research.telcordia.com Mon Apr 28 12:30:18 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06225 for ; Mon, 28 Apr 2003 12:30:18 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h3SGUhRn005021; Mon, 28 Apr 2003 12:30:43 -0400 (EDT) Resent-Date: Mon, 28 Apr 2003 12:30:43 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Choice of ciphering (was Re: question: pana messaging) Date: Mon, 28 Apr 2003 09:30:16 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A43F@TNEXVS02.tahoenetworks.com> Thread-Topic: Choice of ciphering (was Re: question: pana messaging) Thread-Index: AcMLjv37bvZBsvQdQFehrtJh1lakgwCE/tnw From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , "Alper Yegin" Cc: X-OriginalArrivalTime: 28 Apr 2003 16:30:17.0253 (UTC) FILETIME=[73F14D50:01C30DA3] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA06225 Yoshihiro, In your attached mail, you indicate the network may still want to forward unprotected packets for the PaC. You still have not given a reason for this. You also indicate that Pac needs to use strong protection only to protect traffic from others. This is not true. Per-packet protection is needed for service theft. So, I am not sure I understand what you are saying. -mohan > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Thursday, April 24, 2003 2:47 PM > To: Alper Yegin > Cc: Mohan Parthasarathy; pana@research.telcordia.com > Subject: Re: Choice of ciphering (was Re: question: pana messaging) > > > On Fri, Apr 25, 2003 at 04:57:26PM -0700, Alper Yegin wrote: > > Mohan, > > > > >>> It is very complex. > > >> > > >> I'm not sure if it is really that complex. At the end of > PANA, both > > >> the PaC and PAA knows which ciphering needs to be turned on. > > >> Basically PAA indicated which one(s) are mandatory, and PaC > > >> additionally chose optional one(s). If L2 ciphers is included in > > >> this final list, it needs to be turned on. This is just > like what > > >> would have happened if only L2 ciphers were used. If L3 > ciphers is > > >> included, it'll be turned on next. This is independent > of whether > > >> L2 ciphering is on or off. Am I missing something? > > >> > > > I think the optional part is ncreasing the number > > > of combinations. For example, what is the use of "no L2, L3 > > > optional". Why does the network want to keep something > optional ? > > > If you are concerned about service theft, enforce L2 or L3. > > My answer is in the attached email which I sent last week. > But please see my further comments below. > > > > > This question is more about the motivation of this > flexibility, which > > I'll defer to someone else to respond...(because I said > earlier that I > > didn't have a good answer) > > > > > > > >> > > >>> All you need is whether the network can > > >>> support L2 and/or L3 and client chooses one of them. Why isn't > > >>> this sufficient ? > > >> > > >> I think you meant to say "L2 or L3 but not both", right? > Doing both > > >> L2 and L3 is what you are questioning earlier. Some > clients doing > > >> L2 while some other doing L3 is complex. > > >> > > > Thinking more about it, perhaps there is not much use in > preventing > > > both. So, the network says > > > > > > 1) L2 AND L3 > > > 2) L2 or L3 > > > 3) L2 > > > 4) L3 > > > > Let me rewrite it a bit: > > > > 1) L2 and L3 > > 2) L2 > > 3) L3 > > 4) None > > > > This would be the network mandating what ciphering to use. > > Alternatively, the network could blend this with the optional ones > > (hence 9 possible combinations I listed earlier), but at > the end the > > PaC would pick one and it'd boil down to executing one of these 4 > > combinations. So I don't see where the complexity is. Is it > with some > > clients are using L2 ciphering while some others using > L2+L3 ciphering > > (because L3 is optional)? > > > > I removed your original "2) L2 or L3" because I believe that one is > > really complex. If L2 ciphering is necessary and available in an > > access network, then it must be mandatory. I don't think an > optional > > L3 ciphering can fully replace that. Also, if we allow some > clients do > > L2 ciphering only, some others L3 ciphering only, I suspect > all L2 and > > L3 enforcement points should be aware of each other, and aware of > > every client's choice. Otherwise, there might be some > security holes. > > If every (L2 or L3) EP that provides an optional ciphering > performs an appropriate access control to filter out packets > from unauthorized devices, I don't think EPs need to be aware > of each other. But I don't have a good answer for what the > "appropriate access control" is, > so I tend to agree on the Alper's 4 patterns above for now. > > Yoshihiro Ohba > > From pana-request@research.telcordia.com Mon Apr 28 13:46:32 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08258 for ; Mon, 28 Apr 2003 13:46:31 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h3SHkRxd009504; Mon, 28 Apr 2003 13:46:27 -0400 (EDT) Resent-Date: Mon, 28 Apr 2003 13:46:27 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Sat, 26 Apr 2003 01:34:17 -0700 To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@research.telcordia.com Subject: Re: Choice of ciphering (was Re: question: pana messaging) Message-ID: <20030426083417.GC663@steelhead> Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A43F@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A43F@TNEXVS02.tahoenetworks.com> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 141 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <5T9dkD.A.XUC.zjWr-@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com I meant " protect traffic from others" includes protecting traffic from others that spoof MAC address and/or IP address of the PaC (so service theft is covered). I think that if appropriate filtering is performed at EP for both cryptographically protected and unprotected packets, service theft would not occur at least for clients that use per-packet protection even there are some clients that do not use per-packet protection. Of course clients that do not use per-packet protection are vulnerable to service theft, but if they don't much care about service theft (e.g., when they are charged with a flat-rate), and allowing them to connect the network does not compromise security for clients with using per-packet protection, the network might want to allow them to be connected for providing broader level of service availability. On the other hand, defining an appropriate filtering may be difficult as I mentioned in a separate email, so in many cases a network might not want to make per-packet protection optional. Yoshihiro Ohba On Mon, Apr 28, 2003 at 09:30:16AM -0700, Mohan Parthasarathy wrote: > Yoshihiro, > > In your attached mail, you indicate the network may still want to > forward > unprotected packets for the PaC. You still have not given a reason for > this. > You also indicate that Pac needs to use strong protection only to > protect > traffic from others. This is not true. Per-packet protection is needed > for > service theft. So, I am not sure I understand what you are saying. > > -mohan > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Thursday, April 24, 2003 2:47 PM > > To: Alper Yegin > > Cc: Mohan Parthasarathy; pana@research.telcordia.com > > Subject: Re: Choice of ciphering (was Re: question: pana messaging) > > > > > > On Fri, Apr 25, 2003 at 04:57:26PM -0700, Alper Yegin wrote: > > > Mohan, > > > > > > >>> It is very complex. > > > >> > > > >> I'm not sure if it is really that complex. At the end of > > PANA, both > > > >> the PaC and PAA knows which ciphering needs to be turned on. > > > >> Basically PAA indicated which one(s) are mandatory, and PaC > > > >> additionally chose optional one(s). If L2 ciphers is included in > > > >> this final list, it needs to be turned on. This is just > > like what > > > >> would have happened if only L2 ciphers were used. If L3 > > ciphers is > > > >> included, it'll be turned on next. This is independent > > of whether > > > >> L2 ciphering is on or off. Am I missing something? > > > >> > > > > I think the optional part is ncreasing the number > > > > of combinations. For example, what is the use of "no L2, L3 > > > > optional". Why does the network want to keep something > > optional ? > > > > If you are concerned about service theft, enforce L2 or L3. > > > > My answer is in the attached email which I sent last week. > > But please see my further comments below. > > > > > > > > This question is more about the motivation of this > > flexibility, which > > > I'll defer to someone else to respond...(because I said > > earlier that I > > > didn't have a good answer) > > > > > > > > > > >> > > > >>> All you need is whether the network can > > > >>> support L2 and/or L3 and client chooses one of them. Why isn't > > > >>> this sufficient ? > > > >> > > > >> I think you meant to say "L2 or L3 but not both", right? > > Doing both > > > >> L2 and L3 is what you are questioning earlier. Some > > clients doing > > > >> L2 while some other doing L3 is complex. > > > >> > > > > Thinking more about it, perhaps there is not much use in > > preventing > > > > both. So, the network says > > > > > > > > 1) L2 AND L3 > > > > 2) L2 or L3 > > > > 3) L2 > > > > 4) L3 > > > > > > Let me rewrite it a bit: > > > > > > 1) L2 and L3 > > > 2) L2 > > > 3) L3 > > > 4) None > > > > > > This would be the network mandating what ciphering to use. > > > Alternatively, the network could blend this with the optional ones > > > (hence 9 possible combinations I listed earlier), but at > > the end the > > > PaC would pick one and it'd boil down to executing one of these 4 > > > combinations. So I don't see where the complexity is. Is it > > with some > > > clients are using L2 ciphering while some others using > > L2+L3 ciphering > > > (because L3 is optional)? > > > > > > I removed your original "2) L2 or L3" because I believe that one is > > > really complex. If L2 ciphering is necessary and available in an > > > access network, then it must be mandatory. I don't think an > > optional > > > L3 ciphering can fully replace that. Also, if we allow some > > clients do > > > L2 ciphering only, some others L3 ciphering only, I suspect > > all L2 and > > > L3 enforcement points should be aware of each other, and aware of > > > every client's choice. Otherwise, there might be some > > security holes. > > > > If every (L2 or L3) EP that provides an optional ciphering > > performs an appropriate access control to filter out packets > > from unauthorized devices, I don't think EPs need to be aware > > of each other. But I don't have a good answer for what the > > "appropriate access control" is, > > so I tend to agree on the Alper's 4 patterns above for now. > > > > Yoshihiro Ohba > > > > > From pana-request@research.telcordia.com Mon Apr 28 14:14:18 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09080 for ; Mon, 28 Apr 2003 14:14:17 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h3SIFDGM011391; Mon, 28 Apr 2003 14:15:13 -0400 (EDT) Resent-Date: Mon, 28 Apr 2003 14:15:13 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Choice of ciphering (was Re: question: pana messaging) Date: Mon, 28 Apr 2003 11:14:56 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A440@TNEXVS02.tahoenetworks.com> Thread-Topic: Choice of ciphering (was Re: question: pana messaging) Thread-Index: AcMNrikio1/8+eauSim0oIB3rSXIjgAAyyPw From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Alper Yegin" , X-OriginalArrivalTime: 28 Apr 2003 18:14:56.0808 (UTC) FILETIME=[12D95A80:01C30DB2] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA09080 Yoshihiro, > > I meant " protect traffic from others" includes protecting > traffic from others that spoof MAC address and/or IP address > of the PaC (so service theft is covered). I think that if > appropriate filtering is performed at EP for both > cryptographically protected and unprotected packets, service > theft would not occur at least for clients that use > per-packet protection even there are some clients that do not > use per-packet protection. Of course clients that do not use > per-packet protection are vulnerable to service theft, but if > they don't much care about service theft (e.g., when they are > charged with a flat-rate), and allowing them to connect the > network does not compromise security for clients with using > per-packet protection, the network might want to allow them > to be connected for providing broader level of service availability. > Ok, I see your point now. But it is just not the clients who are affected by service theft. As a network operator, I don't want someone to get free service. -mohan > On the other hand, defining an appropriate filtering may be > difficult as I mentioned in a separate email, so in many > cases a network might not want to make per-packet protection optional. > > Yoshihiro Ohba > > > On Mon, Apr 28, 2003 at 09:30:16AM -0700, Mohan Parthasarathy wrote: > > Yoshihiro, > > > > In your attached mail, you indicate the network may still want to > > forward unprotected packets for the PaC. You still have not given a > > reason for this. > > You also indicate that Pac needs to use strong protection only to > > protect > > traffic from others. This is not true. Per-packet > protection is needed > > for > > service theft. So, I am not sure I understand what you are saying. > > > > -mohan > > > > > > > -----Original Message----- > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: Thursday, April 24, 2003 2:47 PM > > > To: Alper Yegin > > > Cc: Mohan Parthasarathy; pana@research.telcordia.com > > > Subject: Re: Choice of ciphering (was Re: question: pana > messaging) > > > > > > > > > On Fri, Apr 25, 2003 at 04:57:26PM -0700, Alper Yegin wrote: > > > > Mohan, > > > > > > > > >>> It is very complex. > > > > >> > > > > >> I'm not sure if it is really that complex. At the end of > > > PANA, both > > > > >> the PaC and PAA knows which ciphering needs to be turned on. > > > > >> Basically PAA indicated which one(s) are mandatory, and PaC > > > > >> additionally chose optional one(s). If L2 ciphers is > included in > > > > >> this final list, it needs to be turned on. This is just > > > like what > > > > >> would have happened if only L2 ciphers were used. If L3 > > > ciphers is > > > > >> included, it'll be turned on next. This is independent > > > of whether > > > > >> L2 ciphering is on or off. Am I missing something? > > > > >> > > > > > I think the optional part is ncreasing the number > > > > > of combinations. For example, what is the use of "no L2, L3 > > > > > optional". Why does the network want to keep something > > > optional ? > > > > > If you are concerned about service theft, enforce L2 or L3. > > > > > > My answer is in the attached email which I sent last week. But > > > please see my further comments below. > > > > > > > > > > > This question is more about the motivation of this > > > flexibility, which > > > > I'll defer to someone else to respond...(because I said > > > earlier that I > > > > didn't have a good answer) > > > > > > > > > > > > > >> > > > > >>> All you need is whether the network can > > > > >>> support L2 and/or L3 and client chooses one of > them. Why isn't > > > > >>> this sufficient ? > > > > >> > > > > >> I think you meant to say "L2 or L3 but not both", right? > > > Doing both > > > > >> L2 and L3 is what you are questioning earlier. Some > > > clients doing > > > > >> L2 while some other doing L3 is complex. > > > > >> > > > > > Thinking more about it, perhaps there is not much use in > > > preventing > > > > > both. So, the network says > > > > > > > > > > 1) L2 AND L3 > > > > > 2) L2 or L3 > > > > > 3) L2 > > > > > 4) L3 > > > > > > > > Let me rewrite it a bit: > > > > > > > > 1) L2 and L3 > > > > 2) L2 > > > > 3) L3 > > > > 4) None > > > > > > > > This would be the network mandating what ciphering to use. > > > > Alternatively, the network could blend this with the > optional ones > > > > (hence 9 possible combinations I listed earlier), but at > > > the end the > > > > PaC would pick one and it'd boil down to executing one > of these 4 > > > > combinations. So I don't see where the complexity is. Is it > > > with some > > > > clients are using L2 ciphering while some others using > > > L2+L3 ciphering > > > > (because L3 is optional)? > > > > > > > > I removed your original "2) L2 or L3" because I believe > that one > > > > is > > > > really complex. If L2 ciphering is necessary and > available in an > > > > access network, then it must be mandatory. I don't think an > > > optional > > > > L3 ciphering can fully replace that. Also, if we allow some > > > clients do > > > > L2 ciphering only, some others L3 ciphering only, I suspect > > > all L2 and > > > > L3 enforcement points should be aware of each other, > and aware of > > > > every client's choice. Otherwise, there might be some > > > security holes. > > > > > > If every (L2 or L3) EP that provides an optional ciphering > > > performs an appropriate access control to filter out packets > > > from unauthorized devices, I don't think EPs need to be aware > > > of each other. But I don't have a good answer for what the > > > "appropriate access control" is, > > > so I tend to agree on the Alper's 4 patterns above for now. > > > > > > Yoshihiro Ohba > > > > > > > > > From pana-request@research.telcordia.com Mon Apr 28 15:18:27 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11983 for ; Mon, 28 Apr 2003 15:18:27 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h3SJIAJs014994; Mon, 28 Apr 2003 15:18:10 -0400 (EDT) Resent-Date: Mon, 28 Apr 2003 15:18:10 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Sat, 26 Apr 2003 03:06:05 -0700 To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@research.telcordia.com Subject: Re: Choice of ciphering (was Re: question: pana messaging) Message-ID: <20030426100605.GF663@steelhead> Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@research.telcordia.com References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A440@TNEXVS02.tahoenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A440@TNEXVS02.tahoenetworks.com> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030322(IM144) Lines: 182 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Mon, Apr 28, 2003 at 11:14:56AM -0700, Mohan Parthasarathy wrote: > Yoshihiro, > > > > > I meant " protect traffic from others" includes protecting > > traffic from others that spoof MAC address and/or IP address > > of the PaC (so service theft is covered). I think that if > > appropriate filtering is performed at EP for both > > cryptographically protected and unprotected packets, service > > theft would not occur at least for clients that use > > per-packet protection even there are some clients that do not > > use per-packet protection. Of course clients that do not use > > per-packet protection are vulnerable to service theft, but if > > they don't much care about service theft (e.g., when they are > > charged with a flat-rate), and allowing them to connect the > > network does not compromise security for clients with using > > per-packet protection, the network might want to allow them > > to be connected for providing broader level of service availability. > > > Ok, I see your point now. But it is just not the clients who are > affected > by service theft. As a network operator, I don't want someone to get > free > service. OK, I have overlooked that point. A network might not want to allow multiple devices to share the same device identifier even in a very short amount of time. So if per-packet protection is enforced, and if there is some user A and gains access to a network with a device-id, it is not possible for his/her friend using a separate device to configure the same device-id and access the network while A is not sending/receiving packets. So it seems that service theft has two aspects, one from client side and the other from network side. I think it might be better to describe these two aspects in draft-ietf-pana-threats-eval-03.txt. Thanks, Yoshihiro Ohba > -mohan > > > On the other hand, defining an appropriate filtering may be > > difficult as I mentioned in a separate email, so in many > > cases a network might not want to make per-packet protection optional. > > > > Yoshihiro Ohba > > > > > > On Mon, Apr 28, 2003 at 09:30:16AM -0700, Mohan Parthasarathy wrote: > > > Yoshihiro, > > > > > > In your attached mail, you indicate the network may still want to > > > forward unprotected packets for the PaC. You still have not given a > > > reason for this. > > > You also indicate that Pac needs to use strong protection only to > > > protect > > > traffic from others. This is not true. Per-packet > > protection is needed > > > for > > > service theft. So, I am not sure I understand what you are saying. > > > > > > -mohan > > > > > > > > > > -----Original Message----- > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > Sent: Thursday, April 24, 2003 2:47 PM > > > > To: Alper Yegin > > > > Cc: Mohan Parthasarathy; pana@research.telcordia.com > > > > Subject: Re: Choice of ciphering (was Re: question: pana > > messaging) > > > > > > > > > > > > On Fri, Apr 25, 2003 at 04:57:26PM -0700, Alper Yegin wrote: > > > > > Mohan, > > > > > > > > > > >>> It is very complex. > > > > > >> > > > > > >> I'm not sure if it is really that complex. At the end of > > > > PANA, both > > > > > >> the PaC and PAA knows which ciphering needs to be turned on. > > > > > >> Basically PAA indicated which one(s) are mandatory, and PaC > > > > > >> additionally chose optional one(s). If L2 ciphers is > > included in > > > > > >> this final list, it needs to be turned on. This is just > > > > like what > > > > > >> would have happened if only L2 ciphers were used. If L3 > > > > ciphers is > > > > > >> included, it'll be turned on next. This is independent > > > > of whether > > > > > >> L2 ciphering is on or off. Am I missing something? > > > > > >> > > > > > > I think the optional part is ncreasing the number > > > > > > of combinations. For example, what is the use of "no L2, L3 > > > > > > optional". Why does the network want to keep something > > > > optional ? > > > > > > If you are concerned about service theft, enforce L2 or L3. > > > > > > > > My answer is in the attached email which I sent last week. But > > > > please see my further comments below. > > > > > > > > > > > > > > This question is more about the motivation of this > > > > flexibility, which > > > > > I'll defer to someone else to respond...(because I said > > > > earlier that I > > > > > didn't have a good answer) > > > > > > > > > > > > > > > > >> > > > > > >>> All you need is whether the network can > > > > > >>> support L2 and/or L3 and client chooses one of > > them. Why isn't > > > > > >>> this sufficient ? > > > > > >> > > > > > >> I think you meant to say "L2 or L3 but not both", right? > > > > Doing both > > > > > >> L2 and L3 is what you are questioning earlier. Some > > > > clients doing > > > > > >> L2 while some other doing L3 is complex. > > > > > >> > > > > > > Thinking more about it, perhaps there is not much use in > > > > preventing > > > > > > both. So, the network says > > > > > > > > > > > > 1) L2 AND L3 > > > > > > 2) L2 or L3 > > > > > > 3) L2 > > > > > > 4) L3 > > > > > > > > > > Let me rewrite it a bit: > > > > > > > > > > 1) L2 and L3 > > > > > 2) L2 > > > > > 3) L3 > > > > > 4) None > > > > > > > > > > This would be the network mandating what ciphering to use. > > > > > Alternatively, the network could blend this with the > > optional ones > > > > > (hence 9 possible combinations I listed earlier), but at > > > > the end the > > > > > PaC would pick one and it'd boil down to executing one > > of these 4 > > > > > combinations. So I don't see where the complexity is. Is it > > > > with some > > > > > clients are using L2 ciphering while some others using > > > > L2+L3 ciphering > > > > > (because L3 is optional)? > > > > > > > > > > I removed your original "2) L2 or L3" because I believe > > that one > > > > > is > > > > > really complex. If L2 ciphering is necessary and > > available in an > > > > > access network, then it must be mandatory. I don't think an > > > > optional > > > > > L3 ciphering can fully replace that. Also, if we allow some > > > > clients do > > > > > L2 ciphering only, some others L3 ciphering only, I suspect > > > > all L2 and > > > > > L3 enforcement points should be aware of each other, > > and aware of > > > > > every client's choice. Otherwise, there might be some > > > > security holes. > > > > > > > > If every (L2 or L3) EP that provides an optional ciphering > > > > performs an appropriate access control to filter out packets > > > > from unauthorized devices, I don't think EPs need to be aware > > > > of each other. But I don't have a good answer for what the > > > > "appropriate access control" is, > > > > so I tend to agree on the Alper's 4 patterns above for now. > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > From pana-request@research.telcordia.com Wed Apr 30 14:41:57 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16593 for ; Wed, 30 Apr 2003 14:41:57 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h3UIe1iK009982; Wed, 30 Apr 2003 14:40:01 -0400 (EDT) Resent-Date: Wed, 30 Apr 2003 14:40:01 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 30 Apr 2003 11:40:37 -0700 Subject: pana-threats WG LC comments From: Alper Yegin To: pana CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hello, I'm forwarding Asokan's comments on PANA security threats draft. Please see below.... Alper Review of draft-ietf-pana-threats-eval-03.txt April 30, 2003 Section 4 - para 1: this text is unclear in a couple of places - "trust operators .. to provide THE service" What service is it? Network access? Some other services? Which nodes? Client nodes only, or other network nodes too? - "not trust other nodes.. e.g., ... Hotel, Airport" These are not nodes. Was the idea that the access points in these places may not be trusted? - "not trust relationship.. [but] belief about how the nodes ... behave in the future" This text is contradictory. If the relationship is not about trust, it cannot be called "trust relationship". Suggestions - since you have already defined your terminology, it would be good to use those defined terms like PaC and AS, rather than a generic term like "nodes" - Perhaps the intended message of this paragraph is something like this: - PANA is intended to be used in an environment where there is no priori trust relationship or security association between PaC and nodes in the access zone like PAA and EP. - para 2: bullet 2 change "access network at layer 2 (3GPP2 CDMA network)" to "access network at layer 2 (e.g., 3GPP2 CDMA network)" Section 5 - The title says "Trust relationships", but the only reference to trust relationships is in the last para (about PaC and EP). I think you should - list the pairs of nodes between which a priori trust relationship is assumed (i.e., trust assumption) e.g., PaC and AS, PAA and EP, PAA and AS - list the initial security associations required to exist before PANA begins. e.g., PaC and AS, PAA and EP (maybe), PAA and AS (either static or derived using the AAA infrastructure) - last para change key derivation to key establishment key may be derived, or transported (chosen by one party and sent to the other) - PANA also MUST result in key establishment between PaC and PAA (Requirement 2) Section 6.1 - Threat 6.1.1 is ok. But it is not clear how that implies "information exchange .. SHOULD be limited". For e.g., discovery process may list 100s of potential PAA addresses. If they are all equal, there is no _security_ reason to limit the number of candidate PAAs. Suggestions for requirement: - security-criticical choices (e.g., authentication methods to be agreed between PaC and PAA) SHOULD be limited. Section 6.2.1 - Protecting Success or Failure indications If this requirement is motivated by EAP, maybe it should be mentioned. Better still, generalize the requirement so that it is not specific to one authentication framework. In a more general sense, the requirement is not just about success/failure indications, but about any "control" message (success/failure, disconnect/revoke, reauthentication requests etc.) - change "methods that can derive keys" to "methods that result in keys"? - question: is it really the intent to protect failure messages, too? (they can't be protected using session keys resulting from authentication methods) - first paragraph on page 7: if the link is not shared then either you assume that the link is physically secure, or it is not necessary to differentiate it from a shared link. In this case, this whole paragraph can be replaced by the sentence that you use in pretty much every other threat "If the link is not a shared medium, then this threat is absent" Section 6.2.2 - You have to clarify when MitM vulnerability exists. Just using a compound authentication method doesn't automatically lead to the vulnerability. For example, PANA may use a tunnel to protect an eavesdropper in the PaC-PAA path from listening in on information exchanged by the inner authentication method. This doesn't lead to a MitM attack. MitM shows up only when the tunnel keys are used as session keys between PaC and some other entity (PAA or EP) - So, before you talk about MitM, you should first decide whether it is a PANA security requirement to use a tunneling method for the purpose of deriving session keys between PaC and PAA. Section 6.2.4 - "protect the device identifier" is too general: What you mean here is something like "protect the integrity of the binding of the device identifier to the authenticated session" Section 6.3 - See comment on Section 6.2.1. Requirements 2 and 6 are related. Section 6.4 - See comment on Section 6.2.4. Requirements 5 and 7 are related (5 is a special case of 7) - The basic requirement is not really about "generating access control information" but that PANA must make sure that the credentials to be used in authorizing packets through the EP (device identifier, IPsec AH key etc.) are securely bound to the authenticated session. In the case of device identifier, the binding is integrity protection. In the case of IPsec AH key, the binding is to ensure that PANA results in a secret session key to be used between PaC and EP. Section 6.5 - point 2: reference to "public key computation" also seems to presume specific solution techniques. Suggestion: replace "public key computation" by "computationally intensive operations" Section 6.6 - change "should not" to "SHOULD NOT"