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

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 31 Jan 2006 19:07:45 +0100

Hi Avi, 

thanks for your feedback. Let me try to clarify what i meant with my text proposal. 

There is the Device-Id AVP (in Section 8.2). 
Now, everything depends what people would like to see being discussed in Section 5.7 (about the 'Device ID Choice'). 

I see two options: 

1) Discussion what the Device-Id AVP could contain

Currently, the Device-Id AVP can either contain IPv4/IPv6 or link-layer addresses. 
In my current text proposal I focused on the question: What should go over the wire in this AVP?

2) Discussion about whether to use the Device-Id AVP or not

This is a more architectural discussion and reflected in the initial text (the text that is still in the draft). 
It tries to shed light on the question: What happens if I used (a) link layer security, (b) network layer security or (c) security protection outside PANA (e.g., physical security). 
If PANA wants to bootstrap (a) and (b) then a Device-Id conveys the necessary information to accomplish the goal. 
In case of (c) the Device-Id AVP is not used. 

I think we should provide a description along the lines of (1). 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: Avi Lior [mailto:[email-masked]] 
> Gesendet: Sonntag, 29. Januar 2006 22:51
> An: Tschofenig, Hannes; Alper Yegin; Yoshihiro Ohba; Hannes 
> Tschofenig PANA-Issues
> Cc: [email-masked]
> Betreff: RE: [Pana] Re: [issue229] Comments on Device-ID choice
> 
> Hannes seems to peg the Device ID to either a MAC address or 
> an IP address.
> 
> I strongly disagree.  At the IETF we create protocols that 
> are to be used broadly and therefore limiting the Device ID 
> to a MAC address or an IP address is inappropriate.
> 
> Instead I think we should be concentrating on guidelines as 
> to what the Device ID should contain and guidelines as to how 
> it is used.  We should then let SDOs define what the Device 
> ID is based on what is available for that particular deployement.
> 
> Avi 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Tschofenig, Hannes
> > Sent: Sunday, January 29, 2006 3:46 PM
> > To: Alper Yegin; Yoshihiro Ohba; Hannes Tschofenig PANA-Issues
> > Cc: [email-masked]
> > Subject: AW: [Pana] Re: [issue229] Comments on Device-ID choice
> > 
> > hi alper, 
> > 
> > how about changing the paragraph from:
> > 
> > "
> > 5.7  Device ID Choice
> > 
> >    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.
> > 
> >    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).  Based on that information, the PAA 
> > can decide
> >    what type of EP device id will be usedused when running 
> > PANA with the
> >    client.
> > 
> >    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.
> > 
> >    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.
> > 
> > " 
> > 
> > to:
> > 
> > "
> > 5.7  Device ID Choice
> > 
> >    The device identifier used in the context of PANA can be an IP
> >    address or a MAC address. 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).  Based on that information, the PAA 
> > can decide
> >    what type of EP device id will be used when running PANA with the
> >    client.
> > 
> >    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.
> > 
> >    In other cases, MAC addresses are used as device identifiers when
> >    they are available.
> > 
> >    If the security protection established via PANA is neighter based
> >    on the network layer nor on the link layer but is provided by 
> >    lower layers outside PANA (e.g., physical security as 
> provided by 
> >    some point-to-point links) then no device identifier can be 
> >    exchanged within PANA messages. 
> > "
> > 
> > 
> > ciao
> > hannes 
> > 
> > > -----Ursprüngliche Nachricht-----
> > > Von: Alper Yegin [mailto:[email-masked]]
> > > Gesendet: Freitag, 27. Januar 2006 00:56
> > > An: Tschofenig, Hannes; 'Yoshihiro Ohba'; 'Hannes Tschofenig 
> > > PANA-Issues'
> > > Cc: [email-masked]
> > > Betreff: RE: [Pana] Re: [issue229] Comments on Device-ID choice
> > > 
> > > > > > "
> > > > > >    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.
> > > > > > "
> > > > >
> > > > >
> > > > > I'm not sure if this last sentence really helps. It does not 
> > > > > really give any guidance.
> > > 
> > > > what guidance would you like to see, alper?
> > > 
> > > I'm not after any particular guidance or message. It's just that 
> > > reading the above sentence did not really clarify what 
> cannot be a 
> > > device identifier.
> > > 
> > > When I read it again, now I found it confusing too. On one 
> > side we are 
> > > talking about "device identifiers", and on the other side we are 
> > > talking about "identifiers related to physical or crypto 
> security".
> > > 
> > > I don't know what (if anything?!?) we should say here. But 
> > the current 
> > > text is not good, imho.
> > > 
> > > Alper
> > >  
> > > 
> > > 
> > > 
> > > > 
> > > > i had problems understanding the initial review comments.
> > > > 
> > > > so, what sort of info should we deliver (without trying to
> > > write the text
> > > > already in a specification type of style)?
> > > 
> > > 
> > 
> > _______________________________________________
> > Pana mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pana
> > 
> 

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 31 Jan 2006 17:58:25 -0500

Hennes,

> If PANA wants to bootstrap (a) and (b) then a Device-Id conveys the necessary information to accomplish the goal. 

Yes.

> I think we should provide a description along the lines of (1). 

In (c), EP still does non-cryptographic per-packet access control
based on a locally significant identifier or a MAC address, relying on
physical layer security.  If we describe the along the line of (1),
Device-Id AVP is not used, but MAC address is a device identifier.  So
I don't think provide a description along the lines of (1) is a good
idea.

Yoshihiro Ohba