IKEv2 tester update

Hi, all.

As I announced at 72nd IETF meeting,
we, TAHI Project released IKEv2 conformance tester.

In that time, v1.0.0a1 was the newest,
but it contained some inconsistency from the test specification.

Now, v1.0.0a2 has been ready.
Please use v1.0.0a2 instead of v1.0.0a1,
if you have interesting in it.

It can be downloaded from <http://www.tahi.org/ikev2/>.

Thanks,

--

-- 
Yukiyo Akisada <akisada <at> tahi.org>

IKEv2 bis guidelines

Hi,

Following the Dublin meeting, we would like to clarify the charter 
regarding the scope of the IKEv2 bis document.

General: The goal of the IKEv2 bis document is to clarify the protocol. 
The goal is not to extend it. Specifically:

* The document will combine RFC 4306 (IKEv2) and RFC 4718 (IKEv2 
clarifications), but no other RFCs.
* The document will add clarifications based on the community's 
deployment experience.
* It is OK to correct minor technical errors and contradictions in the 
source documents. Any such corrections will be pointed out explicitly - 
preferably in an appendix (so that people using the old documents can 
scan it to discover problem areas).
* The document will not add any "nice to have" extensions, no matter how 
much technical sense they make.

Thanks,
    Yaron

Re: IKEv2 bis guidelines

Hi Yaron,

I agree. 
That should be the way to go. Thanks for the clarification! 

Regards,
Ahmad

> -----Original Message-----
> From: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] 
> On Behalf Of Yaron Sheffer
> Sent: Tuesday, August 05, 2008 1:12 AM
> To: ipsec <at> ietf.org
> Subject: [IPsec] IKEv2 bis guidelines
> 
> Hi,
> 
> Following the Dublin meeting, we would like to clarify the 
> charter regarding the scope of the IKEv2 bis document.
> 
> General: The goal of the IKEv2 bis document is to clarify the 
> protocol. 
> The goal is not to extend it. Specifically:
> 
> * The document will combine RFC 4306 (IKEv2) and RFC 4718 
> (IKEv2 clarifications), but no other RFCs.
> * The document will add clarifications based on the 
> community's deployment experience.
> * It is OK to correct minor technical errors and 
> contradictions in the source documents. Any such corrections 

Re: Review of draft-eronen-ipsec-ikev2-ipv6-config-04.txt

Hi Tero,

On Monday 28 July 2008, Tero Kivinen wrote:
> > 6.  Solution Sketch
> > 6.1.  Initial Exchanges
> >
> >    1) During IKE_AUTH, the client sends a new configuration
> > attribute, INTERNAL_IP6_LINK, which requests a virtual link to be
> > created.  The attribute contains the client's interface ID for
> > link-local address (other addresses may use other interface IDs).
> >  Typically, the client would also ask for DHCPv6 server address;
> > this is used only for configuration, not address assignment.
>
> ...
>
> >    (To be determined: is it necessary to include the gateway's
> > link- local interface ID?  Probably the client does not need it.)
>
> I do not think clinet needs the gateway's link-local interface ID,
> and in that case we can change the INTERNAL_IP6_LINK attribute to
> follow the standard rule almost all other attributes use, i.e. client
> proposes something, and server replies with the acceptable value.
> I.e. client would send its own link-local interface ID (and
> optionally IKEv2 Link ID) to the server in INTERNAL_IP6_LINK and
> server would reply with that same link-local interface ID to verify
> that client is allowed to use that address (and the IKEv2 link ID).

I'm understanding this as implying it's possible that the gateway 
replies with a different link-local interface ID which have to be used 
by the client. 

Motivation for ESP-null marking

Hi,

Although we have a charter item on special marking of ESP packets with 
null encryption, there have been some questions raised about the 
rationale for doing this. No matter which solution we choose, this is a 
very fundamental protocol addition (layer 3, directly handled by 
hardware), so Paul and I would like to have one more round of discussion 
on whether this is really needed.

Let us ignore the details of the solution proposals for a while (1 
protocol number vs. 2, ESP wrapper vs. keeping the existing ESP header), 
and consider whether there is a need to have any solution at all for 
this problem:

    * What is the security/threat environment that we are dealing with?
      In other words, what is the security policy for which we want an
      efficient enforcement?
    * Are there alternative ways to detect unencrypted traffic in the
      existing ESP, e.g. heuristics? Are they easy to implement in
      software or in hardware? How significant is the problem of false
      positives?
    * For a "reasonable security policy" (as above) can we provide a
      hardware-only enforcement solution with current technology, or do
      we have to send every packet into software (general CPU or network
      processor)? And if software is involved, does it make the entire
      "efficient to implement in hardware" discussion irrelevant?

When you respond, please describe your personal or your company's 
experience with hardware-based packet processing, for extra points 

Secure Crash Discovery for IKEv2

This is a followup to my mini-presentation in Dublin.

The problem we're trying to solve is that of a state de- 
synchronization between two IKE peers. This could take several minutes  
to discover and resolve, and no IPsec traffic can flow in that time.

The following Wiki page describes the problem, and two proposed  
solutions.

http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki/SecureCrashDiscovery

We would like to solicit input from the WG about these two solutions,  
so that we can either combine them or choose between them, and proceed  
with a unified draft.

Thanks in advance

Frederic, Pratima and Yoav

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: Motivation for ESP-null marking

On Wed, Aug 06, 2008 at 04:35:29PM +0300, Yaron Sheffer wrote:
> Let us ignore the details of the solution proposals for a while (1 
> protocol number vs. 2, ESP wrapper vs. keeping the existing ESP header), 
> and consider whether there is a need to have any solution at all for 
> this problem:
> 
>    * What is the security/threat environment that we are dealing with?
>      In other words, what is the security policy for which we want an
>      efficient enforcement?

Clearly the security policy would be: use confidentiality protection.

Of course, there's no way to ensure that the SAs' keys haven't be made
public or otherwise shared with interested third parties.  That's what
makes ESP-null marking seem silly -- it's like the reverse of the
"secure" bit gag, an "insecure" bit which tells you nothing about the
security of packets that don't have that bit set.

One might argue that middle box enforcement of confidentiality
protection policies adds some value where you can trust end nodes not to
reveal their secret keys.  But in such an environment you might as well
assume that end nodes have the correct policies too, and so there's no
need to enforce those policies in middle boxes.

>    * Are there alternative ways to detect unencrypted traffic in the
>      existing ESP, e.g. heuristics? Are they easy to implement in
>      software or in hardware? How significant is the problem of false
>      positives?

I suspect there'd be enough header content, even in transport mode ESP

Clarification on Protocol ID

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: Motivation for ESP-null marking

I should add that without ESP-null middle box filtering that requires
the use of ESP is, indeed, filtering on the basis of an "insecure" bit
since there's no way for the middle box to ensure that IPsec and ESP are
actually being used correctly.  And yet I wouldn't advocate that middle
boxes don't filter on the basis of whether or not ESP is being used.

Therefore I suppose that checking for an ESP-null marker is no different
than checking for ESP in the first place.  And that if one would not
oppose the latter then one should not oppose the former.

Nico
--

-- 

Re: Motivation for ESP-null marking

On Aug 6, 2008, at 7:47 PM, Nicolas Williams wrote:

<snip>
>>   * What is the security/threat environment that we are dealing with?
>>     In other words, what is the security policy for which we want an
>>     efficient enforcement?
>
> Clearly the security policy would be: use confidentiality protection.
>
> Of course, there's no way to ensure that the SAs' keys haven't be made
> public or otherwise shared with interested third parties.  That's what
> makes ESP-null marking seem silly -- it's like the reverse of the
> "secure" bit gag, an "insecure" bit which tells you nothing about the
> security of packets that don't have that bit set.

I don't think this was the author's intention. The two parties could  
of course use AES and post their secret keys to Wikipedia, but if the  
policy is to drop marked ESP-NULL packets, all the parties really have  
to do, is to negotiate ESP-NULL and use the old ESP with no markings.

I think the policy is "don't send encrypted stuff out, because I (the  
middlebox) want to deep inspect all traffic". That would translate to  
dropping all ESP-non-NULL traffic. Otherwise, I agree that an  
"insecure" bit is ridiculous. A "deep inspection welcome" bit is less  
so.

But you can't just pass the packet marked as ESP-NULL - you need to  
really make sure they're not running encrypted stuff, and also you  
need to deep inspect. So the question is whether it really adds any  
processing time to make sure a packet is really not encrypted, given  
that you're running all kinds of other filtering.

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec