Subject: Re: Re: draft-ietf-pana-usage-scenarios-00.txt

From: Paal Engelstad <[email-masked]>
Date: Thu, 31 Jan 2002 22:41:53 +0100

Yoshihiro Ohba,

I think the usage scenario document is useful, but I also support the idea of explicitly pointing out which parts are out of scope of PANA and which are within.

Your document links the PANA authentication functionality/service (in scope) to access contol enforcement, such as address filtering and per-packet authentication of data traffic (out of scope). Good.

The document also links PANA Authentication functionality/service to routing, in section 3.1.1 "Multiple routers". Hopefully, to simplify the task of PANA WG, we will be able to keep routing out of scope, too!

For example: Couldn't your proposed solution in section 3.1.1 simply be modelled as a combination of subnetting and source IP-address filtering? From the top of my head:
 
- Subnetting for incoming traffic: Each AR manages a range of IP-addresses (i.e. prefix) under the total range of IP-addresses (a shorter prefix) that comprises what you call the access "subnet". Traditional IP routing handles the rest.

- Source IP-Address filtering for outgoing traffic: For outgoing traffic, each AR forwards only traffic with source IP address within the range of IP-addresses managed by the AR.

Thus, to me section 3.1.1 can be simlyfied significantly, and we can keep routing out of scope. 

But since you elaborate so much on this issue, I expect there are some flaws in my proposal above. I may have overlooked some fundamental issues...

Paal

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 31 Jan 2002 17:19:40 -0500

> I think the usage scenario document is useful, but I also support the idea of explicitly pointing out which parts are out of scope of PANA and which are within.

I agree.

> Your document links the PANA authentication functionality/service (in scope) to access contol enforcement, such as address filtering and per-packet authentication of data traffic (out of scope). Go…

OK.

> But since you elaborate so much on this issue, I expect there are some flaws in my proposal above. I may have overlooked some fundamental issues...

That scheme will only work for IPv6, based on the fact that each AR on
the same shared media can advertise a different prefix on the shared
media.  I don't think the same thing applies to IPv4.

Anyway, I can add the text to the usage scenarios I-D, or
alternatively we could expect framework I-D to include that.

> Paal

Yoshihiro Ohba