Subject: [anonsec] Automatic detection of BTNS capability

From: yogesh.swami at acm.org (Yogesh Prem Swami)
Date: Wed, 16 Mar 2005 09:29:02 -0800 (PST)

Oops! sent too quickly by mistake.

>> Noone has argued that BTNS makes zombie DoS/DDoS attacks easier, nor do
>> I see how it would.
>>
> Consider this: A security gagateway accepts self signed certs. Let's say A
and
> B
> are communicating with each other normally. Now a rogue node Malice wants to
> disrupt this connection. To do this Malice established a secure channel using
> self signed cert, and A accepts it. After the secure channel is established,
> malice puts a couple of IPIPn IPIPackets inside the IPIPsecacket and
> ultimately
> a TCP RSRSTackets with the right atattributesf B. This is shown in figure
> below:
>  
          A<--------------------------->B
          |
          | IPIPn-IPIPn-IPIPn-IPIPnd TCP of B
          +---------------------------> Malice

You can solve this by looking inside the IP in IP headers (but that could lead
to other kind of DoS attacks where you keep parsing IPeaders for no reason). I
don't recall if RFC2401 and 2402 bis, mention checking inner tunnels for
inbound processing. Of course, all this could be solved if you change IPsec
that is not an option, right?

Yogesh

>> As to what is meant by "better than no security:" better than just
>> sending and accepting unauthenticated plaintext.
>>
>> So should BTNS' charter say anything about zombie DoS protection?  I
>> don't think so, at least not until we figure out that BTNS has something
>> to offer there.
>>
>> Nico
>> --

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 16 Mar 2005 11:47:01 -0800

Yogesh Prem Swami wrote:
> inbound processing. 

Tunnel mode does; transport mode does not when the inner header is IPIP 
(see RFC3884).

> Of course, all this could be solved if you change IPsec
> _______________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20050316/87329517/signature.bin

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 16 Mar 2005 18:13:58 -0500

>that is not an option, right?

IPsec bounds the depth of header inspection, intentionally. 2401bis 
is pretty clear on that. Changing this is not an option, in my 
opinion.

Steve

---

From: yogesh.swami at acm.org (Yogesh Swami)
Date: Wed, 16 Mar 2005 18:51:57 -0600

> IPsec bounds the depth of header inspection, intentionally. 2401bis is 
> pretty clear on that. Changing this is not an option, in my opinion.
> 

I wasn't suggesting to change. Far from it.

My point was that accepting self-signed certs require a through analysis 
  to make sure that there are no unintended consequences. My example was 
motivated by con artist in a social setting, who start as strangers and 
diligently build trust over a period of time but then dupe the victims 
anyway (similar to going through IKE, and then attacking). Probably it 
was a bad example, but in my opinion BTNS must produce a document that 
addresses such issues. This will also help set the right policies on 
BTNS enabled hosts.

Yogesh

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 17 Mar 2005 13:57:54 -0500

At 6:51 PM -0600 3/16/05, Yogesh Swami wrote:
>My point was that accepting self-signed certs require a through 
>analysis  to make sure that there are no unintended consequences. My 
>example was motivated by con artist in a social setting, who start 
>as strangers and diligently build trust over a period of time but 
>then dupe the victims anyway (similar to going through IKE, and then 
>attacking). Probably it was a bad example, but in my opinion BTNS 
>must produce a document that addresses such issues. This will also 
>help set the right policies on BTNS enabled hosts.
>
>Yogesh

I agree that use of self-signed certs or other non-authenticated keys 
is not trivial. The extensions that will be needed to the PAD and/or 
SPD have to be considered carefully, to avoid undermining the access 
control features that are central to IPsec.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 17 Mar 2005 12:06:49 -0800

> control features that are central to IPsec.

Such potential undermining can occur already with the use of 'pass' mode 
SPD entries, or with keys and CAs that have varying levels of trust.

Although this issue has been raised before, there doesn't seem to be a 
new issue that BTNS exposes regarding "keeping the streams from 
crossing", i.e., that doesn't already existing in current IPsec/IKE use.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20050317/785821b5/signature.bin

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 17 Mar 2005 15:32:10 -0500

At 12:06 PM -0800 3/17/05, Joe Touch wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature";
>	boundary="------------enig9B6CBEE8C0216EAB39AE23B8"
>
>
>
>Stephen Kent wrote:
>>>>IPsec bounds the depth of header inspection, intentionally. 
>>>>2401bis is pretty clear on that. Changing this is not an option, 
>>>>in my opinion.
>>>>
>>>
>>>analysis  to make sure that there are no unintended consequences. 
>>>My example was motivated by con artist in a social setting, who 
>>>start as strangers and diligently build trust over a period of 
>>>time but then dupe the victims anyway (similar to going through 
>>>IKE, and then attacking). Probably it was a bad example, but in my 
>>>opinion BTNS must produce a document that addresses such issues. 
>>>This will also help set the right policies on BTNS enabled hosts.
>>>
>>>Yogesh
>>
>>
>>I agree that use of self-signed certs or other non-authenticated 
>>keys is not trivial. The extensions that will be needed to the PAD 
>>and/or SPD have to be considered carefully, to avoid undermining 
>>the access control features that are central to IPsec.
>>
>>Steve
>
>Such potential undermining can occur already with the use of 'pass' 
>mode SPD entries, or with keys and CAs that have varying levels of 
>trust.

First, I assume you mean BYPASS.

Second, the PAD constrains the scope of authorization for each peer 
re the SPD, and thus provides a clear way to address variability in 
CA trustworthiness.

One obvious danger here is adding controls that make it hard to 
understand the implications of BTNS peers re authenticated peers, and 
thus undermine extant security capabilities.

>Although this issue has been raised before, there doesn't seem to be 
>a new issue that BTNS exposes regarding "keeping the streams from 

That remains to be seen, as people propose specific mechanisms to 
support BTNS target functionality.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 17 Mar 2005 13:27:13 -0800

> First, I assume you mean BYPASS.

Yup.

> thus undermine extant security capabilities.

Agreed. But BYPASS vs. authenticated has similar issues, IMO.

> support BTNS target functionality.

That would require a good argument that BTNS somehow could cross streams 
with authenticated in ways that BYPASS can't, or that two different 
authenticated streams can't. Which, again, would be an issue in 
IPsec/IKE, not with BTNS per se.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20050317/6e0d21a7/signature.bin

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 17 Mar 2005 17:21:34 -0500

>	<SNIP>
>>understand the implications of BTNS peers re authenticated peers, 
>>and thus undermine extant security capabilities.
>
>>>Although this issue has been raised before, there doesn't seem to 
>>>be a new issue that BTNS exposes regarding "keeping the streams 
>>>from crossing", i.e., that doesn't already existing in current 
>>>IPsec/IKE use.
>>
>That would require a good argument that BTNS somehow could cross 
>streams with authenticated in ways that BYPASS can't, or that two 
>different authenticated streams can't. Which, again, would be an 
>issue in IPsec/IKE, not with BTNS per se.
>
>Joe
>

or it requires an argument that the additional management features 
that have to be introduced to accommodate BTNS create systemic, 
management-induced vulnerabilities that otherwise would not have 
existed.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 18 Mar 2005 07:58:54 -0800

Stephen Kent wrote:
....
> management-induced vulnerabilities that otherwise would not have 

An argument that makes such case would indeed be useful.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20050318/289e59a5/signature.bin

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 18 Mar 2005 11:15:34 -0500

At 7:58 AM -0800 3/18/05, Joe Touch wrote:
>	boundary="------------enigC9DEAD8BC58B0B85D7956B22"
>
>
>
>Stephen Kent wrote:
>....
>>>>>Although this issue has been raised before, there doesn't seem 
>>>>>to be a new issue that BTNS exposes regarding "keeping the 
>>>>>streams from crossing", i.e., that doesn't already existing in 
>>>>>current IPsec/IKE use.
>>>>

Glad we agree :-).

Of course, such an argument can be made only once we have concrete 
proposals in front of the WG. So we have to first develop the 
proposals, then analyze them before we know whether they are OK or 
potentially dangerous.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 18 Mar 2005 08:21:37 -0800

> proposals, then analyze them before we know whether they are OK or 

We're agreeing again.

We should stop now while we're ahead ;-)

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20050318/d004540a/signature.bin