Subject: [Pana] Re: Review of draft-ietf-pana-pana-06

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 Nov 2004 21:00:15 -0500

Hi Gerardo,

Thank you for sending the comments.  Please see my comments below.

On Thu, Oct 28, 2004 at 07:00:43PM +0200, Giaretta Gerardo wrote:
> Hi Alper and Yoshi,
> 
> I have some comments about PANA protocol draft.
> 
> Two general comments: 
> 
> 1. the draft specifies that there must be one hop between PaC and PAA.
> This is not mentioned in section 3 (Introduction) and only in section
> 4.1 this is mentioned and partially motivated for the first time. I'd
> suggest to write this requirement also in section 3. 

OK.

> Moreover I have not
> found in any PANA document a complete explanation of the reasons of this
> choice (nor in draft-ietf-pana-requirements-09 where this requirement is
> introduced). I think these reasons should be better explained in a PANA
> WG document (which one? PANA framework?): in particular, this is
> important since draft-tschofenig-mip6-bootstrapping-pana-00 proposes to
> relax this assumption (even though in a complete different scenario).

I think it might be better to have the reasonings on the "one IP hop"
requirement in the framework draft.

> 
> 2. I think the draft lacks of enough considerations about lifetimes of
> PANA session, of PANA SA and of the keys defined in the draft (i.e.
> PANA_MAC_KEY, AAA-key-int, AAA-key-new). For example, it's not clear to
> me which are the relationships between the AAA-key lifetime and the PANA
> session lifetime and the PANA SA lifetime. In the draft it is stated
> that "The lifetime of the PANA SA is the same as the lifetime of the
> PANA session for simplicity" (section 5.6) and "The PANA SA lifetime is
> bounded by the AAA-Key lifetime.  Another execution of EAP method yields
> in a new AAA-Key, and updates the PANA SA, PANA_MAC_KEY and key ID"
> (sec. considerations section). Does it mean that (PANA session
> lifetime)=(PANA SA lifetime)=(AAA-key lifetime)? 

I think so.  Some clarification text would be needed on this probably
in section 5.10.  Just a note that in the pana-ipsec document the IKE
shared secret derived from a AAA-Key can exist even after the AAA-Key
is updated to another AAA-Key.

> Moreover, which are the lifetimes of PANA_MAC_KEY, AAA-key-int and
> AAA-key-new? Is it equal to the AAA-key lifetime? I think something
> about this should be mentioned.

PANA_MAC_KEY lifetime is equal to PANA SA lifetime (and equal to PANA
session lifetime and AAA-key lifetime).  I think AAA-key-int should be
deleted once a new AAA-Key (i.e., AAA-Key-new) is derived.

> 
> 
> Some other (more detailed) comments:
> 
> - there are some terms used in the draft that are not defined in the
> terminology section (Pre PANA Address, Post PANA Address, IPsec Tunnel
> Inner Address, etc.). Since most of them are defined in PANA framework
> terminology section, maybe it could be useful to have a reference to it
> in the terminology section of PANA draft.

I agree.

> 
> - section 3, bullet 2: the term ISP is not introduced, nor the
> difference between NAP and ISP authentication. Maybe a possibility could
> be to introduce ISP in the terminology section or include here a refence
> to PANA framework.

OK.  How about something like this?

"
   Internet Service Provider (ISP):

      A service provider that provides network-layer connectivity to
      the Internet via an access network managed by a NAP.
"

> 
> - section 3, figure 1: I'd suggest to specify that this is an example in
> case of a 1 RTT EAP method.

OK.

> 
> - section 4.1, first paragraph: it would seem that the only reason to
> have PaC and PAA one hop away is the discovery process. I would suggest
> to add a paragraph in introduction in order to state the motivations of
> this choice or as, I stated before, introduce some text in PANA
> framework and reference to it.

OK.  

> 
> - section 4.1, figure 3: the figure shows that a L2 trigger at the EP
> could trigger PANA protocol. This is certainly true, but there is not
> any reference to this in the text. I'd suggest to add some text at the
> end of paragraph 3, page 10.

OK.  How about changing the third paragraph of section 4.1 from:

"
   The PaC MAY also choose to start sending packets before getting
   authenticated.  In that case, the network may detect this and the PAA
   MAY send an unsolicited PANA-Start-Request message to the PaC in
   addition to filtering the unauthorized traffic.  The EP is the node
   that can detect such activity.  The PAA-to-EP protocol MAY be used
   for this purpose.
"

to:

"
   The PaC MAY also choose to start sending packets before getting
   authenticated.  In that case, the network may detect this and the PAA
   MAY send an unsolicited PANA-Start-Request message to the PaC in
   addition to filtering the unauthorized traffic.  The EP is the node
   that can detect such activity and inform the PAA of the presence of
   the PaC.  The PAA-to-EP protocol MAY be used for this purpose.
"

> 
> - section 4.2, paragraph 2: "When an EAP Success/Failure message is sent
> from a PAA, the message is carried in a PANA-Bind-Request (PBR)
> message". This is not completly true because in case of separate NAP/ISP
> authentication EAP Success/Failure message can be carried also in a
> PFER. I'd suggest to add this comment in text. This is useful also
> because, in paragraph 3, PFER and PFEA are mentioned together with PBR
> and PBA.

I tried to avoid mentioning PFER and PFEA in section 4.2 for the
purpose of "incremental disclosure" as suggested by Erik Nordmark.
So how about changing the sentece to:

"
When an EAP Success/Failure message is sent from a PAA and if
separate NAP and ISP authentication is not used, the message is
carried in a PANA-Bind-Request (PBR) message.
"

> 
> - section 5.1 Provider-ID-AVP and Provider-Name-AVP are lacking. Is it
> your choice? 

I think those AVPs should be added in section 5.1.

> 
> - section 5.1, bullet 8: this bullet partially repeats what is specified
> in bullet 3. Remove bullet 3?

Bullet 3 mentions Device-Id AVP and bullet 8 mentions Session-Id AVP.
I failed to find a repeated text in those bullets.

> 
> - section 5.6: which is the reason to repeat the Key-Id AVP also in PBA?
> 

Just to make sure the both ends agreed on the AAA-Key.

> 
> - section 5.10, paragraph 2: "PAA should initiate EAP authentication
> before the current session lifetime expires". Maybe
> s/authentication/reauthentication?

Yes.

> 
> - I don't understand the reason of section 6.1. It does not specify any
> protocol details and it repeats a lot of details previously described.
> Moreover it sounds like a "second" security consideration sectio.n

I tend to agree with you.  We basically have two choices:

- remove section 6.1 
- moving the text in section 6.1 to security considerations section 

What do you think?

> 
> - section 6.2: CTP requires the usage of CTAR in order to trigger and
> authorize the transfer. This means that the MN (PaC) has an active role
> and CTP operations cannot be performed only by PAAs as suggested in this
> section. This issue is tackled deeply in draft-bournelle-pana-ctp-01.
> Maybe it is a CTP issue and not a PANA one but I think this should be
> mentioned in the draft when the reference to CTP is made. 
> Another issue about the mobility handling is the need to communicate to
> the AAA infrastructure the new NAS (PAA) to which the PaC is attached.
> Again, maybe this is not directly a PANA issue but i think it should be
> mentioned.

Let's discuss this issue separately.

> 
> - section 8.2.1: there is still a reference to two sequence numbers.

True.  How about changing the sentence:

"
Both sequence numbers in this message are set to zero (0).
"

to:

"
 The sequence number field in this message are set to zero (0).
"

> 
> - section 8.2.4: if EAP messages are not piggybacked, PARs can be sent
> also by PaC. Same for section 8.2.5 and PAAs.   

True. 

New text for section 8.2.4:

"
   PANA-Auth-Request (PAR) is sent either by the PAA or the PaC.
"

New text for section 8.2.5:

"
   PANA-Auth-Answer (PAN) is sent either by the PaC to the PAA in
   response to a PANA-Auth-Request message.
"

> 
> 
> Editorial nits:
> 
> - caption of figure 2: double space between Phase and when
> 
> - caption of figure 8: I'd suggest to add "triggered by PaC"
> 
> - section 5.5, bullet 3: double "in MAC or or IP header": s/or or/or
>                                         
> - section 8.2.9: s/PANA-Result-Request/PANA-Bind-Request
> 
> - section 8.3.18: "The IP-Address (AVP Code 18) contains an IP address
> of n a PaC or PAA": s/of n a PaC/of a PaC
>  
> 
> - section 10.1: ")" is lacking

I will fix all these editorial nits.

Thanks again.

Yoshihiro Ohba

> 
> 
> Regards,
> 
> --Gerardo
> 
> 
> Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.
> 
> ====================================================================
> CONFIDENTIALITY NOTICE
> This message and its attachments are addressed solely to the persons
> above and may contain confidential information. If you have received
> the message in error, be informed that any use of the content hereof
> is prohibited. Please return it immediately to the sender and delete
> the message. Should you have any questions, please send an e_mail to
> [email-masked]. Thank you
> ====================================================================

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: [email-masked]
Date: Fri, 5 Nov 2004 13:42:46 +0200

Hi Gerardo,

I've created a few issues based on your email. Please see, the issue
tracker: http://danforsberg.info:8080/pana-issues/

Please see one comment below

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Giaretta Gerardo
> Sent: 28 October, 2004 20:01
> To: Yoshihiro Ohba; Alper Yegin
> Cc: [email-masked]
> Subject: [Pana] Review of draft-ietf-pana-pana-06
> 
> 
<klip>
> Another issue about the mobility handling is the need to communicate
> to the AAA infrastructure the new NAS (PAA) to which the PaC is
> attached.  Again, maybe this is not directly a PANA issue but i
> think it should be mentioned.

This is true. Please see:
http://www.watersprings.org/pub/id/draft-liu-aaa-diameter-session-mobility-00.txt

We could re-submit this draft and work together. Please let me know.

Br,
- Dan

---

From: Giaretta Gerardo <[email-masked]>
Date: Mon, 08 Nov 2004 01:22:57 +0100

Hi Yoshi,

> > Maybe I'm missing something, but how the L2 trigger comes into the
> > picture?
> 
> Now I see what you mean.  Then, how about this?
> 
> "
> that can detect such activity by capturing an IP data packet sent from
> the PaC or by receiving a trigger from the lower layer, and then
> inform the PAA of the presence of the PaC.  The PAA-to-EP protocol MAY
> be used for this purpose.
> "
>

Looks good.
 
> > Sorry. I'm referring to bullet 8 and 3 of section 5.5
> 
> Now I found the place.  Actually bullet 3 mentions validity check of
> DI carried in MAC/IP header while bullet 8 mentions validity check of
> Device-Id AVP.  Those two are different things.  So I'd suggest keep
> both of them.
> 

OK

> > I think that moving "as is" the text in section 6.1 to security
> > considerations section it's not a good choice. Maybe we can 
> remove it.
> > Do you think there are issues in section 6.1 that are not 
> tackled and
> > explained in security considerations section?
> 
> I am OK with removing section 6.1.
> 

I agree too

Regards,
--Gerardo