Subject: [pim] TTL for PORT

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 5 Feb 2011 07:34:56 +0530

Hi,

Since the PIM routers are adjacent the draft should must also mention that all PIM routers MUST send all TCP packets with TTL=255 and the receivers MUST only accept them if the TTL=254. This provides an added security where PIM routers will only accept TCP packets from legitimate routers. Since TTL spoofing is considered nearly impossible, a mechanism based on an expected TTL value can provide a simple and reasonably robust defense from infrastructure attacks based on forged protocol packets from outside the network.

Cheers, Manav

---

From: Yiqun Cai <[email-masked]>
Date: Fri, 04 Feb 2011 20:27:22 -0800

Well,  we might want to extend PORT to support tunnels or unidirectional
links.  Enforcing TTL=254 on the receiving end will make it more
complicated.

On 2/4/11 6:04 PM, "Bhatia, Manav (Manav)" <[email-masked]>
wrote:

> Hi,
> 
> Since the PIM routers are adjacent the draft should must also mention that all
> PIM routers MUST send all TCP packets with TTL=255 and the receivers MUST only
> accept them if the TTL=254. This provides an added security where PIM routers
> will only accept TCP packets from legitimate routers. Since TTL spoofing is
> considered nearly impossible, a mechanism based on an expected TTL value can
> provide a simple and reasonably robust defense from infrastructure attacks
> based on forged protocol packets from outside the network.
> 
> Cheers, Manav
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

-- 
Yiqun

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 5 Feb 2011 11:16:37 +0530

If it's the MPLS tunnels that you are alluding to then it would still make sense to have the TTL=254 as it'll still be just one hop away for the PIM packet. It's the MPLS TTL that'll get decremented.

Cheers, Manav 

> -----Original Message-----
> From: Yiqun Cai [mailto:[email-masked]] 
> Sent: Saturday, February 05, 2011 9.57 AM
> To: Bhatia, Manav (Manav); [email-masked]
> Subject: Re: [pim] TTL for PORT
>

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 5 Feb 2011 01:16:30 -0800

In general, i like the TTL scheme, but i am a bit concerned about raising
a requirement against a piece of the software (TCP/IP stack), that
may have platform accelerations and not always expose a property like
TTL easily.

It would be easier to decide whether PORT should use this scheme if there
was some widely deployed unicast protocol (over TCP) that has made the
evaluation of all the implications. Especially a protocol that would be
similar to PORT wrt to scalability/security/performance requirements,
router-platform integration and the need for supporting a mode
with and without TTL checking.

What comes to mind in this respect is of course BGP. Aka: TTL checking
for eBGP (which supposedly is usually one-hop), and no
TTL checking for iBGP. Is this required by any IETF spec for BGP ? 

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
Network Agnostic: Applications that work best on cheap, stupid networks.
Suicide: Devaluating the intelligent network with network agnostic apps.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 5 Feb 2011 15:28:41 +0530

RFC 4274 briefly discusses the GTSM [RFC 5082, which supersedes RFC 3682] technique that's commonly used by BGP for its EBGP peers. I think such protection schemes become important as soon as you start moving things over TCP unicast as such packets can be launched from peers located far away from the network. This is especially true when we expect the packets to traverse only one L3 hop (which is the case here).

If you are concerned about the MUST that I had suggested in the original text then you can replace this with a milder MAY and a recommendation that GTSM techniques should be applied here.

Cheers, Manav 

> From: Toerless Eckert [mailto:[email-masked]] 
> Sent: Saturday, February 05, 2011 2.47 PM
> To: Bhatia, Manav (Manav)
> Cc: Yiqun Cai; [email-masked]
> > If it's the MPLS tunnels that you are alluding to then it 
> would still make sense to have the TTL=254 as it'll still be 
> just one hop away for the PIM packet. It's the MPLS TTL 
> that'll get decremented.
> > 
> > Cheers, Manav 
> >

---

From: Stig Venaas <[email-masked]>
Date: Mon, 07 Feb 2011 10:22:23 -0800

I think using the TTL trick should at most be a SHOULD, maybe just a
recommended option. It might be nice if it is implemented and that
operators have a choice.

I have two concerns with making it a MUST.

One is that there could potentially be some uses for PORT between
non-neighbors. I don't have any good ideas now, but I don't want
to preclude that possibility.

Another thing is that the IP addresses used for the PORT
connection may be loopback addresses (or other addresses of
the routers). Hopefully the loopback addresses are announced
on the interfaces facing a PIM neighbor, but there may be cases
where the TCP connection between two neighbors possibly end up
going multiple hops. You could say that is a misconfiguration
though.

I guess also if you use say TCP-AO, then there is no need for
the TTL trick. I will add that to the security considerations
as you suggest.

Stig

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 8 Feb 2011 05:03:35 +0530

Hi Stig,
 
> recommended option. It might be nice if it is implemented and that

I agree.

> on the interfaces facing a PIM neighbor, but there may be cases

Makes sense.

> going multiple hops. You could say that is a misconfiguration

If its going through multiple hops (and it certainly could in some transient network conditions) and if those hops arent doing PIM then all traffic would get blackholed. Even if they support PIM, it will break the protocol, so the TTL hack would actually help here.

> the TTL trick. I will add that to the security considerations

Yes, but the TTL hack is more effective when you don't have TCP-AO as it's a light weight mechanism to prevent someone spoofing PIM packets. You would need it more in the absence of TCP-AO.

Cheers, Manav

---

From: Pekka Savola <[email-masked]>
Date: Tue, 8 Feb 2011 08:19:13 +0200 (EET)

I have not followed this thread but:

I think you're mainly arguing for "could be used between non-direct 
neighbors".  This is a case that already requires manual configuration 
or should require it.  Such configuration could turn off GTSM on the 
system or it could be manually configured off at the same time.

> to preclude that possibility.

Setting TTL=255 when sending does not preclude that. So do we agree it 
MUST be set to 255?  The real question is how normative checking it 
is.  Luckily, if TTL=255 is set when sending, this does not require 
any coordination and can be done on the receipt side only.

> going multiple hops. You could say that is a misconfiguration

Whether or not an IP address is configured on the loopack interface 
does not change the TTL compared to a physical interface address.

> the TTL trick. I will add that to the security considerations

TCP-AO is a poor substitute for the lightweight TTL security provided 
by GTSM. More often than not, TCP-AO is NOT going to be enabled.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 8 Feb 2011 01:49:58 -0800

> does not change the TTL compared to a physical interface address.

Normally, packets sent with a loopback address would get internally
routed and thereby TTL decremented. Does anybody know if BGP for example
tries to still send out to a router with TTL=255 ?

I haven't followed the details, but would we expect mutual autodiscovery
of loopback addresses between PORT peers, eg: via PIM Hello options ?

If use of loopback is something we would like to be able to occur automatically,
and still want to do TTL checking then it would be good if PORT wasn't the
first protocol coming up with this combination. Did i mention that i would
like to see good proof for protocols like BGP successfully doing the
same stuff that's proposed here on the list for TTL checking ? ;-))

Cheers
    Toerless

---

From: Pekka Savola <[email-masked]>
Date: Tue, 8 Feb 2011 12:11:21 +0200 (EET)

> tries to still send out to a router with TTL=255 ?

BGP spec uses TTL=1 for historical reason, only when enabling GTSM 
they get sent with TTL=255.

Typical router implementations don't do an additional TTL decrement 
when using the loopback address, but there could be cornercases when 
this may happen (one I've seen is when a linecard sends TTL exceeded 
messages -- observable with funnies when running 'tracepath' through 
Juniper routers).  You can easily test this by pinging the router's 
loopback IP and a physical IP.  I've yet to see a case where these 
would differ.

Therefore I contest 'normally'.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 8 Feb 2011 17:22:34 +0530

> Therefore I contest 'normally'.

I agree. The implementation has a bug if it decrements the TTL twice when forwarding packets to the loopback IP. 

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 8 Feb 2011 17:25:25 +0530

> same stuff that's proposed here on the list for TTL checking ? ;-))

You don't lose anything by sending packets with TTL=255. Its only at the receiving end that you do the GTSM check. If you are not comfortable with the GTSM check, and I am not sure why, then we could add a milder statement in the draft suggesting that implementations MAY or SHOULD verify that the TTL=254 before accepting the packets on the TCP connection. We could also add text suggesting that implementations could provide a CLI knob to toggle this behavior.

Cheers, Manav

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 8 Feb 2011 03:57:09 -0800

> I agree. The implementation has a bug if it decrements the TTL twice when forwarding packets to the loopback IP. 

I didn't mean the receiver side, i meant the sender side. YOu send 
into  looback not only to get it's address as the source IP address,
but also often to get routing in the sending router to send out the
packet to whatever is currently the best interface. Once you hit routing,
you should decrement TTL and thereby only send with 254.

Of course, you can work around that in routers, but IMHO it's a hack which
is why i was asking if other protocols, eg: BGP do this (eg: in iBGP or the
like).

Cheers
    Toerless

---

From: Pekka Savola <[email-masked]>
Date: Tue, 8 Feb 2011 14:06:58 +0200 (EET)

> you should decrement TTL and thereby only send with 254.

With ping, you can also check the sender side TTL.  I've yet to see a 
difference between a physical and loopback IP -- but maybe there 
exists a device which actually assigns physical IPs on linecards and 
not the central processor and acts differently with this regard.

Just to make it clear, normally when a router originates a packet, it 
does not decrement the TTL as it is not forwarding the packet.

One thing that you did not comment on but which could be possible is 
that both the loopback IP and physical IP are decremented (if the 
control plane and forwarding plane are decoupled very strongly). I 
haven't seen this either, though.

> is why i was asking if other protocols, eg: BGP do this (eg: in iBGP or the

Protocols such as BGP are burdened by their history. Their TTL 
behaviour was designed before TTL=255 checking was invented and for 
backward compatibility reasons cannot change the default behaviour. 
When designing a new protocol, we should look at current models. 
There may be more recent (TCP) protocols on the field that 
successfully employ TTL=255.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 8 Feb 2011 05:18:28 -0800

> You don't lose anything by sending packets with TTL=255. Its only at the receiving end that you do the GTSM check. If you are not comfortable with the GTSM check, and I am not sure why, then we cou…

I am not uncomfortable with the GTSM check. I think my first sentence about
this on the thread was that i do in general like it. 

I would just like to follow established proven solutions from other protocols
if at all possible, that's why i was asking.

>From this discussion there seem to be at least three cases:

 a) directly connected PORT neighbors using interface IP addresses,
    no routing involved.  This is IMHO the same as eBGP, which seems to
    recommend GTSM now in this case. So i think PORT should do the same
    and i do not see a reason why it could not even be a MUST.
 
 b) directly connected PORT neighbors using loopback addresses to deal
    with eg: multiple links with a single PORT connection. It is not
    clear to me whether GTSM would work in this case due to possible
    TTL decrement on the sender side. I wonder if we have existing
    precedence of other protocols for this case. LDP comes to mind, i think
    it also has this case (loopback addresses).
 
 c) non-directly connected PORT neighbors. The GTSM check is not applicable
    in this situation. I am not quite sure what difference it would make to
    MUST/SHOULD a TTL of 255 in this case. I think that the usual TTL
    used in unicast connectsions more like 64 or 128, right ? Eg: Why should
    we NOT want to use whatever the default for TCP connections is ?

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 8 Feb 2011 05:50:59 -0800

> not the central processor and acts differently with this regard.

Can't find a ttl option in ping *sigh*, but at least when trying a
telnet from a routers loopback interface you seem to be right, the ttl
is still 255. Which also answers my other question: 255 seems to also be
a good default now, even for telnet ;-)

> does not decrement the TTL as it is not forwarding the packet.

I guess the question is always how you model a loopback interface.
If you want a packet to be routed then this routing should normally
decrement the TTL. Of course, in this case it's better to not do this,
but i am not sure there is any good definition what must happen when
you use loopback interfaces. Just maybe common practice.

> haven't seen this either, though.

Well, what is very common are PSA modules that are really just
devices internally connected in routers to an internal ethernet. Any
packets from / such modules does of course get TTL decremented by
the router. But logically this is not different from a process
sending/receiving a loopback interface.

Or for example, in IOS we have an internal virtual interface where a feature
acts like a small packet-rewriter. YOu send packets out that
interface, it gets rewritten and then when it's sent back into the router
then of course the TTL gets decremented because it behaves like a real
interface.

The way it looks to me, processes using loopback interfaces just
behave differently and do not decrement the TTL. I really did never
bother in before about this detail. I just sounded like an illogical
expectation to me to rely on this.

> successfully employ TTL=255.

Sure.

Cheers
    Toerless

---

From: Stig Venaas <[email-masked]>
Date: Tue, 08 Feb 2011 06:35:23 -0800

On 08.02.2011 04:06, Pekka Savola wrote:
[...]
> Protocols such as BGP are burdened by their history. Their TTL behaviour
> was designed before TTL=255 checking was invented and for backward
> compatibility reasons cannot change the default behaviour. When
> designing a new protocol, we should look at current models. There may be
> more recent (TCP) protocols on the field that successfully employ TTL=255.

I would certainly be interested to know whether there are other TCP
based protocols doing this. I'm a bit concerned that there may be TCP
implementations where you cannot check TTL when receiving TCP.

Can you do this with a standard socket API? I know you can for
datagrams of course,

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 08 Feb 2011 06:41:06 -0800

> of loopback addresses between PORT peers, eg: via PIM Hello options ?

Yes. PORT allows for using a single TCP connection for multiple
neighborships (if say two routers are neighbors on multiple links).
You would then announce typically a loopback address in the PIM
Hello's to be used for the connection.

I would say loopback mainly because you want the connection to
stay up if any single physical interface goes down.

> If use of loopback is something we would like to be able to occur automatically,

It would probably not be automatic, although the spec doesn't
specify that.

Stig

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 8 Feb 2011 20:23:06 +0530

BFD, defined in RFC5881 is not a TCP based protocol but it uses GTSM. 

RFC 4953 which describes how TCP can be protected against spoofing attacks. It recommends that GTSM should be used.
RFC 5405 describes UDP usage guidelines for designers recommends using GTSM.
RFC 4381 also recommends using GTSM for all supported protocols.
RFC 4732, RFC 4778 recommends GTSM for BGP.

.. the list is endless.

Cheers, Manav

> From: Stig Venaas [mailto:[email-masked]] 
> Sent: Tuesday, February 08, 2011 8.05 PM
> To: Pekka Savola
> Cc: Toerless Eckert; Bhatia, Manav (Manav); Yiqun Cai; [email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 8 Feb 2011 07:04:34 -0800

Are you aware of any implementations that enforce GTSM and not have a knob
to relax the checck - just in case there is a problem on the remote side
which would make the connection fail the GTSM check ?

I still have to see the first level of increased security that's
without problems.

Maybe PORT needs a statement like this:

  The use of unicast transport makes the neighbor security problem
  more difficult than when using link-local-scope multicast.

  ;-)))

CHeers
    Toerless

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 8 Feb 2011 20:46:07 +0530

Most implementations that I am aware of (including ours) have a CLI option that will enforce this check. On our platforms we do it for BGP and LDP. Its not turned on by default and the user has to explicitly turn on this knob.

>   more difficult than when using link-local-scope multicast.

:-)

It actually does since unicast packets can be spoofed easily and can be launched from a host sitting multiple hops away; something that's almost impossible with multicast.

Cheers, Manav

---

From: Eric Rosen <[email-masked]>
Date: Tue, 08 Feb 2011 10:16:41 -0500

Yiqun> Well, we might want to extend PORT to support tunnels or
Yiqun> unidirectional links.  Enforcing TTL=254 on the receiving end will
Yiqun> make it more complicated.

I agree with Yiqun.  Checking that the TTL is 254 would not be a very good
idea.  PORT could potentially  be used in the same way as, e.g., targeted
LDP.  There's also such a thing as multi-hop EBGP.

Manav> If it's the MPLS tunnels that you are alluding to then it would still
Manav> make sense to have the TTL=254 as it'll still be just one hop away
Manav> for the PIM packet. It's the MPLS TTL that'll get decremented.

Not necessarily:

- The control packets don't necessarily travel through the same tunnel that
  the data packets travel through.  In fact, the tunnel could be
  unidirectional (in the direction of the data).

- If the control packets do travel through a tunnel, there is no guarantee
  that the TTL will not be decremented.  In the case of an MPLS tunnel, the
  MPLS TTL is sometimes initialized from the IP TTL on ingress, and the IP
  TTL is sometimes set from the MPLS TTL on egress.

In general, I think these TTL checks are always a bad practice anyway,
because they embed knowledge of the topology into the protocol.  There will
always be a deployment in which this "knowledge" turns out to be false, so
there always needs to be a knob to turn the TTL checks off.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 08 Feb 2011 07:22:58 -0800

> Most implementations that I am aware of (including ours) have a CLI option that will enforce this check. On our platforms we do it for BGP and LDP. Its not turned on by default and the user has to…

So we could perhaps say that implementations SHOULD have a
knob for enabling such a check.

One question then is whether one should always send with
TTL 255 so that it can be enabled unilaterally, or if one
starts sending with TTL 255 when this is enabled.

I'm still wondering if there is a standard API, although
someone told me that FreeBSD can do this.

> It actually does since unicast packets can be spoofed easily and can be launched from a host sitting multiple hops away; something that's almost impossible with multicast.

Agree. And I have thought about having such a check before.

Stig

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 8 Feb 2011 21:02:15 +0530

Eric,
 
> LDP.  There's also such a thing as multi-hop EBGP.

I don't think I understand this. How would the PIM hello message which goes with TTL=1 reach the PIM neighbor which is multiple hops away. If you really want to do this then the PIM hello message should also be changed. 

Are you alluding to a case where two PIM neighbors are the ingress and egress nodes of a P2MP LSP. Even in that case, how would the PIM HELLO message reach the other end, without which a PORT session cannot be established. If the Hello is reaching then it means that the tunnel was treated as a single hop. In that case the Join/Prune will also cover that same hop length.

>   TTL is sometimes set from the MPLS TTL on egress.

I agree to both the points above.

> because they embed knowledge of the topology into the 

We need the PIM hellos to establish the PORT session. PIM hellos imo assume a directly connected link (ttl=1) and there is thus some knowledge of topology embedded in the protocol already.

Cheers, Manav

---

From: Pekka Savola <[email-masked]>
Date: Tue, 8 Feb 2011 17:33:47 +0200 (EET)

On Tue, 8 Feb 2011, Stig Venaas wrote:
>>  Most implementations that I am aware of (including ours) have a CLI option
>>  that will enforce this check. On our platforms we do it for BGP and LDP.
>>  Its not turned on by default and the user has to explicitly turn on this
>>  knob.
>

I'd argue:

MUST send by default to TTL=255
MUST check at receipt by default that TTL=255
SHOULD be configurable to omit the check at receipt or accept a 
different TTL threshold value

Various signalling mechanisms (PIM Hellos or whatever) that would 
configure PORT to be used by non-adjacent neighbors or in 
non-TTL-preserving tunnel scenarios could reconfigure or disable the 
check as part of the procedure.

FWIW, I think there is no standard API for TCP TTL checking in the 
application (e.g. in Linux, IP_RECVTTL is not supported with TCP). 
This needs to be done in the kernel or by filtering.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 08 Feb 2011 10:06:00 -0800

> MUST check at receipt by default that TTL=255

I think this is too strict. But I'm happy to encourage
implementations to support it (more like a SHOULD).

So I think we may agree that this check can be useful. And also
that we should say something about it in the draft. The main issue
is whether it should be required, and whether it should be on by
default.

> check as part of the procedure.

This is not that easy. Well, basically what I think you would have to
do, is to compare the source address of the PIM Hello with the
ConnectionID, and disable the check if they are different. But I would
prefer a single configuration option. I think it's better to require
manual configuration than to have built in "intelligence".

> application (e.g. in Linux, IP_RECVTTL is not supported with TCP). This
> needs to be done in the kernel or by filtering.

Right, was afraid so. This may not be that critical though, but I
was curious. If it is becoming common to do this kind of filtering for
TCP, then it would be good if the IETF pushed for an API, like a
setsockopt() to be standardized.

Stig

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 8 Feb 2011 10:28:27 -0800

> is whether it should be required, and whether it should be on by

Or going to back what i tried to say initially: We shouldn't put in
stronger requirements than what we know exists in unicast protocols.
Admittedly something like BGP with decades of hstory is a bad protocol
to expect having the strongest security requirements, but if there
is so much agreement that GTSM is a MUST then ther should be any other
protocol from the IETF thats newer and that has the "MUST check".
PORT should not be the first one to explore such a MUST.

Cheers
    Toerless

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 8 Feb 2011 13:53:35 -0500

Agree, it should be SHOULD rather than MUST, let's provide means to configure it and if an operator things it is necessary and doesn't break their network, we as a vendor will be more than happy to provide functionality to do so.

+1 Toerless 

Regards,
Jeff  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Toerless Eckert
Sent: Tuesday, February 08, 2011 10:28
To: Stig Venaas
Cc: Yiqun Cai; Pekka Savola; [email-masked]
Subject: Re: [pim] TTL for PORT

Cheers
    Toerless

---

From: Stig Venaas <[email-masked]>
Date: Tue, 08 Feb 2011 11:10:24 -0800

> Agree, it should be SHOULD rather than MUST, let's provide means to configure it and if an operator things it is necessary and doesn't break their network, we as a vendor will be more than happy to…

I have now looked at various RFCs, like:

RFC 3682, RFC 4953, RFC 5405, RFC 4381, RFC 4732, RFC 4778

and none of them say it should be done by default. That is,
3682 says

Use of GTSM is OPTIONAL, and can be configured on a per-peer
(group) basis.
GTSM SHOULD NOT be enabled by default.

Some of the other RFCs are more operational and give
recommendations to operators.

BTW, many operators have other filtering that makes GTSM less
important. As it says in 3682:

    (ii)   It is common practice for many service providers to ingress
           filter (deny) packets that have the provider's loopback
           addresses as the source IP address.

So I'll update the version of the draft I'm just about to post, with
a SHOULD. Something like:

Implementations SHOULD provide a configuration option for enabling
GTSM.

Of course anyone's opinions are welcome and I'll do what seems to
be the WGs opinion.

Stig

---

From: Eric Rosen <[email-masked]>
Date: Tue, 08 Feb 2011 15:46:29 -0500

Manav> How would the PIM hello message which goes with TTL=1 reach the PIM
Manav> neighbor which is multiple hops away. If you really want to do this
Manav> then the PIM hello message should also be changed.

You're right, the Hello mechanism needs some work (or replacement) in order
to facilitate the use of PORT across multiple hops, e.g., using a different
IP destination address.

Pekka> Various signalling mechanisms (PIM Hellos or whatever) that would
Pekka> configure PORT to be used by non-adjacent neighbors or in
Pekka> non-TTL-preserving tunnel scenarios could reconfigure or disable the
Pekka> check as part of the procedure.

Fair enough.

Stig> But I would prefer a single configuration option.

The spec should not require that there be manual configuration, or that the
check apply (or not apply) to all adjacencies.  The proper default for a
given adjacency really depends on how the adjacency is discovered.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 08 Feb 2011 13:06:54 -0800

> given adjacency really depends on how the adjacency is discovered.

I agree. I've now written the following text for the new version of the
draft (I did not include per adjacency, I can try to add that if you
think it is important). But note that unless you want to statically
configure IP addresses of neighbors, it's more per interface than per
adjacency. Other things, like ConnectionID, is also per interface, so
I think that is OK.

    Implementations SHOULD support the Generalized TTL Security
    Mechanism (GTSM) [RFC3682]. We RECOMMEND that it is
    disabled by default. When this mechanism is enabled, TCP/SCTP
    packets are sent with a TTL/Hop-Limit of 255, and a directly
    connected neighbor only accepts inbound packets with a
    TTL/Hop-Limit of 255. For further details, see [RFC3682].

We have a similar problem with TCP encryption (AO/MD5) where you
have to configure the key per interface rather than per adjacency
(unless statically configuring neighors).

Stig

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 9 Feb 2011 04:00:14 +0530

Eric,

> to facilitate the use of PORT across multiple hops, e.g., 

If we envisage PORT to ever work on non directly connected neighbors, like for example two ends of a point-to-multipoint LSP, then the HELLO discovery message should probably use unicast UDP similar to how its done for LDP.

Also multihop PORT connection will only work when there is a tunnel separating the two ends of the PORT neighbors because otherwise the multicast packets will get dropped between these two routers (as they are not aware of the Joins being exchanged between them). 

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 9 Feb 2011 04:26:09 +0530

> and none of them say it should be done by default. That is,

You should actually look at RFC 5082 which is a standards-track RFC as opposed to 3682 which was experimental.
> GTSM SHOULD NOT be enabled by default.

The was done for ensuring backward compatibility for protocols that were developed before GTSM technique became well known. PORT is a new protocol and we need not be that strict about it not turning this on by default.

I have another clarification that I seek. 

Are we in agreement that PORT by default should use the TTL=255? Is there any opposition to that?

Now whats being contended is whether the receivers should verify this TTL or not.

I think it would be ok to say that receiver MAY want to verify the TTL of the incoming PORT message based on GTSM.

> Implementations SHOULD provide a configuration option for enabling

Yes, as long as this means turning on the receiver behavior. We MUST always send PORT messages with TTL=255.

Cheers, Manav

---

From: Pekka Savola <[email-masked]>
Date: Wed, 9 Feb 2011 08:21:16 +0200 (EET)

>    TTL/Hop-Limit of 255. For further details, see [RFC3682].

The very minimum that needs to happen is that by default, packets are 
sent with TTL=255.  This enables the other end to have the choice 
whether to enable it or not. Checking on receipt could be a SHOULD.

Isn't the fact that a peer is receiving a PIM Hello which was sent 
with TTL=1 proof enough that TTL decrement is not happening?  In any 
case, if negotiation or TTL changes are expected, these should be done 
as part of establishing the adjacency.

I suggest rephrasing this:

     TCP/SCTP packets MUST be sent with a TTL/Hop Limit of 255 to
     facilitate enabling of Generalized TTL Security Mechanism
     [RFC5082] by neighbors.

     Directly connected neighbors see the inbound packets with a
     TTL/Hop Limit as 255, and the implementations SHOULD enable GTSM
     check by default on receipt [RFC5082].  Implementations SHOULD
     provide a configuration option to disable the check or change the
     accepted TTL/Hop Limit threshold. This configuration capability
     MAY be used by signalling protocol(s) establishing PORT
     adjacencies to disable the check when required.

> (unless statically configuring neighors).

No, this is absolutely a different thing.

TCP AO always requires manual keying.

GTSM in normal case does not require manual action.  The typical case 
of PIM is an adjacency between direct neighbors (PIM Hello); other 
types of adjacencies are not even supported at the moment.  Manual 
actions are only required in (what appears to me) special 
circumstances.  Therefore it follows that GTSM should be enabled by 
default (because enabling by default is relatevely "safe"), and TCP AO 
cannot (because there is no default keying).

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 9 Feb 2011 00:38:56 -0800

>     check by default on receipt [RFC5082].  Implementations SHOULD
                                 ^
                                 for these neighbors

>     adjacencies to disable the check when required.

This makes it clearer that we should enable by default GTSM only
for directly connected neighbor. The text still doesn't make any
expllicit statements about the defaults for non-directly
connected neighbors, which i think is in-line with the rest of the
PORT spec: We kinda want to be able to support tem, but there are
no specifics.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 9 Feb 2011 11:00:25 +0200 (EET)

>>     check by default on receipt [RFC5082].  Implementations SHOULD
...

> PORT spec: We kinda want to be able to support tem, but there are

You make an interesting point.  The first part of the text I wrote was 
meant as informative only.

Currently there are no non-directly connected neighbors, right?  I 
could be wrong... So it seems a bit odd to prepare for these in the 
spec at this point.

Obviously, non-directly connected neighbors need to disable TTL 
checking, but logically this should happen when this kind of behaviour 
is specified, right?

But if non-directly connected neighbors are already in the spec, I 
agree that the TTL checking at receipt text should address both 
scenarios.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 9 Feb 2011 01:30:30 -0800

>From reading the opinions on this thread it sounds to me the
goal of the document should be:

"We primarily want to be able to create a complete and sufficient
 spec for PORT with directly connected neighbor. This doc is incomplete
 for indirectly connected neighbors, but we foresee that there can
 be later followup drafts that complete the definition for them.
 To help this futures, we do not explicitly discuss the connectedness
 of neighbor in all parts of the document where we do have at least
 the expectation that it can equally apply to non-directly connected
 neighbors, but we specify point out the behavior explicitly only for
 connected neighbors when we do know the behavior would have to be
 different for non-directly connected ones."

That's why i suggested the change in wording.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 9 Feb 2011 15:11:49 +0530

> could be wrong... So it seems a bit odd to prepare for these in the 

When I started reading this draft I too was under the impression that PORT is only for directly connected neighbors as its discovered through PIM HELLOs which go out with TTL=1. However, I am beginning to think that we could use it for non directly connected neighbors as well. Here is the scenario that I have in mind:

A -- <mpls network cloud> -- B

A and B establish a PORT session. This could either be a trigger for creating an LSP between them or we could have an already existing LSP for the data traffic (beyond the scope of this discussion). B sends PORT JOINs to A (which has to go via multiple hops) which results in A sending multicast traffic destined for groups specified in those Joins over the LSP that has been established (or was pre-established). In this case the intermediate routers need not be aware of the Joins as they don't switch the multicast traffic and only route it based on the outer MPLS labels.

Specifying GTSM behavior in such cases may be a trifle difficult as we may not know the exact hops between A and B.

> checking, but logically this should happen when this kind of 

I think we should not preclude the possibility of the above happening, in which case we might have to be a little lenient in the receiver behavior.

> agree that the TTL checking at receipt text should address both 

I don't think the current draft is explicit on this. However, if the above scenario is possible (and it certainly is) then we must address that in the current draft. It would also be good if we could extend the PIM PORT discovery to work with neighbors that are multiple hops away.

Cheers, Manav

---

From: Stig Venaas <[email-masked]>
Date: Wed, 09 Feb 2011 09:37:29 -0800

> PORT spec: We kinda want to be able to support tem, but there are

I am fine with a MUST for sending. But I'm not so happy about
enabling the receiver check by default.

My main concern is that you may have a topology like this:

                    A --- B
                      \ /
                       C
where A and B are neighbors, and using say loopback addresses
for ConnectionIDs so that the TCP connection between A and B
end-point addresses are those loopbacks.

It may then be that the TCP connection goes via C. This may
happen in two cases.

1. If by accident the loopback is not advertised in the IGP
    on the link A-B, or there could be static routes where
    one is missing for the loopback for one of the routers.
    You may say this is a configuration mistake, but it would
    then make the TCP connection fail.

2. If the link between A and B goes down, the TCP connection
    would still be up. Let's say there is just a brief flap
    of the link, it is then better to keep the connection up,
    than to tear it down, create a new one, and have to do a
    full update. Also, if the link stays down for some time,
    keeping the connection allow prunes to be sent and remove
    state.

Also, there are cases where GTSM would not buy you much.

For IPv6 you would normally use link-local addresses (if just
using PORT between neighbors). Which means the packets can't
arrive from off-link.

Also, if used between routers in say a core network, there
would typically be filters at the edge discarding packets
coming from the outside with internal addresses as source,
and also filters limiting who can send packets addressed to
the routers.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 09 Feb 2011 13:00:03 -0800

On 2/9/2011 1:41 AM, Bhatia, Manav (Manav) wrote:
> A --<mpls network cloud>  -- B
>

Yes, I have been thinking of some such things too. Nothing too
specific at the moment, but I see some potential uses like this
for PORT. And you don't necessarily need Hello's to initiate a PORT
connection.

Stig

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Feb 2011 09:30:53 +0200 (EET)

...
>    keeping the connection allow prunes to be sent and remove

Good that we agree with MUST TTL=255 when sending.

Your point 2 is convincing to me operationally when PIM is run 
internally in a domain.

The big question here, however, is how ConnectionIDs are chosen.

In internal domains (compare to iBGP), GTSM is not strictly necessary 
and could cause issues like you describe upon rerouting if loopback 
ConnectionIDs are used. Further, simple security can already be 
implemented by having ACLs at border devices.

I'd strongly argue in favor of using interface addresses for external 
PIM sessions (compare to eBGP), because there ACLs won't help (that 
much) to protect from spoofing the neighbor.  In these kinds of setups 
using non-loopback ConnectionIDs is usually a good idea.  Even if 
loopback ConnectionIDs are used (e.g. for L3 loadbalancing two links 
between two routers), the TTL is still 255.

So, the question becomes whether the scenario where PORT is used can 
be identified and how ConnectionIDs are chosen.  Is this done 
automatically?  Are we going to expect something similar to i/eBGP 
configuration.

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 10 Feb 2011 12:34:53 -0500

Hi,
Pekka - would you prefer per peer (configurable) connectionID rather than "router pim" global one?

Regards,
Jeff

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Feb 2011 19:49:50 +0200 (EET)

> Pekka - would you prefer per peer (configurable) connectionID rather than "router pim" global one?

Yes, I'd think that would likely make sense when interfacing external 
PIM domains.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 10 Feb 2011 10:33:32 -0800

> Yes, I'd think that would likely make sense when interfacing external

The way I think it should be implemented is basically that you on
a router interface may configure something like:

ip pim sparse-mode
ip pim port

That would enable PORT on the interface and use the primary
IP address (the one used as source for PIM Hello's, link-local
for IPv6) as the Connection-ID. This is the address announced
as the ConnectionID in Hellos sent on this interface.

With this default you won't do connection sharing.

However, you might configure something like

ip pim sparse-mode
ip pim port connection-id Loopback0

Which means that in the PIM Hellos on this interface we
will now use the IP address of Loopback0 as the ConnnectionID.

You would then probably want to do something similar on the
neighbor.

If the two routers have two neighborships, then you could
configure the same on both interfaces on both routers to
get connection sharing.

All this would be per interface. As you say, you might
want to use your loopback on internal interfaces, but
just use the primary interface address for an external
connection.

You could perhaps try to come up with heuristics for
when to apply GTSM, but I would prefer it to be off by
default, and that you have to configure say:

ip pim port ttl-limit 253
or
ip pim port max-hops 2

on the interface. Maybe something slightly simpler
for the common case of 255 (0 hops).

Anyway, these are just examples and as long as we
have interoperability, we should allow implementations
flexibility for how to do this. We agree that it at
least SHOULD be possible to use GTSM. My only concern
is to do the receiver check by default.

Stig

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 10 Feb 2011 14:25:49 -0500

IMHO it should be a bit different:
most implementations out there configure pim in a separate "router pim" stanza and then have interfaces within  + pim  is mostly used within an AS with a common IGP.
I'd propose to have pim global connectionID similar to router-id configuration for IGPs and use it as default connectionID which could then be overwritten under interface

Regards,
Jeff

---

From: Stig Venaas <[email-masked]>
Date: Thu, 10 Feb 2011 11:30:04 -0800

> I'd propose to have pim global connectionID similar to router-id configuration for IGPs and use it as default connectionID which could then be overwritten under interface

OK, that makes sense. Anyway, we don't want to specify this in any way
IMO. Although I think we agree that interface specific config should
be possible.

Stig

> Regards