Subject: RE: [Pana] Erik Nordmark's review comments #1

From: "Alper Yegin" <[email-masked]>
Date: Wed, 14 Jul 2004 13:01:45 -0700

I went over the list and opened new entries in the issue tracker. Please 
start a new thread for discussing individual issues.

On pana-ipsec:
101 Clarify the distinction between initial auth. and per-packet auth.

On pana-pana:
102 Reorganize the document flow
103 "PANA session" needs more clarification
104 Device Id clarification and further consideration
105 Inconsistent and unclear usage of "reauth" messages
106 sequence number on rexmited messages must be incremented

I couldn't create an entry for the framework I-d because the category does 
not exist (and Dan is not available to create it).

Alper
P.S: I'm experiencing huge delays (5-6 hours) in getting my messages posted 
on the list. Is anyone else is having the same problem?

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Alper Yegin
>Sent: Tuesday, July 13, 2004 1:31 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [Pana] Erik Nordmark's review comments #1
>
>
>(re-posting......)
>
>-----Original Message-----
>From: Alper Yegin - SAIT
>Sent: Monday, July 12, 2004 1:55 PM
>To: [email-masked]'
>Cc: [email-masked]'
>Subject: Erik Nordmark's review comments #1
>
>Hello,
>
>Please see Erik's review comments on the base spec, framework, and IPsec
>documents below. I've been holding on to these until we received the
>more detailed ones, but they won't be coming in for another couple of
>weeks. Until than, let's start processing these ones...
>
>
>Alper
>
>
>-----Original Message-----
>From: Erik Nordmark [mailto:[email-masked]]
>Sent: Wednesday, June 16, 2004 10:38 AM
>To: Alper Yegin - SAIT
>Cc: Erik Nordmark; [email-masked]
>Subject: RE: PANA review request
>
>
>So I did finish the read of the document set on Friday,
>but I haven't typed up the comments and some of them are
>extensive.
>
>The quick summary is:
>The framework seems to be in reasonable shape but the introduction
>is lacking in that it doesn't give an overview of the solved problem
>and it doesn't indicate which order the naive implementor or somebody
>that is trying to understand PANA should read the different documents.
>
>The ipsec doc is mostly ok. It should probably make the distinction
>between
>authentication (of a user) and per-packet authentication more clear.
>
>The pana document has significant editorial problems; by the time I'd
>read
>up to and including the security considerations section I finally
>understood
>what the features are of the protocol; reading back to front instead of
>front to back would have made it easier to understand.
>So editorially it needs to be better at incremental disclosure.
>For instance, talking about the features/functions up front without
>mentioning the packet formats and bit fields (RFC 2461 tries to do this
>and might be a reasonable approach). Then talk about the packets and
>what
>they are for (DHCPv6 has that type of info; basically a short paragraph
>per
>packet.)
>The document also seems to have technical omissions. The top 4 are:
>  - a session is not defined. Questions like who allocates the session
>id,
>    whether or not a session is bidirectional or unidirectional (with
>different
>    ids for both ends), and what happens to the session when
>reauthenticating
>    and when using the mobility optimization are unstated.
>  - the usage of device ID seems confused because there are some device
>IDs
>    that are carried in packets (L2/L3 addresses) and others that are not
>    (circuit ID) but most places in the document read as if circuit ids
>are
>    always carried in packets; there is even an EP device ID (which is
>used
>    to just carry the address of the EP). Furthermore, doesn't ipsec
>per-packet
>    auth rely on identifying the packet based on something else (the
>IPsec SA?).
>    Would it be more clear if device ID had two subclasses: local device
>ID
>    (e.g., cirtcuit ID) and address device ID (which would be carried in
>    packets)?
>  - the reauth packets seem to have completely different functions
>depending
>    on the direction they are sent. In one direction it is a reauth
>    and in the other direction it is a keepalive. (The document even uses
>    the term "keepalive" somewhere I think.) Wouldn't it be clearer
>    if these were different messages?
>  - the retransmission text says that a retransmitted packet has a new
>sequence
>    number. This makes no sense to me.
>
>I'll type up more complete comments later.
>
>   Erik
>
>
>_______________________________________________
>Pana mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pana

_________________________________________________________________
Get tips for maintaining your PC, notebook accessories and reviews in 
Technology 101. http://special.msn.com/tech/technology101.armx

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