Subject: [Pana] IESG Review of protocol and framework documents

From: Mark Townsley <[email-masked]>
Date: Fri, 22 Jun 2007 13:54:16 +0200

PANA Folks,

Yesterday, the IESG balloted draft-ietf-pana-pana-17.txt (Proposed 
Standard) and draft-ietf-pana-framework-09.txt (Informational RFC). 
While there are a handful of DISCUSS positions that we need to work 
through, all of you who worked hard on this revision should be 
commended. In particular, a rare word of praise from Sam Hartman:

"[2007-06-21] First, I'd like to compliment Mark and the PANA working 
group on the
excellent work they have done over the last year.  I fully expected to
be unable to support publication of PANA when it came to the IESG.
While I do have some blocking comments, I think they are easy to
resolve and expect to be able to remove my discuss when that happens.
What an excellent job making PANA easier to understand and removing
complexity."

I would like to especially thank Yoshi, Alper, Raj and Jari for all of 
their hard work and perseverance, and the WG for their patience during 
this process.

But there is still a final hurdle to leap. The IESG ballot (one ballot 
for both documents) detail is here:

https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1723&filename=draft-ietf-pana-framework

There are 3 Discuss positions which need to move to Yes or No-Obj for 
the document to pass. If any one moves to Abstain, then the document 
will be in danger of not passing as there are a number of "open 
positions" here (all documents require 1 Yes and 2/3 of IESG members 
voting Yes or No-Obj).

Dan is asking about SNMP. I understand that we have gone in circles with 
respect to whether SNMP is required to be implemented or not, and it 
looks like the result was confusing to Dan. We either need to revive the 
SNMP document, or kill it off completely in the WG and in these specs.

Magnus has concerns about languages. I remember a review we did with the 
ltru chairs which perhaps we never fully closed the loop on, please 
contact Martin Duerst [email-masked] and Magnus directly to sort 
this out.

Sam seems most concerned about:
- Versioning
- IP address reconfig
- underlying link security
- which messages need an AUTH attribute and which do not, explicitly
- new hash algorithm migration
- discussion in the security considerations, moving some "requirements" 
to "tradeoffs"

I think all of these can be resolved with some discussion and one more 
revision on the text, as such I have moved the documents to Revised ID 
Needed. Once we have a new version which alleviates the concerns listed 
here and the ADs have changed their position to Yes or No-Obj, the 
documents will be approved.

- Mark

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

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 24 Jun 2007 01:32:21 +0300

Hello Mark and Dan,

> SNMP document, or kill it off completely in the WG and in these specs.

The WG was originally scoped to work only on the PaC-to-PAA protocol (PANA).
Later the WG was asked by our previous AD to also define at least one
protocol for the PAA-to-EP leg. We ended up embarking on that work to define
a complete picture. 

Irrespective of the EAP peer (e.g., PaC) to authenticator (e.g., PAA)
protocol (e.g., PANA, PKMv2, IEEE 802.1X, HRPD), there is need for an
authenticator to enforcement point protocol when the two are separated.
Today there are numerous protocols used for that (e.g., R6 in WiMAX, CAPWAP
in WiFi, Rp in 3GPP2, and IETF's upcoming ANCP in DSL). Defining an
architecture-neutral protocol is a good task, but I'd say it's better scoped
as a work item for a separate WG.

For that reason, I'm leaning towards putting that work aside for PANA WG. If
and when IETF decides to tackle generic authenticator to enforcement point
protocol, draft-ietf-pana-snmp can be a useful starting point.

Let's see if there is any objection from the WG.

And Dan, would that (removing pana-snmp references from our documents) an
acceptable resolution to your Discuss comment?

Regards,

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 24 Jun 2007 03:14:02 -0400

Ansering to Magnus Westerlund's comment:

>Magnus Westerlund:
>
>Discuss [2007-06-20]:
>What language is used to provide the declarations present in section 7.2 to 7.7?
>A reference to the defintion of this language is required.

(Mark: I believe this comment is different from the language issue we
discussed in the past about Notification AVP which was removed from
the specification.)

The language used to provide the declarations present in section 7.2
to 7.7 (and 7.1 as well) is ABNF.  We have some text on this in
section 7:

"
   PANA message definitions include a corresponding ABNF [RFC4234]
   specification, which is used to define the AVPs for that PANA message
   type, and whether or not each AVP is Mandatory.  The following format
   is used in the definition:
"

I think we can revise this text to address your comment:

"
   PANA message definitions include a corresponding ABNF [RFC4234]
   specification, which is used to define the AVPs for that PANA message
   type, and whether or not each AVP is Mandatory.  The following format
   is used in the definition described in Sections 7.1 through 7.7:
"

>
>Section 9.
>
>There is unclarity on if IRT is absolute time value or an amount of time. Based
>on the formulas the later, but that is not clear in the text definitions. Also
>the definition of RT is a bit of. RT is the amount of time from the previous
>transmission, while the intitial defintion may mislead one to think it is an
>absolute time.

How about revising the RT and IRT definition as follows?

from:

"
         RT     Retransmission timeout

         IRT    Initial retransmission time
"

to:

"
         RT     Retransmission timeout from the previous (re)transmission

         IRT    Base value for RT for the initial retransmission
"

Also, the following text should be revised:

"
   RT for the first message transmission is based on IRT:

         RT = IRT + RAND*IRT
"

to:

"
   RT for the first message retransmission is based on IRT:

         RT = IRT + RAND*IRT
"

Best Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 24 Jun 2007 03:14:41 -0400

Answering to Lars Eggert's comments:

>Lars Eggert:
>
>Comment [2007-06-20]:
>Section 4.1., paragraph 12:
>>    It is possible that both the PAA and the PaC initiate the PANA
>>    session at the same time, i.e., the PAA unsolicitedly sends the
>>    initial PANA-Auth-Request message while the PaC sends a
>>    PANA-Client-Initiation message.  To resolve the race condition, the
>>    PAA MUST silently discard the PANA-Client-Initiation message received
>>    from the PaC after it has sent the initial PANA-Auth-Request message.
>
>  And what must the PaC do when it receives the PANA-Auth-Request from
>  the PAA that it didn't expect to get in response to its
>  PANA-Client-Initiation message?

In this case, the PaC will think that another PANA session is
initiated by the PAA it did not expect to get in response to its PCI
message.  For that PAA, the following rule in Section 4.1 shall apply:

"
   When the PaC receives the initial PANA-Auth-Request message from a
   PAA, it responds with a PANA-Auth-Answer message, if it wishes to
   continue the PANA session.
"

I think that we can further clarify the text to describe the behavior 
when it does not wish to continue the PANA session as follows:

"
   When the PaC receives the initial PANA-Auth-Request message from a
   PAA, it responds with a PANA-Auth-Answer message, if it wishes to
   continue the PANA session.  Otherwise, it silently discards the 
   PANA-Auth-Request message.
"

>Section 6.1., paragraph 2:
>
>>    For any PANA message sent from the peer that has initiated the PANA
>>    session, the UDP source port is set to any number and the destination
>>    port is set to the assigned PANA port number (to be assigned by
>>    IANA).
>
>
>  "source port is set to any number" - it'd probably be good if the node
>  were able to receive packets sent to that port.
>
>  Also, to make this work, you need to also require that all peers
>  listen on the PANA port.

How about revising Section 4.1 as follows?

from:

"
6.1.  IP and UDP Headers

   Any PANA message is unicast between the PaC and the PAA.

   For any PANA message sent from the peer that has initiated the PANA
   session, the UDP source port is set to any number and the destination
   port is set to the assigned PANA port number (to be assigned by
   IANA).  For any PANA message sent from the other peer, the source
   port is set to the assigned PANA port number (to be assigned by IANA)
   and the destination port is copied from the source port of the last
   received message.  In case both the PaC and PAA initiates the session
   (i.e., PANA-Client-Initiation and unsolicited PANA-Auth-Request
   messages cross each other), then the PaC is identified as the
   initiator.  
"

to:

"
6.1.  IP and UDP Headers

   Any PANA message is unicast between the PaC and the PAA.

   For any PANA message sent from the peer that has initiated the PANA
   session, the UDP source port is set to any number on which the peer
   can receive incoming PANA messages and the destination
   port is set to the assigned PANA port number (to be assigned by
   IANA).  For any PANA message sent from the other peer, the source
   port is set to the assigned PANA port number (to be assigned by IANA)
   and the destination port is copied from the source port of the last
   received message.  In case both the PaC and PAA initiates the session
   (i.e., PANA-Client-Initiation and unsolicited PANA-Auth-Request
   messages cross each other), then the PaC is identified as the
   initiator.  All PANA peers MUST listen on the assigned PANA port
   number (to be assigned by IANA).
"

>Section 7., paragraph 7:
>>    message-name     = PANA-name
>
>  ABNF warning: rule message-name previously referred to as Message-Name

OK, s/message-type/Message-Name/.

Best Regards,
Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 24 Jun 2007 16:53:14 +0300

Hi Sam,

Thank you for the review and comments. Please see below for proposed
resolutions and let us know what you think.

Discuss [2007-06-21]:
First, I'd like to compliment Mark and the PANA working group on the
complexity.

-> Thank you.

What must a receiver do if it receives a PANA message with unknown
version?  How is the version field actually useful?  (How do you get
backward compatibility if you discard packets with unknown version?)

-> I think version number must be updated only when we are about to
introduce an incompatible change. So I think (not sure though), if an
implementation receives a message with an unknown version number, it shall
silently ignore the message. I think a peer with version N+M cannot really
speak to another peer with version N unless the former implementation can
also behave like version N.

-> Does this make sense?

The framework document says that sometimes a PAC is expected to
reconfigure its address after PANA.  The PANA protocol has no
normative discussion of this.  In order to get interoperable
implementations, you need to clearly indicate when address
configuration is required.  Perhaps you are deferring this to future
documents.  If so, then the framework should indicate that unless a
PAC implements a protocol extension that mandates address
reconfiguration and that protocol extension is used, then the PAC need
not do address configuration.  Or, if address reconfig is supported in
the base protocol, you need to have normative language describing it.

-> We had thought about it and even designed an AVP to tell PaC what
mechanism to use for re-configuration. Version 12 of the spec included not
only an indication that the PaC shall reconfigure a new IP address but also
the name of the mechanism to use (DHCPv4, DHCPv6, stateless addr. autconf,
IKEv2, etc.).

-> Then we realized we were stepping outside the scope of the access
authentication, and we decided to remove it. We decided that anything with
IP address configuration is outside the scope. 

-> Would you suggest we re-introduce what we had but only with a one-bit
info that says "PaC shall configure a new IP address" (without enumerating
any specific address config mechanisms)?

The framework document talked about a lot of options having to do with
the underlying link and security.  It seems that the mandatory to
implement behavior from the protocol document is support for integrity
of PANA messages using EAP methods that produce MSKs but no mandatory
to implement support for link security either at layer 2 or 3.  If so,
please make this clear in the framework document.  If not, explain
what I'm missing.

-> That's right. 

-> In the introduction section, we had said:

   PANA is intended to be used in any access network regardless of the
   underlying security.  For example, the network might be physically
   secured, or secured by means of cryptographic mechanisms after the
   successful client-network authentication.

-> How about if we extend it to say:

   PANA is intended to be used in any access network regardless of the
   underlying security.  For example, the network might be physically
   secured, or secured by means of cryptographic mechanisms after the
   successful client-network authentication. While mandatory to
   implement behavior for a PANA deployment is the integrity
   of PANA messages when the EAP method produces MSK, there is no 
   mandatory to implement support for network security either at 
   the link-layer or network-layer.  

Section 5.5 of the protocol document should include a rule that
messages expected to have an auth attribute but which do not do so
MUST be discarded.  You need to specify which messages are expected to
have auth attributes (presumably all of them after a completed
authentication with an EAP method that generates an MSK).

-> We shall change 

   o  When an AUTH AVP is included, the AVP value matches the hash value
      computed against the received message.

-> To

   O  Once the PANA authentication succeeds using a key-generating EAP
      method, the PANA-Auth-Request message that carries the EAP Success
      and any subsequent message in that session contain an AUTH AVP. 
      The AVP value matches the hash value computed against the received 
      message.

Please describe how PANA will migrate to a new hash.  You need a
negotiation mechanism so that one side can determine the capabilities
of the other and so that you can maintain backward compatibility when
deploynig a new hash or PRF.

-> I'll leave that to Yoshi as he's the one who introduced the algorithm AVP
inspired from IKEv2. But in general let me ask: Does that mean we shall let
PAA send "a list of algorithms" and PaC choose one during the very first
PANA message exchange?

I am not sure the algorithm AVP quite gives you this.
Also, you SHOULD protect your negotiation after the fact so that  if an
attacker
modifies the unprotected negotiation then the modification will be detected.

-> We already include the negotiated algorithm in the very first
authenticated PANA message exchange (the one that carries the EAP success
from the PAA to the PaC, and its response). 

I'm particularly concerned that even if the  algorithm AVP is sufficient,
you
recommend against using it unless the link is secured.  That seems highly
problematic; protected negotiation is a better solution.

-> We allow inclusion of the Algorithm AVP in the very first message, so
that in case of a mismatch the PaC can decide not to continue. But in case
the link is not secured, that "early negotiation" is susceptible to
spoofing. So we wanted to warn the deployments. Would you recommend we
remove that warning? And would that not have an impact on the PaCs being
turned down due to a spoofed message?

I am uncomfortable with the claim in the protocol document's security
consideration section that physical security provides protection of
confidentiality and spoofing.  I'm not really sure that is true in any
reasonable sense for DSL lines.  I think a better way to state this is
that the environment provides adequate protection against spoofing and
confidentiality based on the operational needs of the environment.

Similarly, I'm concerned that the blanket claim that if a link does
not provide security then security is required at a higher layer.  I
agree that PANA integrity protection is required, but for example I
don't see why data origin authentication or connectionless integrity
is required for most Internet traffic.  I think the security
considerations section could be reworked to talk a lot more about
tradeoffs and a lot less about hard requirements.
Some hard requirements are probably still necessary.

-> We can remove references to any specific network types (DSL/3GPP2), and
physical vs. cryptographic security.

-> I think what we are really concerned is data origin authentication,
integrity and replay protection (not confidentiality, like the current spec
is saying). Those are important, because they are the primary tools for
enforcement points in policing the data traffic. Unless there is a way to
perform data origin authentication, the enforcement points cannot
distinguish traffic of authenticated clients from unauthenticated clients.

-> Based on these, I'd propose we change

   An important element in assessing security of PANA design and
   deployment in a network is the presence of lower-layer (physical and
   link-layer) security.  In the context of this document, lower-layers
   are said to be secure if they can prevent eavesdropping and spoofing
   of packets.  Examples of such networks are physically-secured DSL
   networks and 3GPP2 networks with cryptographically-secured cdma2000
   link-layer.  In these examples, the lower-layer security is enabled
   even before running the first PANA-based authentication.  In the
   absence of such a pre-established secure channel prior to running
   PANA, one needs to be created after the successful PANA
   authentication using a link-layer or network-layer cryptographic
   mechanism (e.g., IPsec). 

-> To

   An important element in assessing security of PANA design and
   deployment in a network is the presence of data origin authentication, 
   integrity and replay protection by the lower-layers. In some networks,
   this level of security is already enabled even before running the 
   first PANA-based authentication.  In the absence of such a 
   pre-established secure channel prior to running PANA, one needs to be
   created after the successful PANA authentication using a link-layer or
   network-layer cryptographic mechanism (e.g., IPsec).

I am uncomfortable with the recommendation of eap methods like md5
even when link security is available.  Can you please work with the
EAP and EMU working groups and see if they support this recommendation
in the framework document?

-> We didn't really mean to recommend use of any EAP method. For that, we
shall remove the statement "For example, weak authentication methods, such
as EAP-MD5, may be used for such networks but not for the others." 

Comment [2007-06-21]:
The PANA protocol document says that the derivation of keys for use in
setting up or binding to link or layer 3 security is out of scope.
That's fine and probably even a good idea.  however there needs to be
a single document that specifies this derivation that all the uses of
the PANA SA end up referring to.  IT would be inappropriate for the
PANA IPsec document to use one method and say a method to set up
preshared secrets for 802.11I to use another mechanism that might
interact badly with the ipsec mechanism.

-> Would the following take care of this?

-> Currently

PANA_AUTH_KEY = prf+(MSK, PaC_nonce|PAA_nonce|Session_ID|Key_ID)

-> We could change this to:

PANA_AUTH_KEY = prf+(MSK, PaC_nonce|PAA_nonce|Session_ID|Key_ID)
PANA_SECASSOC_KEY = prf+(PANA_AUTH_KEY, Key_Name)

-> The PANA_SECASSOC_KEY SHALL be used as the root key for any secure
association key management for securing link-layer or network-layer. Key_
Name is a string and it SHALL be assigned by a separate specification that
describes how PANA-generated keys are used with the specific secure
association protocol (e.g., "SECURE ASSOCIATION ROOT KEY FOR IKE-IPSEC",
"SECURE ASSOCIATION ROOT KEY FOR IEEE 802.11I".) 

-> We also need to change Section 11.5 accordingly (last sentence
especially).

-> Does this make sense?

Thank you.

Alper

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Jun 2007 13:46:14 +0200

> to 7.7 (and 7.1 as well) is ABNF.  We have some text on this in

If it intends to be ABNF according to RFC 4234 then you need to address
the definitions. RFC 4234 ABNF does not allow for the "::=" in
declarations. So please add the clarification that it is ABNF for all
these sections and ensure that it really is ABNF and passes a parser,
like Bill's:
http://rtg.ietf.org/~fenner/abnf.cgi

I think the changes for retransmission will address my issue..

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 25 Jun 2007 08:26:38 -0400

Thank you for your response.

I see what you mean.  

As you pointed out, the defined language itself is not really ABNF (I
apologize that my statement in my previous email was incorrect.)

So the correct statement should be that the language used in sections
7.1 through 7.7 is defined in section 7 using ABNF (that is why the
defined language contains "::=" while ABNF does not.)

So the third paragraph in Section 7 should be revised 

from:

"

to:

"
   The language used for PANA message definitions (i.e., AVPs for that
   PANA message type, and whether or not each AVP is Mandatory) in
   Sections 7.1 through 7.7 is defined using ABNF [RFC4234] as
   follows:
"

I also checked the language definition against Bill's ABNF parser
(thank you for the URL), and found some minor correction.  I'll fix
it as well.

I'll also reflect the changes regarding retransmissions.

I hope all of your issues are addressed now.

Yoshihiro Ohba

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Jun 2007 15:08:07 +0200

>    Sections 7.1 through 7.7 is defined using ABNF [RFC4234] as

I didn't fully understand what you attempted to do. However, I think
there are still some flaws in the definition of the language used in
section 7.1-7.7.

The white spaceing rules are missing. you have nothing thatindicates
that for example "[  EAP-Payload ]" is allowed, while  [EAP-Payload]
would. Also line breaks need to be handled.

Cheers

Magnus Westerlund

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 25 Jun 2007 10:20:28 -0400

I agree with Sam's suggestion.  My detailed analysis and remedy is
shown below.

It is true that in the current PANA specification, neither the PAA
offers multiple choices of algorithms nor the PaC is allowed to tell
the PAA the algorithms it supports.  The PAA forces the PaC to use a
single set of algorithms (one for integrity algorithm and the other
for PRF) in a particular PANA session.  In that sense, there is no
algorithm negotiation mechanism defined for PANA.  The PAA can
indicate which set of algorithms needs to be used by the PaC in the
first (unprotected) PANA-Auth-Request message so that the PaC can
decide to continue the PANA session, but this is not a full algorithm
negotiation.  I fully understand Sam's concern on how a smooth
migration from an old algorithm to a new one can be done.

I think we should follow Sam's suggestion to define a mechanism for
algorithm negotiation.  As Sam commented, this requires a mechanism to
protect the negotiation (after a PANA_AUTH_KEY is generated) to make
sure we don't introduce a bidding down attack here.  (Note that in a
bidding down attack, an attacker can modify the list of algorithms
offered by the PAA to swamp the PaC to agree upon a weaker algorithm).
Here is how it works without adding much complexity.

[1] Split Algorithm AVP into two: Integrity-Algorithm AVP and
PRF-Algorithm AVP, where each AVP contains a single Unsigned16 integer
value.

[2] The algorithm negotiation is performed in the initial PAR-PAN
exchange (with the 'S' bit set).  When a PANA SA is needed, the
initial PAR MUST contain one or more Integrity-Algorithm AVPs and one
or more PRF-Algorithm AVPs supported by the PAA.  The initial PAN sent
in response to such a PAR contains only one Integrity-Algorithm AVP
and only one PRF-Algorithm AVP supported and chosen by the PaC.

[3] When a PANA SA is needed, in the final PAR-PAN exchange of the
authentication and authorization phase (with 'C' bit set), the PAR
contains only one Integrity-Algorithm AVP and only one PRF-Algorithm
AVP chosen by the PaC in the initial PAR-PAN exchange.  The AUTH AVP
contained in such PAR and PAN messages is computed differently than
that of other messages to include the initial (unprotected) PAR-PAN
exchange as follows:

      AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU, 
      PANA_PDU_for_initial_PAR, PANA_PDU_for_initial_PAN)

For other messages, AUTH AVP value is computed in the same way as 
defined in the current specification:

      AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU)

This way, even if an attacker alters the list of algorithms in the
initial unprotectged PAR, the alteration can be detected in the final
PAR/PAN exchange.  This mechanism would also allow future extention to
PANA to allow other types of negotiations to be peformed in the
initial PAR/PAN exchange and then protected in the final PAR/PAN
exchange.

Best Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 25 Jun 2007 10:43:23 -0400

OK.  We will add explicit rules for white spaceing and line breaks in
the language definition.

Thank you very much,
Yoshihiro Ohba

---

From: Mark Townsley <[email-masked]>
Date: Mon, 25 Jun 2007 19:07:32 +0200

> any specific address config mechanisms)?
Sam, the notification of an IP address change in the PANA protocol 
itself was among the items that we removed in order to reduce PANA's 
complexity. If the IP address changes for some reason, whether it is 
configured via DHCP, SA, IKE, IPCP, or manually, PANA would need to 
react like any other protocol that would be affected (e.g., TCP) by 
this. I believe we discussed that ending the current session and 
restarting PANA would be a perfectly reasonable thing to do, but not 
certain that this made it into the text.

You suggest that PANA try and indicate when address configuration is 
required. Trying to enumerate this is due to the number of environments 
PANA wishes to applicable in and the number of ways an address may be 
configured sends the author and the reader out into the weeds rather 
quickly. Rather, I believe in the base framework and protocol spec it is 
sufficient to say that the IP address may change, and if it does PANA 
needs to know this and may need to restart. Specific "PANA with Foo" 
specifications may make this recommendation more precise if need be.

- Mark

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Tue, 26 Jun 2007 02:40:59 +0200

I think that this could be clarified saying that the IP address reconfiguration would be not required by the PANA protocol itself but by some network configurations or any other reason outside the PANA scope. The requirement would not be on the PaC but on the node hosting the PaC (actually the IP address is allocated to the node).

BR,

Lionel 

> -----Message d'origine-----
> De : Mark Townsley [mailto:[email-masked]] 
> Envoyé : lundi 25 juin 2007 19:08
> À : Alper Yegin
> Cc : 'Jari Arkko'; 'Sam Hartman'; [email-masked]
> Objet : [Pana] Re: Sam's IESG comments
> 
> Alper Yegin wrote:
> > mechanism to use for re-configuration. Version 12 of the 
> spec included 
> > not only an indication that the PaC shall reconfigure a new 
> IP address 
> > but also the name of the mechanism to use (DHCPv4, DHCPv6, 
> stateless 
> > addr. autconf, IKEv2, etc.).
> >
> > authentication, and we decided to remove it. We decided 
> that anything 
> > with IP address configuration is outside the scope.
> >
> > -> Would you suggest we re-introduce what we had but only with a 
> > -> one-bit
> > info that says "PaC shall configure a new IP address" (without 
> > enumerating any specific address config mechanisms)?
> >   
> Sam, the notification of an IP address change in the PANA 
> protocol itself was among the items that we removed in order 
> to reduce PANA's complexity. If the IP address changes for 
> some reason, whether it is configured via DHCP, SA, IKE, 
> IPCP, or manually, PANA would need to react like any other 
> protocol that would be affected (e.g., TCP) by this. I 
> believe we discussed that ending the current session and 
> restarting PANA would be a perfectly reasonable thing to do, 
> but not certain that this made it into the text.
> 
> You suggest that PANA try and indicate when address 
> configuration is required. Trying to enumerate this is due to 
> the number of environments PANA wishes to applicable in and 
> the number of ways an address may be configured sends the 
> author and the reader out into the weeds rather quickly. 
> Rather, I believe in the base framework and protocol spec it 
> is sufficient to say that the IP address may change, and if 
> it does PANA needs to know this and may need to restart. 
> Specific "PANA with Foo"