Subject: [karp] Karp-threat-reqs Updated

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 21 Mar 2012 16:43:45 +0530

Hi,

Gregory and I have updated the karp-threat-reqs (with lot of help from Brian) based on the IETF LC and the extensive Sec Dir review comments that we received. Please let us know if you think a few comments have been left unaddressed.

You can easily view the differences from the last version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-karp-threats-reqs-04.txt

Cheers, Manav

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Mar 2012 11:28:36 -0700

Some comments and questions below.

Joe

----

Current Sec 2.2 (incremental approach)

The last sentence (which is repeated) appears to raise issues with 
TCP-AO, but the concerns are already addressed in TCP-AO's design - AO 
already prevents replay attacks, allows TCP connections to restart 
without the need to install new keys at the endpoints, and supports 
different crypto algorithms.

What are the concerns here?

----

Current Sec 4, requirement 5

You state that routing protocols need to be able to detect and reject 
replayed messages.

IMO, they need to be protected against such replays, but it can be 
sufficient for a transport (e.g., TCP-AO) or network (e.g., IPsec) 
mechanism to provide that protection. If they are NOT protected by other 
layers, then the protection needs to be inside the routing protocol.

Is that what you meant, or is there some reason for needing this in the 
routing protocol itself?

-----

On 3/21/2012 4:13 AM, Bhatia, Manav (Manav) wrote:
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 22 Mar 2012 07:41:05 +0530

> You state that routing protocols need to be able to detect 
> and reject replayed messages.
> 
> IMO, they need to be protected against such replays, but it 
> can be sufficient for a transport (e.g., TCP-AO) or network 
> (e.g., IPsec) mechanism to provide that protection. If they 
> are NOT protected by other layers, then the protection needs 
> to be inside the routing protocol.
> 
> Is that what you meant, or is there some reason for needing 
> this in the routing protocol itself?

Yes, that's what we had meant. The authentication mechanism that the routing protocol employs (it could either be inband to the routing protocol or could be a function of the transport layer) must be able to detect and reject replayed messages.

I'll let Gregory address your other comment on TCP-AO.

Cheers, Manav

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Mar 2012 22:04:12 -0700

> Yes, that's what we had meant. The authentication mechanism that the routing protocol employs (it could either be inband to the routing protocol or could be a function of the transport layer) must…

AOK - it might be useful to clarify that in the next rev.

Joe