Subject: RE: [issue9] Message format

From: <[email-masked]>
Date: Wed, 11 Jun 2003 13:37:04 +0300

Hi Alper,

Some comments below.

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 10 June, 2003 20:58
> To: Forsberg Dan (NRC/Helsinki); [email-masked]
> Subject: Re: [issue9] Message format
> 
> 
> Hi Dan,
> 
> >> I meant to say 16 bits each, not 32. Sorry.
> >> 
> >> Currently flags have only 8 bits (too few) and message type
> >> has 24 bits (too
> >> many, we ar not going to define 2^24 AVPs).I can see us
> >> quickly running out
> >> of flags if we keep it 8 bits only.
> > 
> > So far we have used only two flags (FIN & REQ), six left. I 
> don't see this as
> > a good enaough reason.
> 
> It's safer to allocate the bits while we have spare ones. 
> Maybe we won't
> need them, but if we do, we'll have the space. Clearly 24bits 
> for AVP space
> won't be utilized. The chances of requiring more than 8 flags 
> is much more
> than having nearly 2^24 AVPs.

I don't see this a valid argument against Diameter AVP compatibility. Anyway, 16 bits for flags is not a requirement and I have expressed my opinion about it's suitability for (PANA) protocol already.

It's much easier for vendors to specify one AVP that can be used with PANA and with Diameter, when there is no difference with the AVP format. Or let's say to use already specified AVPs with PANA. I see that this kind of approach favors PANA.

> > I think the protocol is way too complicated if we need
> > all the 8 different flags, worse if more than that (16). 
> Btw, AVPs can be used
> > for that purpose too (null data part).
> 
> This would not be a clean solution, right?

It's used already in other protocols in application level (i.e. kind of optional binary AVPs).

> 
> > 
> > Anyway, if we change this for the AVP header we can't use 
> existing AVPs
> > (Result-Code, Session-Id, Termination-Cause, EAP, etc.).
> 
> I see. I understand the desire (not a requirement) to re-use 
> pre-defined
> data types, but we need to evaluate pros and cons.

I guess we have been doing this..

> 
> 
> 
> >>>> Alper:>>> I don't think we need Add-device-ID and
> >>>> remove-device-ID AVPs in
> >>>> the design. So far we have identified use for add device ID
> >>>> (when a DHCP
> >>>> client gets an IP address and wants/needs to use IPsec for
> >>>> access control),
> >>>> but not for remove-device-id. As for the former necessity, I
> >>>> think we can
> >>>> just include device-id in the above message.
> >>> 
> >>> What about multihoming, MIP, and site local addresses in
> >> IPv6? Does PaC create
> >>> another session?
> >> 
> >> What are the issues that we need to handle there? Can we not
> >> handle them
> >> with the mechanism I outlined?
> > 
> > What if the MN wants to access the local network with link 
> local or site local
> > addresses at the same time with a global CoA address?
> 
> We have discussed this. Depending on the DI:
> 
> - if MAC address: then there is no issue. PaC can configure any
> IP address on the specified MAC address. Access control is based on
> the MAC address.

Where is this kind of scenario feasible?

That would mean that PaC can freely spoof IP addresses. I don't think it's a good idea. Filtering should be based on IP addresses as well. PANA is IP level protocol..

> - if IP address: This is the case where IPsec is used. For this, PaC
> determines one of the IP addresses as DI, most probably a link-local
> address. The traffic is tunneled using this DI as the local 
> end point. See
> PANA-Ipsec draft. Now, if the PaC wants to use other IP 
> addresses, they
> will be used only within the tunnel, hence the access control does not
> care about them. 

If DI is IP address, IPSec is not always used (physically secure links for example or links that provide L2 protection). Right?

> 
> > 
> > What if the MN has multiple interfaces (WLAN, Bluetooth, 
> Ethernet, 3G, etc.)
> > that all get a separate IP address from the same NAP 
> through the same PAA?
> > It's better to have one PANA session but add/delete 
> addresses/interfaces.
> 
> The simple answer is: all physical interfaces should do PANA 
> independently.
> Is there a problem with that?

This is not a good approach. Just think about the re-auth message flood, multiple session state information and even possibly multiple AAA backend sessions on the core network. Not scalable. Consumes resources on the client and on the network unnecessarily.

Another point is that adding new interface to the existing session is faster than doing the whole AA process from scratch.

> > 
> > Another possibility is to use only Device-Id AVP, but to 
> send multiple AVPs
> > (list of currently used Device Ids).
> > 
> >>>> Alper:>>> should we say the data is opaque and the exact
> >>>> content is outside
> >>>> the scope of this protocol.
> >>> 
> >>> OctetString is definition of the type not the content. You
> >> think we should
> >>> change the type?
> >> 
> >> No, I'm not suggesting any change. This is just additional
> >> text that does
> >> not conflict with yours.
> > 
> > Ah, ok. Should we make the Cookie AVP optional then? (i.e. 
> no mandatoryy flag
> > in the AVP header).
> 
> If PAA includes the cookie in the message, PaC MUST copy it back.
> But yes, we can say inclusion of cookie by PAA is optional. In some
> environments, cookie might not be needed (e.g., over physical links).

Ok.

> Alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 11 Jun 2003 12:03:43 -0700

> Where is this kind of scenario feasible?

In scenarios described in sections 4.1 and 4.2 of the usage scenarios draft,
plus 4.3 where link-layer ciphers are enabled at the end of PANA.
Effectively, almost anywhere IPsec is not used for access control.

> 
> That would mean that PaC can freely spoof IP addresses.

Exactly. But, this is a SEND problem, not PANA problem.

> I don't think it's a
> good idea. Filtering should be based on IP addresses as well. PANA is IP level
> protocol..
> 
> If DI is IP address, IPSec is not always used (physically secure links for
> example or links that provide L2 protection). Right?

If we are not using IPsec,it does not make sense to use IP address as the
DI, unless we are trying to solve SEND problems here. We should use
lower-layer identifiers.

> This is not a good approach. Just think about the re-auth message flood,
> multiple session state information and even possibly multiple AAA backend
> sessions on the core network. Not scalable. Consumes resources on the client
> and on the network unnecessarily.
> 
> Another point is that adding new interface to the existing session is faster
> than doing the whole AA process from scratch.

You are talking about room for possible optimizations, not problems.
I suggest we open this as a new issue, and follow it up from there. Rather
than continuously optimizing the basic design. I think such optimizations
touch more than the PANA design, so we should do a more thorough analysis.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Jun 2003 10:17:05 -0700

Hi Alper,

Are you suggesting either IP address or MAC address is always enough 
as DI?

I am asking this because I thought that there is a consensus on
supporting an option not only for using either L2 or L3 ciphers but
also for using both L2 and L3 ciphers.  This is because L2 ciphers
does not solve the problem of spoofing of network layer information
such as IP address.  SEND will solve IP address spoofing for ND but I
think subsequent data traffic can be still spoofed if it is not
protected with IPsec.  And the discussion result is reflected in the
current design of Protection-Capability AVP:

9.4.5  Protection-Capability AVP

   The Protection-Capability AVP (Code 1028) is of type Unsigned32.
   The AVP data is used as a collection of flags for different data
                        ^^^^^^^^^^^^^^^^^^^^^^^^
   protection capability indications.  Below is a list of specified
   data protection capabilities:

      0              UNKNOWN
      1		     L2_PROTECTION
      2		     IPSEC_PROTECTION

So 3(=1+2) can be specified as the AVP value.

Note that this does not necessarily mean that {Add,Delete}-Device-Id
AVP is needed.  Alternatively, PaC can always send the list of device
identifiers currently in use.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 11 Jun 2003 21:13:16 -0700

Hi Yoshi,

> Are you suggesting either IP address or MAC address is always enough

For solving in-scope problems, yes.

>  The AVP data is used as a collection of flags for different data

I'm not sure if this is something we should solve, or we can solve easily in
PANA. We are dealing with authorization to send and receive packets, not
authorization to use a particular IP address.

How is this solved today, or is it solved elsewhere? There might be
non-protocol solutions to this problem. For example, when there is either
link-layer encryption or IPsec encryption, an attacker cannot easily figure
out the IP address of a victim. If the attacker tries different random
addresses, its activity can be detected by its EP. If it somehow learns the
IP address of the victim, the anomaly (same IP address coming from different
locations) may be detected.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Jun 2003 19:15:01 -0700

> authorization to use a particular IP address.

I think I don't understand.  When PANA is used for bootstraping IKE, 
how we can dealing with authorization to send and receive packets 
without authorization to use a particular IP address?

> non-protocol solutions to this problem. 

Some enterprise requires the use of IPsec-VPN to access their network
via intranet 802.11 AP with WEP.  Even WEP will be replaced with
802.11i, they might still require the use of IPsec-VPN to improve 
enterprise security furthermore.

> For example, when there is either

- An insider that is authorized at layer-2 can be an attacker at layer-3.
- Broadcast/multicast L2 frames reveals the victim's IP address
  to the insider attacker.
- Since IP address is not only the spoofable field, the anomaly 
  does not provide a complete solution.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 12 Jun 2003 14:09:07 -0700

> without authorization to use a particular IP address?

Yes, when IPsec is used, the IP address that is used as DI is
cryptographically bound to the PaC, hence PaC can:
a- prove that it is authorized to send IP packets
b- prove that it is authorized to use that particular IP address

In the context of PANA, (a) is our goal. (b) is there only because this is
how IPsec works. If there were another per-packet protection mechanism that
does not need to bind the IP address to the trust relation, we could still
satisfy the PANA requirements using that, and that wouldn't involve proving
ownership of an IP address.

We might (have to) enable proving ownership of one DI to the EP as part of
proving authorization to send packets. But we do not have to extend this to
enable proving ownership of every IP address used by the PaC.

> enterprise security furthermore.

Does IPsec-VPN provide checks for authorization to use IP addresses, other
than the tunnel end point addresses? Does it automatically prevent use of
arbitrary IP addresses inside the tunnel?

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 11 Jun 2003 13:04:27 -0700

I agree that when IP address is used as DI, binding one IP address
(the one used as the IPsec tunnel endpoint address) to a PANA SA might
be sufficient.  Any IP address that is used only inside the IPsec
tunnel does not need to be bound to the PANA SA.  

On the other hand, this does not mean that we should not use both MAC
address and IP address as the DI, if we consider the case in which
both L2 and L3 ciphering are used at the same time.  Both ciphering
can be bootstraped by using PANA at the same time.

Regarding existing IPsec-VPN, the IPsec gateway assigns an inner IP
address to the IPsec client host.  Of course the IPsec gateway does
not care if additional level(s) of tunneling is made inside IPsec
tunnel and whichever IP address is used at each level, as long as it
sees the particular inner IP address when it decapsulate/encapsulate a
packet.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Thu, 12 Jun 2003 16:46:05 -0700

> can be bootstraped by using PANA at the same time.

I thought your original message was suggesting using L2 and L3 ciphering at
the same time to solve IP address ownership problem. I don't see this
problem as a motivation to use L2-L3 ciphering at the same time, since the
problem itself is outside the scope of PANA. If we include L2-L3 ciphering
for another reason (did we find one?), and it solves this problem with no
change to the protocol design, then its fine.

> sees the particular inner IP address when it decapsulate/encapsulate a

Then probably a DHCP server/proxy co-located with EP is all one needs.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 11 Jun 2003 15:55:24 -0700

> change to the protocol design, then its fine.

No, I did not mean that the motivation of using L2 and L3 ciphering at
the same time was to solve IP address ownership problem.  The
motivation is to protect network layer traffic (except for neighbor
discovery traffic which is solved by using SEND) from being spoofed by
insider attackers who uses L2 ciphering.  To protect network layer
traffic, IPsec tunnel is used and thus bootstrapping IKE from PANA is
needed.  This is just an additive combination of bootstrapping L2 and
L3 ciphering and thus I don't think we need any change to the current
protocol design to achieve this.

> Then probably a DHCP server/proxy co-located with EP is all one needs.

In addition, DHCP authentication needs to be bootstraped from PANA.

> Alper

Thanks,
Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 13 Jun 2003 11:14:54 -0700

> protocol design to achieve this.

When L2 ciphering is already used in the network, what kind of protection is
gained by also enabling IPsec between the PaC and EP (other than potentially
solving IP address ownership issues)?

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 11 Jun 2003 23:36:14 -0700

> solving IP address ownership issues)?

Insider attacker (meaning that he has L2 ciphering keys) can spoof
other insider's higher-layer fields in data packets (though he cannot
spoof L2 headers).  I think SEND only protects ND messages, not data
packets.  For the same reason, DHCP authentication might be useful 
even when L2 ciphering is used.

Yoshihiro Ohba