date:20230215

Comment:

> 

And how does a Map-Resolver verify a Map-Request? There is no security 
association with it unless it uses draft-ietf-lisp-ecdsa-auth. 

And what does "an xTR is allowed to use" mean? Based on what, a white-list in 
the Map-Resolver, which is intractable?

And for point (2), how does the Map-Server know which are legit Map-Resolvers?

This text is hand-waving with no support text to say how it does it.

Dino

> On Feb 15, 2023, at 2:47 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Locator/ID Separation Protocol WG of the 
> IETF.
> 
>Title   : Publish/Subscribe Functionality for the Locator/ID 
> Separation Protocol (LISP)
>Authors : Alberto Rodriguez-Natal
>  Vina Ermagan
>  Albert Cabellos
>  Sharon Barkai
>  Mohamed Boucadair
>  Filename: draft-ietf-lisp-pubsub-13.txt
>  Pages   : 21
>  Date: 2023-02-15
> 
> Abstract:
>   This document specifies an extension to the request/reply based
>   Locator/ID Separation Protocol (LISP) control plane to enable
>   Publish/Subscribe (PubSub) operation.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-pubsub/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-13
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-pubsub-13
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

Right, that is the idea. We’ll update the section accordingly. Thanks Joel.

Alberto

From: Joel Halpern 
Date: Thursday, February 16, 2023 at 12:14 AM
To: Alberto Rodriguez-Natal (natal) , 
mohamed.boucad...@orange.com , Magnus Westerlund 
, tsv-...@ietf.org 
Cc: draft-ietf-lisp-pubsub@ietf.org , 
last-c...@ietf.org , lisp@ietf.org 
Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

IIf I am understanding you properly, the security considerations in the draft 
can be stated more clearly and strongly to show that the DDOS attack by unknown 
entities is not possible.  And presumably that a known entity pounding the 
system with subscriptions would cause an alarm and response.

Yours,

Joel
On 2/15/2023 6:10 PM, Alberto Rodriguez-Natal (natal) wrote:
Joel,

Currently LISP-SEC is required in PubSub to 1) establish a security association 
(PubSubKey) between ITR and MS when none is present, and 2) reset the nonce 
state when needed. When used, the assumptions from LISP-SEC are carried over 
(secured MR-MS communication channel, etc).

When pre-shared keys are used for PubSubKeys and the nonces are kept reliably  
(e.g. in persistent storage), then LISP-SEC can be optional.

Note that despite LISP-SEC being used or not, the general considerations from 
9301 regarding integrity protection, etc for Map-Request are still valid here.

Thanks,
Alberto

From: Joel Halpern 
Date: Wednesday, February 15, 2023 at 7:48 PM
To: mohamed.boucad...@orange.com 
, Magnus 
Westerlund 
, 
Alberto Rodriguez-Natal (natal) , 
tsv-...@ietf.org 

Cc: 
draft-ietf-lisp-pubsub@ietf.org 
,
 last-c...@ietf.org 
, 
lisp@ietf.org 
Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

Given that a lot of the use cases have a lot of legitimate users, I think 
magnus concern is reasonable, but I am willing to settle for less.

If I am reading things right, the xTR<->Map_Resolver exchanges for pub-sub 
SHOULD use LISP-SEC.

And the Map-Resolver<->Map Server exchanges should magically know that the Map 
Resolvers are doing so?

The SHOULD needs some explanation as to when it is okay not to, or else it 
ought to be upgraded to a MUST.

The Map Server requirement seems like it would benefit from some explanation as 
to how this knowledge would exist.

Yours,

Joel

PS: If LISP Sec can be used along the lines Dino indicated, taht would be a 
nice way to combine some of the protections and better address the issues.
On 2/15/2023 1:36 PM, 
mohamed.boucad...@orange.com wrote:
Hi Joel,

The proposal is not to restrict the usage of PubSub to “limited domains” as per 
RFC8799. Please refer to 
https://github.com/boucadair/draft-ietf-lisp-pubsub/pull/16/files to see the 
text we are planning to include as applicability scope.

I think this is a reasonable suggestion especially that we want to leverage 
9301/9303.

Thank you.

Cheers,
Med

De : Joel Halpern 
Envoyé : mercredi 15 février 2023 17:32
À : BOUCADAIR Mohamed INNOV/NET 
; Magnus 
Westerlund 
; 
Alberto Rodriguez-Natal (natal) ; 
tsv-...@ietf.org
Cc : 
draft-ietf-lisp-pubsub@ietf.org;
 last-c...@ietf.org; 
lisp@ietf.org
Objet : Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

Hmmm.

Maybe I misunderstood, but a lot of the uses I have seen for the pub-sub 
mechanism do not seem to be limited enough to qualify for being a limited 
domain.

On the other hand, the general idea of the DDOS prevention mechanism (modeled 
loosely on the prevention of TCP State attacks) seems valuable and easy to add. 
 If a Map Server serving a broad community gets a pub-sub subscription request, 
and it is under any significant load, it can

1) craft a security token hashing the request, the current time, and a private 
key (and whatever else security says is needed

2) Sending the token and time back to the requestor in an error

3) When the requestor sends back the request, it includes the timestamp and 
token.  The server only processes the request if the information validates.

This validates that the response actually went to the requestor, and was a real 
request.  Yes, it slightly slows down the pub-sub registration under load.

I don't know if I caught all of Magnus' issue, but this would seem a good thing 
to do.

Yours,

Joel
On 2/15/2023 3:24 AM,

Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

Dino, Joel,

The PubSub spec has traditionally required keeping incremental nonce state for 
the publish operation. This was the consensus of the WG after several 
discussions a few years back (you might remember this).

In the most recent iterations of the draft, the incremental nonce has also been 
applied to the subscribe operation (same nonce, no extra state). We have also 
polished the text to describe what to do when the nonce needs to be reset, etc.

Alberto

From: Joel Halpern 
Date: Wednesday, February 15, 2023 at 11:17 PM
To: Dino Farinacci , Joel Halpern 
Cc: mohamed.boucad...@orange.com , Magnus 
Westerlund , Alberto Rodriguez-Natal (natal) 
, tsv-...@ietf.org , 
draft-ietf-lisp-pubsub@ietf.org , 
last-c...@ietf.org , lisp@ietf.org 
Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

Well, the security folks usually want a stateless solution to this sort of 
problem.  The nonce increment requries keeping state per pending correspondent.

Yours,

Joel
On 2/15/2023 4:46 PM, Dino Farinacci wrote:
Tell me what you all think.  Can the map-server just store the nonce and then 
the next Map-Request have the map-server require nance+1?

Stops reply attacks at only the cost of storing an additional 64 bits.  Do you 
think that solves the problem?

Dino


On Feb 15, 2023, at 10:49 AM, Joel Halpern 
 wrote:


Given that a lot of the use cases have a lot of legitimate users, I think 
magnus concern is reasonable, but I am willing to settle for less.

If I am reading things right, the xTR<->Map_Resolver exchanges for pub-sub 
SHOULD use LISP-SEC.

And the Map-Resolver<->Map Server exchanges should magically know that the Map 
Resolvers are doing so?

The SHOULD needs some explanation as to when it is okay not to, or else it 
ought to be upgraded to a MUST.

The Map Server requirement seems like it would benefit from some explanation as 
to how this knowledge would exist.

Yours,

Joel

PS: If LISP Sec can be used along the lines Dino indicated, taht would be a 
nice way to combine some of the protections and better address the issues.
On 2/15/2023 1:36 PM, 
mohamed.boucad...@orange.com wrote:
Hi Joel,

The proposal is not to restrict the usage of PubSub to “limited domains” as per 
RFC8799. Please refer to 
https://github.com/boucadair/draft-ietf-lisp-pubsub/pull/16/files to see the 
text we are planning to include as applicability scope.

I think this is a reasonable suggestion especially that we want to leverage 
9301/9303.

Thank you.

Cheers,
Med

De : Joel Halpern 
Envoyé : mercredi 15 février 2023 17:32
À : BOUCADAIR Mohamed INNOV/NET 
; Magnus 
Westerlund 
; 
Alberto Rodriguez-Natal (natal) ; 
tsv-...@ietf.org
Cc : 
draft-ietf-lisp-pubsub@ietf.org;
 last-c...@ietf.org; 
lisp@ietf.org
Objet : Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10


Hmmm.

Maybe I misunderstood, but a lot of the uses I have seen for the pub-sub 
mechanism do not seem to be limited enough to qualify for being a limited 
domain.

On the other hand, the general idea of the DDOS prevention mechanism (modeled 
loosely on the prevention of TCP State attacks) seems valuable and easy to add. 
 If a Map Server serving a broad community gets a pub-sub subscription request, 
and it is under any significant load, it can

1) craft a security token hashing the request, the current time, and a private 
key (and whatever else security says is needed

2) Sending the token and time back to the requestor in an error

3) When the requestor sends back the request, it includes the timestamp and 
token.  The server only processes the request if the information validates.

This validates that the response actually went to the requestor, and was a real 
request.  Yes, it slightly slows down the pub-sub registration under load.

I don't know if I caught all of Magnus' issue, but this would seem a good thing 
to do.

Yours,

Joel
On 2/15/2023 3:24 AM, 
mohamed.boucad...@orange.com wrote:
Hi Magnus,

Thank you for the follow-up.

First, your observation on the verification procedure at the Map-Server is 
fair. We have documented the issue in 
draft-boucadair-lisp-pubsub-flow-examples-03.html#name-failed-notification-with-ret
 and discussed the alternative to strengthen the verification based on the 
timestamp but we had also the constraint to navigate in the LISP environment 
where LISP-SEC messages are not timestamped. We think that the procedure in the 
draft is a good compromise of what we can achieve given that constraint. FWIW, 
the full

Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

IIf I am understanding you properly, the security considerations in the 
draft can be stated more clearly and strongly to show that the DDOS 
attack by unknown entities is not possible.  And presumably that a known 
entity pounding the system with subscriptions would cause an alarm and 
response.


Yours,

Joel

On 2/15/2023 6:10 PM, Alberto Rodriguez-Natal (natal) wrote:


Joel,

Currently LISP-SEC is required in PubSub to 1) establish a security 
association (PubSubKey) between ITR and MS when none is present, and 
2) reset the nonce state when needed. When used, the assumptions from 
LISP-SEC are carried over (secured MR-MS communication channel, etc).


When pre-shared keys are used for PubSubKeys and the nonces are kept 
reliably  (e.g. in persistent storage), then LISP-SEC can be optional.


Note that despite LISP-SEC being used or not, the general 
considerations from 9301 regarding integrity protection, etc for 
Map-Request are still valid here.


Thanks,

Alberto

*From: *Joel Halpern 
*Date: *Wednesday, February 15, 2023 at 7:48 PM
*To: *mohamed.boucad...@orange.com , 
Magnus Westerlund , Alberto 
Rodriguez-Natal (natal) , tsv-...@ietf.org 

*Cc: *draft-ietf-lisp-pubsub@ietf.org 
, last-c...@ietf.org 
, lisp@ietf.org 

*Subject: *Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

Given that a lot of the use cases have a lot of legitimate users, I 
think magnus concern is reasonable, but I am willing to settle for less.


If I am reading things right, the xTR<->Map_Resolver exchanges for 
pub-sub SHOULD use LISP-SEC.


And the Map-Resolver<->Map Server exchanges should magically know that 
the Map Resolvers are doing so?


The SHOULD needs some explanation as to when it is okay not to, or 
else it ought to be upgraded to a MUST.


The Map Server requirement seems like it would benefit from some 
explanation as to how this knowledge would exist.


Yours,

Joel

PS: If LISP Sec can be used along the lines Dino indicated, taht would 
be a nice way to combine some of the protections and better address 
the issues.


On 2/15/2023 1:36 PM, mohamed.boucad...@orange.com wrote:

Hi Joel,

The proposal is not to restrict the usage of PubSub to “limited
domains” as per RFC8799. Please refer to
https://github.com/boucadair/draft-ietf-lisp-pubsub/pull/16/files
to see the text we are planning to include as applicability scope.

I think this is a reasonable suggestion especially that we want to
leverage 9301/9303.

Thank you.

Cheers,

Med

*De :*Joel Halpern  
*Envoyé :* mercredi 15 février 2023 17:32
*À :* BOUCADAIR Mohamed INNOV/NET 
; Magnus Westerlund

; Alberto Rodriguez-Natal
(natal)  ; tsv-...@ietf.org
*Cc :* draft-ietf-lisp-pubsub@ietf.org; last-c...@ietf.org;
lisp@ietf.org
*Objet :* Re: [lisp] Tsvart last call review of
draft-ietf-lisp-pubsub-10

Hmmm.

Maybe I misunderstood, but a lot of the uses I have seen for the
pub-sub mechanism do not seem to be limited enough to qualify for
being a limited domain.

On the other hand, the general idea of the DDOS prevention
mechanism (modeled loosely on the prevention of TCP State attacks)
seems valuable and easy to add.  If a Map Server serving a broad
community gets a pub-sub subscription request, and it is under any
significant load, it can

1) craft a security token hashing the request, the current time,
and a private key (and whatever else security says is needed

2) Sending the token and time back to the requestor in an error

3) When the requestor sends back the request, it includes the
timestamp and token. The server only processes the request if the
information validates.

This validates that the response actually went to the requestor,
and was a real request.  Yes, it slightly slows down the pub-sub
registration under load.

I don't know if I caught all of Magnus' issue, but this would seem
a good thing to do.

Yours,

Joel

On 2/15/2023 3:24 AM, mohamed.boucad...@orange.com wrote:

Hi Magnus,

Thank you for the follow-up.

First, your observation on the verification procedure at the
Map-Server is fair. We have documented the issue in

draft-boucadair-lisp-pubsub-flow-examples-03.html#name-failed-notification-with-ret


and discussed the alternative to strengthen the verification
based on the timestamp but we had also the constraint to
navigate in the LISP environment where LISP-SEC messages are
not timestamped. We think that the procedure in the draft is a
good compromise of what we can achieve given that constraint.

Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

Joel,

Currently LISP-SEC is required in PubSub to 1) establish a security association 
(PubSubKey) between ITR and MS when none is present, and 2) reset the nonce 
state when needed. When used, the assumptions from LISP-SEC are carried over 
(secured MR-MS communication channel, etc).

When pre-shared keys are used for PubSubKeys and the nonces are kept reliably  
(e.g. in persistent storage), then LISP-SEC can be optional.

Note that despite LISP-SEC being used or not, the general considerations from 
9301 regarding integrity protection, etc for Map-Request are still valid here.

Thanks,
Alberto

From: Joel Halpern 
Date: Wednesday, February 15, 2023 at 7:48 PM
To: mohamed.boucad...@orange.com , Magnus 
Westerlund , Alberto Rodriguez-Natal (natal) 
, tsv-...@ietf.org 
Cc: draft-ietf-lisp-pubsub@ietf.org , 
last-c...@ietf.org , lisp@ietf.org 
Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

Given that a lot of the use cases have a lot of legitimate users, I think 
magnus concern is reasonable, but I am willing to settle for less.

If I am reading things right, the xTR<->Map_Resolver exchanges for pub-sub 
SHOULD use LISP-SEC.

And the Map-Resolver<->Map Server exchanges should magically know that the Map 
Resolvers are doing so?

The SHOULD needs some explanation as to when it is okay not to, or else it 
ought to be upgraded to a MUST.

The Map Server requirement seems like it would benefit from some explanation as 
to how this knowledge would exist.

Yours,

Joel

PS: If LISP Sec can be used along the lines Dino indicated, taht would be a 
nice way to combine some of the protections and better address the issues.
On 2/15/2023 1:36 PM, 
mohamed.boucad...@orange.com wrote:
Hi Joel,

The proposal is not to restrict the usage of PubSub to “limited domains” as per 
RFC8799. Please refer to 
https://github.com/boucadair/draft-ietf-lisp-pubsub/pull/16/files to see the 
text we are planning to include as applicability scope.

I think this is a reasonable suggestion especially that we want to leverage 
9301/9303.

Thank you.

Cheers,
Med

De : Joel Halpern 
Envoyé : mercredi 15 février 2023 17:32
À : BOUCADAIR Mohamed INNOV/NET 
; Magnus 
Westerlund 
; 
Alberto Rodriguez-Natal (natal) ; 
tsv-...@ietf.org
Cc : 
draft-ietf-lisp-pubsub@ietf.org;
 last-c...@ietf.org; 
lisp@ietf.org
Objet : Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10


Hmmm.

Maybe I misunderstood, but a lot of the uses I have seen for the pub-sub 
mechanism do not seem to be limited enough to qualify for being a limited 
domain.

On the other hand, the general idea of the DDOS prevention mechanism (modeled 
loosely on the prevention of TCP State attacks) seems valuable and easy to add. 
 If a Map Server serving a broad community gets a pub-sub subscription request, 
and it is under any significant load, it can

1) craft a security token hashing the request, the current time, and a private 
key (and whatever else security says is needed

2) Sending the token and time back to the requestor in an error

3) When the requestor sends back the request, it includes the timestamp and 
token.  The server only processes the request if the information validates.

This validates that the response actually went to the requestor, and was a real 
request.  Yes, it slightly slows down the pub-sub registration under load.

I don't know if I caught all of Magnus' issue, but this would seem a good thing 
to do.

Yours,

Joel
On 2/15/2023 3:24 AM, 
mohamed.boucad...@orange.com wrote:
Hi Magnus,

Thank you for the follow-up.

First, your observation on the verification procedure at the Map-Server is 
fair. We have documented the issue in 
draft-boucadair-lisp-pubsub-flow-examples-03.html#name-failed-notification-with-ret
 and discussed the alternative to strengthen the verification based on the 
timestamp but we had also the constraint to navigate in the LISP environment 
where LISP-SEC messages are not timestamped. We think that the procedure in the 
draft is a good compromise of what we can achieve given that constraint. FWIW, 
the full reasoning is available at: timestamp to prevent replay attacks · Issue 
#1 · boucadair/draft-ietf-lisp-pubsub 
(github.com).

Second, I support your proposal to add an applicability statement to the 
document. The content will be basically moving (and adjusting the language) the 
following text in Section 7 to that section:

OLD:
   It is also RECOMMENDED that the Map-Resolver
   verifies that

[lisp] I-D Action: draft-ietf-lisp-pubsub-13.txt

2023-02-15 Thread internet-drafts



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Locator/ID Separation Protocol WG of the IETF.

Title   : Publish/Subscribe Functionality for the Locator/ID 
Separation Protocol (LISP)
Authors : Alberto Rodriguez-Natal
  Vina Ermagan
  Albert Cabellos
  Sharon Barkai
  Mohamed Boucadair
  Filename: draft-ietf-lisp-pubsub-13.txt
  Pages   : 21
  Date: 2023-02-15

Abstract:
   This document specifies an extension to the request/reply based
   Locator/ID Separation Protocol (LISP) control plane to enable
   Publish/Subscribe (PubSub) operation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-pubsub/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-13

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-pubsub-13


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10


> Well, the security folks usually want a stateless solution to this sort of 
> problem.  The nonce increment requries keeping state per pending 
> correspondent.

Agree. 

Dino


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

Well, the security folks usually want a stateless solution to this sort 
of problem.  The nonce increment requries keeping state per pending 
correspondent.


Yours,

Joel

On 2/15/2023 4:46 PM, Dino Farinacci wrote:
Tell me what you all think.  Can the map-server just store the nonce 
and then the next Map-Request have the map-server require nance+1?


Stops reply attacks at only the cost of storing an additional 64 bits. 
 Do you think that solves the problem?


Dino


On Feb 15, 2023, at 10:49 AM, Joel Halpern  wrote:



Given that a lot of the use cases have a lot of legitimate users, I 
think magnus concern is reasonable, but I am willing to settle for less.


If I am reading things right, the xTR<->Map_Resolver exchanges for 
pub-sub SHOULD use LISP-SEC.


And the Map-Resolver<->Map Server exchanges should magically know 
that the Map Resolvers are doing so?


The SHOULD needs some explanation as to when it is okay not to, or 
else it ought to be upgraded to a MUST.


The Map Server requirement seems like it would benefit from some 
explanation as to how this knowledge would exist.


Yours,

Joel

PS: If LISP Sec can be used along the lines Dino indicated, taht 
would be a nice way to combine some of the protections and better 
address the issues.


On 2/15/2023 1:36 PM, mohamed.boucad...@orange.com wrote:


Hi Joel,

The proposal is not to restrict the usage of PubSub to “limited 
domains” as per RFC8799. Please refer to 
https://github.com/boucadair/draft-ietf-lisp-pubsub/pull/16/files to 
see the text we are planning to include as applicability scope.


I think this is a reasonable suggestion especially that we want to 
leverage 9301/9303.


Thank you.

Cheers,

Med

*De :*Joel Halpern 
*Envoyé :* mercredi 15 février 2023 17:32
*À :* BOUCADAIR Mohamed INNOV/NET ; 
Magnus Westerlund ; Alberto 
Rodriguez-Natal (natal) ; tsv-...@ietf.org
*Cc :* draft-ietf-lisp-pubsub@ietf.org; last-c...@ietf.org; 
lisp@ietf.org
*Objet :* Re: [lisp] Tsvart last call review of 
draft-ietf-lisp-pubsub-10


Hmmm.

Maybe I misunderstood, but a lot of the uses I have seen for the 
pub-sub mechanism do not seem to be limited enough to qualify for 
being a limited domain.


On the other hand, the general idea of the DDOS prevention mechanism 
(modeled loosely on the prevention of TCP State attacks) seems 
valuable and easy to add.  If a Map Server serving a broad community 
gets a pub-sub subscription request, and it is under any significant 
load, it can


1) craft a security token hashing the request, the current time, and 
a private key (and whatever else security says is needed


2) Sending the token and time back to the requestor in an error

3) When the requestor sends back the request, it includes the 
timestamp and token.  The server only processes the request if the 
information validates.


This validates that the response actually went to the requestor, and 
was a real request.  Yes, it slightly slows down the pub-sub 
registration under load.


I don't know if I caught all of Magnus' issue, but this would seem a 
good thing to do.


Yours,

Joel

On 2/15/2023 3:24 AM, mohamed.boucad...@orange.com wrote:

Hi Magnus,

Thank you for the follow-up.

First, your observation on the verification procedure at the
Map-Server is fair. We have documented the issue in

draft-boucadair-lisp-pubsub-flow-examples-03.html#name-failed-notification-with-ret


and discussed the alternative to strengthen the verification
based on the timestamp but we had also the constraint to
navigate in the LISP environment where LISP-SEC messages are not
timestamped. We think that the procedure in the draft is a good
compromise of what we can achieve given that constraint. FWIW,
the full reasoning is available at: timestamp to prevent replay
attacks · Issue #1 · boucadair/draft-ietf-lisp-pubsub
(github.com)
.

Second, I support your proposal to add an applicability
statement to the document. The content will be basically moving
(and adjusting the language) the following text in Section 7 to
that section:

OLD:

   It is also RECOMMENDED that the Map-Resolver

   verifies that the xTR is allowed to use PubSub and to use the
xTR-ID

   and ITR-RLOCs included in the Map-Request. Map-Servers SHOULD be

configured to only accept subscription requests from Map-Resolvers

   that verify Map-Requests as previously described.

I let Alberto further comment as appropriate.

Cheers,

Med

*De :*Magnus Westerlund 

*Envoyé :* mercredi 15 février 2023 08:33
*À :* Alberto Rodriguez-Natal (natal) 
; BOUCADAIR Mohamed INNOV/NET

;

Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

Tell me what you all think. Can the map-server just store the nonce and then the next Map-Request have the map-server require nance+1?Stops reply attacks at only the cost of storing an additional 64 bits. Do you think that solves the problem?DinoOn Feb 15, 2023, at 10:49 AM, Joel Halpern wrote:

Given that a lot of the use cases have a lot of legitimate users,
I think magnus concern is reasonable, but I am willing to settle
for less.
If I am reading things right, the xTR<->Map_Resolver
exchanges for pub-sub SHOULD use LISP-SEC.
And the Map-Resolver<->Map Server exchanges should
magically know that the Map Resolvers are doing so?
The SHOULD needs some explanation as to when it is okay not to,
or else it ought to be upgraded to a MUST.
The Map Server requirement seems like it would benefit from some
explanation as to how this knowledge would exist.
Yours,
Joel
PS: If LISP Sec can be used along the lines Dino indicated, taht
would be a nice way to combine some of the protections and better
address the issues.
On 2/15/2023 1:36 PM,
mohamed.boucad...@orange.com wrote:

Hi Joel,
The
proposal is not to restrict the usage of PubSub to “limited
domains” as per RFC8799. Please refer to
https://github.com/boucadair/draft-ietf-lisp-pubsub/pull/16/files
to see the text we are planning to include as applicability
scope.
I
think this is a reasonable suggestion especially that we
want to leverage 9301/9303.

Thank
you.

Cheers,
Med

De : Joel Halpern

Envoyé : mercredi 15 février 2023 17:32
À : BOUCADAIR Mohamed INNOV/NET
; Magnus
Westerlund ;
Alberto Rodriguez-Natal (natal)
; tsv-...@ietf.org
Cc : draft-ietf-lisp-pubsub@ietf.org;
last-c...@ietf.org; lisp@ietf.org
Objet : Re: [lisp] Tsvart last call review of
draft-ietf-lisp-pubsub-10

Hmmm.
Maybe I misunderstood, but a lot of the uses I have seen
for the pub-sub mechanism do not seem to be limited enough
to qualify for being a limited domain.
On the other hand, the general idea of the DDOS prevention
mechanism (modeled loosely on the prevention of TCP State
attacks) seems valuable and easy to add. If a Map Server
serving a broad community gets a pub-sub subscription
request, and it is under any significant load, it can
1) craft a security token hashing the request, the current
time, and a private key (and whatever else security says is
needed
2) Sending the token and time back to the requestor in an
error
3) When the requestor sends back the request, it includes
the timestamp and token. The server only processes the
request if the information validates.
This validates that the response actually went to the
requestor, and was a real request. Yes, it slightly slows
down the pub-sub registration under load.

I don't know if I caught all of Magnus' issue, but this
would seem a good thing to do.
Yours,
Joel

On 2/15/2023 3:24 AM,
mohamed.boucad...@orange.com wrote:

Hi Magnus,
Thank you for the
follow-up.
First, your
observation on the verification procedure at the
Map-Server is fair. We have documented the issue in

draft-boucadair-lisp-pubsub-flow-examples-03.html#name-failed-notification-with-ret
and discussed the alternative to strengthen the
verification based on the timestamp but we had also the
constraint to navigate in the LISP environment where
LISP-SEC messages are not timestamped. We think that the
procedure in the draft is a good compromise of what we
can achieve given that constraint. FWIW, the full
reasoning is available at:
timestamp to
prevent replay attacks · Issue #1 ·
boucadair/draft-ietf-lisp-pubsub (github.com).
Second, I support
your proposal to add an applicability statement to the
document. The content will be basically

Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

Given that a lot of the use cases have a lot of legitimate users, I 
think magnus concern is reasonable, but I am willing to settle for less.


If I am reading things right, the xTR<->Map_Resolver exchanges for 
pub-sub SHOULD use LISP-SEC.


And the Map-Resolver<->Map Server exchanges should magically know that 
the Map Resolvers are doing so?


The SHOULD needs some explanation as to when it is okay not to, or else 
it ought to be upgraded to a MUST.


The Map Server requirement seems like it would benefit from some 
explanation as to how this knowledge would exist.


Yours,

Joel

PS: If LISP Sec can be used along the lines Dino indicated, taht would 
be a nice way to combine some of the protections and better address the 
issues.


On 2/15/2023 1:36 PM, mohamed.boucad...@orange.com wrote:


Hi Joel,

The proposal is not to restrict the usage of PubSub to “limited 
domains” as per RFC8799. Please refer to 
https://github.com/boucadair/draft-ietf-lisp-pubsub/pull/16/files to 
see the text we are planning to include as applicability scope.


I think this is a reasonable suggestion especially that we want to 
leverage 9301/9303.


Thank you.

Cheers,

Med

*De :*Joel Halpern 
*Envoyé :* mercredi 15 février 2023 17:32
*À :* BOUCADAIR Mohamed INNOV/NET ; 
Magnus Westerlund ; Alberto 
Rodriguez-Natal (natal) ; tsv-...@ietf.org
*Cc :* draft-ietf-lisp-pubsub@ietf.org; last-c...@ietf.org; 
lisp@ietf.org

*Objet :* Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

Hmmm.

Maybe I misunderstood, but a lot of the uses I have seen for the 
pub-sub mechanism do not seem to be limited enough to qualify for 
being a limited domain.


On the other hand, the general idea of the DDOS prevention mechanism 
(modeled loosely on the prevention of TCP State attacks) seems 
valuable and easy to add.  If a Map Server serving a broad community 
gets a pub-sub subscription request, and it is under any significant 
load, it can


1) craft a security token hashing the request, the current time, and a 
private key (and whatever else security says is needed


2) Sending the token and time back to the requestor in an error

3) When the requestor sends back the request, it includes the 
timestamp and token.  The server only processes the request if the 
information validates.


This validates that the response actually went to the requestor, and 
was a real request.  Yes, it slightly slows down the pub-sub 
registration under load.


I don't know if I caught all of Magnus' issue, but this would seem a 
good thing to do.


Yours,

Joel

On 2/15/2023 3:24 AM, mohamed.boucad...@orange.com wrote:

Hi Magnus,

Thank you for the follow-up.

First, your observation on the verification procedure at the
Map-Server is fair. We have documented the issue in

draft-boucadair-lisp-pubsub-flow-examples-03.html#name-failed-notification-with-ret


and discussed the alternative to strengthen the verification based
on the timestamp but we had also the constraint to navigate in the
LISP environment where LISP-SEC messages are not timestamped. We
think that the procedure in the draft is a good compromise of what
we can achieve given that constraint. FWIW, the full reasoning is
available at: timestamp to prevent replay attacks · Issue #1 ·
boucadair/draft-ietf-lisp-pubsub (github.com)
.

Second, I support your proposal to add an applicability statement
to the document. The content will be basically moving (and
adjusting the language) the following text in Section 7 to that
section:

OLD:

   It is also RECOMMENDED that the Map-Resolver

   verifies that the xTR is allowed to use PubSub and to use the
xTR-ID

   and ITR-RLOCs included in the Map-Request.  Map-Servers SHOULD be

   configured to only accept subscription requests from Map-Resolvers

   that verify Map-Requests as previously described.

I let Alberto further comment as appropriate.

Cheers,

Med

*De :*Magnus Westerlund 

*Envoyé :* mercredi 15 février 2023 08:33
*À :* Alberto Rodriguez-Natal (natal) 
; BOUCADAIR Mohamed INNOV/NET

; tsv-...@ietf.org
*Cc :* draft-ietf-lisp-pubsub@ietf.org; last-c...@ietf.org;
lisp@ietf.org
*Objet :* Re: Tsvart last call review of draft-ietf-lisp-pubsub-10

Hi,

Thanks for the many improvements and I think this is likely safe
enough for limited deployments when the Map-Server are not open to
any xTR to send requests. I don’t think this is safe enough for
general Internet usage for two reasons. First, the verification
procedure forces the MAP-Server to hold state rather than the
requestor

Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

2023-02-15 Thread mohamed.boucadair

Hi Joel,

The proposal is not to restrict the usage of PubSub to “limited domains” as per 
RFC8799. Please refer to 
https://github.com/boucadair/draft-ietf-lisp-pubsub/pull/16/files to see the 
text we are planning to include as applicability scope.

I think this is a reasonable suggestion especially that we want to leverage 
9301/9303.

Thank you.

Cheers,
Med

De : Joel Halpern 
Envoyé : mercredi 15 février 2023 17:32
À : BOUCADAIR Mohamed INNOV/NET ; Magnus 
Westerlund ; Alberto Rodriguez-Natal (natal) 
; tsv-...@ietf.org
Cc : draft-ietf-lisp-pubsub@ietf.org; last-c...@ietf.org; lisp@ietf.org
Objet : Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10


Hmmm.

Maybe I misunderstood, but a lot of the uses I have seen for the pub-sub 
mechanism do not seem to be limited enough to qualify for being a limited 
domain.

On the other hand, the general idea of the DDOS prevention mechanism (modeled 
loosely on the prevention of TCP State attacks) seems valuable and easy to add. 
 If a Map Server serving a broad community gets a pub-sub subscription request, 
and it is under any significant load, it can

1) craft a security token hashing the request, the current time, and a private 
key (and whatever else security says is needed

2) Sending the token and time back to the requestor in an error

3) When the requestor sends back the request, it includes the timestamp and 
token.  The server only processes the request if the information validates.

This validates that the response actually went to the requestor, and was a real 
request.  Yes, it slightly slows down the pub-sub registration under load.

I don't know if I caught all of Magnus' issue, but this would seem a good thing 
to do.

Yours,

Joel
On 2/15/2023 3:24 AM, 
mohamed.boucad...@orange.com wrote:
Hi Magnus,

Thank you for the follow-up.

First, your observation on the verification procedure at the Map-Server is 
fair. We have documented the issue in 
draft-boucadair-lisp-pubsub-flow-examples-03.html#name-failed-notification-with-ret
 and discussed the alternative to strengthen the verification based on the 
timestamp but we had also the constraint to navigate in the LISP environment 
where LISP-SEC messages are not timestamped. We think that the procedure in the 
draft is a good compromise of what we can achieve given that constraint. FWIW, 
the full reasoning is available at: timestamp to prevent replay attacks · Issue 
#1 · boucadair/draft-ietf-lisp-pubsub 
(github.com).

Second, I support your proposal to add an applicability statement to the 
document. The content will be basically moving (and adjusting the language) the 
following text in Section 7 to that section:

OLD:
   It is also RECOMMENDED that the Map-Resolver
   verifies that the xTR is allowed to use PubSub and to use the xTR-ID
   and ITR-RLOCs included in the Map-Request.  Map-Servers SHOULD be
   configured to only accept subscription requests from Map-Resolvers
   that verify Map-Requests as previously described.

I let Alberto further comment as appropriate.

Cheers,
Med

De : Magnus Westerlund 

Envoyé : mercredi 15 février 2023 08:33
À : Alberto Rodriguez-Natal (natal) ; 
BOUCADAIR Mohamed INNOV/NET 
; 
tsv-...@ietf.org
Cc : 
draft-ietf-lisp-pubsub@ietf.org;
 last-c...@ietf.org; 
lisp@ietf.org
Objet : Re: Tsvart last call review of draft-ietf-lisp-pubsub-10

Hi,

Thanks for the many improvements and I think this is likely safe enough for 
limited deployments when the Map-Server are not open to any xTR to send 
requests. I don’t think this is safe enough for general Internet usage for two 
reasons. First, the verification procedure forces the MAP-Server to hold state 
rather than the requestor and the messages only. Secondly, a lot of the 
security procedures are only RECOMMEND/SHOULD. For an open Internet I think a 
more tightly defined security mechanisms and protection profile should be 
specified.

Thus, my recommendation would be to add an applicability statement to the 
document making clear that this is intended for the deployments with more 
limited access to Map-Servers than what an open internet deployment provides.

Cheers

Magnus Westerlund

From: Alberto Rodriguez-Natal (natal) mailto:na...@cisco.com>>
Date: Monday, 13 February 2023 at 20:26
To: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>, Magnus 
Westerlund 
mailto:magnus.westerl...@ericsson.com>>, 
tsv-...@ietf.org 
mailto:tsv-...@ietf.org>>
Cc:

Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

Hi Joel, Dino,

I feel that the suggestion from Magnus is reasonable, since his main point is 
that access to the Map-Server should be limited, which I think it’s a fair 
requirement. I don’t see that very limiting, since on most LISP production 
deployments I’m aware of the Map-Server is already not openly accessible (and I 
assume would also be the case for upcoming use-cases for PubSub such GB-LISP).

Please consider that the current PubSub proposal follows a very lean approach 
on top of existing LISP specs. It builds on top of existing LISP constructs, 
minimizing to the extent possible new protocol machinery. I think we have 
achieved a good balance between functionality and new constructs required. 
Besides, something to note is that if the current PubSub spec runs in a 
deployment with a single [logical] Map-Server (which is very common in 
production), the state that it needs to keep is significantly less.

Unless there’s a strong push to modify the spec to support some flow like the 
one mentioned by Joel, my personal preference would be to go with the 
reasonable suggestion by Magnus about including a note regarding scope of 
applicability.

Thanks!
Alberto

From: Dino Farinacci 
Date: Wednesday, February 15, 2023 at 6:13 PM
To: Joel Halpern 
Cc: mohamed.boucadair , Magnus Westerlund 
, Alberto Rodriguez-Natal (natal) 
, tsv-...@ietf.org , 
draft-ietf-lisp-pubsub@ietf.org , 
last-c...@ietf.org , lisp@ietf.org 
Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10
We should look at the mechanisms of lisp-sec to see if they can be used for 
this algorithm. I think the OTK is the token and hash Joel describes below but 
doesn't include a timestamp.

The algorithm, would require two Map-Requests to be sent, as Joel said, and 
would add subscription delay.

The big benefit is that the map-server doesn't have to hold more client state 
and can scale better, as Magnus referred to.

Dino

> On Feb 15, 2023, at 8:32 AM, Joel Halpern  wrote:
>
> Hmmm.
>
> Maybe I misunderstood, but a lot of the uses I have seen for the pub-sub 
> mechanism do not seem to be limited enough to qualify for being a limited 
> domain.
>
> On the other hand, the general idea of the DDOS prevention mechanism (modeled 
> loosely on the prevention of TCP State attacks) seems valuable and easy to 
> add.  If a Map Server serving a broad community gets a pub-sub subscription 
> request, and it is under any significant load, it can
>
> 1) craft a security token hashing the request, the current time, and a 
> private key (and whatever else security says is needed
>
> 2) Sending the token and time back to the requestor in an error
>
> 3) When the requestor sends back the request, it includes the timestamp and 
> token.  The server only processes the request if the information validates.
>
> This validates that the response actually went to the requestor, and was a 
> real request.  Yes, it slightly slows down the pub-sub registration under 
> load.
>
> I don't know if I caught all of Magnus' issue, but this would seem a good 
> thing to do.
>
> Yours,
>
> Joel
>
> On 2/15/2023 3:24 AM, mohamed.boucad...@orange.com wrote:
>> Hi Magnus,
>>
>> Thank you for the follow-up.
>>
>> First, your observation on the verification procedure at the Map-Server is 
>> fair. We have documented the issue in 
>> draft-boucadair-lisp-pubsub-flow-examples-03.html#name-failed-notification-with-ret
>>  and discussed the alternative to strengthen the verification based on the 
>> timestamp but we had also the constraint to navigate in the LISP environment 
>> where LISP-SEC messages are not timestamped. We think that the procedure in 
>> the draft is a good compromise of what we can achieve given that constraint. 
>> FWIW, the full reasoning is available at: timestamp to prevent replay 
>> attacks · Issue #1 · boucadair/draft-ietf-lisp-pubsub (github.com).
>>
>> Second, I support your proposal to add an applicability statement to the 
>> document. The content will be basically moving (and adjusting the language) 
>> the following text in Section 7 to that section:
>>
>> OLD:
>>It is also RECOMMENDED that the Map-Resolver
>>verifies that the xTR is allowed to use PubSub and to use the xTR-ID
>>and ITR-RLOCs included in the Map-Request.  Map-Servers SHOULD be
>>configured to only accept subscription requests from Map-Resolvers
>>that verify Map-Requests as previously described.
>>
>> I let Alberto further comment as appropriate.
>>
>> Cheers,
>> Med
>>
>> De : Magnus Westerlund 
>> Envoyé : mercredi 15 février 2023 08:33
>> À : Alberto Rodriguez-Natal (natal) ; BOUCADAIR Mohamed 
>> INNOV/NET ; tsv-...@ietf.org
>> Cc : draft-ietf-lisp-pubsub@ietf.org; last-c...@ietf.org; lisp@ietf.org
>> Objet : Re: Tsvart last call review of draft-ietf-lisp-pubsub-10
>>
>> Hi,
>>
>> Thanks for the many improvements and I think this is likely safe enough for 
>> limited deployments when the Map-Server are not open to any xTR to

Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

We should look at the mechanisms of lisp-sec to see if they can be used for 
this algorithm. I think the OTK is the token and hash Joel describes below but 
doesn't include a timestamp.

The algorithm, would require two Map-Requests to be sent, as Joel said, and 
would add subscription delay. 

The big benefit is that the map-server doesn't have to hold more client state 
and can scale better, as Magnus referred to.

Dino

> On Feb 15, 2023, at 8:32 AM, Joel Halpern  wrote:
> 
> Hmmm.
> 
> Maybe I misunderstood, but a lot of the uses I have seen for the pub-sub 
> mechanism do not seem to be limited enough to qualify for being a limited 
> domain.
> 
> On the other hand, the general idea of the DDOS prevention mechanism (modeled 
> loosely on the prevention of TCP State attacks) seems valuable and easy to 
> add.  If a Map Server serving a broad community gets a pub-sub subscription 
> request, and it is under any significant load, it can
> 
> 1) craft a security token hashing the request, the current time, and a 
> private key (and whatever else security says is needed
> 
> 2) Sending the token and time back to the requestor in an error
> 
> 3) When the requestor sends back the request, it includes the timestamp and 
> token.  The server only processes the request if the information validates.
> 
> This validates that the response actually went to the requestor, and was a 
> real request.  Yes, it slightly slows down the pub-sub registration under 
> load.  
> 
> I don't know if I caught all of Magnus' issue, but this would seem a good 
> thing to do.
> 
> Yours,
> 
> Joel
> 
> On 2/15/2023 3:24 AM, mohamed.boucad...@orange.com wrote:
>> Hi Magnus,
>>  
>> Thank you for the follow-up.
>>  
>> First, your observation on the verification procedure at the Map-Server is 
>> fair. We have documented the issue in 
>> draft-boucadair-lisp-pubsub-flow-examples-03.html#name-failed-notification-with-ret
>>  and discussed the alternative to strengthen the verification based on the 
>> timestamp but we had also the constraint to navigate in the LISP environment 
>> where LISP-SEC messages are not timestamped. We think that the procedure in 
>> the draft is a good compromise of what we can achieve given that constraint. 
>> FWIW, the full reasoning is available at: timestamp to prevent replay 
>> attacks · Issue #1 · boucadair/draft-ietf-lisp-pubsub (github.com).
>>  
>> Second, I support your proposal to add an applicability statement to the 
>> document. The content will be basically moving (and adjusting the language) 
>> the following text in Section 7 to that section: 
>>  
>> OLD:
>>It is also RECOMMENDED that the Map-Resolver
>>verifies that the xTR is allowed to use PubSub and to use the xTR-ID
>>and ITR-RLOCs included in the Map-Request.  Map-Servers SHOULD be
>>configured to only accept subscription requests from Map-Resolvers
>>that verify Map-Requests as previously described.
>>  
>> I let Alberto further comment as appropriate.
>>  
>> Cheers,
>> Med
>>  
>> De : Magnus Westerlund  
>> Envoyé : mercredi 15 février 2023 08:33
>> À : Alberto Rodriguez-Natal (natal) ; BOUCADAIR Mohamed 
>> INNOV/NET ; tsv-...@ietf.org
>> Cc : draft-ietf-lisp-pubsub@ietf.org; last-c...@ietf.org; lisp@ietf.org
>> Objet : Re: Tsvart last call review of draft-ietf-lisp-pubsub-10
>>  
>> Hi,
>>  
>> Thanks for the many improvements and I think this is likely safe enough for 
>> limited deployments when the Map-Server are not open to any xTR to send 
>> requests. I don’t think this is safe enough for general Internet usage for 
>> two reasons. First, the verification procedure forces the MAP-Server to hold 
>> state rather than the requestor and the messages only. Secondly, a lot of 
>> the security procedures are only RECOMMEND/SHOULD. For an open Internet I 
>> think a more tightly defined security mechanisms and protection profile 
>> should be specified.
>>  
>> Thus, my recommendation would be to add an applicability statement to the 
>> document making clear that this is intended for the deployments with more 
>> limited access to Map-Servers than what an open internet deployment 
>> provides. 
>>  
>> Cheers
>>  
>> Magnus Westerlund
>>  
>> From: Alberto Rodriguez-Natal (natal) 
>> Date: Monday, 13 February 2023 at 20:26
>> To: mohamed.boucad...@orange.com , Magnus 
>> Westerlund , tsv-...@ietf.org 
>> 
>> Cc: draft-ietf-lisp-pubsub@ietf.org 
>> , last-c...@ietf.org 
>> , lisp@ietf.org 
>> Subject: Re: Tsvart last call review of draft-ietf-lisp-pubsub-10
>> 
>> Hi Magnus,
>>  
>> Just FYI, we have just published a new revision that further polishes some 
>> details.
>>  
>> https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-12
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-pubsub-12
>>  
>> Thanks!
>> Alberto
>>  
>> From: mohamed.boucad...@orange.com 
>> Date: Friday, February 10, 2023 at 3:55 PM
>> To: Magnus Westerlund , Alberto 
>> Rodriguez-Natal (natal) ,

Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10


Hmmm.

Maybe I misunderstood, but a lot of the uses I have seen for the pub-sub 
mechanism do not seem to be limited enough to qualify for being a 
limited domain.


On the other hand, the general idea of the DDOS prevention mechanism 
(modeled loosely on the prevention of TCP State attacks) seems valuable 
and easy to add.  If a Map Server serving a broad community gets a 
pub-sub subscription request, and it is under any significant load, it can


1) craft a security token hashing the request, the current time, and a 
private key (and whatever else security says is needed


2) Sending the token and time back to the requestor in an error

3) When the requestor sends back the request, it includes the timestamp 
and token.  The server only processes the request if the information 
validates.


This validates that the response actually went to the requestor, and was 
a real request.  Yes, it slightly slows down the pub-sub registration 
under load.


I don't know if I caught all of Magnus' issue, but this would seem a 
good thing to do.


Yours,

Joel

On 2/15/2023 3:24 AM, mohamed.boucad...@orange.com wrote:


Hi Magnus,

Thank you for the follow-up.

First, your observation on the verification procedure at the 
Map-Server is fair. We have documented the issue in 
draft-boucadair-lisp-pubsub-flow-examples-03.html#name-failed-notification-with-ret 
 
and discussed the alternative to strengthen the verification based on 
the timestamp but we had also the constraint to navigate in the LISP 
environment where LISP-SEC messages are not timestamped. We think that 
the procedure in the draft is a good compromise of what we can achieve 
given that constraint. FWIW, the full reasoning is available at: 
timestamp to prevent replay attacks · Issue #1 · 
boucadair/draft-ietf-lisp-pubsub (github.com) 
.


Second, I support your proposal to add an applicability statement to 
the document. The content will be basically moving (and adjusting the 
language) the following text in Section 7 to that section:


OLD:

   It is also RECOMMENDED that the Map-Resolver

   verifies that the xTR is allowed to use PubSub and to use the xTR-ID

   and ITR-RLOCs included in the Map-Request.  Map-Servers SHOULD be

   configured to only accept subscription requests from Map-Resolvers

   that verify Map-Requests as previously described.

I let Alberto further comment as appropriate.

Cheers,

Med

*De :*Magnus Westerlund 
*Envoyé :* mercredi 15 février 2023 08:33
*À :* Alberto Rodriguez-Natal (natal) ; BOUCADAIR 
Mohamed INNOV/NET ; tsv-...@ietf.org
*Cc :* draft-ietf-lisp-pubsub@ietf.org; last-c...@ietf.org; 
lisp@ietf.org

*Objet :* Re: Tsvart last call review of draft-ietf-lisp-pubsub-10

Hi,

Thanks for the many improvements and I think this is likely safe 
enough for limited deployments when the Map-Server are not open to any 
xTR to send requests. I don’t think this is safe enough for general 
Internet usage for two reasons. First, the verification procedure 
forces the MAP-Server to hold state rather than the requestor and the 
messages only. Secondly, a lot of the security procedures are only 
RECOMMEND/SHOULD. For an open Internet I think a more tightly defined 
security mechanisms and protection profile should be specified.


Thus, my recommendation would be to add an applicability statement to 
the document making clear that this is intended for the deployments 
with more limited access to Map-Servers than what an open internet 
deployment provides.


Cheers

Magnus Westerlund

*From: *Alberto Rodriguez-Natal (natal) 
*Date: *Monday, 13 February 2023 at 20:26
*To: *mohamed.boucad...@orange.com , 
Magnus Westerlund , tsv-...@ietf.org 

*Cc: *draft-ietf-lisp-pubsub@ietf.org 
, last-c...@ietf.org 
, lisp@ietf.org 

*Subject: *Re: Tsvart last call review of draft-ietf-lisp-pubsub-10

Hi Magnus,

Just FYI, we have just published a new revision that further polishes 
some details.


https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-12

https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-pubsub-12

Thanks!

Alberto

*From: *mohamed.boucad...@orange.com 
*Date: *Friday, February 10, 2023 at 3:55 PM
*To: *Magnus Westerlund , Alberto 
Rodriguez-Natal (natal) , tsv-...@ietf.org 

*Cc: *draft-ietf-lisp-pubsub@ietf.org 
, last-c...@ietf.org 
, lisp@ietf.org 

*Subject: *RE: Tsvart last call review of draft-ietf-lisp-pubsub-10

Hi Magnus,

FWIW, an updated version that implements the changes that were 
discussed in this thread is now online:


https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-pubsub-11 



Cheers,

Med

*De :*BOUCADAIR Mohamed INNOV/NET
*Envoyé :* mardi 7 février 2023 13:15
*À :* 'Magnus Westerlund' ; Alberto 
Rodriguez-Natal (natal) ;

Re: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10