Damien,
Also regarding EID-to-RLOC Cache overflow, in Paragraph 3 of Section 5.4, you
suggest that an ETR, upon receiving a LISP encapsulated packet, might consult
its EID-to-RLOC Cache to verify that the sending RLOC is authorized to
originate traffic from the packet's source EID. If the ETR does not have a map
entry for that EID, it might originate a Map-Request for the EID.
Might SA use this behavior to overflow the ETRs map-cache? What would happen if
SA sent a sustained flow of packets, spoofing many RLOCs and many EID prefixes.
The victim ETR has three options:
1) pass each packet without verification
2) query the map cache for each packet. If no entry exists, discard the packet
and do not query the map server
3) query the map cache for each packet. If no entry exists, discard the packet
and query the map server
If you choose Option 3, won't the victim ETR map cache overflow?
Option #2 appears to be a non-starter.
Option #1 leaves you open to other types of attacks.
Ron
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Damien Saucez
> Sent: Friday, March 15, 2013 9:56 AM
> To: LISP mailing list list
> Subject: [lisp] Need comments on LISP Threats Analysis
>
> Dear all,
>
> As requested by chairs in today's meeting we would like to ask you to
> comment on the threats analysis.
>
> Here are the there questions that must be precisely answered by you:
>
> 1. are the 4 severity levels well defined? (do you see intermediate
> levels?)
>
> 2. do you agree with the level of severity given for each threat
> (yes/no/why)?
>
> 3. if a feature has to be deactivated, do you agree for having it
> deactivated?
>
> Thank you.
>
> Damien Saucez
> _______________________________________________
> lisp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
