headers
Markku Savela | 20 Jul 2005 14:05

local / remote problems with SA


I've tried to prepare for the new Ipsec implementation and I keep
bumping into problems that are related to the local/remote vs. src/dst
in SA's.

My current attempt was to keep src/dst of the SA as is, and use the
transport selectors in local/remote style.

However, I run into a bit of a compatiblity problem. I need to support
old PFKEY with IKEv1, and in there I have a "transport selector" in a
form of port and protocol in address extension. The problem is that in
the "old" PFKEY there is no indication of the direction of the SA, and
I don't know whether the port in DST extesion is supposed to be local
or remote. (I course, I could try to make heuristic guess based on the
dst address, but it can fail, because not all own addresses are
necessarily known when SA is loaded).

I'm just sounding off list opinion about possible solutions. I think I
have the following choices:

1) use my current mixed model (SA dst/src, transport selectors
   remote/local) and in IKEv1 mode, make the heuristic guess.

2) go all the way, change SA's also to use remote/local, and in IKEv1
   mode, make the heuristic guess. I would probably have new
   SADB_EXT_ADDRESS_REMOTE and SADB_ADDRESS_LOCAL, which would be used
   instead of _SRC/_DST by IKEv2), as well as the new transport
   selectors SADB_EXT_SELECTOR_REMOTE, SADB_EXT_SELECTOR_LOCAL)

3) go all the way to other direction, ignore local/remote in SA's, and
(Continue reading)

Permalink | Reply | 1 comment |
headers
Markku Savela | 20 Jul 2005 19:31

Per packet information extension?


rfc2401bis and IKEv2 mention that the addresses and ports of the
triggering packet are passed in local and remote selectors as first
elements.

I find this somewhat inconvenient, and would prefer to pass this part
more compactly in a separate extension, containing:

 - src address
 - dst address
 - src port
 - dst port

This is more compact than using TS, because in TS we end up using
ranges, and it would take double space.
Permalink | Reply | 11 comments |
headers
RJ Atkinson | 20 Jul 2005 20:11
Favicon

Re: Per packet information extension?


On Jul 20, 2005, at 13:31, Markku Savela wrote:
> rfc2401bis and IKEv2 mention that the addresses and ports of the
> triggering packet are passed in local and remote selectors as first
> elements.
>
> I find this somewhat inconvenient, and would prefer to pass this part
> more compactly in a separate extension, containing:
>
>  - src address
>  - dst address
>  - src port
>  - dst port
>
> This is more compact than using TS, because in TS we end up using
> ranges, and it would take double space.

A cleaner fix might be to change the words in those Internet-Drafts
to revert to the conventional terminology of:
     source address
     destination address
     protocol
     source-port
     destination-port

If those documents are not yet RFCs, then interested parties might
want to make this suggestion on the IETF IPsec list as an implementer
concern -- and pointing out that this has backwards compatibility
issues for deployed applications software.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Markku Savela | 21 Jul 2005 00:38

Re: Per packet information extension?


> From: RJ Atkinson <rja <at> extremenetworks.com>
> 
> A cleaner fix might be to change the words in those Internet-Drafts
> to revert to the conventional terminology of:
>      source address
>      destination address
>      protocol
>      source-port
>      destination-port

This is somewhat OT for PFKEY list. However, despite my problems with
remote/local in relation to SADB, I'm perfectly happy to use the
local/remote concepts in the actual policy and policy selectors.
Permalink | Reply | 0 comments |
headers
Dan McDonald | 21 Jul 2005 16:44
Picon

Re: local / remote problems with SA


On Wed, Jul 20, 2005 at 03:05:33PM +0300, Markku Savela wrote:
> 
> However, I run into a bit of a compatiblity problem. I need to support
> old PFKEY with IKEv1, and in there I have a "transport selector" in a
> form of port and protocol in address extension. The problem is that in
> the "old" PFKEY there is no indication of the direction of the SA, and
> I don't know whether the port in DST extesion is supposed to be local
> or remote. (I course, I could try to make heuristic guess based on the
> dst address, but it can fail, because not all own addresses are
> necessarily known when SA is loaded).

That last bit (not all addresses are known when the SA is loaded) is a good
justification for direction bits in PF_KEY v3.  For example:

	#define	SADB_SAFLAGS_INBOUND  xxx	/* Inbound SA */
	#define	SADB_SAFLAGS_INBOUND  xxx	/* Outbound SA */

Out of your choices...

> 3) go all the way to other direction, ignore local/remote in SA's, and
>    base everything in SRC/DST. This leave it up to IKEv2 to map
>    local/remote vs. dst/src. The selectors would also be
>    SADB_EXT_SELECTOR_SRC, SABD_EXT_SELECTOR_DST.

I agree.

In 2401:

   A security association is uniquely identified by a triple consisting
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francis Dupont | 25 Jul 2005 18:11
Picon
Picon

Re: Per packet information extension?


 In your previous mail you wrote:

   rfc2401bis and IKEv2 mention that the addresses and ports of the
   triggering packet are passed in local and remote selectors as first
   elements.

   I find this somewhat inconvenient, and would prefer to pass this part
   more compactly in a separate extension, containing:

    - src address
    - dst address
    - src port
    - dst port

=> + protocol

   This is more compact than using TS, because in TS we end up using
   ranges, and it would take double space.

=> I don't understand your concern: do you like to modify IKEv2
because a TS pair is too large or do you address an issue in
PF_KEY?
BTW for MIPv6 support I proposed to add similar infos to ACQUIRE
messages, there are three solutions:
 - put the whole triggering packet
 - put enough of it (my proposal)
 - put a summary of it (i.e., extract the infos in the kernel).
The extension (SADB_X_EXT_PACKET) should be in the next version
of draft-sugimoto-mip6-pfkey-migrate-xx.txt. The idea is simple:
(Continue reading)

Permalink | Reply | 8 comments |
headers
Markku Savela | 25 Jul 2005 20:00

Re: Per packet information extension?


> From: Francis Dupont <Francis.Dupont <at> enst-bretagne.fr>
>  In your previous mail you wrote:
> 
>    rfc2401bis and IKEv2 mention that the addresses and ports of the
>    triggering packet are passed in local and remote selectors as first
>    elements.
> 
>    I find this somewhat inconvenient, and would prefer to pass this part
>    more compactly in a separate extension, containing:
>    
>     - src address
>     - dst address
>     - src port
>     - dst port
>    
> => + protocol
> 
>    This is more compact than using TS, because in TS we end up using
>    ranges, and it would take double space.
>    
> => I don't understand your concern: do you like to modify IKEv2
> because a TS pair is too large or do you address an issue in

I'm only talking about PFKEYv2. It's totally upto IKEv2 what it does
with this information. It can easily insert the information to it's
traffic selectors, which as you know, have different semantics than
what RFC-2401bis specify (e.g. the logic how remote and local
selectors are supposed to be combined). I plan to have PFKEY TS to
follow the 2401bis logic, because that's how the policy selectors
(Continue reading)

Permalink | Reply | 7 comments |
headers
Dan McDonald | 25 Jul 2005 20:04
Picon

Re: Per packet information extension?


On Mon, Jul 25, 2005 at 09:00:54PM +0300, Markku Savela wrote:

<mucho snippage deleted!>

> Secondly, I think something is architecturally badly wrong, if IKE (or
> even IPSEC) needs to know about Mobile IP.

There are some who say that you could remove "if IKE (or even IPSEC) needs to
know" and have a remaining sentence that's been true for a decade.  :)

Dan
Permalink | Reply | 3 comments |
headers
Francis Dupont | 26 Jul 2005 14:35
Picon
Picon

Re: Per packet information extension?


 In your previous mail you wrote:

   > BTW for MIPv6 support I proposed to add similar infos to ACQUIRE
   > messages, there are three solutions:
   >  - put the whole triggering packet
   >  - put enough of it (my proposal)
   >  - put a summary of it (i.e., extract the infos in the kernel).
   > The extension (SADB_X_EXT_PACKET) should be in the next version
   > of draft-sugimoto-mip6-pfkey-migrate-xx.txt. The idea is simple:
   > the IKE daemon gets the triggering packet, recognizes a home
   > registration binding update and launches the phase one with
   > the right address (the care-of address) when stupid application
   > of the SPD gives the wrong one (the home address, usable only
   > after the home registration).

   Whether home or care address in acquire, depends then on
   application.

=> no, it should be always the home address. The problem is this is
correct for all applications at the exception of the SA establishment
tool used to protect the home registration binding update.

   I don't remember having this problem.

=> this problem occurs in a very special case (MIPv6 security
bootstrapping on the mobile node).

   Secondly, I think something is architecturally badly wrong, if IKE (or
   even IPSEC) needs to know about Mobile IP.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Francis Dupont | 26 Jul 2005 14:42
Picon
Picon

Re: Per packet information extension?


 In your previous mail you wrote:

   On Mon, Jul 25, 2005 at 09:00:54PM +0300, Markku Savela wrote:

   <mucho snippage deleted!>

   > Secondly, I think something is architecturally badly wrong, if IKE (or
   > even IPSEC) needs to know about Mobile IP.

   There are some who say that you could remove "if IKE (or even IPSEC) needs
   to know" and have a remaining sentence that's been true for a decade.  :)

=> I disagree: IMHO the real source of the issue is PFKEY users believe
the endpoint addresses are tunnel mode only parameters. This is another
issue from the lack of regard for the transport mode...

Regards

Francis.Dupont <at> enst-bretagne.fr
Permalink | Reply | 2 comments |

Gmane