Subject: [Pana] Other suggestions for pana-pana

From: Mark Townsley <[email-masked]>
Date: Thu, 05 Oct 2006 15:30:21 +0200

I have been spending a lot of time reviewing your documents and raising 
a lot of issues on the PANA specification. Thank you for your responses, 
and please understand that my goal is to help the group produce 
something that is more palatable to the community at large. I am 
focusing largely on issues of complexity and layer violation, based on 
feedback I have seen from the IETF LC and my own analysis of what I 
think this protocol needs in order to succeed (in the marketplace as 
well as when I take it to the IESG to become a Proposed Standard).

This email includes what I believe to be the final list of topics that I 
would like discussed and acted upon in some way for the next revision of 
the pana-pana specification. Some are nits, some are significant issues. 
They are presented as the associated text occurs in the document from 
beginning to end. Note that I have not yet reviewed the Appendices of 
pana-pana, nor the pana-framework document.

Thanks,

- Mark

In the Introduction:

Please delete the following sentence, it will seem odd to someone 
reading this as an RFC in the future (and could even be factually 
debated today).
> Currently there is no standard network-layer solution for 
> authenticating clients for network access.
The 3rd paragraph of the Introduction claims that PANA is link-layer 
agnostic. It may be to a large extent, but (unfortunately) it is not 
entirely in the form I see in this document. Either this paragraph needs 
to be rewritten,  admitting that it is an overstatement to claim that 
PANA permits EAP to work with "any link-layer technology" straightaway, 
or this document needs to truly abolish its ties to L2 - Including L2 
Device parameters (such as MAC addresses, "local identifiers" that rely 
on point-to-point links to make sense), "Protection Capability" defined 
by lower layers, etc. I would *strongly* recommend the elimination of 
all L2 ties, leaving PANA to Network Layer only authentication and 
access alone.

End of Section 1:

"filter rule installation," is identified as out of scope. As discussed 
on the list and with the chairs on the phone, this isn't entirely true 
when an IP address as a Device ID is communicated via PANA and used to 
permit packets with that Source IP address to flow after authentication 
occurs. This is a filter. A very simple one, but a very important one. 
Thus, I don't think that this statement is factual in its current form.

The above two issues are related. If PANA would eliminate trying to 
operate on L2 access controls, and rely solely on an IP Address and 
associated filter, then it would truly be a Network Layer authentication 
and Network Layer access protocol. I believe this would go a very long 
way to eliminate confusion over where PANA can add value. I cannot 
understate this enough.

Nit: s/go through/read

Section 2:

Nit: s/be also/also be

The definition of "Device Identifier" here makes it patently clear that 
there is a tie between PANA and L2, and the use of the DI to setup 
filters. Both items that are declared out of scope in the introduction. 
This needs to be resolved.

Please expand MSK 

Section 4.3:

Nit: s/specificaiton/specification
Nit: s/the send cookie/the sent cookie

Section 5.2:

You say:
>  When
>    available, the cached answer can be used instead of fully processing
>    the retransmitted request and forming a new answer from scratch.
But:
>
>    PANA MUST NOT generate EAP message duplication.  EAP payload of a
>    retransmitted PANA message MUST NOT be passed to the EAP layer.
I'm not sure what the last sentence means, but with all these capital 
letters it
must be important. At first glance, the two statements above seem to be 
in conflict with one another.  Are you saying that any message carrying 
EAP payloads must not be retransmitted? Are you saying that if they are 
retransmitted, that this should somehow be detected and the EAP payload 
dropped internally before being processed by EAP? This needs to be make 
more clear.

Section 5.8: If the PaC updates its IP address, shouldn't the PAA (or 
EP) be changing its filter somehow? I see no mention of this.

Section 6.3:

> AVP Code
>
>       The AVP Code, combined with the Vendor-Id field, identifies the
>       attribute uniquely.  AVP numbers are allocated by IANA [ianaweb].
>       PANA uses its own address space for this field although some of
>       the AVP formats are borrowed from Diameter protocol [RFC3588].

In the above text, since the Vendor ID field is optional, 
it is really the AVP Code, the V-bit, and the Vendor ID 
(you left out the V-bit) that identifies the attribute uniquely. 
I think you should underscore the fact that the Vendor ID is optionally 
present in the header. As an aside, if I were doing this, it 
wouldn't be optionally present, but simply set to zero for IETF 
AVPs, but perhaps you had a reason for this type of encoding.

Possible New Text:

The AVP Code, together with the optional Vendor ID field, identifies
attribute that follows. If the V-bit is not set, the Vendor ID is not
present and the AVP Code refers to an IETF attribute.

Section 8:

I understand that "OctetString" and "Unsigned32" comes from RFC3588, but 
please make that more clear somewhere early in the document. A specific 
reference to section 4.2 itself of RFC 3588 could be a good idea. 
Something like, "This documentuses AVP Data Format such as 'OctetString' 
and 'Unsigned32' as defined in Section4.2 of [RFC3588]. The definitions 
of these data formats are not repeated in this document."

Could the Nonce and Cookie AVPs be the same? Why do you need *two* 
random value AVPs? Particularly if, as being discussed on another 
thread, the handshake phase was eliminated, perhaps you only need one 
random value AVP.

Section 8.11 - Language tags can be a touchy subject. I have asked for a review of
this section.

Section 8.12:

>    o  PPAC AVP: Post-PANA-Address-Configuration AVP.  Used to indicate
>       the available/chosen IP address configuration methods that can be
>       used by the PaC after successful PANA authentication.

Why does PANA need to control or announce this policy/capability? 
Once authentication is finished, the PaC or PAA should be able to issue a DHCP 
Inform or do whatever it likes to obtain a new IP address, and it is up to
the policy of that protocol to be rejected or not. This kind of 
"list of possible other protocols you can run after PANA" creates layer 
bindings that I don't think you want the PANA protocol to have to maintain. 
What if the IP address is being allocated by IPCP? What about some future
version of IKE or some other configuration? What about some other 
type of tunnel that can configure IP addresses? I don't see the advantage
of constraining yourself here, or poking into the rest of the IP stack
in this manner.

8.13: The "Protection Capability" AVP is another layer violation. Why does the 
PANA protocol itself care about what kind of a connection it is running over? 
At the system level you may be concerned, but why within PANA itself? What if
you are using something other than IPsec (DTLS? SSL? etc?)? Do you really 
want to maintain all of the possibilities here? To what gain?

8.14 and 8.15 It is unclear here what "the provider" is supposed to be.

8.17:

> The Session-Id MUST be globally and eternally unique, as it is meant 
> to identify a PANA session without reference to any other information, 
> and may be needed to correlate historical authentication 
Globally and eternally unique? This is a tall order. First, I don't think 
you mean "Global" here as that implies an global allocation system. Also, 
I don't think you mean "eternal" as that literally means forever. 

Realistically, this number is Global to a given PAA or PaC, and effort
should be made to not repeat Session IDs over a certain period of time.

If you really want an AVP for logging, you could consider a "serial number"
AVP that is monotonically increasing and saved across reboots, tied to 
a system clock, etc. but not actively used to lookup state for a given 
session.

10.2.1 Message Type

Why only 2 experimental message types? It would seem that if you are going
to specify and allow such an experimental range, you should grant a useful 
number of values, no?

Section 10.3.1

Section 6.3 does not mention that the Vendor-ID value of zero can be used for 
IETF assigned AVPs. The IANA considerations section is *not* the place to
defined such functionality for implementations!

>    The absence of a
>    Vendor-ID or a Vendor-ID value of zero (0) identifies the IETF IANA
>    controlled AVP Codes namespace.

Please choose one or the other and stick to it. Either the V bit indicates that
the Vendor ID and attribute indicate a vendor-specific value, or just use
zero in the Vendor ID field for IETF values. I think the latter is probably
better only because it is simpler to not have optional fields. But, please choose
*one* 

Also, please give IANA an indication of the size of the AVP Code, this is missing.

> Release of blocks of AVPs (more than 3 at a time for a given purpose) 
> should require IETF Consensus. 
Why 3? Why at all? You have 64K of these, and any Expert Reviewer worth his salt 
should be able to detect when these values are being abused. I fear that
this could cause folks to "design around" the restriction by encoding subtypes
with a single AVP, which doesn't help anyone. Not to mention that this kind of
rule is just one more variation on a theme for IANA to have to keep up with. 

10.4.1

I think having such an AVP is not a good idea, and making it a Standards Action
to assign a new value makes it even worse. You never know what is going
to come along in the future than might allow an IP address assignment after
PANA runs, and frankly PANA shouldn't care *how* it happens, just that it
get notified that it was done.

10.4.2 

I can make much the same argument here as for 10.4.1.

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 5 Oct 2006 16:22:11 -0400

> >authenticating clients for network access.

I agree with removing the above sentence.

> all L2 ties, leaving PANA to Network Layer only authentication and 

I have a problem with the elimination of all L2 ties, as I mentioned 
earlier (i.e., use of MAC address as device identifier (i) can
simplify access control of devices with multiple IP addresses and (ii)
is needed for bootstrapping link-layer security).  Thus, I'd suggest 
keep L2 ties but revising the 3rd paragraph of the Introduction something like:

"
   Scope of this work is identified as designing a network layer 
   transport for network access authentication methods.  The Extensible
   Authentication Protocol (EAP) [RFC3748] provides such authentication
   methods.  In other words, PANA will carry EAP which can carry various
   authentication methods.  By the virtue of enabling transport of EAP
   above IP, any authentication method that can be carried as an EAP
   method is made available to PANA and hence to any link-layer
   technology with a minimum link-layer dependency.  There is a clear
   division of labor between PANA (an EAP lower layer), EAP and EAP
   methods as described in [RFC3748].
"

> Thus, I don't think that this statement is factual in its current form.

OK.  How about changing the first sensence of the last paragraph of
Section 1 as follows?

"
   There are components that are part of a complete secure network
   access solution but are outside of the PANA protocol specification,
   including IP address configuration, authentication method choice,
   detailed filter rule installation other than use of device
   identifiers as filtering parameters, data traffic protection,
   PAA-EP protocol and PAA discovery.  
"

> way to eliminate confusion over where PANA can add value. I cannot 

This is fundamental difference in how we view PANA.  I don't consider
PANA as "Network Layer access protocol" while I only consider PANA as
a network layer protocol for carrying authentication information for
network access.

> Nit: s/go through/read

OK.

> Nit: s/be also/also be

OK.

> This needs to be resolved.

What do you think about the suggested changes for Introduction I made 
earlier in this email?

> Please expand MSK 

OK.

> Nit: s/the send cookie/the sent cookie

OK.

> dropped internally before being processed by EAP? This needs to be make 

The latter is the meaning the text is trying to convey.  Perhaps we
can rephrase something like:

"
  PANA MUST NOT generate EAP message duplication.  EAP payload of a
  retransmitted PANA message MUST be detected using Sequence
  Number field of PANA header and the EAP payload contained in the
  duplicate PANA message MUST be silently discarded internally before being
  processed by EAP. 
"

> EP) be changing its filter somehow? I see no mention of this.

You are right.  How about changing the last paragraph of Section 5.8 to:

   After the PaC has changed its IP address, it MUST send a PANA-Update-
   Request message to the PAA.  If the PaC has also changed its device
   identifier, the PANA-Update-Request message MUST include a Device-Id
   AVP containing the new device identifier.  The PAA MUST update the
   PANA session with the new PaC address carried in the Source Address
   field of the IP header and the new device identifier carried in the
   Device-Id AVP, return a PANA-Update-Answer message and update EPs 
   with the new device identifier.  The PANA-
   Update-Answer message MUST contain one or more Device-Id AVPs for the
   EPs if the set of EPs serving the PaC has also changed.  If there is
   an established PANA SA, both PANA-Update-Request and PANA-Update-
   Answer messages MUST be protected with an AUTH AVP.

> AVPs, but perhaps you had a reason for this type of encoding.

The main reason is to save 4 octets for standard AVPs.

> present and the AVP Code refers to an IETF attribute.

I agree with the new text.

> of these data formats are not repeated in this document."

Yes, your suggested text looks better.

> thread, the handshake phase was eliminated, perhaps you only need one 

Nonces are generated by both entities for increasing randomness in key
generation, while cookie is generated by PAA only (PaC is just echoing
the received cookie).  So nonce and cookie AVPs cannot be the same.

> Section 8.11 - Language tags can be a touchy subject. I have asked for a 

OK, I will be waiting for the review.

> Once authentication is finished, the PaC or PAA should be able to issue a 
> DHCP Inform or do whatever it likes to obtain a new IP address, and it is 
> up to

If we don't define PPAC AVP, how the PaC can/should choose the IP
address method for obtaining POPA address?

> 
> 8.13: The "Protection Capability" AVP is another layer violation. Why does 
> the PANA protocol itself care about what kind of a connection it is running 
> over? At the system level you may be concerned, but why within PANA itself? 
> What if

Similar question: If we don't define Protection-Capability AVP, how
the PaC can/should know which layer security needs to be bootstrapped?

BTW, we are not supposed to bootstrap L4 or higher-layer security
using PANA.  We only deal with bootstrapping L2 or L3 security.  We
only deal with IPsec for L3 security.  For L2 security, L2 security
types can be determined by the underlying link-layers.

> 8.14 and 8.15 It is unclear here what "the provider" is supposed to be.

This is NAP or ISP.  

BTW, after my recent experience with IEEE 802.21 work, I have realized
that use of "SMI Network Management Private Enterprise Codes" as
Provider-Identifier AVP is not so useful in the real world.  In fact,
802.21 uses the combination of operator namespace and operator name
that is is defined in draft-ietf-geopriv-radius-lo-10.txt for
identifying a operator.

> a system clock, etc. but not actively used to lookup state for a given 

There is one usage of Session-Id across multiple PAAs, which is
defined in pana-mobopts draft (the I-D has been expired), in which
case global uniqueness across multiple PAAs is important.

> to specify and allow such an experimental range, you should grant a useful 

We can certainly extend the experimental space to allow 16 message
types.

> 
> 
> Section 10.3.1
> 
> Section 6.3 does not mention that the Vendor-ID value of zero can be used 
> for IETF assigned AVPs. The IANA considerations section is *not* the place 
> to

We should choose the former, i.e., 

"
The absence of a Vendor-ID identifies the IETF IANA controlled AVP Codes namespace.
"

> Also, please give IANA an indication of the size of the AVP Code, this is 

OK.

> Why 3? Why at all? You have 64K of these, and any Expert Reviewer worth his 
> salt should be able to detect when these values are being abused. I fear 
> that

This is copied from RFC 3588.  I don't know the reason of 3, but I
don't have a problem with requring IETF Consensus even for every
non-vendor-specific AVP.

> I can make much the same argument here as for 10.4.1.

Please see my above comments on PPAC and Protection-Cap. AVPs.

Regards,
Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 6 Oct 2006 15:26:08 +0300

> > something that is more palatable to the community at large. 

Thanks a lot, your help is appreciated.

> > PANA permits EAP to work with "any link-layer technology" straightaway,

But it does. Do we have to add any new bits, fields, or even logic to the
PANA protocol to accommodate a specific L2?

I've been trying to understand the issue. The mere fact that a protocol
carries info that pertains to a lower layer should not take away its lower
layer independency, especially when the content of the data is not
interpreted in any way by the transporting layer.

Good examples are DHCP, Neighbor Discovery, even IKE (a transport layer
carrying network layer addresses). 

> I have a problem with the elimination of all L2 ties, as I mentioned

I agree with this with device IDs in mind. I'll respond the
Protection-Capability in a separate thread.

>    technology with a minimum link-layer dependency.  There is a clear

I don't even know what that "dependency" is.

>    methods as described in [RFC3748].

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 6 Oct 2006 15:41:30 +0300

> > Thus, I don't think that this statement is factual in its current form.

Filter rule creation is different than filter rule installation. The former
involves identifying the rules (e.g., allow packets with source IP ==
64.236.10.20), the latter involves sending the filters from where they are
created (partially or fully) to where they will be used (e.g., from PAA to
EP).

>    PAA-EP protocol and PAA discovery.

So, I'd rewrite this paragraph as:

    There are components that are part of a complete secure network
    access solution but are outside of the PANA protocol specification,
    including IP address configuration, authentication method choice,
    data traffic protection, PAA-EP protocol, and PAA discovery. PANA
    authentication output is used for creating access control filters. But
    creation of fine-granularity filters and their installation on 
    the enforcement elements are outside the scope as well.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 6 Oct 2006 15:54:14 +0300

> a network layer protocol for carrying authentication information for

This is a terminology issue, I believe.

As we said in RFC 4058:

   After a device is authenticated by using PANA, it MUST be authorized
   for "network access." That is, the core requirement of PANA is to
   verify the authorization of a PaC so that PaC's device may send and
   receive any IP packets.

So, PANA authenticates for (and used for authorization of) "network access."

Execution of access control is orthogonal to PANA authentication. A network
can choose to change IP filters to allow traffic from authenticated client,
change L2 filters to do equivalent, or even do some L1 filtering. 

At the end, what's really allowed/disallowed is the IP network access.

I hope this clarifies.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 6 Oct 2006 15:58:37 +0300

>   duplicate PANA message MUST be silently discarded internally before

Why do we care about this? EAP can handle duplicates. 

Can we get rid of this special handling?

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 6 Oct 2006 16:08:28 +0300

> address method for obtaining POPA address?

The answer to that could be "how does any host choose it today?"
Meaning, maybe this is not our problem.

I wonder if there is any PANA-specific aspect here that suggests us solving
this "discovery and selection" problem for the PaCs.

One thing though... In case the PRPA and POPA are different (a PANA aspect),
the PAA still needs to tell the PaC to configure POPA. Maybe all we need is
one bit of information (a Boolean).

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 6 Oct 2006 16:12:56 +0300

> the PaC can/should know which layer security needs to be bootstrapped?

Similar to my feedback on the earlier comment, maybe this is not our problem
either. Unless we identify some PANA-specific aspect here, we may not have
to solve this problem as well.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 6 Oct 2006 16:16:24 +0300

> > should be made to not repeat Session IDs over a certain period of time.

This "global and eternal" term is coming from RFC 3588 where session-ID is
defined. Note that, this ID includes the PAA ID, hence it is not per-PAA.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 06 Oct 2006 09:58:59 -0400

You are right.  I think we can remove the last paragraph of Section 5.2.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 06 Oct 2006 10:07:43 -0400

OK, it seems that we can safely say that it's not our problem.  I am
fine with reducing the information to just one bit (perhaps in PANA
header?) to indicate POPA acquisition is needed.

Yoshihiro Ohba

---

From: Mark Townsley <[email-masked]>
Date: Fri, 06 Oct 2006 16:27:03 +0200

> created (partially or fully) to where they will be used (e.g., from PAA to
Wouldn't that be the PAA-EP protocol? That is listed separately in the 
same paragraph.
>     the enforcement elements are outside the scope as well.
OK, in the first part you have simply removed "filter rule 
installation"- I agree that helps. I don't think you need the extra 
sentence at the end though. Read without context of this discussion, it 
raises more questions than answers (what does "fine-granularity" mean, 
for example; a single filter on a single IP hostroute sounds pretty 
"granular" to me!).

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Fri, 06 Oct 2006 16:27:42 +0200

> PANA protocol to accommodate a specific L2?
Yes, you have a MAC address, reference to L2-encryption, IPsec, ND, 
DHCP, etc. You are poking into a variety of different places in the 
stack (not just L2). Each time you do this, you remove the "agnostic" 
behavior that you claim to have. I'm looking for "Truth In Advertising" 
here.

The way PANA is positioned, you may need all these hooks to have a 
useful functioning system, but you cannot make wild claims of 
agnosticism and still have protocol constructs that clearly have to be 
updated and tracked based on a variety of things outside of PANA.
> interpreted in any way by the transporting layer.
Each bit of information about anything other than PANA that you carry, 
is a link to another part of the stack that reduces the modularity of 
the protocol.
> carrying network layer addresses). 
IKE, as an IP tunneling protocol, configures an IP address and carries 
packets for that IP address, making it look like its own data-link layer 
to the tunneled packets. ND has to carry a MAC address as it is the 
actual glue between IP and the link-layer. In any case, DHCP, ND, ARP, 
etc. do not make claims that they can work over "any link-layer" 
technology. In fact, it is up to the individual link-layers to be sure 
that DHCP and ND (or ARP, etc) work, not the other way around. We 
charter whole working groups to make ND and ARP work over a given 
link-layer. ND and DHCP do not claim they work with any link-layer 
technology, that's up to the link-layers to decide and work out.

> Protection-Capability in a separate thread.

Like I said, at a minimum, if you keep this capability you have to be 
honest and state that you are hooking yourselves to L2, while operating 
at L3.  I think it is a mistake to do this, and doing so will only make 
it more difficult for your protocol to succeed as it adds complexity for 
little gain.
> I don't even know what that "dependency" is.
Your text, not mine :-)

I think it is accurate to say that the link-layer dependency is reduced 
via PANA, but it is not eliminated. Also, nothing is for free, and the 
engineering tradeoff here is requiring filtering at L3 (if nothing else 
to allow PANA packets to flow before authentication) and use of IP 
addresses before authentication occurs (something that may or may not be 
important operationally).

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Fri, 06 Oct 2006 16:27:10 +0200

> So, PANA authenticates for (and used for authorization of) "network access."
"Network" access to me means access to send "Network" packets, which is 
synonymous  to "IP packets" in the statement above. Expanded a bit, I 
believe the intent here is to say that:

PANA authenticates a PaC so that it can be authorized by a PAA to 
install filters on an (colocated or separate) EP that permits IP packets 
to flow to or from a PaC on a given network. I see nothing in that 
statement that requires L2 or L1 specifics. Since the EP probably 
already has to filter at the network layer simply to permit/deny the 
PANA packets themselves onto the network, it is perfectly reasonable to 
assume that enforcement may be done at L3. Doing so, reduces the 
complexity of your problem dramatically, and I believe puts PANA in a 
place that most people will be able to readily understand.
> change L2 filters to do equivalent, or even do some L1 filtering. 
Which is where you get into the layer violations that people get 
concerned about, and why your protocol ends up looking more complex than 
it need be. Stick to "Network Access" and you are fine. Move down into 
"Data Link Access" and you start putting the cart before the horse, and 
open yourself up to an array of complexities by looking downward into 
the stack.
> At the end, what's really allowed/disallowed is the IP network access.
If you allow this type of logic, I could say that in the end what is 
really allowed/disallowed is email access. If you are carrying PANA 
packets on the network, by definition you already have at least some 
level of data-link and Network (IP) connectivity. I honestly believe 
that trying to manipulate L2 and L1 via PANA is becoming a burden that 
may, in the end, sink the entire ship.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Fri, 06 Oct 2006 16:27:45 +0200

Yoshihiro Ohba wrote:
> Similar to PPAC discussion, I think we still need one bit to indicate
> that protection is needed.  Actual protection layer can be known from
> the Address Family information in EP's Device-Id in PBR.
>   
Does the "protection needed" bit really need to be defined in the
protocol? Where is the policy for this need of protection located and
who initiates the protection? If they can be in the same place (on the
same device), then the PAA and PaC do not have to communicate this in
the PANA protocol.

- Mark
> Yoshihiro Ohba
>
>
> On Fri, Oct 06, 2006 at 04:12:56PM +0300, Alper Yegin wrote:
>   
>>>> 8.13: The "Protection Capability" AVP is another layer violation. Why
>>>>         
>>> does
>>>       
>>>> the PANA protocol itself care about what kind of a connection it is
>>>>         
>>> running
>>>       
>>>> over? At the system level you may be concerned, but why within PANA
>>>>         
>>> itself?
>>>       
>>>> What if
>>>> you are using something other than IPsec (DTLS? SSL? etc?)? Do you
>>>>         
>>> really
>>>

---

From: Mark Townsley <[email-masked]>
Date: Fri, 06 Oct 2006 16:27:58 +0200

Alper Yegin wrote:
>>> Globally and eternally unique? This is a tall order. First, I don't
>>>       
>> think
>>     
>>> you mean "Global" here as that implies an global allocation system.
>>>       
> Also,
>   
> defined. 
I do see that now, and don't believe it is the best reference to go by. 
Aside of what this document said when we published it in 2003, Webster 
says this:

http://www.webster.com/dictionary/eternally

No reason to propagate such confusing uses of a term.

> Note that, this ID includes the PAA ID, hence it is not per-PAA.
Forgive me for asking, but who assigns the PAA ID, and is *that* 
supposed to be global?

- Mark

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 06 Oct 2006 10:10:42 -0400

Yoshihiro Ohba

---

From: Mark Townsley <[email-masked]>
Date: Fri, 06 Oct 2006 16:54:04 +0200

>    methods as described in [RFC3748].
Somewhere, I think you need to mention that, also by virtue of carrying
PANA over IP, that the link-layer needs to be able to carry PANA IP
packets and no other until authorization is complete. Is this covered
anywhere in the document? I think it is a very important point. Perhaps
this will be covered with text describing local filter installation is
complete?

>    PAA-EP protocol and PAA discovery.  
I do not think "detailed filter rule installation" helps, as it leaves
the reader wondering what is detailed and what is not detailed.

If you can come out and admit that PANA does sanction the ability to
open and close a simple set of filters, including (at a minimum, as
there may be other IP protocols (e.g., DHCP, even SIP) that you may wish
to allow before authorization is complete):

Permit PANA traffic to/from a PAA/PaC, Deny all other traffic.
Permit all traffic to/from a PaC.

I need to think a bit more about how in the world you reliably handle
the first filter if you allow UDP ports to move off a well-known
destination. I think it becomes far more difficult, particularly for
equipment that may be snooping PANA and opening or closing its own
filters accordingly (something that is quite common in similar
situations on DSL networks, for example).
> a network layer protocol for carrying authentication information for
What is "network access" - to me, "network" is at Layer 3. This isn't
the Protocol for Authenticating Data Link Access!
> What do you think about the suggested changes for Introduction I made 
We're getting there, but I need to see it in context with other changes
to be sure.
>   duplicate PANA message MUST be silently discarded internally before being
Perhaps this can be removed, as per Alper's suggestion in another email.
>    Answer messages MUST be protected with an AUTH AVP.
Assuming "update the EPs with the new device identifier" means "install
a filter accordingly" in turn, then I suppose this is OK. But, there is
still a lot of text missing on how to update those filters (for a
colocated EP, which I think this document should cover at least).
> The main reason is to save 4 octets for standard AVPs.
Like I said, the gain to me isn't worth the complexity, but it's not a
sticking point for me. What is important is that you don't imply that
there are two ways to do this, as I saw in the IANA considerations section.
> the received cookie).  So nonce and cookie AVPs cannot be the same.
Understood, thanks.
> OK, I will be waiting for the review.
I have the response, coming in a separate email.
> address method for obtaining POPA address?
However it likes, the point is whether this needs to be conveyed in the
protocol. I'll await resolution on the thread Alper initiated.
> that is is defined in draft-ietf-geopriv-radius-lo-10.txt for
Perhaps you can remove all of this then?
> case global uniqueness across multiple PAAs is important.
I think this adds significant complexity. Walk before you can run. Deal
with truly global unique Session Ids if and only if the mobopts work
becomes a reality. So, in that draft, you state something like "In
[pana-pana] the Session ID is unique for a given PAA. The mechanism
defined in this document requires that the Session ID be unique across
the set of PAAs operating within the mobile administrative domain. In
order to obtain a unique Session ID, the PAA. consults... is configured
with... etc." - and cross that bridge when you get to it.
> We can certainly extend the experimental space to allow 16 message
That seems more useful.
> The absence of a Vendor-ID identifies the IETF IANA controlled AVP Codes namespace.
As long as there is only one way to do it, that is fine.
> don't have a problem with requring IETF Consensus even for every
That's probably best.
> Please see my above comments on PPAC and Protection-Cap. AVPs.
Hopefully we are getting rid of PPACs and PCAPs so this won't be an issue...

- Mark

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 6 Oct 2006 09:37:06 -0700 (PDT)

PANA requires an IP address to start running the protocol. The mechanism
to acquire this is using any standard methods available today. But then
how does the host know what this IP address can be used for ? If the same
IP address can be used for PANA and for sending packets after authenticated,
then there is no issue. But it is not the case here as defined today. So, we can
potentially make it by restricting what sort of an address it obtains before running
PANA so that it does not require a new one after (it can be outside the PANA spec) OR
indicate to the host that you need to acquire a different address. 

I am beginning to think the first option may be better than the latter just from the
complexity perspective. Flexibility Vs Complexity ? 
Perhaps, there is something i am missing...

-mohan

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 06 Oct 2006 13:11:47 -0400

> same device), then the PAA and PaC do not have to communicate this in

The protection policy is determined by PAA and enforced by EP.
Depending on the lower layer, either PaC or EP initiates protection
signaling, i.e., Secure Association Protocol.  Since PAA and EP are
not always in the same place, I think that the "protection needed" bit
is needed.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 06 Oct 2006 13:35:33 -0400

On Fri, Oct 06, 2006 at 04:27:03PM +0200, Mark Townsley wrote:

(snip)
> for example; a single filter on a single IP hostroute sounds pretty 

I agree with removing the last sentence as Mark suggested.

Yoshihiro Ohba

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 6 Oct 2006 10:53:02 -0700 (PDT)

Yoshi,

I somehow think that this is related to the other thread "Network Layer".
If PANA stops with authenticating the client and not bother about
filter  rule creation and installations (this is what i think Mark is
suggesting), then no bits are needed i guess. This means when you deploy
PANA, the respective SDO can define a specific mechanism for protection.

-mohan

----- Original Message ----
From: Yoshihiro Ohba <[email-masked]>
To: Mark Townsley <[email-masked]>
Cc: Yoshihiro Ohba <[email-masked]>; [email-masked]
Sent: Friday, October 6, 2006 10:11:47 AM
Subject: Re: Protection capability needed? (was RE: [Pana] Other suggestions for pana-pana)

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 06 Oct 2006 14:19:17 -0400

This looks like a very good suggestion.  I start to think that it is
possible to deploy PANA transparently on top of usual IP usage.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 06 Oct 2006 14:30:18 -0400

> PANA, the respective SDO can define a specific mechanism for protection.

Since we are also defining PaC-EP-Master-Key for bootstrapping
lower-layer (IPsec or link-layer) ciphering, I think we need to define
one bit in PANA to indicate the use of PaC-EP-Master-Key.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 06 Oct 2006 15:09:50 -0400

> No reason to propagate such confusing uses of a term.

How about revising the text to:

"
The Session-Id MUST be globally unique among multiple PAAs and
locally unique within the PAA for a certain period of time,...
"

> Forgive me for asking, but who assigns the PAA ID, and is *that* 

PAA ID is actually PAA's FQDN, which is supposed to be global unique.

Yoshihiro Ohba

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 6 Oct 2006 12:39:53 -0700 (PDT)

Yoshi,

Why do you need to indicate to the client ? Isn't it obvious ?

-mohan

----- Original Message ----
From: Yoshihiro Ohba <[email-masked]>
To: Mohan Parthasarathy <[email-masked]>
Cc: Mark Townsley <[email-masked]>; Yoshihiro Ohba <[email-masked]>; [email-masked]
Sent: Friday, October 6, 2006 11:30:18 AM
Subject: Re: Protection capability needed? (was RE: [Pana] Other suggestions for pana-pana)

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 06 Oct 2006 15:44:47 -0400

Why it is obvious??

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 6 Oct 2006 23:19:37 +0300

Mohan,

> So,
> we can
> PANA so that it does not require a new one after (it can be outside the
> PANA spec)

I'm not sure I understand this proposal. Can you please elaborate?

Thanks.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 6 Oct 2006 23:27:23 +0300

> Similar to PPAC discussion, I think we still need one bit to indicate

This is different than PPAC. In PPAC case, configuration of so-called POPA
is an aspect introduced by PANA. Hence we deal with it.

The same cannot be said about protection capability of the access network. 
For that, I'm inclined to think this is not a problem that we need to deal
with PANA. 

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 6 Oct 2006 23:29:16 +0300

> I agree with removing the last sentence as Mark suggested.

So do I.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 06 Oct 2006 16:33:05 -0400

Does it mean bootstrapping lower-layer security (i.e., mechanisms described
in draft-ietf-pana-ipsec, etc.) is not an aspect introduced by PANA?

Yoshihiro Ohba

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 6 Oct 2006 13:56:00 -0700 (PDT)

If we agree that PANA is used for authentication only, then it is the
responsibility of the other SDOs that want to use PANA to define
what key will be used for securing the link-layer etc. The Pac already
has the key, you don't need anything in the protocol to tell it. Juse use it
as defined in other "access control"/SDO specific documents.

-mohan

----- Original Message ----
From: Yoshihiro Ohba <[email-masked]>
To: Mohan Parthasarathy <[email-masked]>
Cc: Yoshihiro Ohba <[email-masked]>; Mark Townsley <[email-masked]>; [email-masked]
Sent: Friday, October 6, 2006 12:44:47 PM
Subject: Re: Protection capability needed? (was RE: [Pana] Other suggestions for pana-pana)

Why it is obvious??

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 6 Oct 2006 13:59:21 -0700 (PDT)

If the initial address (PRPA) is not a link-local address, then you can
use it both before and after PANA. Either it is a private address that
gets NATed or a public address. If the underlying
protection (e.g. IPsec) needs another address, it may have to get another
address which PANA does not have to worry about it i guess.
Missing something ?

-mohan

----- Original Message ----
From: Alper Yegin <[email-masked]>
To: Mohan Parthasarathy <[email-masked]>; Yoshihiro Ohba <[email-masked]>; Mark Townsley <[email-masked]>
Cc: [email-masked]
Sent: Friday, October 6, 2006 1:19:37 PM
Subject: RE: PPAC needed? (was RE: [Pana] Other suggestions for pana-pana)

Mohan,

Thanks.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 7 Oct 2006 00:07:10 +0300

> No reason to propagate such confusing uses of a term.

I see and I agree.

So, how about "globally and temporally"? [I've got inspired by Bernard as he
used this qualification ('temporally') for EAP session ID.] 

> Forgive me for asking, but who assigns the PAA ID, and is *that*

It's the FQDN.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 06 Oct 2006 17:18:40 -0400

If we follow that path, it would mean that not only
Protection-Capability AVP but also the following items are also not
needed in PANA specification:

- Device-Id AVPs for EPs in PBR (if we don't have this, how IPsec EPs
can be discovered?)

- PaC-EP-Master-Key derivation algorithm (if we let each SDO to define
this, how we can avoid possible key conflict among different SDOs?)

Please answer to those questions.

Yoshihro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 7 Oct 2006 00:40:34 +0300

OK, I realize it's best if we remove that "link-layer agnostic" term from
the spec. It appears very difficult to converge on the terminology, and
removing that text from the spec does not take anything away from the
protocol.

Alper

> -----Original Message-----
> From: Mark Townsley [mailto:[email-masked]]
> Sent: Friday, October 06, 2006 5:28 PM
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; [email-masked]
> Subject: Re: L2 agnisticism (was RE: [Pana] Other suggestions for pana-
> pana)
> 
> Alper Yegin wrote:
> >> keep L2 ties but revising the 3rd paragraph of the Introduction
> something
> >> like:
> >>
> >> "

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 6 Oct 2006 15:34:05 -0700 (PDT)

Yoshi,

I never said remove the Pac-EP-Master-Key. You can keep it and use it when
you want to and this would be described in the document that describes the
usage. Would that work ? I still don't understand why you have to tell the
client explicitly to use the Pac-EP-Master Key ? What are the other possibilities ?
I am missing something here..

If you can discover PAAs using DHCP, i would use the same mechanism for EP
also. Would that work ?

-mohan

----- Original Message ----
From: Yoshihiro Ohba <[email-masked]>
To: Mohan Parthasarathy <[email-masked]>
Cc: Mark Townsley <[email-masked]>; Yoshihiro Ohba <[email-masked]>; [email-masked]
Sent: Friday, October 6, 2006 2:18:40 PM
Subject: Re: Protection capability needed? (was RE: [Pana] Other suggestions for pana-pana)

Yoshihro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 06 Oct 2006 19:08:56 -0400

On Fri, Oct 06, 2006 at 03:34:05PM -0700, Mohan Parthasarathy wrote:
> usage. Would that work ? 

Yes, that would work.

> I still don't understand why you have to tell the

One possibility is to use the inclusion of Device-Id AVPs in PBR as
the indication of the use of PaC-EP-Master Key.  However, Device-Id
AVPs in PBR is also used for another purpose (i.e., requesting PaC to
include its Device-Id in PBA for MiTM detection), but I think that if
Device-Id AVP is always carried in PBA, then Device-Id AVPs in PBR can
be always for the single purpose, i.e., indication of the use of
PaC-EP-Master Key.  This way, we can get rid of Protection-Cap. AVP.

> If you can discover PAAs using DHCP, i would use the same mechanism for EP

I believe the specification that defines PaC-EP-Master Key needs to be
the same as the specification that defines Device-Id format because
Device-Id is used in PaC-EP-Master Key derivation algorithm.
Otherwise, an interoperability issue would arise.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 06 Oct 2006 19:33:21 -0400

A second thought:

> PaC-EP-Master Key.  This way, we can get rid of Protection-Cap. AVP.

Always including Device-Id AVP in PBA does not work for locally
significant identifiers, so I am wondering if we can remove MiTM
detection functionality from the specification.  The MiTM detection
functinality is not needed for physically secure links such as DSL
(MiTM does not happen) and links with per-packet ciphering (MiTM can
be detected by lower-layer).  For links that are not secured at all,
many other attacks are possible and MiTM detection does not help much.

Yoshihiro Ohba

> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 06 Oct 2006 20:02:59 -0400

On Fri, Oct 06, 2006 at 04:54:04PM +0200, Mark Townsley wrote:

(snip)
> this will be covered with text describing local filter installation is

There was some text about this in previous version of pana-framework draft but 
the text was removed as a result of simplifying the draft.  The text was:

"
   EPs should prevent data
   traffic from and to any unauthorized client unless it's either PANA
   or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor
   discovery, DHCP, etc.).
"

Perhaps we can include this text in the definition of EP in Section 2
of pana specification.

> the reader wondering what is detailed and what is not detailed.

Since we are accepting Alper's suggested text with some modification
instead of the above text, so I think the issue has been resolved.

> the Protocol for Authenticating Data Link Access!

Then we should probably call it "network and datalink access".  I really
see a problem with removing all L2 ties.

Yoshihiro Ohba

---

From: Mark Townsley <[email-masked]>
Date: Sat, 07 Oct 2006 15:33:23 +0200

> not always in the same place, I think that the "protection needed" bit
But, the PAA-EP protocol is out of scope in *this* document.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Sat, 07 Oct 2006 15:47:46 +0200

> locally unique within the PAA for a certain period of time,...
Scoping unique IDs beyond a single device is something that generally
adds significant operational complexity. If the only reason for unique
IDs across multiple PAAs is for mobility, I would suggest making that
requirement part of the mobility document.

> PAA ID is actually PAA's FQDN, which is supposed to be global unique.
Using the Session-ID format of RFC3588 seems extremely heavyweight to
me. There are, I believe, two uses of a Session ID in PANA:

1. To match up messages being exchanged between the PAA and PaC
2. To keep in a log for troubleshooting, record-keeping, etc.

The former should be able to be an ephemeral value that is unique only
between the PaC and PAA. In fact, there could be two values, one for
each direction.

The latter is largely informational, and could be made up of a variety
of things as they are available. FQDN, IP address, locally administered
name, etc.

For a protocol that goes to such lengths to be more efficient in so many
ways, it seems odd that a Session ID would be so complex. There are
operational difficulties when you tie a Session ID to FQDN and such as
well - for example, if you ever change the FQDN of the PAA, then you
will lose all sessions. The tie to FQDN seems arbitrary for the
operation of the protocol itself, and unless I am missing something, I
believe it could be simplified accordingly.

- Mark

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 8 Oct 2006 00:50:44 +0300

> adds significant operational complexity. 

If the PAA is running Diameter, reliance on FQDN comes for free. The node
needs to have FQDN for running Diameter anyways. FQDNs are recommended as
NAS-Identifier in RADIUS. 

> If the only reason for unique

We were not motivated by that. Historically, we simply adopted the
Session-ID from Diameter, as we needed one and aligning with the rest of the
AAA infra made sense.

Making that requirement part of any optional-to-implement-and-use document
would not achieve the same result, as its use cannot be guaranteed.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 8 Oct 2006 01:01:23 +0300

Yoshi,

Irrespective of whether PANA is used, "how PaC knows the right layer to
enable per-packet security" is an orthogonal issue (note PANA's business).
Agreed?

If so, unless the appropriate per-packet security was already established
prior to PANA execution, PaC can figure out that it needs to be enabled
after PANA.

I think this is how we can clean PANA off this mechanism. Sure I agree that
an explicit message like we have in PANA is, well, "more explicit!" But I
think this approach also make sense, especially for the sake of simplifying
the PANA.

Alper

> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Friday, October 06, 2006 11:33 PM
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; 'Mark Townsley'; [email-masked]
> > > > > > 8.13: The "Protection Capability" AVP is another layer
violation.
> > > Why
> > > > either. Unless we identify some PANA-specific aspect here, we may
> not
> > > have

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 8 Oct 2006 01:04:03 +0300

> address which PANA does not have to worry about it i guess.

You only talked about the IPsec case.

But for example in DSL case, the PaC cannot know whether the PRPA is good
for post-PANA data communication or not. Unless the PRPA is a link-local
address, the PaC cannot tell one way or the other. And there is no IKE/IPsec
in that case.

Alper

> To: Mohan Parthasarathy <[email-masked]>; Yoshihiro Ohba
> <[email-masked]>; Mark Townsley <[email-masked]>
> Cc: [email-masked]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 7 Oct 2006 23:40:42 -0400

Alper,

I think Mohan is proposing that the access network that uses PANA is
expected to be designed such that PaC does not require to change its
IP address used for PANA communication before and after PANA
authentication (PaC may acquire additional IP addresses after
successful PANA authentication, though).

Yoshihiro Ohba

---

From: Mark Townsley <[email-masked]>
Date: Sun, 08 Oct 2006 10:36:53 +0200

Alper Yegin wrote:
> We were not motivated by that. 
Yoshi said you were.
> Historically, we simply adopted the

 From a security standpoint, do you want to be advertising the FQDN to 
all PaC's? What if some version of RADIUS that is *not* using an FQDN 
NAS-ID is being used? What if the PAA is not interfacing with DIAMETER 
or RADIUS?

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Sun, 08 Oct 2006 10:43:10 +0200

> IP address used for PANA communication before and after PANA
That would be dramatically simpler.
> successful PANA authentication, though).
Couldn't the PAA signal DHCP to terminate the lease and offer a new IP
address in this case? Why can't the PaC be passive here?

- Mark

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 8 Oct 2006 14:09:35 +0300

> successful PANA authentication, though).

These were considered in the past. The current design is not by accident :-)
We want to make the minimum impact on the host behavior. Requiring
additional IP address configuration because host is using PANA is not a good
idea. And in the case of IPv4, it's even a problem (multihoming, source
address selection issues, etc.).

Alper

> > > > potentially make it by restricting what sort of an address it
> obtains
> > > > before running

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 8 Oct 2006 14:19:34 +0300

> NAS-ID is being used? What if the PAA is not interfacing with DIAMETER

Mark, the point I tried to make was, if it is not a problem for Diameter to
mandate availability of FQDN, why should it be a problem for PANA?
Applicability of Diameter is no less than that of PANA. We are referring to
the very same FQDN used in PANA and Diameter. I'm personally not aware of
anyone being concerned about Diameter's reliance on FQDNs. If we have any
input on that, that's be useful to know.

As for every PaC knowing the FQDN of the PAA, we had a similar discussion
for "MIP6 Home Agent discovery via DNS." Similar concerns were raised there,
but the MIP6 WG has decided to retain that method. In my understanding, IETF
community does not see this as a vulnerability.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 8 Oct 2006 14:22:08 +0300

> That would be dramatically simpler.

I disagree. Please see below.

> address in this case? Why can't the PaC be passive here?

Now this introduces a new leg of protocol -- between PAA and DHCP server.
Not only that, but also in a given deployment the IP address configuration
mechanism may not even be based on DHCP. It's simpler and more scalable to
give a one-bit heads up to the PaC, and let it do whatever it does to
configure another IP address.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 8 Oct 2006 07:36:50 -0400

Alper,

I am not saying that additional IP address configuration may be
required because of PANA.  Additional IP address may be required
regardless of PANA.  For example, in the case of IPv6, a global IP
address is required in addition to link-local address which may be
used for PANA.  In the case of use of IKEv2 for lower-layer ciphering,
an IPsec-TIA is required in addition to IPsec-TOA which may be used
for PANA.

We seem to be re-visiting several fundamental issues that were
discussed in the long past but with more experienced insights of Mark.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 8 Oct 2006 08:11:34 -0400

I have to admit that when I brought the idea of Diameter Session-Id
for use of session identifier of MIHF protocol being defined in IEEE
802.21 WG, they had comments similar to yours and finally came up with
a 4-octet session identifier that is not globally unique.

Yoshihiro Ohba

---

From: Mark Townsley <[email-masked]>
Date: Sun, 08 Oct 2006 15:01:25 +0200

> mandate availability of FQDN, why should it be a problem for PANA?
Because, generally speaking, Diameter doesn't talk directly to a 
client-type device.
> Applicability of Diameter is no less than that of PANA. 
Really? Then why even have PANA?
> We are referring to
My guess is that when people who read this for the first time see 
Session ID, they aren't even aware that this is the multi-field value 
defined in Diameter until they dig into the details (I surely didn't 
realize it until I searched for what the Session ID format actually was).

I'm not sure why you are tying yourself so closely to Diameter. It is 
hardly a sure thing to be present in all of the environments that PANA 
could finally end up in -- including DSL.
> community does not see this as a vulnerability.
Perhaps MIP6 had a really good reason for doing so, considered the 
tradeoff, and decided to keep using it despite the raised concerns. I 
don't see the benefit for PANA, I only see the concerns.

- Mark
> Alper
>
>
>
>   
>> - Mark
>>     
>>> Making that requirement part of any optional-to-implement-and-use
>>>       
>> document
>>     
>>>> For a protocol that goes to such lengths to be more efficient in so
>>>>         
>> many
>>

---

From: Mark Townsley <[email-masked]>
Date: Sun, 08 Oct 2006 16:36:12 +0200

> Now this introduces a new leg of protocol -- between PAA and DHCP server.
Assuming they are not co-located, but yes. In any case, there is at 
least some sharing of policy between the DHCP server and PAA if the PAA 
is supposed to "know" what kind of IP address the client was assigned 
for the PANA exchange, and thus whether or not it should tell the client 
to renegotiate. As an aside, how does the DHCP server know whether to 
hand out a temporary or permanent IP address anyway?

> configure another IP address.
This is a classic argument over where the complexity lies - in the PaC 
or in the Network. I think there are tradeoffs both ways on this. I do 
think that the communication from the PAA to PaC here should be 
optional,  leaving the door open for the Network to  hand out a new IP 
address on its own accord without relying on the PaC to ask for one in 
all cases where it is necessary.

In general, renegotiating an IP address is typically problematic on IPv4 
networks today (HIP and such aside). I don't think PANA should be 
recommending this as not all stacks, transports, and applications can 
handle it without difficulty (e.g., if this is a MUST for PANA, it 
raises the bar considerably for where PANA could be used).

- Mark

- Mark
>>>>> If the initial address (PRPA) is not a link-local address, then you
>>>>>           
>> can
>>     
>>>>> protection (e.g. IPsec) needs another address, it may have to get
>>>>>           
>> another
>>     
>>>> But for example in DSL case, the PaC cannot know whether the PRPA is
>>>>         
>> good
>>     
>>>> for post-PANA data communication or not. Unless the PRPA is a link-
>>>>         
>> local
>>     
>>>> address, the PaC cannot tell one way or the other. And there is no
>>>>         
>> IKE/IPsec
>>     
>>>> in that case.
>>>>
>>>> Alper
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>>> -mohan
>>>>>
>>>>>
>>>>> Subject: RE: PPAC needed? (was RE: [Pana] Other suggestions for pana-
>>>>>           
>> pana)
>>     
>>>>> Mohan,
>>>>>
>>>>>
>>>>>           
>>>>>> So,
>>>>>> we can
>>>>>> PANA so that it does not require a new one after (it can be outside
>>>>>>             
>> the
>>     
>>>>>> PANA spec)
>>>>>>
>>>>>>

---

From: Mark Townsley <[email-masked]>
Date: Sun, 08 Oct 2006 16:44:07 +0200

> a 4-octet session identifier that is not globally unique.
Thanks for making us aware of that. A locally chosen 4-octet Session ID
is precisely the kind of thing that I believe that would make more sense
here. You could even make it unidirectional, so that either side can
choose a value which they can lookup in memory to find the context for
PANA when a message is received in the most efficient manner possible
(and also eliminating the possibility of collision in a meshed scenario
of PaCs and PAAs). Other AVPs can carry FQDNs and such if that is truly
necessary for some applications or features, but it would be nice if you
wouldn't burden the most basic operation of PANA with this.

- Mark

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 8 Oct 2006 22:35:33 +0300

Mark,

> could finally end up in -- including DSL.

We are not tying anything to Diameter. We are simply re-using a format
that's already defined in another spec (RFC 3588). Whether we use this
format or not, PANA does not rely on Diameter usage.

> don't see the benefit for PANA, I only see the concerns.

OK, you seemed to be more concerned about it than I see benefits for keeping
it. For the types of benefits I see, probably we can deal with them later by
other means. I don't mind going along with your suggestion.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 8 Oct 2006 22:38:29 +0300

> wouldn't burden the most basic operation of PANA with this.

For the spirit of keeping it simple, can we stick to one session-id? Since
the session-id space is per-PAA (as it is assigned by the PAA), I don't see
a mesh causing trouble.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 8 Oct 2006 22:49:36 +0300

Consider this case.
PRPA may be a link-local or short-leased private address (IPv4).
After PANA, the PaC needs to configure another IPv4 address for its
end-to-end communication.
There is no IKE/IPsec.
Hence, the PRPA shall be released. Hosts cannot deal with two IPv4
addresses. 

So, Mohan's case is one case, but it cannot cover all cases.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 9 Oct 2006 00:22:38 +0300

> hand out a temporary or permanent IP address anyway?

Several architectural possibilities exist.

PRPA can be a link-local address. DHCP packets can be allowed to hit the
DHCP server only after the PANA authentication. Hence, DHCP always allocates
permanent addresses.

Or...

PRPA can be a temporary IP address allocated by the DHCP.
Unspecified-sourced clients are allowed to hit the DHPC server and allocated
the temp IP address. Once the client is PANA authenticated, now the
PRPA-sourced IP packet is allowed to hit the DHCP server and allocated
permanent address.

There may be other (better) architectural solutions that do not require
PAA-DHCP signaling.

> all cases where it is necessary.

Sure, that's fine. 

> raises the bar considerably for where PANA could be used).

It's not a MUST for PANA (more specifically "for PaC").

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 9 Oct 2006 00:53:27 +0300

Mark,

Your earlier recommendation to deal with only IP addresses (scrapping MAC
addresses) as the device ID would cause complications. As Yoshi explained
earlier, dealing with router type PaCs, PaCs with multiple addresses, PaCs
with changing addresses (for privacy), etc. becomes a burden.

I think one way to deal with your concern is to remove the "device ID" from
the PANA specification. That way we don't need to be concerned whether it is
an IP address, a MAC address, or a locally-significant identifier. 

Device ID is used for:

- PaC's EP discovery.
- Per-PaC access control filter settings on the EP.

I think both can be handled by mechanisms outside PANA specification. 

With that, we can also remove the PaC-EP- master key computation.

We still have requirements about "device IDs" in RFC 4058. But that should
not be a concern if we want to make this simplification.

Alper

> Sent: Friday, October 06, 2006 5:27 PM
> To: Alper Yegin
> Subject: Re: Network Layer (was RE: [Pana] Other suggestions for pana-
> pana)
> 
> Alper Yegin wrote:

---

From: Ralph Droms <[email-masked]>
Date: Sun, 08 Oct 2006 19:13:38 -0400

I'm not sure who wrote the innermost text...

> It's not a MUST for PANA (more specifically "for PaC").

Can you be more specific about how "renegotiating an IP address is typically
problematic on IPv4 networks today"?  I think most IPv4 stacks with DHCP can
successfully obtain and assign a new IP address, usually prompted by moving
between links.

The effect on applications of assigning a new IP address is more
troublesome...

- Ralph

---

From: Mark Townsley <[email-masked]>
Date: Mon, 09 Oct 2006 09:50:03 +0200

Alper Yegin wrote:
> We are not tying anything to Diameter. 
But your argument that it was "for free" was predicated on existence of 
Diameter. Unless you tie yourself to Diameter, it is not "free" at all.
> We are simply re-using a format
<snip>
> OK, you seemed to be more concerned about it than I see benefits for keepinFrom [email-masked] Mon Oct 09 08:31:40 2006
Date: Mon, 09 Oct 2006 09:50:03 +0200
From: Mark Townsley <[email-masked]>
To: Alper Yegin <[email-masked]>
Subject: Re: Global Session-id (was RE: [Pana] Other suggestions for pana-pana)
Cc: 'Yoshihiro Ohba' <[email-masked]>, [email-masked]

Alper Yegin wrote:
> We are not tying anything to Diameter. 
But your argument that it was "for free" was predicated on existence of 
Diameter. Unless you tie yourself to Diameter, it is not "free" at all.
> We are simply re-using a format
<snip>
> other means. I don't mind going along with your suggestion.
I think the protocol will be improved for it.

- Mark
>>>>>>> PAA ID is actually PAA's FQDN, which is supposed to be global
>>>>>>>               
> unique.
>   
>>>>>>>
>>>>>>>               
>>>>>> The former should be able to be an ephemeral value that is unique
>>>>>>             
>> only
>>     
>>>>>> The latter is largely informational, and could be made up of a
>>>>>>             
>> variety
>>     
>>>>>> of things as they are available. FQDN, IP address, locally
>>>>>>             
>> administered
>>     
>>>>>> name, etc.
>>>>>>
>>>>>> operational difficulties when you tie a Session ID to FQDN and such
>>>>>>             
>> as
>>     
>>>>>> operation of the protocol itself, and unless I am missing something,
>>>>>>             
>> I
>>

---

From: Mark Townsley <[email-masked]>
Date: Mon, 09 Oct 2006 10:25:15 +0200

Alper Yegin wrote:
>>> Now this introduces a new leg of protocol -- between PAA and DHCP
>>>       
> server.
>   
If it's link-local, the client surely knows that it needs to get a 
non-link-local address. Note that I don't think IPv4 link-local is very 
realistic as a tool for PANA.

> There may be other (better) architectural solutions that do not require
If the DHCP server hands out temporary and permanent addresses depending 
on whether authentication has occurred or not, I don't see how you get 
around some sort of PAA-DHCP interaction anyway. This could be via 
option 82 information inserted by the PAA, or somem (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k99CV8DM011840; 
	Mon, 9 Oct 2006 08:31:08 -0400 (EDT)
Date: Mon, 09 Oct 2006 10:25:15 +0200
From: Mark Townsley <[email-masked]>
To: Alper Yegin <[email-masked]>
Subject: Re: PPAC needed? (was RE: [Pana] Other suggestions for pana-pana)
Cc: 'Yoshihiro Ohba' <[email-masked]>,
	'Mohan Parthasarathy' <[email-masked]>, [email-masked]

Alper Yegin wrote:
>>> Now this introduces a new leg of protocol -- between PAA and DHCP
>>>       
> server.
>   
If it's link-local, the client surely knows that it needs to get a 
non-link-local address. Note that I don't think IPv4 link-local is very 
realistic as a tool for PANA.

> There may be other (better) architectural solutions that do not require
If the DHCP server hands out temporary and permanent addresses depending 
on whether authentication has occurred or not, I don't see how you get 
around some sort of PAA-DHCP interaction anyway. This could be via 
option 82 information inserted by the PAA, or some other direct 
communication (or just assume that they are co-located for these cases).

- Mark
>  
>   
>>> Not only that, but also in a given deployment the IP address
>>>       
>> configuration
>>     
>>> mechanism may not even be based on DHCP. It's simpler and more scalable
>>>       
>> to
>>     
>>>>>>> use it both before and after PANA. Either it is a private address
>>>>>>>               
>> that
>>     
>>>>>>> Subject: RE: PPAC needed? (was RE: [Pana] Other suggestions for
>>>>>>>               
>> pana-
>>     
>>>> pana)
>>>>
>>>>         
>>>>>>> Mohan,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> So,
>>>>>>>> we can

 other direct 
communication (or just assume that they are co-located for these cases).

- Mark
>  
>   
>>> Not only that, but also in a given deployment the IP address
>>>       
>> configuration
>>     
>>> mechanism may not even be based on DHCP. It's simpler and more scalable
>>>       
>> to
>>     
>>>>>>> use it both before and after PANA. Either it is a private address
>>>>>>>               
>> that
>>     
>>>>>>> Subject: RE: PPAC needed? (was RE: [Pana] Other suggestions for
>>>>>>>               
>> pana-
>>     
>>>> pana)
>>>>
>>>>         
>>>>>>> Mohan,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> So,
>>>>>>>> we can

---

From: Mark Townsley <[email-masked]>
Date: Mon, 09 Oct 2006 09:58:09 +0200

> the session-id space is per-PAA (as it is assigned by the PAA), I don't see
As long as you don't believe a single PaC will be talking to more than 
one PAA (what I referred to as a mesh), that is fine. What you don't 
want to have to do is build in logic for Session ID collisions and the 
like, that's what two IDs lets you avoid (without having to refer to the 
IP address the message arrived from - which may have NAT issues in some 
convoluted cases).

- Mark
>>>>>>>>>> The Session-Id MUST be globally and eternally unique, as it is
>>>>>>>>>>                     
>> meant
>>     
>>>>>>>>>> to identify a PANA session without reference to any other
>>>>>>>>>>                     
>> information,
>>     
>>>>>>>>> Globally and eternally unique? This is a tall order. First, I
>>>>>>>>>                   
>> don't
>>     
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>> think
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> you mean "Global" here as that implies an global allocation
>>>>>>>>>                   
> system.
>   
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> Also,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>> Realistically, this number is Global to a given PAA or PaC, and
>>>>>>>>>                   
>> effort
>>     
>>>>>>>>> should be made to not repeat Session IDs over a certain period of
>>>>>>>>>                   
>> time.
>>     
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> This "global and eternal" term is coming from RFC 3588 where
>>>>>>>               
>> session-ID is
>>     
>>>>>>> defined.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> I do see that now, and don't believe it is the best reference to go
>>>>>>             
>> by.
>>     
>>>>>> Aside of what this document said when we published it in 2003,
>>>>>>             
>> Webster
>>     
>>>>>> says this:
>>>>>>

---

From: Mark Townsley <[email-masked]>
Date: Mon, 09 Oct 2006 10:27:35 +0200

OK, are you still planning on being able to identify at least one PaC IP 
address for the EP to setup a simple filter based upon? Will this just 
be the IP address that PANA packets arrive at the PAA from?

- Mark

Alper Yegin wrote:
>>>>> associated filter, then it would truly be a Network Layer
>>>>>           
>> authentication
>>     
>>> So, PANA authenticates for (and used for authorization of) "network
>>>       
>> access."
>>     
>>> Execution of access control is orthogonal to PANA authentication. A
>>>       
>> network
>>     
>>> can choose to change IP filters to allow traffic from authenticated
>>>       
>> client,
>>

---

From: Mark Townsley <[email-masked]>
Date: Mon, 09 Oct 2006 10:00:05 +0200

> Hence, the PRPA shall be released. Hosts cannot deal with two IPv4
But how real is this case? And, could the DHCP server, when handing out 
the short lease, indicate that it is *just* for PANA so that the client 
could then request a new IP address after? The difference here is 
whether the PAA is telling the client the IP address it has is 
"short-leased" or if the DHCP server is telling the client that the IP 
address is "short leased" - something that is potentially significant 
operationally.

- Mark
>>> These were considered in the past. The current design is not by
>>>       
>> accident :-)
>>     
>>> additional IP address configuration because host is using PANA is not a
>>>       
>> good
>>     
>>>>>> If the initial address (PRPA) is not a link-local address, then
>>>>>>             
>> you
>>     
>>>> can
>>>>         
>>>>>>> PANA so that it does not require a new one after (it can be
>>>>>>>               
>> outside
>>     
>>>> the
>>>>         
>>>>>>> PANA spec)
>>>>>>>

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 9 Oct 2006 14:42:35 +0200

Hi,

> other means. I don't mind going along with your suggestion.

 The PANA session-id, as it is, is used in pana-mobopts (and thus
  pana-cxtp) to help the new PAA to find the previous PAA.
 Thus, removing this will have some implications on the two mentionned
 documents.

  Julien

-- 
julien.bournelle at int-evry.fr

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 9 Oct 2006 09:50:18 -0700 (PDT)

Alper,

Remove the link-local and short-leased private address case. Too many
options may not be useful if there is no widespread use for it. I remember
that the reason for short-leased private address is the attacker can
consume all the addresses. Should we be really concerned  about this ?

-mohan

----- Original Message ----
From: Alper Yegin <[email-masked]>
To: Yoshihiro Ohba <[email-masked]>
Cc: Mark Townsley <[email-masked]>; Mohan Parthasarathy <[email-masked]>; [email-masked]
Sent: Sunday, October 8, 2006 12:49:36 PM
Subject: RE: PPAC needed? (was RE: [Pana] Other suggestions for pana-pana)

Consider this case.

Alper

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 9 Oct 2006 10:05:04 -0700 (PDT)

I am not sure why we need that. The information that is needed to setup the access
control is outside the scope of PANA. I might have repeated what you said or
misunderstood what you said earlier :-) How much the simple filter is useful as
the PaC can always spoof the IP address ? This may not be possible in
e.g. PPP, but then it depends on factors outside PANA. No ?

-mohan

----- Original Message ----
From: Mark Townsley <[email-masked]>
To: Alper Yegin <[email-masked]>
Cc: Yoshihiro Ohba <[email-masked]>; [email-masked]
Sent: Monday, October 9, 2006 1:27:35 AM
Subject: Re: Network Layer (was RE: [Pana] Other suggestions for pana-pana)

- Mark

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 9 Oct 2006 22:10:45 +0300

Mohan,

That's not the only case. The other case is when the IP address assignment
depends on the client authentication (e.g., client-id and/or
home-domain-based assignment).

In that case, we need a POPA configuration.

Alper

> From: Mohan Parthasarathy [mailto:[email-masked]]
> Sent: Monday, October 09, 2006 7:50 PM
> To: Alper Yegin; Yoshihiro Ohba
> Cc: Mark Townsley; [email-masked]

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 9 Oct 2006 22:19:45 +0300

> communication (or just assume that they are co-located for these cases).

In my above example, the deployment depends on the EP doing the appropriate
filtering. Anyways, this is just an example of how "a" deployment can
achieve this without requiring PAA-DHCP interaction. 

I acknowledge that some other deployments may prefer relying on PAA-DHCP
interaction. I'm fine with that, as long as we don't need to build any more
bits into the PANA specification to support that :-)

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 9 Oct 2006 22:30:23 +0300

> But how real is this case? 

This is a realistic DSL case.

> And, could the DHCP server, when handing out
> could then request a new IP address after? 

I presume you are not suggesting adding new semantics to DHCP to indicate
"this IP address is for PANA." You are simply relying on setting the lease
time to a short period, right?

> The difference here is

Semantically, DHCP is the one who can really say "this IP address has a
short lease." 

The one bit information we proposed to keep in PANA is the one that says
"PaC needs to configure a new IP address after PANA."

I'm wondering if the former scheme can be a substitute for the latter one
for the purposes of forcing the PaC to configure a POPA. I'm not sure, as it
would not be as precise. We really want the PaC to configure the POPA as
soon as PANA succeeds.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 9 Oct 2006 22:33:26 +0300

The PAA will know the IP address of the PaC, but that's only for reaching
the PaC for PANA signaling. 

Like Mohan was saying, we'd leave filter details out-of scope for the base
specification. 

Alper

> Sent: Monday, October 09, 2006 11:28 AM
> To: Alper Yegin

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 9 Oct 2006 13:01:03 -0700 (PDT)

Alper,

Perhaps there is a little confusion here. I guess we are mixing up two separate
issues i think.

1) Is there a need to configure an additional address after PANA completes ?
2) What is required in the PANA specification to handle such IP address configuration ?

I agree that there are lot of cases where you need additional IP address
configuration.  But then, do we need anything  in the PANA base specification to
handle this ? You said that we might need a bit to indicate to the PaC that it indicate
whether it should configure an additional IP address or not. How does the PAA
learn this information ? 

-mohan

----- Original Message ----
From: Alper Yegin <[email-masked]>
To: Mohan Parthasarathy <[email-masked]>; Yoshihiro Ohba <[email-masked]>
Cc: Mark Townsley <[email-masked]>; [email-masked]
Sent: Monday, October 9, 2006 12:10:45 PM
Subject: RE: PPAC needed? (was RE: [Pana] Other suggestions for pana-pana)

Mohan,

Alper

---

From: Mark Townsley <[email-masked]>
Date: Mon, 09 Oct 2006 22:33:18 +0100

> This is a realistic DSL case.
"Realistic" for DSL is fairly subjective given that today authentication 
is performed before an IP address is ever handed out (even for 
retail/wholesale environments) for the vast majority of architectures. 
Perhaps in the future, but that hasn't been fully hashed out yet.
> time to a short period, right?
You are already sending an option to contact a PAA, the PaC can 
interpret that however it you define it to (including, "when finished 
with PANA ask for another lease"). But, yes, a short-lease is probably 
the least impact way to handle this. In either case, even with the PAA 
to PaC option you have today to indicate that a new IP address needs to 
be obtained, I do not know how you indicate to the DHCP server to 
handout a PRPA vs. a POPA without some sort of heads up from the PAA 
that authentication has completed (it's not like you can trust the PaC 
to tell the DHCP server).  Has that been worked out by the WG in general?

> would not be as precise. We really want the PaC to configure the POPA as
But how does the DHCP server know that the PaC is now authentic vs. the 
earlier request?

- Mark
>>>>> additional IP address configuration because host is using PANA is not
>>>>>           
>> a
>>     
>>>> good
>>>>
>>>>         
>>>>> idea. And in the case of IPv4, it's even a problem (multihoming,
>>>>>           
>> source
>>

---

From: Mark Townsley <[email-masked]>
Date: Mon, 09 Oct 2006 22:35:02 +0100

> Like Mohan was saying, we'd leave filter details out-of scope for the base
Where would you define this, for example, for the DSL case? In a 
separate DSL-specific draft?

- Mark
>>> Your earlier recommendation to deal with only IP addresses (scrapping
>>>       
>> MAC
>>     
>>> addresses) as the device ID would cause complications. As Yoshi
>>>       
>> explained
>>     
>>> earlier, dealing with router type PaCs, PaCs with multiple addresses,
>>>       
>> PaCs
>>     
>>> I think one way to deal with your concern is to remove the "device ID"
>>>       
>> from
>>     
>>> the PANA specification. That way we don't need to be concerned whether
>>>       
>> it is
>>     
>>> We still have requirements about "device IDs" in RFC 4058. But that
>>>       
>> should
>>     
>>>>>>> and Network Layer access protocol. I believe this would go a very
>>>>>>>               
>> long
>>     
>>>>>    After a device is authenticated by using PANA, it MUST be
>>>>>           
>> authorized
>>     
>>>> install filters on an (colocated or separate) EP that permits IP
>>>>         
>> packets
>>     
>>>> concerned about, and why your protocol ends up looking more complex
>>>>         
>> than
>>

---

From: Mark Townsley <[email-masked]>
Date: Mon, 09 Oct 2006 22:39:41 +0100

> whether it should configure an additional IP address or not. 
Right, I'd like to know that as well. Also, how does the DHCP server 
know when the client is authenticated or not? I think there is a 
fundamental collusion of policy here between the PAA and DHCP server 
that is difficult to get around, and the extra bit here doesn't 
necessarily help matters. Unless the PAA and DHCP server are co-located 
and allowed to share an API between one another, I do not see how this 
can be made to work without a new PAA-DHCP protocol - neither of which I 
am sure the WG has the energy or scope to define right now.

- Mark
>>>>>>> use it both before and after PANA. Either it is a private
>>>>>>>               
>> address
>>     
>>> that
>>>       
>>>>>>> protection (e.g. IPsec) needs another address, it may have to
>>>>>>>               
>> get
>>     
>>>>> another
>>>>>           
>>>>>> But for example in DSL case, the PaC cannot know whether the PRPA
>>>>>>             
>> is
>>     
>>>>> good
>>>>>           
>>>>>> for post-PANA data communication or not. Unless the PRPA is a
>>>>>>             
>> link-
>>     
>>> local
>>>       
>>>>>>> I'm not sure I understand this proposal. Can you please
>>>>>>>               
>> elaborate?
>>     
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Alper
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>
>>>>>>             
>>>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 9 Oct 2006 20:47:22 -0400

Alper,

> achieve this without requiring PAA-DHCP interaction. 

I don't see much difference between PAA-EP interaction and PAA-DHCP
interaction.  In fact, I tend to view the DHCP server as another EP.

Since DHCP server can send a reconfiguration trigger to DHCP client, I
think we can simply rely on such a DHCP functionality and simplify
PANA not requiring PaC to take any active role for IP address
reconfiguration.

Yoshihiro Ohba

---

From: Ralph Droms <[email-masked]>
Date: Tue, 10 Oct 2006 02:06:26 -0400

A couple of practical considerations...

Adding PAA-DHCP interaction now involves an entirely different protocol
suite and creates inter-protocol entanglements.  While there may be some
standards-based ways for PAA-EP interaction (SNMP? [I know the issue is out
of scope for the doc itself]), there is no such mechanism in place for DHCP
today.

DHCPv4 reconfiguration is, as far as I know, not implemented anywhere, so a
requirement for DHCPv4 reconfiguration is another inter-protocol
entanglement.

I don't intend to imply that these considerations are show-stoppers; I do
see a difference in practice between PAA-EP interaction and PAA_DHCP
interaction.

- Ralph

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 10 Oct 2006 12:40:34 +0300

Ralph,

> requirement for DHCPv4 reconfiguration is another inter-protocol

Can you clarify what part of re-configuration process you are referring to
as not implemented? Is it the host's ability to request another IP address,
DHCP server's ability to hand out another IP address, or something else?

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 10 Oct 2006 13:38:14 +0300

Other SDOs who have control over their full architecture and its plumbing
can define this on their own. 

We can talk about it in the DSL-specific I-D. But the level of details in
that informational document is not likely to match what DSL Forum may
eventually define in their own standard specification. 

Alper

> Sent: Tuesday, October 10, 2006 12:35 AM
> To: Alper Yegin

---

From: Ralph Droms <[email-masked]>
Date: Tue, 10 Oct 2006 08:21:13 -0400

I was referring to RFC 3203 (defines DHCPFORCERENEW message), which is the
trigger that signals a host (through its DHCP client) to send a DHCPREQUEST
message to the server.  As far as I know, this feature is not widely
implemented in clients or servers.

Once the client sends the DHCPREQUEST message, all the required DHCP
functions are part of RFCC 2131 and are widely implemented:

* Host sends DHCPREQUEST, as though the host is requesting a lease extension
* Server responds with DHCPNAK
* Host removes current IP address from interface
* Host sends DHCPDISCOVER
* Server responds with DHCPOFFER containing new IP address
* Host sends DHCPREQUEST for new IP address
* Server responds with DHCPACK, completing assignment of new IP address

I don't imply that "not widely implemented" is a reason not to include
DHCPFORCERENEW in the PANA spec (if that is what you had intended).

- Ralph

---

From: Mark Townsley <[email-masked]>
Date: Tue, 10 Oct 2006 20:53:50 +0200

Thanks, Ralph. It sounds much more prudent to rely on DHCP's method for 
"force-renew" than reinventing one inside PANA. Of course, there are a 
lot of details surrounding how this action gets invoked between the PAA 
and DHCP server, but I think the most prudent this for PANA to do is to 
keep this out of scope for now (effectively making the assumption that 
the PAA and DHCP server are collocated) and remove the PANA-specific 
"force-renew" bit.

- Mark

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 16 Oct 2006 13:14:34 +0300

> IP address the message arrived from - which may have NAT issues in some

If the two PAA has colliding IP addresses, I think this is a problem
regardless of whether we handle colliding session identifiers. I'm for
leaving this as a future exercise. If we ever need to handle such a case, we
can introduce auxiliary info (e.g., another session ID like you suggest,
etc.) to help demux the messages.

Alper

unique.