Subject: [pcp] WGLC: draft-ietf-pcp-anycast-02 comments due by NOV 10

From: Dave Thaler <[email-masked]>
Date: Mon, 27 Oct 2014 20:23:27 +0000

This email initiates a Working Group Last Call on : draft-ietf-pcp-anycast-02 to conclude on

Monday, November 10th at the PCP WG meeting in Honolulu.  Please send comments to the list.

As a reminder, when responding to a WGLC, what we chairs are looking for is a statement about

document quality (not really about whether the mechanism should move forward).  That is,

state whether you think the document is ready as is, or if not, what issues you see.

Thanks,

-Dave

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 30 Oct 2014 10:33:12 +0200

> state whether you think the document is ready as is, or if not, what issues you see.

I think the document (and the mechanism) is mostly fine and needed.

What I am wondering about is security considerations section; given implementations not aware of this draft, a host on the inner side can also advertise the anycast address, and potentially get traffic meant for first-hop PCP server. Given the scheme defined in section 2.1 (SHOULD use first-hop first), it is possible, although not probable. But still, I would say the same problem is both on local network(s) _and_ on the other side of the firewall.

(It could also state that finding (platform independently) next-hop gateway programmatically can be hard for pure ‘applications’ sometimes, but I wonder if this is too much detail. But if app just chose anycast address, the above SHOULD would not be followed and the security considerations problems would be more severe.)

Also.. Is there actually defined mechanism to redirect or provide list of PCP servers that is mentioned in the introduction?

Cheers,

-Markus

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 30 Oct 2014 09:57:07 +0000

> -----Original Message-----
> From: pcp [mailto:[email-masked]] On Behalf Of Markus Stenberg
> Sent: Thursday, October 30, 2014 2:03 PM
> To: Dave Thaler
> Cc: [email-masked]
> Subject: Re: [pcp] WGLC: draft-ietf-pcp-anycast-02 comments due by NOV 10
> 
> > This email initiates a Working Group Last Call on :
> > draft-ietf-pcp-anycast-02 to conclude on Monday, November 10th at the
> PCP WG meeting in Honolulu.  Please send comments to the list.
> >
> > As a reminder, when responding to a WGLC, what we chairs are looking
> > for is a statement about document quality (not really about whether
> > the mechanism should move forward).  That is, state whether you think the
> document is ready as is, or if not, what issues you see.
> 
> What I am wondering about is security considerations section; given
> implementations not aware of this draft, a host on the inner side can also
> advertise the anycast address, and potentially get traffic meant for first-hop
> PCP server. 

One possible way to mitigate that attack is use PCP authentication (PCP client and server must be able to mutually authenticate).

-Tiru

> Given the scheme defined in section 2.1 (SHOULD use first-hop
> first), it is possible, although not probable. But still, I would say the same
> problem is both on local network(s) _and_ on the other side of the firewall.
> 
> (It could also state that finding (platform independently) next-hop gateway
> programmatically can be hard for pure 'applications' sometimes, but I
> wonder if this is too much detail. But if app just chose anycast address, the
> above SHOULD would not be followed and the security considerations
> problems would be more severe.)
> 
> Also.. Is there actually defined mechanism to redirect or provide list of PCP
> servers that is mentioned in the introduction?
> 
> Cheers,
> 
> -Markus
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: <[email-masked]>
Date: Thu, 30 Oct 2014 10:11:11 +0000

Dear all,

I have a comment about this text:

   The PCP client SHOULD select the PCP anycast address to be of the
   same IP address family as its requested PCP mapping, i.e., the
   address family of the Requested Internal IP Address.

This assumes the PCP client is always dual-stack. More importantly, this is a case that is covered in general by this behavior : https://tools.ietf.org/html/draft-ietf-pcp-server-selection-06#section-3.

I suggest removing the text above. Instead add a reference to the server selection document.

Cheers,
Med

De : pcp [mailto:[email-masked]] De la part de Dave Thaler
Envoyé : lundi 27 octobre 2014 21:23
À : [email-masked]
Objet : [pcp] WGLC: draft-ietf-pcp-anycast-02 comments due by NOV 10

Thanks,

-Dave

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 30 Oct 2014 12:11:32 +0100

Hi Med,

On Thu, Oct 30, 2014 at 10:11:11AM +0000, [email-masked] wrote:
> This assumes the PCP client is always dual-stack. 

This is not true. Or at least not what we wanted to say.

What we want to say is:  Whatever address family you decide to use on
your side of the NAT for the actual user data traffic, you should use
the same address family for the related PCP anycast signaling to the
NAT.  It doesn't matter whether the NAT will translate the user data
traffic to the same or another address family on its other side.

If a host is not dual stack, i.e., IPv4-only or IPv6-only, it has no
other choice than sending both the user data and the PCP anycast
signaling using the one address family it supports.
This is completely fine and inline with this requirement.

Does this make sense?

> More importantly, this is a case that is covered in general by this behavior : https://tools.ietf.org/html/draft-ietf-pcp-server-selection-06#section-3.
> 

I must say that I have difficulties finding this special case in
draft-ietf-pcp-server-selection-06#section-3 
Can you narrow down which statement includes our case?

Thanks
Sebastian

---

From: Simon Perreault <[email-masked]>
Date: Thu, 30 Oct 2014 09:12:01 -0400

> This is completely fine and inline with this requirement.

Yes, and it is specified by draft-ietf-pcp-server-selection. I agree with
Mohamed that this guidance is redundant and should be replaced by a pointer
to that draft.

Simon

---

From: <[email-masked]>
Date: Thu, 30 Oct 2014 13:26:41 +0000

Re-,

draft-ietf-pcp-server-selection specifies the behavior of a PCP client to contact a PCP server having multiple IP address.

This behavior applies in particular for your case: PCP server with 2 IP addresses (read IPvx anycast addresses). No need to be redundant here.

Cheers,
Med

-----Message d'origine-----
De : Sebastian Kiesel [mailto:[email-masked]] 
Envoyé : jeudi 30 octobre 2014 12:12
À : BOUCADAIR Mohamed IMT/OLN
Cc : Dave Thaler; [email-masked]
Objet : Re: [pcp] WGLC: draft-ietf-pcp-anycast-02 comments due by NOV 10

Hi Med,

Does this make sense?

Thanks
Sebastian

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 30 Oct 2014 23:23:43 +0100

On Thu, Oct 30, 2014 at 09:12:01AM -0400, Simon Perreault wrote:
> Yes,

ok. so we agree what to say, now let's see how ...

> and it is specified by draft-ietf-pcp-server-selection. I agree with

I'm not sure whether it is really helpful to eliminate a tiny bit
of redundancy by referencing a much more generic other document, which
in turn references further documents.

What would be the text proposal for that change?

Old:

New:

   The PCP client selects the IP address family as specified
   in [draft-ietf-pcp-server-selection].

What do you think?

Thanks
Sebastian

---

From: <[email-masked]>
Date: Fri, 31 Oct 2014 06:38:40 +0000

Dear Sebastien,

Looks good to me. Thanks.

Cheers,
Med

-----Message d'origine-----
De : Sebastian Kiesel [mailto:[email-masked]] 
Envoyé : jeudi 30 octobre 2014 23:24
À : Simon Perreault
Cc : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : Re: [pcp] WGLC: draft-ietf-pcp-anycast-02 comments due by NOV 10

Old:

New:

What do you think?

Thanks
Sebastian