Subject: Issue4: (new) Device identifier (types)

From: Alper Yegin <[email-masked]>
Date: Thu, 07 Aug 2003 14:42:10 -0700

http://www.danforsberg.info:8080/pana-issues/issue4

The issue text refers to multi-homed hosts and device ID changes. These are
covered under separate issues (#16 and #5).

So, issue #4 should only be talking about new DI types. And the one
mentioned in the text is "subnet prefix." Unless anyone has another proposed
device ID type, let's discuss that.

I'm trying to understand the utility of setting the DI as a subnet prefix.
If this is proposed to enable mobile routers to connect to an access
network, we can easily achive that by using either a mac address DI along
with L2 ciphering, or a single IP address DI along with IPsec. In the latter
case, any IP address can be used inside the IPsec tunnel. Aside from not
needing it, I'm also not sure how we can use this DI as an IPsec end point.

Unless anybody objects, I recommend we reject this issue.

Comments please.

Alper

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 13 Aug 2003 13:47:12 -0700

> 
> On Wed, Aug 13, 2003 at 05:01:45PM +0300, 
> [email-masked] wrote:
> > One of the questions in IETF57 PANA wg meeting was that should PAA
> > take care of authorizing IP addresses. I think it should, because 
> > it informs the EPs about the filtering rules.
> > 
> > If I've understood correctly IPSec tunnel is used between PaC and
> > EP/PAA with link local addresses. Then the inner IP address in the 
> > IPSec tunnel should be PANA DI. In this case it could be a subnet 
> > prefix, right?
> 
> The inner IP address in the IPsec tunnel is not necessarily 
> be a PANA DI, since the outer IP address (i.e., a link local 
> IP address) can be used as a PANA DI.  Authorization for the 
> inner IP address can be done in IKE negotiation by which an 
> appropriate per-packet filtering rule for the inner IP 
> address is set to IPsec SPD.  IKE also supports negotiatin of 
> subnet-prefix parameters for inner packets.
> 
It is not possible to know the inner IP addresses always i.e the
dynamic SPD setup should be very simple. Just use the DI (link-local
in IPv6 or the DHCP address in IPv4) for binding to the Ipsec SA.

> 
> > 
> > If PANA uses MAC as the DI (and even with IPSec tunnel), 
> PAA/EP can't
> > control the IP addresses the PaC is using (inner IP address in the 
> > IPSec tunnel). Anyway, I firmly believe that access networks wount 
> > pass packets with ANY source IP address to the network (refusal to 
> > route). So I don't think that any IP address can be used inside the 
> > IPSec tunnel.
> 
> I think the required functionality of per-packet filtering 
> for inner packets is already covered by the combination of:
> 
> - Support of DI update (from MAC address to IP address).
> 
> - Use of link-local address as a DI when bootstrapping IKE.
> 
> - Use of IKE for establishing an tunnel mode IPsec SA between 
> PaC and EP.
>   (as a result, an SPD entry for inner packet filtering will 
> be created.)
> 
As I mentioned in other mail, we don't need this. We are talking
about access control. MIC is sufficient for authorization. 

-mohan

> - Use of IPsec tunnel (whether inner packet filtering is done
>   based on the created SPD entry).
> 
> 
> Yoshihiro Ohba
> 
> 
> > 
> > - Dan
> > 
> > > -----Original Message-----
> > > From: ext Alper Yegin [mailto:[email-masked]]
> > > Sent: 08 August, 2003 00:42
> > > To: [email-masked]
> > > Subject: Issue4: (new) Device identifier (types)
> > > 
> > > 
> > > 
> > > mentioned in the text is "subnet prefix." Unless anyone 
> has another 
> > > proposed device ID type, let's discuss that.
> > >

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 14 Aug 2003 10:02:59 -0700

> 
> Let's face the problem. If we don't bind the global 
> IP address to the PANA session, PaC is able to spoof 
> all the other (possibly authenticated) clients (and 
> in the worst case even network elements etc.).
> 
> If you say this problem is out of scope of PANA, I don't
> agree with you. This is a question that needs to be 
> resolved in a standard. Otherwise vendors will do 
> something by their own.
> 
Please point to me where in requirements is this specified ?
At least I don't remember reading one.

The important goal of the working group is to specify PANA
protocol. And we also agreed that we will come up with some
mechanism to provide access control. We are documenting
one way of doing this i.e using Ipsec. Now we can keep
adding more to this list. We can explore to see if we
can use Ipsec to solve all the problems. But is this
really in scope ? If Ipsec solves it for free, then it
is fine. But I still strongly feel that it is not in
the scope.

-mohan

> In short, PANA MUST provide support for IP address 
> spoofing prevention both with L2 and L3 ciphering, or 
> without ciphering at all. Otherwise we have a serious
> security problem.
> 
> Since PANA has a SA and thus supports authenticated 
> messages between PaC and PAA, it is a proper protocol
> to use for IP address spoofing prevention.
> 
> - Dan
> 
> > From: ext Mohan Parthasarathy [mailto:[email-masked]]
> > Sent: 13 August, 2003 23:47
> > To: Yoshihiro Ohba; Forsberg Dan (NRC/Helsinki)
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: Issue4: (new) Device identifier (types)
> > 
> > 
> > 
> >  
> > > 
> > As I mentioned in other mail, we don't need this. We are 
> talking about 
> > access control. MIC is sufficient for authorization.
> > 
> > -mohan
> > 
> > > > > The issue text refers to multi-homed hosts and device ID 
> > > > > changes. These are covered under separate issues (#16 and #5).
> > > > > 
> > > > > I'm trying to understand the utility of setting the DI as a 
> > > > > subnet prefix. If this is proposed to enable mobile 
> routers to 
> > > > > connect
> > > to an access

---

From: <[email-masked]>
Date: Fri, 15 Aug 2003 10:12:45 +0300

> From: ext Yoshihiro Ohba [mailto:[email-masked]]
<klip>
> Except for the following case: If neither L3 ciphering is used nor the
> lower-layer is physically secured, it is not possible to prevent IP
> address spoofing by authenticated attackers.

The security can be enhanced here too. If only authenticated nodes with authorized IP addresses can send packets, then spoofing other addresses (like IP addresses that are not currently authorized for usage and other network prefixes that are not on the same link) is not possible.

> I believe IPsec is the proper protocol to use for IP address spoofing
> prevention.  What PANA must do for this is to bootstap IPsec.

IPSec is not always used. Consider the case with physically secure links.

I suggest that PANA lists all the IP addresses it is using. If changes are required, PANA-Reauth messages can be used (updating the list of IP addresses/prefixes in use). Authorization decision for the IP address usage can be set out of the scope of PANA. For example draft-tschofenig-pana-bootstrap-rfc3118-00.txt can help in this authorization decision.

- Dan

> > > > > > changes. These are
> > > > > > subnet prefix.

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 15 Aug 2003 09:37:11 -0700

> Mohan,
> 
> Here are some references to the requirements document.
> 
> draft-ietf-pana-requirements-07.txt:
>    4.1.2. Authorization, Accounting and Access Control  
>      
>    After a device is authenticated using PANA, it MUST be authorized 
>    for "network access." That is, the core requirement of PANA is to 
>    verify the authorization of a PaC so that PaC's device may 
> send and 
>    receive any IP packets.
> 
> draft-ietf-pana-requirements-07.txt:
>    4.4. PAA-to-EP Protocol 
>     
>    PANA does not assume that the PAA is always co-located with the 
>    EP(s). Network access enforcement can be provided by one or more 
>    nodes on the same IP subnet as the client (e.g., multiple 
> routers), 
>    or on another subnet in the access domain (e.g., gateway to the 
>    Internet, depending on the network architecture). When the PAA and 
>    the EP(s) are separated, there needs to be another transport for 
>    client provisioning. This transport is needed to create access 
>    control lists to allow authenticated and authorized 
> clients' traffic 
>    through the EPs. PANA Working Group will preferably identify an 
>    existing protocol solution that allows the PAA to deliver the 
>    authorization information to one or more EPs when the PAA is 
>    separated from EPs.
> 
> Authorization for "network access" includes IP address authorization. 
> The requirements spec (above) says "-- so that PaC's device 
> may send and receive any IP packets". My interpretation about 
> this is that in the 
> beginning PaC is able to communicate only to the PAA, but after 
> authentication and authorization PaC is able to really access the 
> Internet.
> 
If you just use the IP address for authorizing in shared links,
then some one can spoof and steal the service. So, you
need some stronger mechanism e.g. Ipsec. With Ipsec, you can be sure
that the packets are being sent only by authenticated clients and there
is no service theft in the network. If authenticated clients can spoof
one another, they need to protect themselves using end-to-end mechanism.
Sure, Access network can do something to prevent it. Unless there are
some explicit words in the requirements, I disagree with this being
a requirement. There was some discussion in the threats evaluation draft
early on but later was removed. 

> Also, PAA needs to have the info of PaC's IP address(es) for 
> PAA-to-EP 
> protocol to carry it to the EP that really needs this info for 
> access control.
> 
Sure, but define access control please ? I see it as "only authenticated
clients use my network". You want to see addditional things like no
spoofing etc. Perhaps possible, but I would like to see the requirements
more clear on this. SEND working group is working on ways to prevent
stealing of IPv6 addresses. So, I am not sure what we need to do here.

> So, this really is in the scope of PANA.
> 
Please see above. Are you saying that PANA should come up with some
mechanism to prevent address spoofing ?

-mohan

> > Sent: 14 August, 2003 20:03
> > To: Forsberg Dan (NRC/Helsinki); [email-masked]
> agree with 
> > > you. This is a question that needs to be resolved in a standard. 
> > > Otherwise vendors will do something by their own.
> > > 
> > Please point to me where in requirements is this specified 
> ? At least 
> > I don't remember reading one.
> > 
> protocol. 
> > And we also agreed that we will come up with some mechanism 
> to provide 
> > access control. We are documenting one way of doing this i.e using 
> > Ipsec. Now we can keep adding more to this list. We can 
> explore to see 
> > if we can use Ipsec to solve all the problems. But is this
> > > > > The inner IP address in the IPsec tunnel is not 
> necessarily be a 
> > > > > PANA DI, since the outer IP address (i.e., a link local IP 
> > > > > address) can be used as a PANA DI.  Authorization for 
> the inner 
> > > > > IP address can be done in IKE negotiation by which an 
> > > > > appropriate per-packet filtering rule for the inner 
> IP address 
> > > > > is set to IPsec SPD.  IKE also supports negotiatin of 
> > > > > I think the required functionality of per-packet 
> filtering for 
> > > > > inner packets is already covered by the combination of:
> > > > > 
> > > > > > > network, we can easily achive that by using either a mac 
> > > > > > > address DI along with L2 ciphering, or a single 
> IP address 
> > > > > > > DI along with IPsec. In the latter
> > > > > > > needing it, I'm also not sure how we can use this 
> DI as an 
> > > > > > > IPsec end point.
> > > > > > >

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 15 Aug 2003 09:39:04 -0700

t on the same link) is not possible.
> I suggest that PANA lists all the IP addresses it is using. 

Tell me how you want to stop the PaC from listing some other
node's IP address. This is want SEND does.

-mohan

> If changes are required, PANA-Reauth messages can be used 
> (updating the list of IP addresses/prefixes in use). 
> Authorization decision for the IP address usage can be set 
> out of the scope of PANA. For example 
> draft-tschofenig-pana-bootstrap-rfc3118-00.txt can help in 
> this authorization decision.
> 
> - Dan
> 
> > 
> > Yoshihiro Ohba
> > 
> > > 
> > > - Dan
> > > 
> > > > > > > subnet prefix. If this is proposed to enable 
> mobile routers 
> > > > > > > to connect
> > > > > to an access
> > > > > > > address DI along

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 19 Aug 2003 10:52:28 -0700

> That is out of the scope, but PANA can act as a carrier for 
> that information. Or should we say that the addresses that 
> PaC is using can be bound to the PANA session within the PANA 
> protocol - securely.
> 
I am not sure I parsed everything correctly. PANA protocol
is about authenticating the clients. Are you saying that
we should extend PANA protocol to interact with other protocols
to authorize the addresses the clients can use ? I guess
you are talking about how to bind the addresses to the
PANA clients securely.
 
> I'm not saying that PANA should do something that is in the 
> scope of SEND. PAA could for example query other parties:
>  - PANA and DHCP interworking, 
>  - PANA and MIPv6/v4 interworking, 
>  - PANA and SEND interworking, 
>  - PANA and "local administration" interworking (network policies, 
>    access control, packet filtering and firewalling)
> if the listed DIs are ok for the PaC.
> 
> What do you think about this?
> 
Some of these would be interesting to analyse about. But it
still might be a bit too much for this WG to handle.

-mohan

---

From: <[email-masked]>
Date: Wed, 20 Aug 2003 13:58:45 +0300

> you are talking about how to bind the addresses to the

No, I'm not saying that we should extend the scope of PANA 
protocol. Yes, I'm talking about to bind the addresses to 
the PANA session.

- Dan