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

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Jan 2006 16:17:51 -0500

On Sun, Jan 08, 2006 at 02:07:55PM +0000, Hannes Tschofenig PANA-Issues wrote:
> 
> Hannes Tschofenig <[email-masked]> added the comment:
> 
> > 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".
> 
> 
> [hannes] what about using the term "AUTH AVP" similarly as the ikev2 spec uses 
> the term AUTH payload. 

This has been taken care of in Issue 221.

> 
> > 
> > >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
> 
> [hannes] i think that this issue will be resolved once we use two different 
> terms for layer-two addresses and for security mechanisms. 
> 
> > 
> > security.
> 
> We will revise the text to include the PPPoE/L2TP cases.
> 
> [hannes] what text do you have in mind? 

Something like:

"
   The device identifier used in the context of PANA can be an IP
   address, a MAC 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.  Identifiers that are not related to
   physical or cryptographic security (e.g., session identifiers in
   PPP tunneling protocols) are not used as device identifiers.
"

> 
> > 
> > >   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.
> 
> [hannes] i think that there is only a wording problem here: 
> 
> "
> It is assumed that the PAA knows the link type and the security
> mechanisms being provided or required on the access network (based on 
> configuration of the network administrator). For example, one network 
> administrator might want to use IPsec for securing the network access while 
> another one (for a different network) might rely on physical security. 
> "

This looks good.

> 
> > 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".
> 
> [hannes] has to be  a MUST

OK.

> 
> > 
> > >   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.
> 
> [hannes] i addressed this aspect already in the introduction.

OK.

Thanks,
Yoshihiro Ohba

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

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 26 Jan 2006 02:04:14 +0200

>    PPP tunneling protocols) are not used as device identifiers.

I'm not sure if this last sentence really helps. It does not really give any
guidance.

Alper