Subject: [karp] requirement 17 from karp-threat-reqs-03

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 17 Mar 2012 12:51:01 +0530

Hi,

Gregory, Brian and I had some discussion on what we wanted to do with the requirement 17 that existed in http://tools.ietf.org/html/draft-ietf-karp-threats-reqs-03

The requirement 17 was as follows:

"The authentication mechanism does not provide message confidentiality, but SHOULD NOT preclude the possibility of confidentiality support being added in the future."

The above text has been removed in the latest version and we would like to solicit comments from the WG members on this issue.

At the first glance the requirement seems to be absurd because an "authentication mechanism" cannot by definition provide confidentiality. This can be fixed by tweaking the text to say that the new security mechanism should provide message integrity in addition to being able to support confidentiality if required. 

However, the bigger question is, that do we even want to keep this requirement? Do we envisage a scenario in future where we might want to encrypt the routing packets? If not, then we can safely remove this requirement. The reason this text was added was because certain people felt that we ought to address confidentiality (and not just message integrity) of the routing packets. The result of that discussion was this text where we are trying to say that in future when you add a new security mechanism ensure that it also has the provision to encrypt in addition to verifying the integrity of the routing packets.

So while we have removed this from the -04 version, this can be added in -05, if the WG feels that it ought to be captured somewhere.

Cheers, Manav

---

From: Uma Chunduri <[email-masked]>
Date: Sat, 17 Mar 2012 19:31:07 -0400

"The authentication mechanism does not provide message confidentiality, but SHOULD NOT preclude the possibility of confidentiality support being added in the future."
The above text has been removed in the latest version and we would like to solicit comments from the WG members on this issue.
At the first glance the requirement seems to be absurd because an "authentication mechanism" cannot by definition provide confidentiality. 

This is definitely absurd and confidentiality for routing protocol messages is bit red herring (out of KARP scope, I would say).

It's good this has been removed and I don't think it should be captured somewhere.

--
Uma C.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 19 Mar 2012 13:32:51 -0700

Manav,

Another way to look at this would be to see where the need is coming from. Do we know?

One of the reasons I have heard is to keep the internal topology of the network private. How important is this requirement?

> "The authentication mechanism does not provide message confidentiality, but SHOULD NOT preclude the possibility of confidentiality support being added in the future."

Mahesh Jethanandani
[email-masked]

---

From: Russ White <[email-masked]>
Date: Tue, 20 Mar 2012 22:14:12 -0400

> However, the bigger question is, that do we even want to keep this requirement? Do we envisage a scenario in future where we might want to encrypt the routing packets? If not, then we can safely re…

I wouldn't keep it... I don't know of any requirement for keeping the
topology hidden on a link that can otherwise be easily compromised. If
this type of security is required, it should be provided at a lower
layer, IMHO.

:-)

Russ

---

From: Gregory Lebovitz <[email-masked]>
Date: Fri, 23 Mar 2012 10:12:26 -0700

On Sat, Mar 17, 2012 at 12:21 AM, Bhatia, Manav (Manav) <
[email-masked]> wrote:
--SNIP--

>
> At the first glance the requirement seems to be absurd because an
> "authentication mechanism" cannot by definition provide confidentiality.
> This can be fixed by tweaking the text to say that the new security
> mechanism should provide message integrity in addition to being able to
> support confidentiality if required.
>

One issue with "a new security mechanism should provide message integrity
in addition to being able to support confidentiality if required" is that
it would be out of scope of the WG, as currently chartered.

The original requirement was compromise text for the pro-encryption crowd.
It was intended to say, "we are going to focus on message integrity, but
someone may, in the future, want to charter work to do message
confidentiality. Keep that in mind and don't do anything that would
PRECLUDE adding message confidentiality later." Such a requirement, though
appearing extremely wise and considerate at first glance, is very difficult
to fulfill in actuality. How do we design to not conflict with a message
confidentiality mechanism that we have not yet created? We would
essentially need to complete design of the "future" message confidentiality
mechanism before we complete the message integrity in order to fulfill the
requirement. Such is both out of scope, and not practical.

>
> However, the bigger question is, that do we even want to keep this
> requirement? Do we envisage a scenario in future where we might want to
> encrypt the routing packets?

>From my above comment, I hope I have made a strong case that whether or not
we may want encryption in the future is not the question. The question is
one of scope and practical execution. Can the requirement actually be
accomplished while staying in scope in a reasonable amount of time?

> If not, then we can safely remove this requirement. The reason this text
> was added was because certain people felt that we ought to address
> confidentiality (and not just message integrity) of the routing packets.
> The result of that discussion was this text where we are trying to say that
> in future when you add a new security mechanism ensure that it also has the
> provision to encrypt in addition to verifying the integrity of the routing
> packets.
>
> So while we have removed this from the -04 version, this can be added in
> -05, if the WG feels that it ought to be captured somewhere.
>

I would be comfortable adding it back in if someone could demonstrate a
high probability of fulfilling the requirement while staying in scope. I
would assume the text would be very different in order to communicate this
strong probability and keeping in scope. To date, I have not seen this.

Gregory

>
> Cheers, Manav
>
>
>
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks