Subject: Re: [Pana] pana-pana Issue229: Comments on Device-ID choice

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 03 Jan 2006 19:38:44 -0500

> >5.7  Device ID Choice
> >
> >   The device identifier used in the context of PANA can be an IP
> >   address, a MAC address, 
> >
> Here is the "MAC" conflict I referred to earlier. You could fix this by 
> renaming the MAC AVP, or calling this a "layer 2 address" as you do 
> earlier in the doc. I think renaming the MAC AVP makes more sense, but 
> do as you like.

I would prefer keeping "MAC AVP", and chaning "MAC address" to
"link-layer address".

> 
> >or an identifier that is not carried in data
> >   packets but has local significance in identifying a connected device
> >   (e.g., circuit id, PPP interface id).  The last type of identifiers
> >   are commonly used in point-to-point links where MAC addresses are
> not
> >   available and lower-layers are already physically or
> >   cryptographically secured.
> >  
> >
> PPPoE and L2TP use an identifier for a PPP session that is carried in 
> the header itself, and have nothing to do with physical or cryptographic
> 
> security.

We will revise the text to include the PPPoE/L2TP cases.

> 
> >   It is assumed that the PAA knows the link type and the security
> >   mechanisms being provided or required on the access network (e.g.,
> >   based on physical security, link-layer ciphers enabled before or
> >   after PANA, or IPsec).
> >
> This may be a bold assumption for IPsec.

Since the applicability of PANA is within access network, I think it
is not too bold assumption.

> 
> >  Based on that information, the PAA can decide
> >   what type of EP device id will be usedused when running PANA with
> the
> >   client.
> >  
> >
> s/usedused/used

OK.

> 
> Does the PAA decide, or does an administrator configuring PANA decide? 

The latter.

> I
> think you are starting to see some of the suffering of supporting too 
> many options here.

Three options (physical security, link-layer ciphers enabled before or
after PANA, or IPsec) seems not too many.

> 
> >   When IPsec-based security [I-D.ietf-pana-ipsec] is the choice of
> >   access control, the PAA SHOULD provide IP address(es) as EP(s)'
> >   device ID, and expect the PaC to provide its IP address in return.
> >   Similarly, IP addresses are used when the EP(s) is not on the same
> IP
> >   subnet as the PaC is.
> >  
> >
> If IP addresses are not used for IPsec, what is? Point here is whether 
> this is a SHOULD or a MUST.

I think it should be "MUST".

> 
> >   In other cases, MAC addresses are used as device identifiers when
> >   they are available.
> >  
> >   If non-IPsec access control is enabled, and a MAC address is not
> >   available, locally-significant identifiers (e.g., as a circuit id)
> >   MUST be used as device id.  Note that these identifiers are not
> >   exchanged within PANA messages.  Instead, peers rely on lower-layers
> >   to provide them along with received PANA messages.
> >  
> >
> This is another linkage of PANA with a layer below IP, invalidating the 
> claim in the introduction that PANA can work with any link-layer, and 
> that PANA/IP isolates EAP from all link-layer specifics.

I expect this specific comment to be solved under Issue218: AD
comments on Introduction.

Yoshihiro Ohba

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

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 4 Jan 2006 19:45:57 +0200

> I would prefer keeping "MAC AVP", and chaning "MAC address" to

How about replacing "MAC" with "MIC"?

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 04 Jan 2006 14:04:53 -0500

> How about replacing "MAC" with "MIC"?

RFC 2828 does not recommend the following terms in ISDs (Internet
Standards documents):

   $ message integrity check
   $ message integrity code
      (D) ISDs SHOULD NOT use these terms because they mix concepts in a
      potentially misleading way. (The word "message" is misleading
      because it suggests that the mechanism is particularly suitable
      for or limited to electronic mail. The word "code" is misleading
      because it suggests that either encoding or encryption is
      involved, or that the term refers to computer software.) Instead,
      use "checksum", "error detection code", "hash", "keyed hash",
      "Message Authentication Code", or "protected checksum", depending
      on what is meant.

Yoshihiro Ohba