Subject: [pcp] Revising PANA side-by-side approach

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 Oct 2012 12:18:13 +0900

Since PCP Version 0 is used by draft-cheshire-nat-pmp, I plan to
revise PANA side-by-side approach I-D (draft-ohba-pcp-pana) to use
Bit 0 instead of Bits 5-6-7. The new logic is that when bit 0 is 1 it's
PANA,
otherwise it's PCP and alike. If there is an issue with the new logic,
please let me know.

I also plan to submit PANA encasulation approach as a separate I-D
before the next interim meeting.

Regards,
Yoshihiro Ohba

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 5 Oct 2012 09:07:52 -0400

Hi Yoshi,

The concern that I have with this approach is that it seems short-sited to me...

If we expect PANA to be used as a generic authentication mechanism, rather than being used specifically for network access authentication, I think we need to do two things:

1) Provide a clear explanation of what parts of PANA will be used with PCP.   For example, the notion of a network access enforcement point doesn't really make sense in a PCP context. 
2) Describe a clean mechanism that allows PANA to be used for authentication of other protocols.

Overloading a single bit in the PCP version field, because it happens to coincide with a flag bit in PANA doesn't seem like a method that will work for other protocols, and I am concerned that it doesn't provide a clean basis for moving forward.

Margaret

On Oct 4, 2012, at 11:18 PM, Yoshihiro Ohba wrote:

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 Oct 2012 23:37:13 +0900

Hi Margaret,

> 1) Provide a clear explanation of what parts of PANA will be used with PCP.   For example, the notion of a network access enforcement point doesn't really make sense in a PCP context.

I agree that EP is not needed in the context of PCP authentication. We 
probably do not need
to use 'I' (IP Reconfiguration) and 'P' (Ping) flags either.

> Overloading a single bit in the PCP version field, because it happens to coincide with a flag bit in PANA doesn't seem like a method that will work for other protocols, and I am concerned that it d…

The single bit use is specific to PCP.  If some other protocol operating 
over port X
wants to multiplex PANA, then a different set of bits may be used for 
port X.    I would like
to hear from you if there is a cleaner way.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 5 Oct 2012 23:36:26 +0300

Just to add to few things to what Yoshi said…

> 1) Provide a clear explanation of what parts of PANA will be used with PCP.   For example, the notion of a network access enforcement point doesn't really make sense in a PCP context. 

PANA spec recognizes the possibility that the authenticator and the enforcement point may be separate.
This is a possible case in access networks.
While this possibility is recognized, it does not make any difference on the authentication procedure as you can see from RFC 5191.

(and in the case of PCP use, enforcement point and PAA are co-located.)

> Overloading a single bit in the PCP version field, because it happens to coincide with a flag bit in PANA doesn't seem like a method that will work for other protocols, and I am concerned that it d…

This is done here just because folks wanted to share the same port for PANA and PCP.
I'm in fact seeking further clarification on this need. I had asked this on the ML http://www.ietf.org/mail-archive/web/pcp/current/msg02395.html (*) but no one answered. So, I'm not sure how necessary this port sharing is. 
And I don't know if anyone else would require the same for another protocol down the road. 
So, when we need to do this for other protocols, I don't think we'd need to do port sharing.

(*) I had said "I wasn't on the jabber at previous IETF, so maybe I missed some of the discussions." in that email. I made a typo. I meant "I was on the jabber (not in the meeting room), so maybe I missed some of the discussions."

Alper

---

From: Sam Hartman <[email-masked]>
Date: Fri, 05 Oct 2012 16:43:28 -0400

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:

    Alper> port sharing is.  And I don't know if anyone else would
    Alper> require the same for another protocol down the road.  So,
    Alper> when we need to do this for other protocols, I don't think
    Alper> we'd need to do port sharing.

The explanation Stuart gave you in the meeting for port sharing  applies
fairly universally.
I've generally found that applications with authentication over the same
port are significantly easier to deploy.
One of the many issues is firewalls, but the other issues Stuart
described also apply.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 5 Oct 2012 20:58:57 -0400

Hi Yoshi,

> I agree that EP is not needed in the context of PCP authentication. We probably do not need

I doubt we have any major disconnect regarding what parts of PANA would/wouldn't be used with PCP.  However, we need to capture that understanding and document it, for people who are attempting to implement PANA for use with PCP.  I believe we will find that we are only using a fairly small subset of PANA for this purpose.

>> Overloading a single bit in the PCP version field, because it happens to coincide with a flag bit in PANA doesn't seem like a method that will work for other protocols, and I am concerned that it…

The cleanest mechanism, IMO, would be to define a demultiplexing header that is used to determine whether the contents beyond that header are a PCP packet or a PANA packet.  If we want to send that header over the PCP port, though, it needs to look like a PCP header, which quickly devolves to the encapsulation approach.

Margaret

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 06 Oct 2012 10:24:33 +0900

Hi Margaret,

> I doubt we have any major disconnect regarding what parts of PANA would/wouldn't be used with PCP.  However, we need to capture that understanding and document it, for people who are attempting to…

I would rather think that the difference that I mentioned above is small.
I would say more than 90% of code is the same, that is one reason why I 
suggest to use PANA.

> The cleanest mechanism, IMO, would be to define a demultiplexing header that is used to determine whether the contents beyond that header are a PCP packet or a PANA packet.  If we want to send that…

I may be misunderstanding, but I don't think this is cleaner, as the 
demultiplexing header needs to look like a PCP header for PCP.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Sat, 6 Oct 2012 10:00:28 +0300

> One of the many issues is firewalls, but the other issues Stuart

Sam, I'm seeking elaboration on "Stuart explanation". What I remember is a high-level "configuring two ports is harder than configuring one". Maybe more was said but I couldn't capture it. In the interest of time in the call I didn't go after it. You seem to have an understanding of it , since you are referring to it. Can you elaborate on the issue?

What's the firewall issue? 

You are just naming the issues "Firewall issue", "Stuart issue". Can you expand them a bit beyond their titles?

Alper

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 8 Oct 2012 10:55:32 +0200

Hi Margaret:

Just a clarification below.

> I doubt we have any major disconnect regarding what parts of PANA would/wouldn't be used with PCP.  However, we need to capture that understanding and document it, for people who are attempting to…

Let me give some insight regarding your last sentence here. For people who are implementing PANA (we are, for example), Flags I (IP Reconfiguration) and P represents nearly nothing in source code. So removing it, it does not imply too much.

Curiously, OpenPANA does not add code for IP reconfig so far (it just includes #define I_FLAG). Adding it, it would not be a problem at all. However, it would not imply too much source code either.

Regarding PANA ping:
-- It would imply 4 transitions in PaC and PAA state machines, which is basically nothing.
-- In OpenPANA, it also includes alarm management once PaC is authenticated. It would imply to remove 15-20 lines of source code. Again, nothing.

Thus, if these are just the features that we do not have to implement to support PANA in the context PCP, it means we are still using a lot of PANA.

Best regards.  

> The cleanest mechanism, IMO, would be to define a demultiplexing header that is used to determine whether the contents beyond that header are a PCP packet or a PANA packet.  If we want to send that…

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------