Subject: Re: [Pana] WG LC: Pre-authentication Support for PANA

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 19 Jan 2009 18:12:57 -0500

Alper,

Thank you for your review.  I agree all of your comments.
Please see my comments in line.

On Thu, Jan 15, 2009 at 11:38:20AM +0200, Alper Yegin wrote:
> Here are my comments.
> 
> 
> - "The PCI message MUST be unicast."
> 
> Not sure why we have such a constraint. Does using a non-unicast address
> break anything? If not, let's not be constraining the spec unnecessarily.
> Not that I see any use for this right away, but I don't see a reason to
> prohibit future possibilities unless we see a value in having such a
> constraint.

I agree that the sentence is not needed.

> 
> 
> - "Once the PaC and CPAA have agreed on performing pre-authentication
>       using the 'S' (Start) and 'E' (prE-authentication) bits, the
>       subsequent PANA messages exchanged between them MUST have the 'E'
>       (prE-authentication) bit set."
> 
> Not forever, right? We shall state "... MUST have the 'E' bit set until CPAA
> becomes SPAA of the PaC".

Yes, that is clearer.

> 
> - I didn't understand the utility of "Pre-authorization SA" and
> "Pre-authorization SA" distinction. There is only one PANA SA. It does not
> change when the PaC attaches to the target network. 

This is a good point.  By {pre,post}-authorization, I meant to
represent status of PANA session.  We can change "Pre-authorization
SA" and "Post-authorization SA" to "pre-authorization state of the
PANA session" and "post-authorization state of the PANA session",
respectively.

> 
> -  In an access network where accounting is performed, accounting starts
>    when the pre-authorization SA becomes the post-authorization SA by
>    default.  Depending on the pre-authorization policy, accounting may
>    start immediately after the pre-authorization SA is established.
> 
> 
> This spec should not care when acct starts. 

We can remove the paragraph and change the Section title to
"Authorization Considerations".

> 
> -    Since the mechanism described in this document is designed to work
>    across multiple access networks, each EP in the serving network
>    SHOULD be configured to allow PANA messages to be forwarded between a
>    PaC and a CPAA only if the PaC has a post-authorization SA with the
>    SPAA in order to avoid an unauthorized PaC to initiate pre-
>    authentication.
> 
> Not sure why we have to say anything like that. PANA pre-auth is just UDP.
> Unless the serving network "intends to block" pre-auth, it would not be
> preventing pre-auth. 
> 
> An EP should allow PANA messages from unauthorized only if they are destined
> to SPAA.
> So, it should not blindly allow PANA messages. They may not only allow
> pre-authentication (not that harmful), but they may even piggyback some data
> to punch a hole through EP. I guess this is what the spec intends to talk
> about, but it was not that clear to me from reading it.

I agree.  How about revising the paragraph as follows?

"
   Since the mechanism described in this document is designed to work
   across multiple access networks, each EP in the serving network
   SHOULD allow PANA messages originated from unauthorized PaCs to be
   forwarded only if they are destined to SPAA.  Also, each access
   network that supports pre-authentication SHOULD block
   pre-authentication attempts from networks from which a handover is
   not likely to occur.
"

> 
> -    The pre-authentication mechanism defined in this document does not
>    have an issue on context binding in which link-layer independent
>    context carried over pre-authentication signaling is bound to the
>    link-layer specific context [I-D.ietf-hokey-preauth-ps], because the
>    same EAP transport protocol (i.e., PANA) is used for normal
>    authentication and pre-authentication in the candidate network.
> 
> 
> This does not even describe what the issue could be. I don't see a value in
> having this paragraph here.

I agree.  We can remove the paragraph since this document has no issue
with context binding.

> 
> 
> Editorial:
> 
> -  If the PaC is a
>    mobile device and is capable of moving one access network to another
>    while running its applications,
> 
> s/moving one/moving from one

OK.

> 
> 
> - allow the PaC to sent or receive packets
> 
> s/sent/send

OK.

Regards,
Yoshihiro Ohba

> 
> 
> Thank you.
> 
> Alper
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Basavaraj Patil
> > Sent: Thursday, January 08, 2009 9:52 PM
> > To: [email-masked]
> > Subject: [Pana] WG LC: Pre-authentication Support for PANA
> > 
> > 
> > 
> > Hello,
> > 
> > This is a WG last call for I-D: Pre-authentication Support for PANA
> > <draft-ietf-pana-preauth-04>.
> > 
> > The last call will end on January 22nd, 09. Please send your comments
> > to the mailing list prior to the deadline.
> > 
> > -Chairs
> > 
> > _______________________________________________
> > Pana mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/pana
> 
> 
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pana
> 
_______________________________________________
Pana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pana

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 27 Jan 2009 11:34:50 +0200

Yoshi,

>    forwarded only if they are destined to SPAA.  

I now think we don't even need to say this. The above paragraph is related
to the serving access network and it has nothing to do with "pre-auth"
operation. It may not even be a PANA-enabled network. It may not even have
access authentication. I'd remove this part.

> Also, each access

This makes sense. 

Alper