Subject: RE: [Pana] Issue 5

From: [email-masked]
Date: Wed, 1 Oct 2003 11:20:27 +0300

Since the issue 5 was already closed I created a new issue about this.
http://danforsberg.info:8080/pana-issues/issue33

A comment about the Device-Id.
From section 4.1.7.

   o When a Device-Id AVP is included, the AVP is valid if the device 
   identifier type contained in the AVP matches the expected one (this 
   check is for PAA only) and the device identifier value contained in 
   the AVP matches the value extracted from the lower-layer 
   encapsulation header corresponding to the device identifier type 
   contained in the AVP. 

Section 4.7. seems to assume that Device-Id carries the PaC's device id in messages from PaC to PAA and PAA's device id in messages from PAA to PaC. I think this should be clarified in the draft. I.e. why "this check is for PAA only" is valid?

Br,
- Dan

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 01 October, 2003 03:39
> To: [email-masked]
> Subject: [Pana] Issue 5
> 
> 
> 
> New proposed text for section 4.7, for handling issue 5. 
> Comments welcome...
> http://danforsberg.info:8080/pana-issues/issue5
> 
> 4.7 Device ID Choice
>     
>    A PaC SHOULD configure an IP address before PANA if it 
> can. It might
>    either have a pre-configured IP address, or have to obtain one via
>    dynamic methods such as DHCP or stateless address 
> autoconfiguration.
>    Dynamic methods may or may not succeed depending on the local
>    security policy.  In networks where clients have to be authorized
>    before they are allowed to obtain an IP address, EPs will 
> detect the
>    associated activity and PANA protocol will be engaged 
> before the clients
>    can configure a valid IP address.
>    
>    Either an IP address or a link-layer address should be 
> used as device
>    ID at any time. It is assumed that PAA knows 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).
>    When IPsec-based mechanism [PANA-IPSEC] is the choice of 
> access control,
>    PAA should provide its IP address as device ID, and expect 
> the PaC to
>    provide its IP address in return.  In all other cases, link-layer
>    addresses can be provided from both sides.
>     
>    When IPsec-based access control is used but the PaC is using an
>    unspecified IP address in the authentication phase, the device ID
>    reported by the PaC MUST be either 0.0.0.0 or 0::0. This 
> device ID MUST
>    be recorded as a temporary one by the PAA until the PaC 
> obtains a valid
>    one and informs the PAA. Eventually PaC MUST obtain an IP address,
>    possibly by relying on the newly-created PANA session 
> [PANA-DHCP], in
>    order to gain full access to the network. PaC MUST update 
> the device
>    identifier registered on the PAA from unspecified to the 
> valid IP address
>    by initiating a PANA-Reauth-Request/PANA-Reauth-Answer exchange in
>    which the IP address of the PaC is contained in the Device-Id AVP.
> 
> References:
> 
> [PANA-IPSEC] M. Parthasarathy: "Securing the first hop in 
> PANA using IPsec,"
> Internet Draft, Internet Engineering Task Force, May 2003, Work in
> progress. 
> 
> [PANA-DHCP] H. Tschofenig, A. Yegin, D. Forsberg: 
> "Bootstrapping RFC3118
> Delayed authentication using PANA," Internet Draft, Internet 
> Engineering
> Task Force, June 2003, Work in progress. 
> 
> 
> _______________________________________________
> 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: Thu, 02 Oct 2003 01:24:50 -0700

On Wed, Oct 01, 2003 at 11:20:27AM +0300, [email-masked] wrote:
> Section 4.7. seems to assume that Device-Id carries the PaC's device id in messages from PaC to PAA and PAA's device id in messages from PAA to PaC. 

Yes.

> I think this should be clarified in the draft. I.e. why "this check is for PAA only" is valid?

"this check" means the device idententifier *type* check.  Since PaC
is expected to obey the device identifier type requested by the PAA, I
thought that the request type DI type is always considered as valid by
the PaC.  However, this is not always true since the PaC cannot obey a
device identifier type it does not support.  So both PaC and PAA would
need to check device idententifier type as well as device identifier
value.

So how about this?

"  o When a Device-Id AVP is included, the AVP is valid if the device
     identifier type contained in the AVP is supported (this check is
     for both PaC and PAA) and is the requested one (this check is
     for PAA only) and the device identifier value contained in
     the AVP matches the value extracted from the lower-layer 
     encapsulation header corresponding to the device identifier type 
     contained in the AVP.  Note that a Device-Id AVP carries the
     PaC's device identifier in messages from PaC to PAA and PAA's
     device identifier in messages from PAA to PaC."

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 02 Oct 2003 01:24:50 -0700

Yes.

So how about this?

Yoshihiro Ohba