Hi Ross, See inline,
On Mon, May 12, 2014 at 7:11 PM, Ross Callon <[email protected]> wrote: > Thanks Joel; > > I think that draft-ietf-lisp-threats-09.txt is a start towards a threats > document, but that it has serious omissions and needs more work before being > progressed. Here are some specific comments: > > > Section 2 (On-path Attackers), first paragraph: > > On-path attackers are attackers that are able to capture and modify > all the packets exchanged between an Ingress Tunnel Router (ITR) and > an Egress Tunnel Router (ETR). To cope with such an attacker, > cryptographic techniques such as those used by IPSec ([RFC4301]) are > required. As with IP, LISP relies on higher layer cryptography to > secure packet payloads from on path attacks, so this document does > not consider on-path attackers. > > To me an on-path attacker is one which is on the data path. Such an attacker > might attack the contents of the data packet. In this case the paragraph > seems mostly correct to me: You encrypt the contents if you don't want > someone on the path to the destination to look at the contents. However, as > is discussed later in the document, LISP allows systems which are not in the > normal physical path, through a gleaning attack, to inject themselves into > the data path. This could be applied to allow attacker's systems to inject > themselves into the path of the key management protocol. This implies that a > legitimate user could get keys supplied by an attacker, just as easily as it > could get keys supplied by a legitimate Internet site. If you are proposing > that end to end encryption is the solution to on path attackers then you need > to understand the implications of LISP on the operation of the protocol > needed for key management to support end to end encryption. There exist two draft that are relevant to what you address. You have https://datatracker.ietf.org/doc/draft-farinacci-lisp-crypto/ where the payload of a LISP encapsulated packet are encrypted. None of the keys for encrypting/decrypting are stored in the mapping system but is calculated by the xTR's involved. Then you have https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/ that attempts to secure the xTR to xTR relationship. -- Roger Jorgensen | ROJO9-RIPE [email protected] | - IPv6 is The Key! http://www.jorgensen.no | [email protected] _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
